Re: [PATCH] arm: Zero/Sign extends for CMSE security on Armv8-M.baseline
Hi Torbjörn!
On Thu, 6 Jun 2024 at 18:47, Torbjörn SVENSSON
wrote:
>
> I would like to push this patch to the following branches:
>
> - releases/gcc-11
> - releases/gcc-12
> - releases/gcc-13
> - releases/gcc-14
> - trunk
>
> Ok?
>
> The problem was highlighted by https://linaro.atlassian.net/browse/GNU-1239
>
> --
>
> Properly handle zero and sign extension for Armv8-M.baseline as
> Cortex-M23 can have the security extension active.
> Currently, there is a internal compiler error on Cortex-M23 for the
> epilog processing of sign extension.
>
> This patch addresses the following CVE-2024-0151 for Armv8-M.baseline.
>
> gcc/ChangeLog:
>
> * config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear):
> Sign extend for Thumb1.
> (thumb1_expand_prologue): Add zero/sign extend.
Quick nitpicking: I think the ICE you are fixing was reported as
https://linaro.atlassian.net/browse/GNU-1205
(GNU-1239 is about your test improvements failing too, in addition to
the existing ones)
and your patch is actually about fixing GCC bug report 115253.
So your commit title should end with "[PR115253]" (or maybe "PR target/115253")
and your ChangeLog should also contain "PR target/115253".
You can use contrib/git_check_commit.py to check your patch is
correctly formatted (otherwise it will be rejected by the commit hooks
anyway).
I haven't looked into the details of the patch yet :-)
Thanks for looking at this,
Christophe
>
> Signed-off-by: Torbjörn SVENSSON
> Co-authored-by: Yvan ROUX
> ---
> gcc/config/arm/arm.cc | 68 ++-
> 1 file changed, 60 insertions(+), 8 deletions(-)
>
> diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
> index ea0c963a4d6..077cb61f42a 100644
> --- a/gcc/config/arm/arm.cc
> +++ b/gcc/config/arm/arm.cc
> @@ -19220,17 +19220,23 @@ cmse_nonsecure_call_inline_register_clear (void)
> || TREE_CODE (ret_type) == BOOLEAN_TYPE)
> && known_lt (GET_MODE_SIZE (TYPE_MODE (ret_type)), 4))
> {
> - machine_mode ret_mode = TYPE_MODE (ret_type);
> + rtx ret_mode = gen_rtx_REG (TYPE_MODE (ret_type), R0_REGNUM);
> + rtx si_mode = gen_rtx_REG (SImode, R0_REGNUM);
> rtx extend;
> if (TYPE_UNSIGNED (ret_type))
> - extend = gen_rtx_ZERO_EXTEND (SImode,
> - gen_rtx_REG (ret_mode,
> R0_REGNUM));
> + extend = gen_rtx_SET (si_mode, gen_rtx_ZERO_EXTEND (SImode,
> +
> ret_mode));
> + else if (TARGET_THUMB1)
> + {
> + if (known_lt (GET_MODE_SIZE (TYPE_MODE (ret_type)), 2))
> + extend = gen_thumb1_extendqisi2 (si_mode, ret_mode);
> + else
> + extend = gen_thumb1_extendhisi2 (si_mode, ret_mode);
> + }
> else
> - extend = gen_rtx_SIGN_EXTEND (SImode,
> - gen_rtx_REG (ret_mode,
> R0_REGNUM));
> - emit_insn_after (gen_rtx_SET (gen_rtx_REG (SImode, R0_REGNUM),
> -extend), insn);
> -
> + extend = gen_rtx_SET (si_mode, gen_rtx_SIGN_EXTEND (SImode,
> +
> ret_mode));
> + emit_insn_after (extend, insn);
> }
>
>
> @@ -27250,6 +27256,52 @@ thumb1_expand_prologue (void)
>live_regs_mask = offsets->saved_regs_mask;
>lr_needs_saving = live_regs_mask & (1 << LR_REGNUM);
>
> + /* The AAPCS requires the callee to widen integral types narrower
> + than 32 bits to the full width of the register; but when handling
> + calls to non-secure space, we cannot trust the callee to have
> + correctly done so. So forcibly re-widen the result here. */
> + if (IS_CMSE_ENTRY (func_type))
> +{
> + function_args_iterator args_iter;
> + CUMULATIVE_ARGS args_so_far_v;
> + cumulative_args_t args_so_far;
> + bool first_param = true;
> + tree arg_type;
> + tree fndecl = current_function_decl;
> + tree fntype = TREE_TYPE (fndecl);
> + arm_init_cumulative_args (_so_far_v, fntype, NULL_RTX, fndecl);
> + args_so_far = pack_cumulative_args (_so_far_v);
> + FOREACH_FUNCTION_ARGS (fntype, arg_type, args_iter)
> + {
> + rtx arg_rtx;
> +
> + if (VOID_TYPE_P (arg_type))
> + break;
> +
> + function_arg_info arg (arg_type, /*named=*/true);
> + if (!first_param)
> + /* We should advance after processing the argument and pass
> + the argument we're advancing past. */
> + arm_function_arg_advance (args_so_far, arg);
> + first_param = false;
> + arg_rtx = arm_function_arg (args_so_far, arg);
> + gcc_assert (REG_P (arg_rtx));
> + if ((TREE_CODE
Re: [PATCH] Arm: Fix disassembly error in Thumb-1 relaxed load/store [PR115188]
Hi Wilco,
On 6/3/24 15:42, Wilco Dijkstra wrote:
A Thumb-1 memory operand allows single-register LDMIA/STMIA. This doesn't get
printed as LDR/STR with writeback in unified syntax, resulting in strange
assembler errors if writeback is selected. To work around this, use the 'Uw'
constraint that blocks writeback.
Passes bootstrap & regress, OK for commit?
gcc:
PR target/115153
I guess this is typo (should be 115188) ?
* config/arm/sync.md (arm_atomic_load): Use 'Uw' constraint.
(arm_atomic_store): Likewise.
gcc/testsuite:
PR target/115188
* gcc.target/arm/pr115188.c: Add new test.
---
diff --git a/gcc/config/arm/sync.md b/gcc/config/arm/sync.md
index
df8dbe170cacb6b60d56a6f19aadd5a6c9c51f7a..e856ee51d9ae7b945c4d1e9d1f08afeedc95707a
100644
--- a/gcc/config/arm/sync.md
+++ b/gcc/config/arm/sync.md
@@ -65,7 +65,7 @@
(define_insn "arm_atomic_load"
[(set (match_operand:QHSI 0 "register_operand" "=r,l")
(unspec_volatile:QHSI
- [(match_operand:QHSI 1 "memory_operand" "m,m")]
+ [(match_operand:QHSI 1 "memory_operand" "m,Uw")]
VUNSPEC_LDR))]
""
"ldr\t%0, %1"
@@ -81,7 +81,7 @@
)
(define_insn "arm_atomic_store"
- [(set (match_operand:QHSI 0 "memory_operand" "=m,m")
+ [(set (match_operand:QHSI 0 "memory_operand" "=m,Uw")
(unspec_volatile:QHSI
[(match_operand:QHSI 1 "register_operand" "r,l")]
VUNSPEC_STR))]
diff --git a/gcc/testsuite/gcc.target/arm/pr115188.c
b/gcc/testsuite/gcc.target/arm/pr115188.c
new file mode 100644
index
..ef40d7732b77936c845707989465a01ecca5adb0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/pr115188.c
@@ -0,0 +1,10 @@
+/* { dg-do assemble } */
+/* { dg-require-effective-target arm_arch_v6m_ok }
+/* { dg-options "-O2 -mthumb" } */-mthumb is included in arm_arch_v6m, so I think you don't need to add it
here?
Thanks,
Christophe
+/* { dg-add-options arm_arch_v6m } */
+
+void init (int *p, int n)
+{
+ for (int i = 0; i < n; i++)
+__atomic_store_4 (p + i, 0, __ATOMIC_RELAXED);
+}
Re: [Linaro-TCWG-CI] gcc-15-168-g21e7aa5f3ea: FAIL: 6 regressions on aarch64
Hi Harald, On Mon, 6 May 2024 at 21:02, wrote: > > Dear contributor, our automatic CI has detected problems related to your > patch(es). Please find some details below. If you have any questions, > please follow up on linaro-toolch...@lists.linaro.org mailing list, Libera's > #linaro-tcwg channel, or ping your favourite Linaro toolchain developer on > the usual project channel. > > We appreciate that it might be difficult to find the necessary logs or > reproduce the issue locally. If you can't get what you need from our CI > within minutes, let us know and we will be happy to help. > > We track this report status in https://linaro.atlassian.net/browse/GNU-1214 , > please let us know if you are looking at the problem and/or when you have a > fix. > > In master-aarch64 after: > > | commit gcc-15-168-g21e7aa5f3ea > | Author: Harald Anlauf > | Date: Mon Apr 29 19:52:52 2024 +0200 > | > | Fortran: fix issues with class(*) assignment [PR114827] > | > | gcc/fortran/ChangeLog: > | > | PR fortran/114827 > | * trans-array.cc (gfc_alloc_allocatable_for_assignment): Take > into > | account _len of unlimited polymorphic entities when > calculating > | ... 9 lines of the commit log omitted. > > FAIL: 6 regressions > > regressions.sum: > === gfortran tests === > > Running gfortran:gfortran.dg/asan/asan.exp ... > FAIL: gfortran.dg/asan/unlimited_polymorphic_34.f90 -fsanitize=address -O0 > execution test > FAIL: gfortran.dg/asan/unlimited_polymorphic_34.f90 -fsanitize=address -O1 > execution test > FAIL: gfortran.dg/asan/unlimited_polymorphic_34.f90 -fsanitize=address -O2 > execution test > FAIL: gfortran.dg/asan/unlimited_polymorphic_34.f90 -fsanitize=address -O3 > -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions > execution test > FAIL: gfortran.dg/asan/unlimited_polymorphic_34.f90 -fsanitize=address -O3 > -g execution test > FAIL: gfortran.dg/asan/unlimited_polymorphic_34.f90 -fsanitize=address -Os > execution test > > > You can find the failure logs in *.log.1.xz files in > - > https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-aarch64-build/1426/artifact/artifacts/00-sumfiles/ > The full lists of regressions and progressions as well as configure and make > commands are in > - > https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-aarch64-build/1426/artifact/artifacts/notify/ > The list of [ignored] baseline and flaky failures are in > - > https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-aarch64-build/1426/artifact/artifacts/sumfiles/xfails.xfail > > The configuration of this build is: > CI config tcwg_gnu_cross_check_gcc master-aarch64 Sorry for the delay in coming back to you regarding this notification. You can consider this as a false alarm, caused by the fact that the above configurations use QEMU, which is not (currently) compatible with LSAN (which is enabled by ASAN). We are working on a fix in our testing framework to avoid such issues in the future. Thanks, Christophe > > -8<--8<--8<-- > The information below can be used to reproduce a debug environment: > > Current build : > https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-aarch64-build/1426/artifact/artifacts > Reference build : > https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-aarch64-build/1425/artifact/artifacts > > Reproduce last good and first bad builds: > https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sha1/21e7aa5f3ea44ca2fef8deb8788edffc04901b5c/tcwg_gnu_cross_check_gcc/master-aarch64/reproduction_instructions.txt > > Full commit : > https://github.com/gcc-mirror/gcc/commit/21e7aa5f3ea44ca2fef8deb8788edffc04901b5c > > List of configurations that regressed due to this commit : > * tcwg_gnu_cross_check_gcc > ** master-aarch64 > *** FAIL: 6 regressions > *** > https://git-us.linaro.org/toolchain/ci/interesting-commits.git/plain/gcc/sha1/21e7aa5f3ea44ca2fef8deb8788edffc04901b5c/tcwg_gnu_cross_check_gcc/master-aarch64/details.txt > *** > https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-aarch64-build/1426/artifact/artifacts
Re: [PATCH] wwwdocs: contribute.html: Update consensus on patch content.
On Mon, 20 May 2024 at 15:23, Nick Clifton wrote: > > Hi Christophe, > > > I have a follow-up one: I think the same applies to binutils, but I > > don't think any maintainer / contributor expressed an opinion, and > > IIUC patch policy for binutils is (lightly) documented at > > https://sourceware.org/binutils/wiki/HowToContribute > > Maybe Nick can update it? > > Done. Thanks! > > > (I don't have such rights) > > Would you like them ? It is easy enough to set up. > No need to bother :-) Christophe > Cheers >Nick > >
Re: [PATCH] [testsuite] conditionalize dg-additional-sources on target and type
Hi Alexandre,
On Thu, 23 May 2024 at 15:29, Alexandre Oliva wrote:
>
> On Apr 30, 2024, Christophe Lyon wrote:
>
> > On Tue, 30 Apr 2024 at 01:31, Alexandre Oliva wrote:
> >> >> for gcc/testsuite/ChangeLog
> >> >>
> >> >> * lib/target-supports.exp (check_vect_support_and_set_flags):
> >> >> Decay to link rather than compile.
> >>
> >> Alas, linking may fail because of an incompatible libc, as reported by
> >> Linaro with a link to their issue GNU-1206 (I'm not posting the link to
> >> the fully-Javascrippled Jira web page; it shows nothing useful, and I
> >> can't post feedback there) and to
> >> https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m7_hard_eabi-build/10/artifact/artifacts/00-sumfiles/
> >> (where I could get useful information)
> >>
> >> I'm reverting the patch, and I'll see about some alternate approach
>
> > Indeed, that's another instance of the tricky multilibs configuration
> > issues.
>
> > - we run the tests with
> > qemu/-mthumb/-march=armv7e-m+fp.dp/-mtune=cortex-m7/-mfloat-abi=hard/-mfpu=auto
> > which matches the GCC configuration flags,
> > but the vect.exp tests add -mfpu=neon -mfloat-abi=softfp -march=armv7-a
> > and link fails because the toolchain does not support softfp libs
>
> Hello, Christophe, thanks for the info.
>
> I came up with an entirely different approach:
>
>
> g++.dg/vect/pr95401.cc has dg-additional-sources, and that fails when
> check_vect_support_and_set_flags finds vector support lacking for
> execution tests: tests decay to compile tests, and additional sources
> are rejected by the compiler when compiling to a named output file.
>
> At first I considered using some effective target to conditionalize
> the additional sources. There was no support for target-specific
> additional sources, so I added that.
>
> But then, I found that adding an effective target to check whether the
> test involves linking would just make for busy work in this case, and
> so I went ahead and adjusted the handling of additional sources to
> refrain from adding them on compile tests, reporting them as
> unsupported.
>
> That solves the problem without using the newly-added machinery for
> per-target additional sources, but I figured since I'd implemented it
> I might as well contribute it, since there might be other uses for it.
Thanks for improving this, LGTM at quick glance, but I can't approve :-)
Christophe
>
> Regstrapped on x86_64-linux-gnu. Also tested on ppc64-vx7r2 with
> gcc-13. Ok to install?
>
>
> for gcc/ChangeLog
>
> * doc/sourcebuild.texi (dg-additional-sources): Document
> newly-added support for target selectors, and implicit discard
> on non-linking tests that name the compiler output explicitly.
>
> for gcc/testsuite/ChangeLog
>
> * lib/gcc-defs.exp (dg-additional-sources): Support target
> selectors. Make it cumulative.
> (dg-additional-files-options): Take dest and type. Note
> unsupported additional sources when not linking and naming the
> compiler output. Adjust source dirname prepending to cope
> with leading blanks.
> * lib/g++.exp (g++_target_compile): Pass dest and type on to
> dg-additional-files-options.
> * lib/gcc.exp (gcc_target_compile): Likewise.
> * lib/gdc.exp (gdb_target_compile): Likewise.
> * lib/gfortran.exp (gfortran_target_compile): Likewise.
> * lib/go.exp (go_target_compile): Likewise.
> * lib/obj-c++.exp (obj-c++_target_compile): Likewise.
> * lib/objc.exp (objc_target_compile): Likewise.
> * lib/rust.exp (rust_target_compile): Likewise.
> * lib/profopt.exp (profopt-execute): Likewise-ish.
> ---
> gcc/doc/sourcebuild.texi |8 +++-
> gcc/testsuite/lib/g++.exp |2 +-
> gcc/testsuite/lib/gcc-defs.exp | 35 ++-
> gcc/testsuite/lib/gcc.exp |2 +-
> gcc/testsuite/lib/gdc.exp |2 +-
> gcc/testsuite/lib/gfortran.exp |2 +-
> gcc/testsuite/lib/go.exp |2 +-
> gcc/testsuite/lib/obj-c++.exp |2 +-
> gcc/testsuite/lib/objc.exp |2 +-
> gcc/testsuite/lib/profopt.exp |2 +-
> gcc/testsuite/lib/rust.exp |2 +-
> 11 files changed, 46 insertions(+), 15 deletions(-)
>
> diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
> index 8e4e59ac44c74..e997dbec3334b 100644
> --- a/gcc/doc/sourcebuild.texi
> +++ b/gcc/doc/sourcebuild.texi
> @@ -1320,9 +1320,15 @@ to @var{var_value} before execution of the program
> created by the test
Re: [COMMITTED] Regenerate cygming.opt.urls and mingw.opt.urls
Thank you Mark and sorry for missing this during the reviews.
Christophe
Le dim. 12 mai 2024, 14:54, Mark Wielaard a écrit :
> The new cygming.opt.urls and mingw.opt.urls in the
> gcc/config/mingw/cygming.opt.urls directory need to generated by make
> regenerate-opt-urls in the gcc subdirectory. They still contained
> references to the gcc/config/i386 directory from which they were
> copied.
>
> Fixes: 1f05dfc131c7 ("Reuse MinGW from i386 for AArch64")
> Fixes: e8d003736e6c ("Rename "x86 Windows Options" to "Cygwin and MinGW
> Options"")
>
> gcc/ChangeLog:
>
> * config/mingw/cygming.opt.urls: Regenerate.
> * config/mingw/mingw.opt.urls: Likewise.
> ---
> gcc/config/mingw/cygming.opt.urls | 7 +++
> gcc/config/mingw/mingw.opt.urls | 2 +-
> 2 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/gcc/config/mingw/cygming.opt.urls
> b/gcc/config/mingw/cygming.opt.urls
> index c624e22e4427..af11c4997609 100644
> --- a/gcc/config/mingw/cygming.opt.urls
> +++ b/gcc/config/mingw/cygming.opt.urls
> @@ -1,4 +1,4 @@
> -; Autogenerated by regenerate-opt-urls.py from
> gcc/config/i386/cygming.opt and generated HTML
> +; Autogenerated by regenerate-opt-urls.py from
> gcc/config/mingw/cygming.opt and generated HTML
>
> mconsole
> UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mconsole)
> @@ -9,9 +9,8 @@ UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mdll)
> mnop-fun-dllimport
> UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mnop-fun-dllimport)
>
> -; skipping UrlSuffix for 'mthreads' due to multiple URLs:
> -; duplicate: 'gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1'
> -; duplicate: 'gcc/x86-Options.html#index-mthreads'
> +mthreads
> +UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1)
>
> mwin32
> UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mwin32)
> diff --git a/gcc/config/mingw/mingw.opt.urls
> b/gcc/config/mingw/mingw.opt.urls
> index f8ee5be6a535..40fb086606b2 100644
> --- a/gcc/config/mingw/mingw.opt.urls
> +++ b/gcc/config/mingw/mingw.opt.urls
> @@ -1,4 +1,4 @@
> -; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/mingw.opt
> and generated HTML
> +; Autogenerated by regenerate-opt-urls.py from gcc/config/mingw/mingw.opt
> and generated HTML
>
> mcrtdll=
> UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mcrtdll)
> --
> 2.39.3
>
>
[PATCH v2] arm: [MVE intrinsics] Fix support for predicate constants [PR target/114801]
In this PR, we have to handle a case where MVE predicates are supplied
as a const_int, where individual predicates have illegal boolean
values (such as 0xc for a 4-bit boolean predicate). To avoid the ICE,
we hide the constant behind an unspec.
On MVE V8BI and V4BI multi-bit masks are interpreted byte-by-byte at
instruction level, see
https://developer.arm.com/documentation/101028/0012/14--M-profile-Vector-Extension--MVE--intrinsics.
This is a workaround until we change such predicates representation to
V16BImode.
2024-05-06 Christophe Lyon
Jakub Jelinek
PR target/114801
gcc/
* config/arm/arm-mve-builtins.cc
(function_expander::add_input_operand): Handle CONST_INT
predicates.
* mve.md (set_mve_const_pred): New pattern.
* unspec.md (MVE_PRED): New unspec.
gcc/testsuite/
* gcc.target/arm/mve/pr114801.c: New test.
---
gcc/config/arm/arm-mve-builtins.cc | 27 ++-
gcc/config/arm/mve.md | 12 +++
gcc/config/arm/unspecs.md | 1 +
gcc/testsuite/gcc.target/arm/mve/pr114801.c | 37 +
4 files changed, 76 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/arm/mve/pr114801.c
diff --git a/gcc/config/arm/arm-mve-builtins.cc
b/gcc/config/arm/arm-mve-builtins.cc
index 6a5775c67e5..7d5af649857 100644
--- a/gcc/config/arm/arm-mve-builtins.cc
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -2205,7 +2205,32 @@ function_expander::add_input_operand (insn_code icode,
rtx x)
mode = GET_MODE (x);
}
else if (VALID_MVE_PRED_MODE (mode))
-x = gen_lowpart (mode, x);
+{
+ if (CONST_INT_P (x) && (mode == V8BImode || mode == V4BImode))
+ {
+ /* In V8BI or V4BI each element has 2 or 4 bits, if those
+bits aren't all the same, gen_lowpart might ICE. Hide
+the move behind an unspec to avoid this.
+V8BI and V4BI multi-bit masks are interpreted
+byte-by-byte at instruction level, see
+
https://developer.arm.com/documentation/101028/0012/14--M-profile-Vector-Extension--MVE--intrinsics.
*/
+ unsigned HOST_WIDE_INT xi = UINTVAL (x);
+ if ((xi & 0x) != ((xi >> 1) & 0x)
+ || (mode == V4BImode
+ && (xi & 0x) != ((xi >> 2) & 0x)))
+ {
+ rtx unspec_x;
+ unspec_x = gen_rtx_UNSPEC (HImode, gen_rtvec (1, x), MVE_PRED);
+ x = force_reg (HImode, unspec_x);
+ }
+
+ }
+ else if (SUBREG_P (x))
+ /* gen_lowpart on a SUBREG can ICE. */
+ x = force_reg (GET_MODE (x), x);
+
+ x = gen_lowpart (mode, x);
+}
m_ops.safe_grow (m_ops.length () + 1, true);
create_input_operand (_ops.last (), x, mode);
diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index 35916f62604..d337422d695 100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -6621,3 +6621,15 @@ (define_expand "@arm_mve_reinterpret"
}
}
)
+
+;; Hide predicate constants from optimizers
+(define_insn "set_mve_const_pred"
+ [(set
+ (match_operand:HI 0 "s_register_operand" "=r")
+ (unspec:HI [(match_operand:HI 1 "general_operand" "n")] MVE_PRED))]
+ "TARGET_HAVE_MVE"
+{
+return "movw%?\t%0, %L1\t%@ set_mve_const_pred";
+}
+ [(set_attr "type" "mov_imm")]
+)
diff --git a/gcc/config/arm/unspecs.md b/gcc/config/arm/unspecs.md
index 4713ec840ab..336f2fe08e6 100644
--- a/gcc/config/arm/unspecs.md
+++ b/gcc/config/arm/unspecs.md
@@ -1256,4 +1256,5 @@ (define_c_enum "unspec" [
SQRSHRL_48
VSHLCQ_M_
REINTERPRET
+ MVE_PRED
])
diff --git a/gcc/testsuite/gcc.target/arm/mve/pr114801.c
b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
new file mode 100644
index 000..fb3e4d855f9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
@@ -0,0 +1,37 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-options "-O2" } */
+/* { dg-add-options arm_v8_1m_mve } */
+/* { dg-final { check-function-bodies "**" "" "" } } */
+
+#include
+
+/*
+** test_32:
+**...
+** movwr[0-9]+, 52428 @ set_mve_const_pred
+**...
+*/
+uint32x4_t test_32() {
+ return vdupq_m_n_u32(vdupq_n_u32(0x), 0, 0x);
+}
+
+/*
+** test_16:
+**...
+** movwr[0-9]+, 6927 @ set_mve_const_pred
+**...
+*/
+uint16x8_t test_16() {
+ return vdupq_m_n_u16(vdupq_n_u16(0x), 0, 0x1b0f);
+}
+
+/*
+** test_8:
+**...
+** mov r[0-9]+, #23055 @ movhi
+**...
+*/
+uint8x16_t test_8() {
+ return vdupq_m_n_u8(vdupq_n_u8(0xff), 0, 0x5a0f);
+}
--
2.34.1
Re: [PATCH v3 00/12] Add aarch64-w64-mingw32 target
Hi,
I've just pushed this patch series, congratulations!
Thanks,
Christophe
On Thu, 11 Apr 2024 at 15:40, Evgeny Karpov wrote:
>
> Hello,
>
> Thank you for reviewing v2!
> v3 addresses all comments on v2.
>
> v3 Changes:
> - Exclude the aarch64_calling_abi declaration from the patch series.
> - Refactor x18 adjustment for MS ABI.
> - Remove unnecessary headers.
> - Add an extra comment to explain empty definitions.
> - Use gcc_unreachable for definitions that are needed for compilation,
> but not used by the aarch64-w64-mingw32 target.
> - Retain old index entries.
> - Rebase from 11th April 2024
>
> Regards,
> Evgeny
>
>
> Zac Walker (12):
> Introduce aarch64-w64-mingw32 target
> aarch64: Mark x18 register as a fixed register for MS ABI
> aarch64: Add aarch64-w64-mingw32 COFF
> Reuse MinGW from i386 for AArch64
> Rename section and encoding functions from i386 which will be used in
> aarch64
> Exclude i386 functionality from aarch64 build
> aarch64: Add Cygwin and MinGW environments for AArch64
> aarch64: Add SEH to machine_function
> Rename "x86 Windows Options" to "Cygwin and MinGW Options"
> aarch64: Build and add objects for Cygwin and MinGW for AArch64
> aarch64: Add aarch64-w64-mingw32 target to libatomic
> Add aarch64-w64-mingw32 target to libgcc
>
> fixincludes/mkfixinc.sh | 3 +-
> gcc/config.gcc| 47 +++--
> gcc/config/aarch64/aarch64-abi-ms.h | 34
> gcc/config/aarch64/aarch64-coff.h | 91 +
> gcc/config/aarch64/aarch64-protos.h | 5 +
> gcc/config/aarch64/aarch64.h | 13 +-
> gcc/config/aarch64/cygming.h | 172 ++
> gcc/config/i386/cygming.h | 18 +-
> gcc/config/i386/cygming.opt.urls | 30 ---
> gcc/config/i386/i386-protos.h | 12 +-
> gcc/config/i386/mingw-w64.opt.urls| 2 +-
> gcc/config/lynx.opt.urls | 2 +-
> gcc/config/{i386 => mingw}/cygming.opt| 0
> gcc/config/mingw/cygming.opt.urls | 30 +++
> gcc/config/{i386 => mingw}/cygwin-d.cc| 0
> gcc/config/{i386 => mingw}/mingw-stdint.h | 9 +-
> gcc/config/{i386 => mingw}/mingw.opt | 0
> gcc/config/{i386 => mingw}/mingw.opt.urls | 2 +-
> gcc/config/{i386 => mingw}/mingw32.h | 4 +-
> gcc/config/{i386 => mingw}/msformat-c.cc | 0
> gcc/config/{i386 => mingw}/t-cygming | 23 ++-
> gcc/config/{i386 => mingw}/winnt-cxx.cc | 0
> gcc/config/{i386 => mingw}/winnt-d.cc | 0
> gcc/config/{i386 => mingw}/winnt-stubs.cc | 0
> gcc/config/{i386 => mingw}/winnt.cc | 30 +--
> gcc/doc/invoke.texi | 10 +
> gcc/varasm.cc | 2 +-
> libatomic/configure.tgt | 2 +-
> libgcc/config.host| 23 ++-
> libgcc/config/aarch64/t-no-eh | 2 +
> libgcc/config/{i386 => mingw}/t-gthr-win32| 0
> libgcc/config/{i386 => mingw}/t-mingw-pthread | 0
> 32 files changed, 473 insertions(+), 93 deletions(-)
> create mode 100644 gcc/config/aarch64/aarch64-abi-ms.h
> create mode 100644 gcc/config/aarch64/aarch64-coff.h
> create mode 100644 gcc/config/aarch64/cygming.h
> delete mode 100644 gcc/config/i386/cygming.opt.urls
> rename gcc/config/{i386 => mingw}/cygming.opt (100%)
> create mode 100644 gcc/config/mingw/cygming.opt.urls
> rename gcc/config/{i386 => mingw}/cygwin-d.cc (100%)
> rename gcc/config/{i386 => mingw}/mingw-stdint.h (86%)
> rename gcc/config/{i386 => mingw}/mingw.opt (100%)
> rename gcc/config/{i386 => mingw}/mingw.opt.urls (86%)
> rename gcc/config/{i386 => mingw}/mingw32.h (99%)
> rename gcc/config/{i386 => mingw}/msformat-c.cc (100%)
> rename gcc/config/{i386 => mingw}/t-cygming (73%)
> rename gcc/config/{i386 => mingw}/winnt-cxx.cc (100%)
> rename gcc/config/{i386 => mingw}/winnt-d.cc (100%)
> rename gcc/config/{i386 => mingw}/winnt-stubs.cc (100%)
> rename gcc/config/{i386 => mingw}/winnt.cc (97%)
> create mode 100644 libgcc/config/aarch64/t-no-eh
> rename libgcc/config/{i386 => mingw}/t-gthr-win32 (100%)
> rename libgcc/config/{i386 => mingw}/t-mingw-pthread (100%)
>
> --
> 2.25.1
>
[gcc r15-297] aarch64: Add aarch64-w64-mingw32 target to libatomic
https://gcc.gnu.org/g:0c23efc04b754a1959f7151ef101ad0daba1e5af
commit r15-297-g0c23efc04b754a1959f7151ef101ad0daba1e5af
Author: Zac Walker
Date: Fri Mar 1 02:23:45 2024 +0100
aarch64: Add aarch64-w64-mingw32 target to libatomic
libatomic/ChangeLog:
* configure.tgt: Add aarch64-w64-mingw32 target.
Diff:
---
libatomic/configure.tgt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libatomic/configure.tgt b/libatomic/configure.tgt
index 4237f283fe40..e49fd57ab418 100644
--- a/libatomic/configure.tgt
+++ b/libatomic/configure.tgt
@@ -44,7 +44,7 @@ case "${target_cpu}" in
aarch64*)
ARCH=aarch64
case "${target}" in
- aarch64*-*-linux*)
+ aarch64*-*-linux* | aarch64-*-mingw*)
if test -n "$enable_aarch64_lse"; then
try_ifunc=yes
fi
[gcc r15-298] Add aarch64-w64-mingw32 target to libgcc
https://gcc.gnu.org/g:d6d7afcdbc04adb0ec42a44b2d7e05600945af42
commit r15-298-gd6d7afcdbc04adb0ec42a44b2d7e05600945af42
Author: Zac Walker
Date: Mon Feb 12 15:22:47 2024 +0100
Add aarch64-w64-mingw32 target to libgcc
Reuse MinGW definitions from i386 for libgcc. Move reused files to
libgcc/config/mingw folder.
libgcc/ChangeLog:
* config.host: Add aarch64-w64-mingw32 target. Adjust targets
after moving MinGW files.
* config/i386/t-gthr-win32: Move to...
* config/mingw/t-gthr-win32: ...here.
* config/i386/t-mingw-pthread: Move to...
* config/mingw/t-mingw-pthread: ...here.
* config/aarch64/t-no-eh: New file. EH is not yet implemented for
the target, and the default definition should be disabled.
Diff:
---
libgcc/config.host| 23 +++
libgcc/config/aarch64/t-no-eh | 2 ++
libgcc/config/{i386 => mingw}/t-gthr-win32| 0
libgcc/config/{i386 => mingw}/t-mingw-pthread | 0
4 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/libgcc/config.host b/libgcc/config.host
index a8e465aa3abb..694602d31859 100644
--- a/libgcc/config.host
+++ b/libgcc/config.host
@@ -452,6 +452,21 @@ aarch64*-*-vxworks7*)
tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp t-crtfm"
tmake_file="${tmake_file} t-dfprules"
;;
+aarch64-*-mingw*)
+ case ${target_thread_file} in
+ win32)
+ tmake_thr_file="mingw/t-gthr-win32"
+ ;;
+ posix)
+ tmake_thr_file="mingw/t-mingw-pthread"
+ ;;
+ esac
+ tmake_file="${tmake_file} ${cpu_type}/t-no-eh ${tmake_thr_file}"
+ tmake_file="${tmake_file} t-dfprules"
+ tmake_file="${tmake_file} ${cpu_type}/t-aarch64"
+ tmake_file="${tmake_file} ${cpu_type}/t-lse"
+ tmake_file="${tmake_file} ${cpu_type}/t-softfp t-softfp t-crtfm"
+ ;;
alpha*-*-linux*)
tmake_file="${tmake_file} alpha/t-alpha alpha/t-ieee t-crtfm
alpha/t-linux"
extra_parts="$extra_parts crtfastmath.o"
@@ -870,10 +885,10 @@ i[34567]86-*-mingw*)
fi
case ${target_thread_file} in
win32)
- tmake_thr_file="i386/t-gthr-win32"
+ tmake_thr_file="mingw/t-gthr-win32"
;;
posix)
- tmake_thr_file="i386/t-mingw-pthread"
+ tmake_thr_file="mingw/t-mingw-pthread"
;;
mcf)
tmake_thr_file="i386/t-mingw-mcfgthread"
@@ -897,10 +912,10 @@ i[34567]86-*-mingw*)
x86_64-*-mingw*)
case ${target_thread_file} in
win32)
- tmake_thr_file="i386/t-gthr-win32"
+ tmake_thr_file="mingw/t-gthr-win32"
;;
posix)
- tmake_thr_file="i386/t-mingw-pthread"
+ tmake_thr_file="mingw/t-mingw-pthread"
;;
mcf)
tmake_thr_file="i386/t-mingw-mcfgthread"
diff --git a/libgcc/config/aarch64/t-no-eh b/libgcc/config/aarch64/t-no-eh
new file mode 100644
index ..1802339a5834
--- /dev/null
+++ b/libgcc/config/aarch64/t-no-eh
@@ -0,0 +1,2 @@
+# Not using EH
+LIB2ADDEH =
diff --git a/libgcc/config/i386/t-gthr-win32 b/libgcc/config/mingw/t-gthr-win32
similarity index 100%
rename from libgcc/config/i386/t-gthr-win32
rename to libgcc/config/mingw/t-gthr-win32
diff --git a/libgcc/config/i386/t-mingw-pthread
b/libgcc/config/mingw/t-mingw-pthread
similarity index 100%
rename from libgcc/config/i386/t-mingw-pthread
rename to libgcc/config/mingw/t-mingw-pthread
[gcc r15-296] aarch64: Build and add objects for Cygwin and MinGW for AArch64
https://gcc.gnu.org/g:10a2f11b4101bdea84048ca90cd06e362f254c4c
commit r15-296-g10a2f11b4101bdea84048ca90cd06e362f254c4c
Author: Zac Walker
Date: Tue Feb 20 13:55:51 2024 +0100
aarch64: Build and add objects for Cygwin and MinGW for AArch64
gcc/ChangeLog:
* config.gcc: Build and add objects for Cygwin and MinGW. Add Cygwin
and MinGW options to the target.
Diff:
---
gcc/config.gcc | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 5f9225907a70..cfc2db545d01 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1278,6 +1278,11 @@ aarch64-*-mingw*)
tm_file="${tm_file} mingw/mingw-stdint.h"
tmake_file="${tmake_file} aarch64/t-aarch64"
target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
+ extra_options="${extra_options} mingw/cygming.opt mingw/mingw.opt"
+ extra_objs="${extra_objs} winnt.o"
+ c_target_objs="${c_target_objs} msformat-c.o"
+ d_target_objs="${d_target_objs} winnt-d.o"
+ tmake_file="${tmake_file} mingw/t-cygming"
case ${enable_threads} in
"" | yes | win32)
thread_file='win32'
[gcc r15-295] Rename "x86 Windows Options" to "Cygwin and MinGW Options"
https://gcc.gnu.org/g:e8d003736e6c3ba9bddbd74bb07b5d91d3674b9f
commit r15-295-ge8d003736e6c3ba9bddbd74bb07b5d91d3674b9f
Author: Zac Walker
Date: Thu Apr 11 13:43:23 2024 +0200
Rename "x86 Windows Options" to "Cygwin and MinGW Options"
Rename "x86 Windows Options" to "Cygwin and MinGW Options".
It will be used also for AArch64.
gcc/ChangeLog:
* config/i386/mingw-w64.opt.urls: Rename options' name and
regenerate option URLs.
* config/lynx.opt.urls: Likewise.
* config/mingw/cygming.opt.urls: Likewise.
* config/mingw/mingw.opt.urls: Likewise.
* doc/invoke.texi: Likewise.
Diff:
---
gcc/config/i386/mingw-w64.opt.urls | 2 +-
gcc/config/lynx.opt.urls | 2 +-
gcc/config/mingw/cygming.opt.urls | 18 +-
gcc/config/mingw/mingw.opt.urls| 2 +-
gcc/doc/invoke.texi| 10 ++
5 files changed, 22 insertions(+), 12 deletions(-)
diff --git a/gcc/config/i386/mingw-w64.opt.urls
b/gcc/config/i386/mingw-w64.opt.urls
index 6bb53ef29b2b..5cceba1d1a17 100644
--- a/gcc/config/i386/mingw-w64.opt.urls
+++ b/gcc/config/i386/mingw-w64.opt.urls
@@ -1,5 +1,5 @@
; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/mingw-w64.opt
and generated HTML
municode
-UrlSuffix(gcc/x86-Windows-Options.html#index-municode)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-municode)
diff --git a/gcc/config/lynx.opt.urls b/gcc/config/lynx.opt.urls
index 63e7b9c4b33f..b547138f7ffa 100644
--- a/gcc/config/lynx.opt.urls
+++ b/gcc/config/lynx.opt.urls
@@ -1,5 +1,5 @@
; Autogenerated by regenerate-opt-urls.py from gcc/config/lynx.opt and
generated HTML
mthreads
-UrlSuffix(gcc/x86-Windows-Options.html#index-mthreads-1)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1)
diff --git a/gcc/config/mingw/cygming.opt.urls
b/gcc/config/mingw/cygming.opt.urls
index 87799befe3c4..c624e22e4427 100644
--- a/gcc/config/mingw/cygming.opt.urls
+++ b/gcc/config/mingw/cygming.opt.urls
@@ -1,30 +1,30 @@
; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/cygming.opt and
generated HTML
mconsole
-UrlSuffix(gcc/x86-Windows-Options.html#index-mconsole)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mconsole)
mdll
-UrlSuffix(gcc/x86-Windows-Options.html#index-mdll)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mdll)
mnop-fun-dllimport
-UrlSuffix(gcc/x86-Windows-Options.html#index-mnop-fun-dllimport)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mnop-fun-dllimport)
; skipping UrlSuffix for 'mthreads' due to multiple URLs:
+; duplicate: 'gcc/Cygwin-and-MinGW-Options.html#index-mthreads-1'
; duplicate: 'gcc/x86-Options.html#index-mthreads'
-; duplicate: 'gcc/x86-Windows-Options.html#index-mthreads-1'
mwin32
-UrlSuffix(gcc/x86-Windows-Options.html#index-mwin32)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mwin32)
mwindows
-UrlSuffix(gcc/x86-Windows-Options.html#index-mwindows)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mwindows)
mpe-aligned-commons
-UrlSuffix(gcc/x86-Windows-Options.html#index-mpe-aligned-commons)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mpe-aligned-commons)
fset-stack-executable
-UrlSuffix(gcc/x86-Windows-Options.html#index-fno-set-stack-executable)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-fno-set-stack-executable)
fwritable-relocated-rdata
-UrlSuffix(gcc/x86-Windows-Options.html#index-fno-writable-relocated-rdata)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-fno-writable-relocated-rdata)
diff --git a/gcc/config/mingw/mingw.opt.urls b/gcc/config/mingw/mingw.opt.urls
index 2cbbaadf310d..f8ee5be6a535 100644
--- a/gcc/config/mingw/mingw.opt.urls
+++ b/gcc/config/mingw/mingw.opt.urls
@@ -1,7 +1,7 @@
; Autogenerated by regenerate-opt-urls.py from gcc/config/i386/mingw.opt and
generated HTML
mcrtdll=
-UrlSuffix(gcc/x86-Windows-Options.html#index-mcrtdll)
+UrlSuffix(gcc/Cygwin-and-MinGW-Options.html#index-mcrtdll)
; skipping UrlSuffix for 'pthread' due to multiple URLs:
; duplicate: 'gcc/Link-Options.html#index-pthread-1'
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ed03a613b4b4..ddcd5213f06a 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1499,6 +1499,8 @@ See RS/6000 and PowerPC Options.
-munroll-only-small-loops -mlam=@var{choice}}
@emph{x86 Windows Options}
+
+@emph{Cygwin and MinGW Options}
@gccoptlist{-mconsole -mcrtdll=@var{library} -mdll
-mnop-fun-dllimport -mthread
-municode -mwin32 -mwindows -fno-set-stack-executable}
@@ -21041,6 +21043,7 @@ platform.
* C6X Options::
* CRIS Options::
* C-SKY Options::
+* Cygwin and MinGW Options::
* Darwin Options::
* DEC Alpha Options::
* eBPF Options::
@@ -36316,6 +36319,13 @@ positions 62:57 can be used for metadata.
@cindex x86 Windows Options
@cindex Windows Options for x86
+@xref{Cygwin and MinGW Options}.
+
+@node Cygwin and MinGW Options
+@subsection
[gcc r15-293] aarch64: Add Cygwin and MinGW environments for AArch64
https://gcc.gnu.org/g:565b782bfa85332a4aba91dec3b871d2f50f1fb8
commit r15-293-g565b782bfa85332a4aba91dec3b871d2f50f1fb8
Author: Zac Walker
Date: Thu Apr 11 13:41:51 2024 +0200
aarch64: Add Cygwin and MinGW environments for AArch64
Define Cygwin and MinGW environment such as types, SEH definitions,
shared libraries, etc.
gcc/ChangeLog:
* config.gcc: Add Cygwin and MinGW difinitions.
* config/aarch64/aarch64-protos.h
(mingw_pe_maybe_record_exported_symbol): Declare functions
which are used in Cygwin and MinGW environment.
(mingw_pe_section_type_flags): Likewise.
(mingw_pe_unique_section): Likewise.
(mingw_pe_encode_section_info): Likewise.
* config/aarch64/cygming.h: New file.
Diff:
---
gcc/config.gcc | 4 +
gcc/config/aarch64/aarch64-protos.h | 5 ++
gcc/config/aarch64/cygming.h| 172
3 files changed, 181 insertions(+)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index cb1bba73f8d2..5f9225907a70 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1273,7 +1273,11 @@ aarch64*-*-gnu*)
aarch64-*-mingw*)
tm_file="${tm_file} aarch64/aarch64-abi-ms.h"
tm_file="${tm_file} aarch64/aarch64-coff.h"
+ tm_file="${tm_file} aarch64/cygming.h"
+ tm_file="${tm_file} mingw/mingw32.h"
+ tm_file="${tm_file} mingw/mingw-stdint.h"
tmake_file="${tmake_file} aarch64/t-aarch64"
+ target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
case ${enable_threads} in
"" | yes | win32)
thread_file='win32'
diff --git a/gcc/config/aarch64/aarch64-protos.h
b/gcc/config/aarch64/aarch64-protos.h
index 42639e9efcf1..1d3f94c813ea 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -1110,6 +1110,11 @@ extern void aarch64_output_patchable_area (unsigned int,
bool);
extern void aarch64_adjust_reg_alloc_order ();
+extern void mingw_pe_maybe_record_exported_symbol (tree, const char *, int);
+extern unsigned int mingw_pe_section_type_flags (tree, const char *, int);
+extern void mingw_pe_unique_section (tree, int);
+extern void mingw_pe_encode_section_info (tree, rtx, int);
+
bool aarch64_optimize_mode_switching (aarch64_mode_entity);
void aarch64_restore_za (rtx);
diff --git a/gcc/config/aarch64/cygming.h b/gcc/config/aarch64/cygming.h
new file mode 100644
index ..2e7b01feb768
--- /dev/null
+++ b/gcc/config/aarch64/cygming.h
@@ -0,0 +1,172 @@
+/* Operating system specific defines to be used when targeting GCC for
+ hosting on Windows32, using a Unix style C library and tools.
+ Copyright (C) 1995-2024 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+
[gcc r15-294] aarch64: Add SEH to machine_function
https://gcc.gnu.org/g:38e422e2ef539ccf6db1bdd340079631b1141637
commit r15-294-g38e422e2ef539ccf6db1bdd340079631b1141637
Author: Zac Walker
Date: Tue Feb 20 18:10:08 2024 +0100
aarch64: Add SEH to machine_function
SEH is not enabled in aarch64-w64-mingw32 target yet. However, it is
needed to be declared in machine_function for reusing winnt.cc.
gcc/ChangeLog:
* config/aarch64/aarch64.h (struct seh_frame_state): Declare SEH
structure in machine_function.
(GTY): Add SEH field.
Diff:
---
gcc/config/aarch64/aarch64.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/gcc/config/aarch64/aarch64.h b/gcc/config/aarch64/aarch64.h
index 319fe032a4b3..bbf11faaf4b4 100644
--- a/gcc/config/aarch64/aarch64.h
+++ b/gcc/config/aarch64/aarch64.h
@@ -1046,6 +1046,9 @@ struct GTY (()) aarch64_frame
bool is_scs_enabled;
};
+/* Private to winnt.cc. */
+struct seh_frame_state;
+
#ifdef hash_set_h
typedef struct GTY (()) machine_function
{
@@ -1086,6 +1089,9 @@ typedef struct GTY (()) machine_function
still exists and still fulfils its original purpose. the same register
can be reused by other code. */
rtx_insn *advsimd_zero_insn;
+
+ /* During SEH output, this is non-null. */
+ struct seh_frame_state * GTY ((skip (""))) seh;
} machine_function;
#endif
#endif
[gcc r15-292] Exclude i386 functionality from aarch64 build
https://gcc.gnu.org/g:de2bcdaf399d3f97af6ab312893ffe089e69d42b
commit r15-292-gde2bcdaf399d3f97af6ab312893ffe089e69d42b
Author: Zac Walker
Date: Thu Apr 11 13:38:59 2024 +0200
Exclude i386 functionality from aarch64 build
This patch defines TARGET_AARCH64_MS_ABI in config.gcc and uses it to
exclude i386 functionality from aarch64 build and adjust MinGW headers
for AArch64 MS ABI.
gcc/ChangeLog:
* config.gcc: Define TARGET_AARCH64_MS_ABI.
* config/mingw/mingw-stdint.h (INTPTR_TYPE): Use
TARGET_AARCH64_MS_ABI to adjust MinGW headers for
AArch64 MS ABI.
(UINTPTR_TYPE): Likewise.
(defined): Likewise.
* config/mingw/mingw32.h (DEFAULT_ABI): Likewise.
(defined): Likewise.
* config/mingw/winnt.cc (defined): Use TARGET_ARM64_MS_ABI to
exclude ix86_get_callcvt.
(i386_pe_maybe_mangle_decl_assembler_name): Likewise.
(i386_pe_mangle_decl_assembler_name): Likewise.
Diff:
---
gcc/config.gcc | 1 +
gcc/config/mingw/mingw-stdint.h | 9 +++--
gcc/config/mingw/mingw32.h | 4 +++-
gcc/config/mingw/winnt.cc | 8
4 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index f95417c2e69f..cb1bba73f8d2 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1284,6 +1284,7 @@ aarch64-*-mingw*)
esac
default_use_cxa_atexit=yes
user_headers_inc_next_post="${user_headers_inc_next_post} float.h"
+ tm_defines="${tm_defines} TARGET_AARCH64_MS_ABI=1"
;;
aarch64*-wrs-vxworks*)
tm_file="${tm_file} elfos.h aarch64/aarch64-elf.h"
diff --git a/gcc/config/mingw/mingw-stdint.h b/gcc/config/mingw/mingw-stdint.h
index c0feade76e9f..debbe829bdf8 100644
--- a/gcc/config/mingw/mingw-stdint.h
+++ b/gcc/config/mingw/mingw-stdint.h
@@ -46,5 +46,10 @@ along with GCC; see the file COPYING3. If not see
#define UINT_FAST32_TYPE "unsigned int"
#define UINT_FAST64_TYPE "long long unsigned int"
-#define INTPTR_TYPE (TARGET_64BIT ? "long long int" : "int")
-#define UINTPTR_TYPE (TARGET_64BIT ? "long long unsigned int" : "unsigned int")
+#if defined (TARGET_AARCH64_MS_ABI)
+# define INTPTR_TYPE "long long int"
+# define UINTPTR_TYPE "long long unsigned int"
+#else
+# define INTPTR_TYPE (TARGET_64BIT ? "long long int" : "int")
+# define UINTPTR_TYPE (TARGET_64BIT ? "long long unsigned int" : "unsigned
int")
+#endif
\ No newline at end of file
diff --git a/gcc/config/mingw/mingw32.h b/gcc/config/mingw/mingw32.h
index 58304fc55f62..08f1b5f06967 100644
--- a/gcc/config/mingw/mingw32.h
+++ b/gcc/config/mingw/mingw32.h
@@ -19,7 +19,9 @@ along with GCC; see the file COPYING3. If not see
[gcc r15-291] Rename section and encoding functions from i386 which will be used in aarch64
https://gcc.gnu.org/g:99d7d5ec8d88415a7e1f74fade0841a0ebbd0092
commit r15-291-g99d7d5ec8d88415a7e1f74fade0841a0ebbd0092
Author: Zac Walker
Date: Tue Feb 20 17:22:31 2024 +0100
Rename section and encoding functions from i386 which will be used in
aarch64
gcc/ChangeLog:
* config/i386/cygming.h (SUBTARGET_ENCODE_SECTION_INFO):
Rename functions in mingw folder which will be reused for
aarch64.
(TARGET_ASM_UNIQUE_SECTION): Likewise.
(TARGET_ASM_NAMED_SECTION): Likewise.
(TARGET_SECTION_TYPE_FLAGS): Likewise.
(ASM_DECLARE_COLD_FUNCTION_NAME): Likewise.
(ASM_OUTPUT_EXTERNAL_LIBCALL): Likewise.
* config/i386/i386-protos.h (i386_pe_unique_section):
Rename into ...
(mingw_pe_unique_section): ... this.
(i386_pe_declare_function_type): Rename into ...
(mingw_pe_declare_function_type): ... this.
(i386_pe_encode_section_info): Rename into ...
(mingw_pe_encode_section_info): ... this.
(i386_pe_maybe_record_exported_symbol): Rename into ...
(mingw_pe_maybe_record_exported_symbol): ... this.
(i386_pe_section_type_flags): Rename into ...
(mingw_pe_section_type_flags): ... this.
(i386_pe_asm_named_section): Rename into ...
(mingw_pe_asm_named_section): ... this.
* config/mingw/winnt.cc (i386_pe_encode_section_info):
Rename into ...
(mingw_pe_encode_section_info): ... this.
(i386_pe_unique_section): Rename into ...
(mingw_pe_unique_section): ... this.
(i386_pe_section_type_flags): Rename into ...
(mingw_pe_section_type_flags): ... this.
(i386_pe_asm_named_section): Rename into ...
(mingw_pe_asm_named_section): ... this.
(i386_pe_asm_output_aligned_decl_common): Likewise.
(i386_pe_declare_function_type): Rename into ...
(mingw_pe_declare_function_type): ... this.
(i386_pe_maybe_record_exported_symbol): Rename into ...
(mingw_pe_maybe_record_exported_symbol): ... this.
(i386_pe_start_function): Likewise.
* varasm.cc (switch_to_comdat_section): Likewise.
Diff:
---
gcc/config/i386/cygming.h | 18 +-
gcc/config/i386/i386-protos.h | 12 ++--
gcc/config/mingw/winnt.cc | 22 +++---
gcc/varasm.cc | 2 +-
4 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/gcc/config/i386/cygming.h b/gcc/config/i386/cygming.h
index 1af5bc380a50..beedf7c398a5 100644
--- a/gcc/config/i386/cygming.h
+++ b/gcc/config/i386/cygming.h
@@ -219,7 +219,7 @@ do {
\
section and we need to set DECL_SECTION_NAME so we do that here.
Note that we can be called twice on the same decl. */
-#define SUBTARGET_ENCODE_SECTION_INFO i386_pe_encode_section_info
+#define SUBTARGET_ENCODE_SECTION_INFO mingw_pe_encode_section_info
/* Local and global relocs can be placed always into readonly memory
for PE-COFF targets. */
@@ -235,7 +235,7 @@ do {
\
#undef ASM_DECLARE_OBJECT_NAME
#define ASM_DECLARE_OBJECT_NAME(STREAM, NAME, DECL)\
do { \
- i386_pe_maybe_record_exported_symbol (DECL, NAME, 1);\
+ mingw_pe_maybe_record_exported_symbol (DECL, NAME, 1); \
ASM_OUTPUT_LABEL ((STREAM), (NAME)); \
} while (0)
@@ -283,16 +283,16 @@ do { \
/* Windows uses explicit import from shared libraries. */
#define MULTIPLE_SYMBOL_SPACES 1
-#define TARGET_ASM_UNIQUE_SECTION i386_pe_unique_section
+#define TARGET_ASM_UNIQUE_SECTION mingw_pe_unique_section
#define TARGET_ASM_FUNCTION_RODATA_SECTION default_no_function_rodata_section
#define SUPPORTS_ONE_ONLY 1
/* Switch into a generic section. */
-#define TARGET_ASM_NAMED_SECTION i386_pe_asm_named_section
+#define TARGET_ASM_NAMED_SECTION mingw_pe_asm_named_section
/* Select attributes for named sections. */
-#define TARGET_SECTION_TYPE_FLAGS i386_pe_section_type_flags
+#define TARGET_SECTION_TYPE_FLAGS mingw_pe_section_type_flags
/* Write the extra assembler code needed to declare a function
properly. */
@@ -307,7 +307,7 @@ do {\
#define ASM_DECLARE_COLD_FUNCTION_NAME(FILE, NAME, DECL) \
do \
{ \
- i386_pe_declare_function_type (FILE, NAME, 0); \
+ mingw_pe_declare_function_type (FILE, NAME, 0); \
i386_pe_seh_cold_init (FILE, NAME); \
[gcc r15-290] Reuse MinGW from i386 for AArch64
https://gcc.gnu.org/g:1f05dfc131c7996a85dd82b3300f7b5f93d4b1bd
commit r15-290-g1f05dfc131c7996a85dd82b3300f7b5f93d4b1bd
Author: Zac Walker
Date: Fri Mar 1 02:41:50 2024 +0100
Reuse MinGW from i386 for AArch64
This patch creates a new config/mingw directory to share MinGW
related definitions, and moves there the corresponding existing files
from config/i386.
gcc/ChangeLog:
* config.gcc: Adjust targets after moving MinGW related files
from i386 to mingw folder.
* config/i386/cygming.opt: Move to...
* config/mingw/cygming.opt: ...here.
* config/i386/cygming.opt.urls: Move to...
* config/mingw/cygming.opt.urls: ...here.
* config/i386/cygwin-d.cc: Move to...
* config/mingw/cygwin-d.cc: ...here.
* config/i386/mingw-stdint.h: Move to...
* config/mingw/mingw-stdint.h: ...here.
* config/i386/mingw.opt: Move to...
* config/mingw/mingw.opt: ...here.
* config/i386/mingw.opt.urls: Move to...
* config/mingw/mingw.opt.urls: ...here.
* config/i386/mingw32.h: Move to...
* config/mingw/mingw32.h: ...here.
* config/i386/msformat-c.cc: Move to...
* config/mingw/msformat-c.cc: ...here.
* config/i386/t-cygming: Move to...
* config/mingw/t-cygming: ...here and updated.
* config/i386/winnt-cxx.cc: Move to...
* config/mingw/winnt-cxx.cc: ...here.
* config/i386/winnt-d.cc: Move to...
* config/mingw/winnt-d.cc: ...here.
* config/i386/winnt-stubs.cc: Move to...
* config/mingw/winnt-stubs.cc: ...here.
* config/i386/winnt.cc: Move to...
* config/mingw/winnt.cc: ...here.
Diff:
---
gcc/config.gcc | 22 +++---
gcc/config/{i386 => mingw}/cygming.opt | 0
gcc/config/{i386 => mingw}/cygming.opt.urls | 0
gcc/config/{i386 => mingw}/cygwin-d.cc | 0
gcc/config/{i386 => mingw}/mingw-stdint.h | 0
gcc/config/{i386 => mingw}/mingw.opt| 0
gcc/config/{i386 => mingw}/mingw.opt.urls | 0
gcc/config/{i386 => mingw}/mingw32.h| 0
gcc/config/{i386 => mingw}/msformat-c.cc| 0
gcc/config/{i386 => mingw}/t-cygming| 23 +--
gcc/config/{i386 => mingw}/winnt-cxx.cc | 0
gcc/config/{i386 => mingw}/winnt-d.cc | 0
gcc/config/{i386 => mingw}/winnt-stubs.cc | 0
gcc/config/{i386 => mingw}/winnt.cc | 0
14 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 1dcba6be6502..f95417c2e69f 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2167,9 +2167,9 @@ i[4567]86-wrs-vxworks*|x86_64-wrs-vxworks7*)
i[34567]86-*-cygwin*)
tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h i386/cygming.h
i386/cygwin.h i386/cygwin-stdint.h"
xm_file=i386/xm-cygwin.h
- tmake_file="${tmake_file} i386/t-cygming t-slibgcc"
- target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc"
- extra_options="${extra_options} i386/cygming.opt i386/cygwin.opt"
+ tmake_file="${tmake_file} mingw/t-cygming t-slibgcc"
+ target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
+ extra_options="${extra_options} mingw/cygming.opt i386/cygwin.opt"
extra_objs="${extra_objs} winnt.o winnt-stubs.o"
c_target_objs="${c_target_objs} msformat-c.o"
cxx_target_objs="${cxx_target_objs} winnt-cxx.o msformat-c.o"
@@ -2185,9 +2185,9 @@ x86_64-*-cygwin*)
need_64bit_isa=yes
tm_file="${tm_file} i386/unix.h i386/bsd.h i386/gas.h i386/cygming.h
i386/cygwin.h i386/cygwin-w64.h i386/cygwin-stdint.h"
xm_file=i386/xm-cygwin.h
- tmake_file="${tmake_file} i386/t-cygming t-slibgcc"
- target_gtfiles="$target_gtfiles \$(srcdir)/config/i386/winnt.cc"
- extra_options="${extra_options} i386/cygming.opt i386/cygwin.opt"
+ tmake_file="${tmake_file} mingw/t-cygming t-slibgcc"
+ target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
+ extra_options="${extra_options} mingw/cygming.opt i386/cygwin.opt"
extra_objs="${extra_objs} winnt.o winnt-stubs.o"
c_target_objs="${c_target_objs} msformat-c.o"
cxx_target_objs="${cxx_target_objs} winnt-cxx.o msformat-c.o"
@@ -2223,7 +2223,7 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
if test x$enable_threads = xmcf ; then
tm_file="${tm_file} i386/mingw-mcfgthread.h"
fi
- tm_file="${tm_file} i386/mingw32.h"
+ tm_file="${tm_file} mingw/mingw32.h"
# This makes the logic if mingw's or the w64 feature set has to be used
case ${target} in
*-w64-*)
@@ -2252,8 +2252,8 @@ i[34567]86-*-mingw* | x86_64-*-mingw*)
*)
;;
esac
- tm_file="${tm_file}
[gcc r15-289] aarch64: Add aarch64-w64-mingw32 COFF
https://gcc.gnu.org/g:21fbaa1a2d274a36454332a6e10a496024bbc560
commit r15-289-g21fbaa1a2d274a36454332a6e10a496024bbc560
Author: Zac Walker
Date: Thu Apr 11 14:46:07 2024 +0200
aarch64: Add aarch64-w64-mingw32 COFF
Define ASM specific for COFF format on AArch64.
gcc/ChangeLog:
* config.gcc: Add COFF format support definitions.
* config/aarch64/aarch64-coff.h: New file.
Diff:
---
gcc/config.gcc| 1 +
gcc/config/aarch64/aarch64-coff.h | 91 +++
2 files changed, 92 insertions(+)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 007a64d010d5..1dcba6be6502 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1272,6 +1272,7 @@ aarch64*-*-gnu*)
;;
aarch64-*-mingw*)
tm_file="${tm_file} aarch64/aarch64-abi-ms.h"
+ tm_file="${tm_file} aarch64/aarch64-coff.h"
tmake_file="${tmake_file} aarch64/t-aarch64"
case ${enable_threads} in
"" | yes | win32)
diff --git a/gcc/config/aarch64/aarch64-coff.h
b/gcc/config/aarch64/aarch64-coff.h
new file mode 100644
index ..81fd9954f755
--- /dev/null
+++ b/gcc/config/aarch64/aarch64-coff.h
@@ -0,0 +1,91 @@
+/* Machine description for AArch64 architecture.
+ Copyright (C) 2024 Free Software Foundation, Inc.
+
+ This file is part of GCC.
+
+ GCC is free software; you can redistribute it and/or modify it
+ under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3, or (at your option)
+ any later version.
+
+ GCC is distributed in the hope that it will be useful, but
+ WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with GCC; see the file COPYING3. If not see
+
[gcc r15-288] aarch64: Mark x18 register as a fixed register for MS ABI
https://gcc.gnu.org/g:b9415046fa27d6b3faea89871dbb84b673afadaf
commit r15-288-gb9415046fa27d6b3faea89871dbb84b673afadaf
Author: Zac Walker
Date: Thu Apr 11 13:30:27 2024 +0200
aarch64: Mark x18 register as a fixed register for MS ABI
Define the MS ABI for aarch64-w64-mingw32.
Adjust FIXED_REGISTERS, CALL_REALLY_USED_REGISTERS and
STATIC_CHAIN_REGNUM for AArch64 MS ABI.
The X18 register is reserved on Windows for the TEB.
gcc/ChangeLog:
* config.gcc: Define TARGET_AARCH64_MS_ABI when
AArch64 MS ABI is used.
* config/aarch64/aarch64.h (FIXED_X18): Adjust
FIXED_REGISTERS, CALL_REALLY_USED_REGISTERS and
STATIC_CHAIN_REGNUM for AArch64 MS ABI.
(CALL_USED_X18): Likewise.
(FIXED_REGISTERS): Likewise.
* config/aarch64/aarch64-abi-ms.h: New file.
Diff:
---
gcc/config.gcc | 1 +
gcc/config/aarch64/aarch64-abi-ms.h | 34 ++
gcc/config/aarch64/aarch64.h| 7 +--
3 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 0a737bf37ae0..007a64d010d5 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1271,6 +1271,7 @@ aarch64*-*-gnu*)
tm_defines="${tm_defines} TARGET_DEFAULT_ASYNC_UNWIND_TABLES=1"
;;
aarch64-*-mingw*)
+ tm_file="${tm_file} aarch64/aarch64-abi-ms.h"
tmake_file="${tmake_file} aarch64/t-aarch64"
case ${enable_threads} in
"" | yes | win32)
diff --git a/gcc/config/aarch64/aarch64-abi-ms.h
b/gcc/config/aarch64/aarch64-abi-ms.h
new file mode 100644
index ..15dc33d04749
--- /dev/null
+++ b/gcc/config/aarch64/aarch64-abi-ms.h
@@ -0,0 +1,34 @@
+/* Machine description for AArch64 MS ABI.
+ Copyright (C) 2024 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GCC; see the file COPYING3. If not see
+
[gcc r15-287] Introduce aarch64-w64-mingw32 target
https://gcc.gnu.org/g:13bad1ac7a6ea4dbbde67c69d31c218a2f2d7a5d
commit r15-287-g13bad1ac7a6ea4dbbde67c69d31c218a2f2d7a5d
Author: Zac Walker
Date: Fri Mar 1 01:40:53 2024 +0100
Introduce aarch64-w64-mingw32 target
Add the initial aarch64-w64-mingw32 target for gcc.
This is the first commit in a sequence of patch series to add
new aarch64-w64-mingw32 target.
Coauthors: Zac Walker ,
Mark Harmstone and
Ron Riddle
Refactored, prepared, and validated by
Radek Barton and
Evgeny Karpov
fixincludes/ChangeLog:
* mkfixinc.sh: Extend for *-mingw32* targets.
gcc/ChangeLog:
* config.gcc: Add aarch64-w64-mingw32 target.
Diff:
---
fixincludes/mkfixinc.sh | 3 +--
gcc/config.gcc | 13 +
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/fixincludes/mkfixinc.sh b/fixincludes/mkfixinc.sh
index df90720b716f..7112f4dcd64b 100755
--- a/fixincludes/mkfixinc.sh
+++ b/fixincludes/mkfixinc.sh
@@ -12,8 +12,7 @@ target=fixinc.sh
# Check for special fix rules for particular targets
case $machine in
i?86-*-cygwin* | \
-i?86-*-mingw32* | \
-x86_64-*-mingw32* | \
+*-mingw32* | \
powerpc-*-eabisim* | \
powerpc-*-eabi*| \
powerpc-*-rtems* | \
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 65bbe9e840fc..0a737bf37ae0 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1270,6 +1270,19 @@ aarch64*-*-gnu*)
tmake_file="${tmake_file} aarch64/t-aarch64"
tm_defines="${tm_defines} TARGET_DEFAULT_ASYNC_UNWIND_TABLES=1"
;;
+aarch64-*-mingw*)
+ tmake_file="${tmake_file} aarch64/t-aarch64"
+ case ${enable_threads} in
+ "" | yes | win32)
+ thread_file='win32'
+ ;;
+ posix)
+ thread_file='posix'
+ ;;
+ esac
+ default_use_cxa_atexit=yes
+ user_headers_inc_next_post="${user_headers_inc_next_post} float.h"
+ ;;
aarch64*-wrs-vxworks*)
tm_file="${tm_file} elfos.h aarch64/aarch64-elf.h"
tm_file="${tm_file} vx-common.h vxworks.h aarch64/aarch64-vxworks.h"
Re: [PATCH] libgm2: re-generate with autoreconf
On Thu, 2 May 2024 at 15:47, Gaius Mulley wrote: > > Simon Marchi writes: > > > > > I don't have access to the gcc repo, so could you please push the patch > > on my behalf? > > all done - many thanks for the patch! > Great, I think we now have to update autoregen.py on the buildbot so that it stops complaining :-) Thanks, Christophe > regards, > Gaius
Re: [PATCH] libgfortran: Fix up the autoreconf warnings.
On Thu, 2 May 2024 at 23:13, FX Coudert wrote: > > > libgfortran/ChangeLog: > > * Makefile.am: Use sub-dirs, amend recipies accordingly. > > * Makefile.in: Regenerate. > > Thanks Iain, I’ve tested it both with and without maintainer mode, and > regenerated files with no issue. I can also confirm that the many autoreconf > warnings that plagued libgfortran are now gone. > > Push as affd24bfc62203db9f9937c0d6cf8f1f75b80d72 > Nice, I can see on Sourceware's buildbot that there is now zero warning in libgfortran. Thanks, Christophe > FX
Re: [PATCH] fixincludes: add AC_CONFIG_MACRO_DIRS to configure.ac
On Tue, 30 Apr 2024 at 17:47, Simon Marchi wrote: > > On 4/30/24 4:54 AM, Christophe Lyon wrote: > > On Tue, 30 Apr 2024 at 04:25, Simon Marchi wrote: > >> > >> Add an "AC_CONFIG_MACRO_DIRS" call in configure.ac, with the same > >> directories as specified in "ACLOCAL_AMFLAGS", in Makefile.in. > >> > >> This makes it possible to re-generate aclocal.m4 using "autoreconf". > > > > Thanks, this LGTM, although like in your other patch, we need a > > ChangeLog entry in the commit message. > > > > Christophe > > Here is the ChangeLog entry: > > fixincludes/ChangeLog: > > * configure.ac: Add AC_CONFIG_MACRO_DIRS. > * configure: Re-generate. > > I don't have access to the gcc repo, so if/when this patch gets > approved, can you push it on my behalf? Sure! > > Thanks, > > Simon
Re: [PATCH] decay vect tests from run to link for pr95401
Hi Alexandre, On Tue, 30 Apr 2024 at 01:31, Alexandre Oliva wrote: > > On Apr 22, 2024, Richard Biener wrote: > > >> Regstrapped on x86_64-linux-gnu and ppc64el-linux-gnu. Also tested with > >> gcc-13 on ppc64-vx7r2 and ppc-vx7r2. Ok to install? > > > That makes sense. OK > > >> for gcc/testsuite/ChangeLog > >> > >> * lib/target-supports.exp (check_vect_support_and_set_flags): > >> Decay to link rather than compile. > > Alas, linking may fail because of an incompatible libc, as reported by > Linaro with a link to their issue GNU-1206 (I'm not posting the link to > the fully-Javascrippled Jira web page; it shows nothing useful, and I > can't post feedback there) and to > https://ci.linaro.org/job/tcwg_gnu_embed_check_gcc--master-thumb_m7_hard_eabi-build/10/artifact/artifacts/00-sumfiles/ > (where I could get useful information) > > I'm reverting the patch, and I'll see about some alternate approach that > can accommodate this scenario after I return from LibrePlanet. > Indeed, that's another instance of the tricky multilibs configuration issues. In this case: - we configure GCC: --disable-multilib --with-mode=thumb --with-cpu=cortex-m7 --with-float=hard --target=arm-eabi (we disable multilibs to save build time) - we run the tests with qemu/-mthumb/-march=armv7e-m+fp.dp/-mtune=cortex-m7/-mfloat-abi=hard/-mfpu=auto which matches the GCC configuration flags, but the vect.exp tests add -mfpu=neon -mfloat-abi=softfp -march=armv7-a and link fails because the toolchain does not support softfp libs HTH Thanks, Christophe > -- > Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ >Free Software Activist GNU Toolchain Engineer > More tolerance and less prejudice are key for inclusion and diversity > Excluding neuro-others for not behaving ""normal"" is *not* inclusive
[gcc r15-65] Fix pretty printers regexp for GDB output
https://gcc.gnu.org/g:6d4593a178b49cab205d81cdf36f52e12eabbc6d
commit r15-65-g6d4593a178b49cab205d81cdf36f52e12eabbc6d
Author: Christophe Lyon
Date: Thu Jan 25 15:43:56 2024 +
Fix pretty printers regexp for GDB output
GDB emits end of lines as \r\n, we currently match any >0 number of
either \n or \r, possibly leading to mismatches under racy conditions.
I noticed this while running the GCC testsuite using the equivalent of
GDB's READ1 feature [1] which helps detecting bufferization issues.
We try to match
\n$1 = empty std::tuple\r
against {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} which fails because
of the leading \n (which was left in the buffer after the previous
"skipping" pattern matched the preceding \r).
This patch accepts any number of leading \n and/or \r in the "got" clause.
Also take this opportunity to quote \r and \r in the logs, to make
debugging such issues easier.
Tested on aarch64-linux-gnu.
[1]
https//github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269
2024-01-24 Christophe Lyon
libstdc++-v3/
* testsuite/lib/gdb-test.exp (gdb-test): Fix regexp. Quote
newlines in logs.
Diff:
---
libstdc++-v3/testsuite/lib/gdb-test.exp | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/libstdc++-v3/testsuite/lib/gdb-test.exp
b/libstdc++-v3/testsuite/lib/gdb-test.exp
index 31206f2fc32..2ec5596983d 100644
--- a/libstdc++-v3/testsuite/lib/gdb-test.exp
+++ b/libstdc++-v3/testsuite/lib/gdb-test.exp
@@ -194,8 +194,11 @@ proc gdb-test { marker {selector {}} {load_xmethods 0} } {
set test_counter 0
remote_expect target [timeout_value] {
- -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
- send_log "got: $expect_out(buffer)"
+ -re {^[\n\r]*(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
+ # Escape newlines so that we can print them.
+ set escaped [string map {"\n" "\\n"} $expect_out(buffer)]
+ set escaped2 [string map {"\r" "\\r"} $escaped]
+ send_log "got: $escaped2"
incr test_counter
set first $expect_out(3,string)
@@ -251,7 +254,10 @@ proc gdb-test { marker {selector {}} {load_xmethods 0} } {
}
-re {^[^$][^\n\r]*[\n\r]+} {
- send_log "skipping: $expect_out(buffer)"
+ # Escape newlines so that we can print them.
+ set escaped [string map {"\n" "\\n"} $expect_out(buffer)]
+ set escaped2 [string map {"\r" "\\r"} $escaped]
+ send_log "skipping: $escaped2"
exp_continue
}
Re: [PATCH] fixincludes: add AC_CONFIG_MACRO_DIRS to configure.ac
On Tue, 30 Apr 2024 at 04:25, Simon Marchi wrote: > > Add an "AC_CONFIG_MACRO_DIRS" call in configure.ac, with the same > directories as specified in "ACLOCAL_AMFLAGS", in Makefile.in. > > This makes it possible to re-generate aclocal.m4 using "autoreconf". Thanks, this LGTM, although like in your other patch, we need a ChangeLog entry in the commit message. Christophe > --- > fixincludes/configure| 1 + > fixincludes/configure.ac | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/fixincludes/configure b/fixincludes/configure > index 662c94dc1120..7147c9a618aa 100755 > --- a/fixincludes/configure > +++ b/fixincludes/configure > @@ -4627,6 +4627,7 @@ $as_echo "$ac_cv_path_SED" >&6; } >rm -f conftest.sed > > > + > # Figure out what compiler warnings we can enable. > # See config/warnings.m4 for details. > > diff --git a/fixincludes/configure.ac b/fixincludes/configure.ac > index 4e78511d20fc..3d177699ebfa 100644 > --- a/fixincludes/configure.ac > +++ b/fixincludes/configure.ac > @@ -7,6 +7,7 @@ AC_CANONICAL_SYSTEM > AC_PROG_CC > AC_USE_SYSTEM_EXTENSIONS > AC_PROG_SED > +AC_CONFIG_MACRO_DIRS([.. ../config]) > > # Figure out what compiler warnings we can enable. > # See config/warnings.m4 for details. > > base-commit: 22b20ac6c6aead2d3f36c413a77dd0b80adfec39 > -- > 2.44.0 >
Re: [PATCH] libgm2: re-generate with autoreconf
On Tue, 30 Apr 2024 at 04:01, Simon Marchi wrote: > > I get a diff when running "autoreconf" in this directory. I think that > the current state is erroneous: it appears to have been generated using > > aclocal -I ../config -I .. > > even though configure.ac and Makefile.am list the include flag in the > reverse order: > >aclocal -I .. -I ../config > > Running "autoreconf" uses the latter order, so I think that's the > "right" output. > > No functional difference expected. Thanks, this matches what I noticed. I'm not a maintainer, so I cannot approve, but a minor remark: in GCC we still need a ChangeLog entry in the commit message. Christophe > --- > libgm2/Makefile.in | 10 +- > libgm2/aclocal.m4 | 10 +- > libgm2/libm2cor/Makefile.in | 10 +- > libgm2/libm2iso/Makefile.in | 10 +- > libgm2/libm2log/Makefile.in | 10 +- > libgm2/libm2min/Makefile.in | 10 +- > libgm2/libm2pim/Makefile.in | 10 +- > 7 files changed, 35 insertions(+), 35 deletions(-) > > diff --git a/libgm2/Makefile.in b/libgm2/Makefile.in > index f259df7842cf..9cd79824a53d 100644 > --- a/libgm2/Makefile.in > +++ b/libgm2/Makefile.in > @@ -90,15 +90,15 @@ host_triplet = @host@ > target_triplet = @target@ > subdir = . > ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 > -am__aclocal_m4_deps = $(top_srcdir)/../libtool.m4 \ > - $(top_srcdir)/../ltoptions.m4 $(top_srcdir)/../ltsugar.m4 \ > - $(top_srcdir)/../ltversion.m4 $(top_srcdir)/../lt~obsolete.m4 \ > - $(top_srcdir)/../config/acx.m4 \ > +am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \ > $(top_srcdir)/../config/depstand.m4 \ > $(top_srcdir)/../config/lead-dot.m4 \ > $(top_srcdir)/../config/multi.m4 \ > $(top_srcdir)/../config/no-executables.m4 \ > - $(top_srcdir)/../config/override.m4 $(top_srcdir)/acinclude.m4 \ > + $(top_srcdir)/../config/override.m4 \ > + $(top_srcdir)/../libtool.m4 $(top_srcdir)/../ltoptions.m4 \ > + $(top_srcdir)/../ltsugar.m4 $(top_srcdir)/../ltversion.m4 \ > + $(top_srcdir)/../lt~obsolete.m4 $(top_srcdir)/acinclude.m4 \ > $(top_srcdir)/../config/gc++filt.m4 \ > $(top_srcdir)/../config/tls.m4 $(top_srcdir)/../config/gthr.m4 \ > $(top_srcdir)/../config/cet.m4 $(top_srcdir)/configure.ac > diff --git a/libgm2/aclocal.m4 b/libgm2/aclocal.m4 > index bee67b05dee2..19cfb0d1eb26 100644 > --- a/libgm2/aclocal.m4 > +++ b/libgm2/aclocal.m4 > @@ -1187,15 +1187,15 @@ AC_SUBST([am__tar]) > AC_SUBST([am__untar]) > ]) # _AM_PROG_TAR > > -m4_include([../libtool.m4]) > -m4_include([../ltoptions.m4]) > -m4_include([../ltsugar.m4]) > -m4_include([../ltversion.m4]) > -m4_include([../lt~obsolete.m4]) > m4_include([../config/acx.m4]) > m4_include([../config/depstand.m4]) > m4_include([../config/lead-dot.m4]) > m4_include([../config/multi.m4]) > m4_include([../config/no-executables.m4]) > m4_include([../config/override.m4]) > +m4_include([../libtool.m4]) > +m4_include([../ltoptions.m4]) > +m4_include([../ltsugar.m4]) > +m4_include([../ltversion.m4]) > +m4_include([../lt~obsolete.m4]) > m4_include([acinclude.m4]) > diff --git a/libgm2/libm2cor/Makefile.in b/libgm2/libm2cor/Makefile.in > index 63299388dd8f..f9952cff71a7 100644 > --- a/libgm2/libm2cor/Makefile.in > +++ b/libgm2/libm2cor/Makefile.in > @@ -108,15 +108,15 @@ target_triplet = @target@ > @BUILD_CORLIB_TRUE@@ENABLE_DARWIN_AT_RPATH_TRUE@am__append_1 = > -nodefaultrpaths -Wl,-rpath,@loader_path/ > subdir = libm2cor > ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 > -am__aclocal_m4_deps = $(top_srcdir)/../libtool.m4 \ > - $(top_srcdir)/../ltoptions.m4 $(top_srcdir)/../ltsugar.m4 \ > - $(top_srcdir)/../ltversion.m4 $(top_srcdir)/../lt~obsolete.m4 \ > - $(top_srcdir)/../config/acx.m4 \ > +am__aclocal_m4_deps = $(top_srcdir)/../config/acx.m4 \ > $(top_srcdir)/../config/depstand.m4 \ > $(top_srcdir)/../config/lead-dot.m4 \ > $(top_srcdir)/../config/multi.m4 \ > $(top_srcdir)/../config/no-executables.m4 \ > - $(top_srcdir)/../config/override.m4 $(top_srcdir)/acinclude.m4 \ > + $(top_srcdir)/../config/override.m4 \ > + $(top_srcdir)/../libtool.m4 $(top_srcdir)/../ltoptions.m4 \ > + $(top_srcdir)/../ltsugar.m4 $(top_srcdir)/../ltversion.m4 \ > + $(top_srcdir)/../lt~obsolete.m4 $(top_srcdir)/acinclude.m4 \ > $(top_srcdir)/../config/gc++filt.m4 \ > $(top_srcdir)/../config/tls.m4 $(top_srcdir)/../config/gthr.m4 \ > $(top_srcdir)/../config/cet.m4 $(top_srcdir)/configure.ac > diff --git a/libgm2/libm2iso/Makefile.in b/libgm2/libm2iso/Makefile.in > index 964c6da85270..370837f15b82 100644 > --- a/libgm2/libm2iso/Makefile.in > +++ b/libgm2/libm2iso/Makefile.in > @@ -108,15 +108,15 @@ target_triplet = @target@ > @BUILD_ISOLIB_TRUE@@ENABLE_DARWIN_AT_RPATH_TRUE@am__append_1 = > -nodefaultrpaths -Wl,-rpath,@loader_path/ > subdir = libm2iso > ACLOCAL_M4 =
Re: [PATCH] arm: [MVE intrinsics] Fix support for predicate constants [PR target/114801]
On Mon, 29 Apr 2024 at 15:29, Jakub Jelinek wrote:
>
> On Fri, Apr 26, 2024 at 11:10:12PM +, Christophe Lyon wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
> > @@ -0,0 +1,36 @@
> > +/* { dg-do compile } */
> > +/* { dg-require-effective-target arm_v8_1m_mve_ok } */
> > +/* { dg-add-options arm_v8_1m_mve } */
> > +/* { dg-final { check-function-bodies "**" "" "" } } */
> > +
> > +#include
> > +
> > +/*
> > +** test_32:
> > +**...
> > +** mov r[0-9]+, #65535 @ movhi
> > +**...
> > +*/
> > +uint32x4_t test_32() {
> > + return vdupq_m_n_u32(vdupq_n_u32(0), 0, 0x);
>
> Just a testcase nit. I think testing 0x isn't that useful,
> it tests the same 4 bits 4 times.
> Might be more interesting to test 4 different 4 bit elements,
> one of them 0 (to verify it doesn't turn that into all ones),
> one all 1s (that is the other valid case) and then 2 random
> other values in between.
>
> > +}
> > +
> > +/*
> > +** test_16:
> > +**...
> > +** mov r[0-9]+, #52428 @ movhi
> > +**...
> > +*/
> > +uint16x8_t test_16() {
> > + return vdupq_m_n_u16(vdupq_n_u16(0), 0, 0x);
>
> And for these it can actually test all 4 possible 2 bit elements,
> so say 0x3021
>
> > +}
> > +
> > +/*
> > +** test_8:
> > +**...
> > +** mov r[0-9]+, #52428 @ movhi
> > +**...
> > +*/
> > +uint8x16_t test_8() {
> > + return vdupq_m_n_u8(vdupq_n_u8(0), 0, 0x);
>
> and here use some random pattern.
>
> BTW, the patch is ok for 14.1 if it is approved and committed today
> (so that it can be cherry-picked tomorrow morning at latest to the branch).
Thanks for your comments, I'll update the testcase, but Andre provided
additional info in the PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114801#c17
I tried just removing the call to gcc_unreachable in
rtx_vector_builder::find_cached_value and that does the trick, but I'm
worried by such a change.
Christophe
>
> Jakub
>
Re: [PATCH] rust: Add rust.install-dvi and rust.install-html rules
On Mon, 29 Apr 2024 at 15:24, Arthur Cohen wrote: > > Thanks Christophe! > > I've added your patch as part of a documentation pull-request I'm adding > to our dev repo: https://github.com/Rust-GCC/gccrs/pull/2966 > > It'll be upstreamed with the next batch of commits we send, as soon as > trunk reopens fully for 15.1. > Thanks! Note that I already pushed the patch as r14-9865-g73fb0a6153f478 so you may have conflicts (easy to fix ;-) ) Christophe > Best, > > Arthur > > On 4/4/24 18:27, Christophe Lyon wrote: > > rust has the (empty) rust.dvi and rust.html rules, but lacks the > > (empty) rust.install-dvi and rust.install-html ones. > > > > 2024-04-04 Christophe Lyon > > > > gcc/rust/ > > * Make-lang.in (rust.install-dvi, rust.install-html): New rules. > > --- > > gcc/rust/Make-lang.in | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in > > index 4d646018792..4d73412739d 100644 > > --- a/gcc/rust/Make-lang.in > > +++ b/gcc/rust/Make-lang.in > > @@ -342,6 +342,8 @@ selftest-rust-valgrind: $(RUST_SELFTEST_DEPS) > > # should have dependencies on info files that should be installed. > > rust.install-info: > > > > +rust.install-dvi: > > +rust.install-html: > > rust.install-pdf: > > > > # Install man pages for the front end. This target should ignore errors.
[PATCH] arm: [MVE intrinsics] Fix support for predicate constants [PR target/114801]
In this PR, we have to handle a case where MVE predicates are supplied
as a const_int, where individual predicates have illegal boolean
values (such as 0xc for a 4-bit boolean predicate). To avoid the ICE,
we canonicalize them, replacing a non-null value with -1.
2024-04-26 Christophe Lyon
Jakub Jelinek
PR target/114801
gcc/
* config/arm/arm-mve-builtins.cc
(function_expander::add_input_operand): Handle CONST_INT
predicates.
gcc/testsuite/
* gcc.target/arm/mve/pr114801.c: New test.
---
gcc/config/arm/arm-mve-builtins.cc | 21 +++-
gcc/testsuite/gcc.target/arm/mve/pr114801.c | 36 +
2 files changed, 56 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/arm/mve/pr114801.c
diff --git a/gcc/config/arm/arm-mve-builtins.cc
b/gcc/config/arm/arm-mve-builtins.cc
index 6a5775c67e5..f338ab36434 100644
--- a/gcc/config/arm/arm-mve-builtins.cc
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -43,6 +43,7 @@
#include "stringpool.h"
#include "attribs.h"
#include "diagnostic.h"
+#include "rtx-vector-builder.h"
#include "arm-protos.h"
#include "arm-builtins.h"
#include "arm-mve-builtins.h"
@@ -2205,7 +2206,25 @@ function_expander::add_input_operand (insn_code icode,
rtx x)
mode = GET_MODE (x);
}
else if (VALID_MVE_PRED_MODE (mode))
-x = gen_lowpart (mode, x);
+{
+ if (CONST_INT_P (x) && (mode == V8BImode || mode == V4BImode))
+ {
+ /* In V8BI or V4BI each element has 2 or 4 bits, if those
+bits aren't all the same, it is UB and gen_lowpart might
+ICE. Canonicalize all the 2 or 4 bits to all ones if any
+of them is non-zero. */
+ unsigned HOST_WIDE_INT xi = UINTVAL (x);
+ xi |= ((xi & 0x) << 1) | ((xi & 0x) >> 1);
+ if (mode == V4BImode)
+ xi |= ((xi & 0x) << 2) | ((xi & 0x) >> 2);
+ x = gen_int_mode (xi, HImode);
+ }
+ else if (SUBREG_P (x))
+ /* gen_lowpart on a SUBREG can ICE. */
+ x = force_reg (GET_MODE (x), x);
+
+ x = gen_lowpart (mode, x);
+}
m_ops.safe_grow (m_ops.length () + 1, true);
create_input_operand (_ops.last (), x, mode);
diff --git a/gcc/testsuite/gcc.target/arm/mve/pr114801.c
b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
new file mode 100644
index 000..676b109f9b8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/pr114801.c
@@ -0,0 +1,36 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-add-options arm_v8_1m_mve } */
+/* { dg-final { check-function-bodies "**" "" "" } } */
+
+#include
+
+/*
+** test_32:
+**...
+** mov r[0-9]+, #65535 @ movhi
+**...
+*/
+uint32x4_t test_32() {
+ return vdupq_m_n_u32(vdupq_n_u32(0), 0, 0x);
+}
+
+/*
+** test_16:
+**...
+** mov r[0-9]+, #52428 @ movhi
+**...
+*/
+uint16x8_t test_16() {
+ return vdupq_m_n_u16(vdupq_n_u16(0), 0, 0x);
+}
+
+/*
+** test_8:
+**...
+** mov r[0-9]+, #52428 @ movhi
+**...
+*/
+uint8x16_t test_8() {
+ return vdupq_m_n_u8(vdupq_n_u8(0), 0, 0x);
+}
--
2.34.1
Re: [PATCH] wwwdocs: contribute.html: Update consensus on patch content.
On Fri, 26 Apr 2024 at 10:25, Christophe Lyon wrote: > > On Thu, 25 Apr 2024 at 17:44, Carlos O'Donell wrote: > > > > Discussion is here: > > https://inbox.sourceware.org/gcc/CAPS5khZeWkAD=v8ka9g5eecdnk3bdhfnzjumpvc+hedmkvj...@mail.gmail.com/ > > > > Rough consensus from Jakub Jelinek, Richard Biener and others is > > that maintainers are for the change. > > > > This changes the contribution notes to allow it. > > Thank you Carlos for the patch and helping with the discussions! > > Christophe > And BTW sorry I wasn't able to attend the meeting yesterday, thanks Thiago for raising the question. I have a follow-up one: I think the same applies to binutils, but I don't think any maintainer / contributor expressed an opinion, and IIUC patch policy for binutils is (lightly) documented at https://sourceware.org/binutils/wiki/HowToContribute Maybe Nick can update it? (I don't have such rights) Thanks, Christophe > > --- > > htdocs/contribute.html | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/htdocs/contribute.html b/htdocs/contribute.html > > index 7c1ae323..e8137edc 100644 > > --- a/htdocs/contribute.html > > +++ b/htdocs/contribute.html > > @@ -195,8 +195,9 @@ of your testing. > > > > The patch itself > > > > -Do not include generated files as part of the patch, just mention > > -them in the ChangeLog (e.g., "* configure: Regenerate."). > > +The patch should include everything you are changing (including > > +regenerated files which should be noted in the ChangeLog e.g. > > +"* configure: Regenerate."). > > > > > > > > -- > > 2.44.0 > >
Re: [PATCH] wwwdocs: contribute.html: Update consensus on patch content.
On Thu, 25 Apr 2024 at 17:44, Carlos O'Donell wrote: > > Discussion is here: > https://inbox.sourceware.org/gcc/CAPS5khZeWkAD=v8ka9g5eecdnk3bdhfnzjumpvc+hedmkvj...@mail.gmail.com/ > > Rough consensus from Jakub Jelinek, Richard Biener and others is > that maintainers are for the change. > > This changes the contribution notes to allow it. Thank you Carlos for the patch and helping with the discussions! Christophe > --- > htdocs/contribute.html | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/htdocs/contribute.html b/htdocs/contribute.html > index 7c1ae323..e8137edc 100644 > --- a/htdocs/contribute.html > +++ b/htdocs/contribute.html > @@ -195,8 +195,9 @@ of your testing. > > The patch itself > > -Do not include generated files as part of the patch, just mention > -them in the ChangeLog (e.g., "* configure: Regenerate."). > +The patch should include everything you are changing (including > +regenerated files which should be noted in the ChangeLog e.g. > +"* configure: Regenerate."). > > > > -- > 2.44.0 >
Re: [pushed] c++/modules: make bits_in/out move-constructible
Hi Patrick,
On Sat, 13 Apr 2024 at 22:12, Patrick Palka wrote:
>
> Pushed as obvious after verifying C++11 bootstrap is restored.
I guess this also fixes the bootstrap_ubsan breakage on aarch64
reported by Linaro CI?
See https://linaro.atlassian.net/browse/GNU-1199
(I think you also received a notification about this a few days ago?)
Thanks,
Christophe
>
> -- >8 --
>
> gcc/cp/ChangeLog:
>
> * module.cc (struct bytes_in::bits_in): Define defaulted
> move ctor.
> (struct bytes_out::bits_out): Likewise.
> ---
> gcc/cp/module.cc | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> index bbed82652d4..c6f71e11515 100644
> --- a/gcc/cp/module.cc
> +++ b/gcc/cp/module.cc
> @@ -706,6 +706,7 @@ struct bytes_in::bits_in {
> bflush ();
>}
>
> + bits_in(bits_in&&) = default;
>bits_in(const bits_in&) = delete;
>bits_in& operator=(const bits_in&) = delete;
>
> @@ -752,6 +753,7 @@ struct bytes_out::bits_out {
> bflush ();
>}
>
> + bits_out(bits_out&&) = default;
>bits_out(const bits_out&) = delete;
>bits_out& operator=(const bits_out&) = delete;
>
> --
> 2.44.0.591.g8f7582d995
>
Re: [PATCH] contrib: Add autoregen.py
On Fri, 19 Apr 2024 at 11:03, Christophe Lyon
wrote:
>
> This script is a copy of the current script used by Sourceware's
> autoregen buildbots.
>
> It is intended as a helper to regenerate files managed by autotools
> (autoconf, automake, aclocal, ), as well as the toplevel
> Makefile.in which is created by autogen.
>
> Other files can be updated when using maintainer-mode, but this is not
> covered by this script.
>
> 2024-04-19 Christophe Lyon
>
> contrib/
> * autogen.py: New script.
Of course this should read "autoregen.py" :-)
> ---
> contrib/autoregen.py | 221 +++
> 1 file changed, 221 insertions(+)
> create mode 100755 contrib/autoregen.py
>
> diff --git a/contrib/autoregen.py b/contrib/autoregen.py
> new file mode 100755
> index 000..faffc88c5bd
> --- /dev/null
> +++ b/contrib/autoregen.py
> @@ -0,0 +1,221 @@
> +#!/usr/bin/env python3
> +
> +# This script helps to regenerate files managed by autotools and
> +# autogen in binutils-gdb and gcc repositories.
> +
> +# It can be used by buildbots to check that the current repository
> +# contents has been updated correctly, and by developers to update
> +# such files as expected.
> +
> +import os
> +import shutil
> +import subprocess
> +from pathlib import Path
> +
> +
> +# On Gentoo, vanilla unpatched autotools are packaged separately.
> +# We place the vanilla names first as we want to prefer those if both exist.
> +AUTOCONF_NAMES = ["autoconf-vanilla-2.69", "autoconf-2.69", "autoconf"]
> +AUTOMAKE_NAMES = ["automake-vanilla-1.15", "automake-1.15.1", "automake"]
> +ACLOCAL_NAMES = ["aclocal-vanilla-1.15", "aclocal-1.15.1", "aclocal"]
> +AUTOHEADER_NAMES = ["autoheader-vanilla-2.69", "autoheader-2.69",
> "autoheader"]
> +AUTORECONF_NAMES = ["autoreconf-vanilla-2.69", "autoreconf-2.69",
> "autoreconf"]
> +
> +# Pick the first for each list that exists on this system.
> +AUTOCONF_BIN = next(name for name in AUTOCONF_NAMES if shutil.which(name))
> +AUTOMAKE_BIN = next(name for name in AUTOMAKE_NAMES if shutil.which(name))
> +ACLOCAL_BIN = next(name for name in ACLOCAL_NAMES if shutil.which(name))
> +AUTOHEADER_BIN = next(name for name in AUTOHEADER_NAMES if
> shutil.which(name))
> +AUTORECONF_BIN = next(name for name in AUTORECONF_NAMES if
> shutil.which(name))
> +
> +AUTOGEN_BIN = "autogen"
> +
> +# autoconf-wrapper and automake-wrapper from Gentoo look at this environment
> variable.
> +# It's harmless to set it on other systems though.
> +EXTRA_ENV = {
> +"WANT_AUTOCONF": AUTOCONF_BIN.split("-", 1)[1] if "-" in AUTOCONF_BIN
> else "",
> +"WANT_AUTOMAKE": AUTOMAKE_BIN.split("-", 1)[1] if "-" in AUTOMAKE_BIN
> else "",
> +"AUTOCONF": AUTOCONF_BIN,
> +"ACLOCAL": ACLOCAL_BIN,
> +"AUTOMAKE": AUTOMAKE_BIN,
> +"AUTOGEN": AUTOGEN_BIN,
> +}
> +ENV = os.environ.copy()
> +ENV.update(EXTRA_ENV)
> +
> +
> +# Directories we should skip entirely because they're vendored or have
> different
> +# autotools versions.
> +SKIP_DIRS = [
> +# readline and minizip are maintained with different autotools versions
> +"readline",
> +"minizip",
> +]
> +
> +# these directories are known to be re-generatable with a simple autoreconf
> +# without special -I flags
> +# Entries commented out (and directories not listed) are handled by
> +# regenerate_manually().
> +AUTORECONF_DIRS = [
> +# subdirs common to binutils-gdb and gcc
> +"libbacktrace",
> +"libdecnumber", # No Makefile.am
> +"libiberty", # No Makefile.am
> +"zlib",
> +
> +# binutils-gdb subdirs
> +"bfd",
> +"binutils",
> +"etc",
> +"gas",
> +"gdb",
> +"gdbserver",
> +"gdbsupport",
> +"gnulib",
> +"gold",
> +"gprof",
> +"gprofng",
> +"gprofng/libcollector",
> +"ld",
> +"libctf",
> +"libsframe",
> +"opcodes",
> +"sim",
> +
> +# gcc subdirs
> +"c++tools", # No aclocal.m4
> +"gcc", # No Makefile.am
> +#"fixincludes", # autoreconf complains about GCC_AC_FUNC_MMAP_BLACKLIST
> +"gnattools
[PATCH] contrib: Add autoregen.py
This script is a copy of the current script used by Sourceware's
autoregen buildbots.
It is intended as a helper to regenerate files managed by autotools
(autoconf, automake, aclocal, ), as well as the toplevel
Makefile.in which is created by autogen.
Other files can be updated when using maintainer-mode, but this is not
covered by this script.
2024-04-19 Christophe Lyon
contrib/
* autogen.py: New script.
---
contrib/autoregen.py | 221 +++
1 file changed, 221 insertions(+)
create mode 100755 contrib/autoregen.py
diff --git a/contrib/autoregen.py b/contrib/autoregen.py
new file mode 100755
index 000..faffc88c5bd
--- /dev/null
+++ b/contrib/autoregen.py
@@ -0,0 +1,221 @@
+#!/usr/bin/env python3
+
+# This script helps to regenerate files managed by autotools and
+# autogen in binutils-gdb and gcc repositories.
+
+# It can be used by buildbots to check that the current repository
+# contents has been updated correctly, and by developers to update
+# such files as expected.
+
+import os
+import shutil
+import subprocess
+from pathlib import Path
+
+
+# On Gentoo, vanilla unpatched autotools are packaged separately.
+# We place the vanilla names first as we want to prefer those if both exist.
+AUTOCONF_NAMES = ["autoconf-vanilla-2.69", "autoconf-2.69", "autoconf"]
+AUTOMAKE_NAMES = ["automake-vanilla-1.15", "automake-1.15.1", "automake"]
+ACLOCAL_NAMES = ["aclocal-vanilla-1.15", "aclocal-1.15.1", "aclocal"]
+AUTOHEADER_NAMES = ["autoheader-vanilla-2.69", "autoheader-2.69", "autoheader"]
+AUTORECONF_NAMES = ["autoreconf-vanilla-2.69", "autoreconf-2.69", "autoreconf"]
+
+# Pick the first for each list that exists on this system.
+AUTOCONF_BIN = next(name for name in AUTOCONF_NAMES if shutil.which(name))
+AUTOMAKE_BIN = next(name for name in AUTOMAKE_NAMES if shutil.which(name))
+ACLOCAL_BIN = next(name for name in ACLOCAL_NAMES if shutil.which(name))
+AUTOHEADER_BIN = next(name for name in AUTOHEADER_NAMES if shutil.which(name))
+AUTORECONF_BIN = next(name for name in AUTORECONF_NAMES if shutil.which(name))
+
+AUTOGEN_BIN = "autogen"
+
+# autoconf-wrapper and automake-wrapper from Gentoo look at this environment
variable.
+# It's harmless to set it on other systems though.
+EXTRA_ENV = {
+"WANT_AUTOCONF": AUTOCONF_BIN.split("-", 1)[1] if "-" in AUTOCONF_BIN else
"",
+"WANT_AUTOMAKE": AUTOMAKE_BIN.split("-", 1)[1] if "-" in AUTOMAKE_BIN else
"",
+"AUTOCONF": AUTOCONF_BIN,
+"ACLOCAL": ACLOCAL_BIN,
+"AUTOMAKE": AUTOMAKE_BIN,
+"AUTOGEN": AUTOGEN_BIN,
+}
+ENV = os.environ.copy()
+ENV.update(EXTRA_ENV)
+
+
+# Directories we should skip entirely because they're vendored or have
different
+# autotools versions.
+SKIP_DIRS = [
+# readline and minizip are maintained with different autotools versions
+"readline",
+"minizip",
+]
+
+# these directories are known to be re-generatable with a simple autoreconf
+# without special -I flags
+# Entries commented out (and directories not listed) are handled by
+# regenerate_manually().
+AUTORECONF_DIRS = [
+# subdirs common to binutils-gdb and gcc
+"libbacktrace",
+"libdecnumber", # No Makefile.am
+"libiberty", # No Makefile.am
+"zlib",
+
+# binutils-gdb subdirs
+"bfd",
+"binutils",
+"etc",
+"gas",
+"gdb",
+"gdbserver",
+"gdbsupport",
+"gnulib",
+"gold",
+"gprof",
+"gprofng",
+"gprofng/libcollector",
+"ld",
+"libctf",
+"libsframe",
+"opcodes",
+"sim",
+
+# gcc subdirs
+"c++tools", # No aclocal.m4
+"gcc", # No Makefile.am
+#"fixincludes", # autoreconf complains about GCC_AC_FUNC_MMAP_BLACKLIST
+"gnattools", # No aclocal.m4
+"gotools",
+"libada", # No aclocal.m4
+"libatomic",
+"libcc1",
+"libcody", # No aclocal.m4
+"libcpp", # No Makefile.am
+"libffi",
+"libgcc", # No aclocal.m4
+"libgfortran",
+# Hack: ACLOCAL_AMFLAGS = -I .. -I ../config in Makefile.in but we
+# apply -I../config -I.. otherwise we do not match the current
+# contents
+#"libgm2",
+"libgo",
+"libgomp",
+"libgrust",
+"libitm",
+"libobjc", # No Makefile.am
+"libphobos",
+"libquadmath",
+&quo
Re: [PATCH] libgcc: Fix up __divmodbitint4 [PR114755]
On Thu, 18 Apr 2024 at 09:37, Jakub Jelinek wrote:
>
> Hi!
>
> The following testcase aborts on aarch64-linux but does not on x86_64-linux.
> In both cases there is UB in the __divmodbitint4 implemenetation.
> When the divisor is negative with most significant limb (even when partial)
> all ones, has at least 2 limbs and the second most significant limb has the
> most significant bit clear, when this number is negated, it will have 0
> in the most significant limb.
> Already in the PR114397 r14-9592 fix I was dealing with such divisors, but
> thought the problem is only if because of that un < vn doesn't imply the
> quotient is 0 and remainder u.
> But as this testcase shows, the problem is with such divisors always.
> What happens is that we use __builtin_clz* on the most significant limb,
> and assume it will not be 0 because that is UB for the builtins.
> Normally the most significant limb of the divisor shouldn't be 0, as
> guaranteed by the bitint_reduce_prec e.g. for the positive numbers, unless
> the divisor is just 0 (but for vn == 1 we have special cases).
Just curious: could this have been caught by ubsan? (I don't know if
it knows about clz)
Thanks,
Christophe
>
> The following patch moves the handling of this corner case a few lines
> earlier before the un < vn check, because adjusting the vn later is harder.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, plus tested with
> make check-gcc -j32 -k GCC_TEST_RUN_EXPENSIVE=1
> RUNTESTFLAGS="GCC_TEST_RUN_EXPENSIVE=1 dg.exp='*bitint* pr112673.c
> builtin-stdc-bit-*.c pr112566-2.c pr112511.c' dg-torture.exp=*bitint*
> dfp.exp=*bitint*"
> on aarch64-linux, ok for trunk?
>
> 2024-04-18 Jakub Jelinek
>
> PR libgcc/114755
> * libgcc2.c (__divmodbitint4): Perform the decrement on negative
> v with most significant limb all ones and the second least
> significant limb with most significant bit clear always, regardless of
> un < vn.
>
> * gcc.dg/torture/bitint-69.c: New test.
>
> --- libgcc/libgcc2.c.jj 2024-03-21 13:07:43.629886730 +0100
> +++ libgcc/libgcc2.c2024-04-17 19:00:55.453691368 +0200
> @@ -1705,69 +1705,62 @@ __divmodbitint4 (UBILtype *q, SItype qpr
>USItype rn = ((USItype) rprec + W_TYPE_SIZE - 1) / W_TYPE_SIZE;
>USItype up = auprec % W_TYPE_SIZE;
>USItype vp = avprec % W_TYPE_SIZE;
> + /* If vprec < 0 and the top limb of v is all ones and the second most
> + significant limb has most significant bit clear, then just decrease
> + vn/avprec/vp, because after negation otherwise v2 would have most
> + significant limb clear. */
> + if (vprec < 0
> + && ((v[BITINT_END (0, vn - 1)] | (vp ? ((UWtype) -1 << vp) : 0))
> + == (UWtype) -1)
> + && vn > 1
> + && (Wtype) v[BITINT_END (1, vn - 2)] >= 0)
> +{
> + vp = 0;
> + --vn;
> +#if __LIBGCC_BITINT_ORDER__ == __ORDER_BIG_ENDIAN__
> + ++v;
> +#endif
> +}
>if (__builtin_expect (un < vn, 0))
> {
> - /* If abs(v) > abs(u), then q is 0 and r is u.
> -Unfortunately un < vn doesn't always mean abs(v) > abs(u).
> -If uprec > 0 and vprec < 0 and vn == un + 1, if the
> -top limb of v is all ones and the second most significant
> -limb has most significant bit clear, then just decrease
> -vn/avprec/vp and continue, after negation both numbers
> -will have the same number of limbs. */
> - if (un + 1 == vn
> - && uprec >= 0
> - && vprec < 0
> - && ((v[BITINT_END (0, vn - 1)] | (vp ? ((UWtype) -1 << vp) : 0))
> - == (UWtype) -1)
> - && (Wtype) v[BITINT_END (1, vn - 2)] >= 0)
> - {
> - vp = 0;
> - --vn;
> + /* q is 0 and r is u. */
> + if (q)
> + __builtin_memset (q, 0, qn * sizeof (UWtype));
> + if (r == NULL)
> + return;
> #if __LIBGCC_BITINT_ORDER__ == __ORDER_BIG_ENDIAN__
> - ++v;
> + r += rn - 1;
> + u += un - 1;
> #endif
> + if (up)
> + --un;
> + if (rn < un)
> + un = rn;
> + for (rn -= un; un; --un)
> + {
> + *r = *u;
> + r += BITINT_INC;
> + u += BITINT_INC;
> }
> - else
> + if (!rn)
> + return;
> + if (up)
> {
> - /* q is 0 and r is u. */
> - if (q)
> - __builtin_memset (q, 0, qn * sizeof (UWtype));
> - if (r == NULL)
> + if (uprec > 0)
> + *r = *u & (((UWtype) 1 << up) - 1);
> + else
> + *r = *u | ((UWtype) -1 << up);
> + r += BITINT_INC;
> + if (!--rn)
> return;
> -#if __LIBGCC_BITINT_ORDER__ == __ORDER_BIG_ENDIAN__
> - r += rn - 1;
> - u += un - 1;
> -#endif
> - if (up)
> - --un;
> - if (rn < un)
> - un = rn;
> - for (rn -= un; un; --un)
> - {
> - *r = *u;
> - r += BITINT_INC;
> - u +=
Re: Updated Sourceware infrastructure plans
Hi, On Thu, 18 Apr 2024 at 10:15, FX Coudert wrote: > > > I regenerate auto* files from time to time for libgfortran. Regenerating > > them has always been very fragile (using --enable-maintainer-mode), > > and difficult to get right. > > I have never found them difficult to regenerate, but if you have only a non > maintainer build, it is a pain to have to make a new maintainer build for a > minor change. > FWIW, we have noticed lots of warnings from autoreconf in libgfortran. I didn't try to investigate, since the regenerated files are identical to what is currently in the repo. For instance, you can download the "stdio" output from the autoregen.py step in https://builder.sourceware.org/buildbot/#/builders/269/builds/4373 Thanks, Christophe > Moreover, our m4 code is particularly painful to use and unreadable. I have > been wondering for some time: should we switch to simpler Python scripts? It > would also mean that we would have fewer files in the generated/ folder: > right now, every time we add new combinations of types, we have a > combinatorial explosion of files. > > $ ls generated/sum_* > generated/sum_c10.c generated/sum_c17.c generated/sum_c8.c > generated/sum_i16.c generated/sum_i4.c generated/sum_r10.c > generated/sum_r17.c generated/sum_r8.c > generated/sum_c16.c generated/sum_c4.c generated/sum_i1.c > generated/sum_i2.c generated/sum_i8.c generated/sum_r16.c generated/sum_r4.c > > We could imagine having a single file for all sum intrinsics. > > How do Fortran maintainers feel about that? > > FX
[gcc r14-10006] libcpp: Regenerate aclocal.m4 and configure [PR 114748]
https://gcc.gnu.org/g:a9fefbf71726bb0ce89c79e547ab3319af3227a8 commit r14-10006-ga9fefbf71726bb0ce89c79e547ab3319af3227a8 Author: Christophe Lyon Date: Wed Apr 17 13:56:19 2024 + libcpp: Regenerate aclocal.m4 and configure [PR 114748] As discussed in the PR, aclocal.m4 and configure were incorrectly regenerated at some point. 2024-04-17 Christophe Lyon PR preprocessor/114748 libcpp/ * aclocal.m4: Regenerate. * configure: Regenerate. Diff: --- libcpp/aclocal.m4 | 1 + libcpp/configure | 3 +++ 2 files changed, 4 insertions(+) diff --git a/libcpp/aclocal.m4 b/libcpp/aclocal.m4 index 4fc81709622..4d898ea2c97 100644 --- a/libcpp/aclocal.m4 +++ b/libcpp/aclocal.m4 @@ -26,6 +26,7 @@ m4_include([../config/lib-ld.m4]) m4_include([../config/lib-link.m4]) m4_include([../config/lib-prefix.m4]) m4_include([../config/nls.m4]) +m4_include([../config/override.m4]) m4_include([../config/po.m4]) m4_include([../config/progtest.m4]) m4_include([../config/warnings.m4]) diff --git a/libcpp/configure b/libcpp/configure index 8a38c0546e3..32d6aaa3069 100755 --- a/libcpp/configure +++ b/libcpp/configure @@ -2670,6 +2670,9 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu + + + ac_aux_dir= for ac_dir in "$srcdir" "$srcdir/.." "$srcdir/../.."; do if test -f "$ac_dir/install-sh"; then
[PATCH] libcpp: Regenerate aclocal.m4 and configure [PR 114748]
As discussed in the PR, aclocal.m4 and configure were incorrectly regenerated at some point. 2024-04-17 Christophe Lyon PR preprocessor/114748 libcpp/ * aclocal.m4: Regenerate. * configure: Regenerate. --- libcpp/aclocal.m4 | 1 + libcpp/configure | 3 +++ 2 files changed, 4 insertions(+) diff --git a/libcpp/aclocal.m4 b/libcpp/aclocal.m4 index 4fc81709622..4d898ea2c97 100644 --- a/libcpp/aclocal.m4 +++ b/libcpp/aclocal.m4 @@ -26,6 +26,7 @@ m4_include([../config/lib-ld.m4]) m4_include([../config/lib-link.m4]) m4_include([../config/lib-prefix.m4]) m4_include([../config/nls.m4]) +m4_include([../config/override.m4]) m4_include([../config/po.m4]) m4_include([../config/progtest.m4]) m4_include([../config/warnings.m4]) diff --git a/libcpp/configure b/libcpp/configure index 8a38c0546e3..32d6aaa3069 100755 --- a/libcpp/configure +++ b/libcpp/configure @@ -2670,6 +2670,9 @@ ac_compiler_gnu=$ac_cv_c_compiler_gnu + + + ac_aux_dir= for ac_dir in "$srcdir" "$srcdir/.." "$srcdir/../.."; do if test -f "$ac_dir/install-sh"; then -- 2.34.1
Re: [PATCH] [testsuite] Fix pretty printers regexps for GDB output
ping?
On Tue, 6 Feb 2024 at 10:26, Christophe Lyon wrote:
>
> ping?
>
> On Thu, 25 Jan 2024 at 16:54, Christophe Lyon
> wrote:
> >
> > On Wed, 24 Jan 2024 at 12:02, Jonathan Wakely wrote:
> > >
> > > On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
> > > >
> > > > GDB emits end of lines as \r\n, we currently match the reverse \n\r,
> > >
> > > We currently match [\n\r]+ which should match any of \n, \r, \n\r or \r\n
> > >
> >
> > Hmm, right, sorry I had this patch in my tree for quite some time, but
> > wrote the description just now, so I read a bit too quickly.
> >
> > >
> > > > possibly leading to mismatches under racy conditions.
> > >
> > > What do we incorrectly match? Is the problem that a \r\n sequence
> > > might be incompletely printed, due to buffering, and so the regex only
> > > sees (and matches) the \r which then leaves an unwanted \n in the
> > > stream, which then interferes with the next match? I don't understand
> > > why that problem wouldn't just result in a failed match with your new
> > > regex though.
> > >
> > Exactly: READ1 forces read() to return 1 byte at a time, so we leave
> > an unwanted \r in front of a string that should otherwise match the
> > "got" case.
> >
> > >
> > > >
> > > > I noticed this while running the GCC testsuite using the equivalent of
> > > > GDB's READ1 feature [1] which helps detecting bufferization issues.
> > > >
> > > > Adjusting the first regexp to match the right order implied fixing the
> > > > second one, to skip the empty lines.
> > >
> > > At the very least, this part of the description is misleading. The
> > > existing regex matches "the right order" already. The change is to
> > > match *exactly* \r\n instead of any mix of CR and LF characters.
> > > That's not about matching "the right order", it's being more precise
> > > in what we match.
> > >
> > > But I'm still confused about what the failure scenario is and how the
> > > change fixes it.
> > >
> >
> > I followed what the GDB testsuite does (it matches \r\n at the end of
> > many regexps), but in fact it seems it's not needed:
> > it works if I update the "got" regexp like this (ie. accept any number
> > of leading \r or \n):
> > - -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> > + -re {^[\n\r]*(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> > and leave the "skipping" regexp as it is currently.
> >
> > Is the new attached version OK?
> >
> > Thanks,
> >
> > Christophe
> >
> > > >
> > > > Tested on aarch64-linux-gnu.
> > > >
> > > > [1]
> > > > https//github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269
> > > >
> > > > 2024-01-24 Christophe Lyon
> > > >
> > > > libstdc++-v3/
> > > > * testsuite/lib/gdb-test.exp (gdb-test): Fix regexps.
> > > > ---
> > > > libstdc++-v3/testsuite/lib/gdb-test.exp | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > > b/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > > index 31206f2fc32..0de8d9ee153 100644
> > > > --- a/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > > +++ b/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > > @@ -194,7 +194,7 @@ proc gdb-test { marker {selector {}} {load_xmethods
> > > > 0} } {
> > > >
> > > > set test_counter 0
> > > > remote_expect target [timeout_value] {
> > > > - -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> > > > + -re {^(type|\$([0-9]+)) = ([^\n\r]*)\r\n} {
> > > > send_log "got: $expect_out(buffer)"
> > > >
> > > > incr test_counter
> > > > @@ -250,7 +250,7 @@ proc gdb-test { marker {selector {}} {load_xmethods
> > > > 0} } {
> > > > return
> > > > }
> > > >
> > > > - -re {^[^$][^\n\r]*[\n\r]+} {
> > > > + -re {^[\r\n]*[^$][^\n\r]*\r\n} {
> > > > send_log "skipping: $expect_out(buffer)"
> > > > exp_continue
> > > > }
> > > > --
> > > > 2.34.1
> > > >
> > >
[gcc r14-9865] rust: Add rust.install-dvi and rust.install-html rules
https://gcc.gnu.org/g:73fb0a6153f4781587c925c56683b61632e63dee commit r14-9865-g73fb0a6153f4781587c925c56683b61632e63dee Author: Christophe Lyon Date: Thu Apr 4 16:21:46 2024 + rust: Add rust.install-dvi and rust.install-html rules rust has the (empty) rust.dvi and rust.html rules, but lacks the (empty) rust.install-dvi and rust.install-html ones. 2024-04-04 Christophe Lyon gcc/rust/ * Make-lang.in (rust.install-dvi, rust.install-html): New rules. Diff: --- gcc/rust/Make-lang.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in index 4d646018792..4d73412739d 100644 --- a/gcc/rust/Make-lang.in +++ b/gcc/rust/Make-lang.in @@ -342,6 +342,8 @@ selftest-rust-valgrind: $(RUST_SELFTEST_DEPS) # should have dependencies on info files that should be installed. rust.install-info: +rust.install-dvi: +rust.install-html: rust.install-pdf: # Install man pages for the front end. This target should ignore errors.
Re: [RFC] add regenerate Makefile target
Hi, On Mon, 25 Mar 2024 at 15:19, Christophe Lyon wrote: > > On Thu, 21 Mar 2024 at 15:32, Christophe Lyon > wrote: > > > > On Wed, 20 Mar 2024 at 16:34, Simon Marchi wrote: > > > > > > On 3/18/24 13:25, Christophe Lyon wrote: > > > > Well the rule to regenerate Makefile.in (eg in in opcodes/) is a bit > > > > more complex > > > > than just calling automake. IIUC it calls automake --foreign it any of > > > > *.m4 file from $(am__configure_deps) that is newer than Makefile.in > > > > (with an early exit in the loop), does nothing if Makefile.am or > > > > doc/local.mk are newer than Makefile.in, and then calls 'automake > > > > --foreign Makefile' > > > > > > The rules looks complex because they've been generated by automake, this > > > Makefile.in is not written by hand. And I guess automake has put > > > `--foreign` there because foreign is used in Makefile.am: > > Yes, I know :-) > > > > > > > > AUTOMAKE_OPTIONS = foreign no-dist > > > > > > But a simple call so `automake -f` (or `autoreconf -f`) just works, as > > > automake picks up the foreign option from AUTOMAKE_OPTIONS, so a human > > > or an external script who wants to regenerate things would probably just > > > use that. > > > > Indeed. I guess my concern is: if some change happens to > > Makefile.am/Makefile.in which would imply that 'autoreconf -f' would > > not work, how do we make sure autoregen.py (or whatever script) is > > updated accordingly? Or maybe whatever change is made to > > Makefile.am/Makefile.in, 'autoreconf -f' is supposed to handle it > > without additional flag? > > > I think I've just noticed a variant of this: if you look at > opcodes/Makefile.in, you can see that aclocal.m4 depends on > configure.ac (among others). So if configure.ac is updated, a > maintainer-mode rule in Makefile.in will call aclocal and regenerate > aclocal.m4. > > However, autoregen.py calls aclocal only if configure.ac contains > AC_CONFIG_MACRO_DIRS, which is not the case here. > > That's probably a bug in opcode/configure.ac, but still the current > Makefile.in machinery would update aclocal.m4 as needed when > autoregen.py will not. > > I haven't audited all configure.ac but there are probably other > occurrences of this. > Another discrepancy I've just noticed: if you look at libsframe/Makefile.am, you can see that ACLOCAL_AMFLAGS = -I .. -I ../config -I ../bfd, so if you run autoreconf -f, it will invoke aclocal with these flags (the same is performed by the aclocal.m4 regeneration rule in the Makefile), but autoregen.py won't run aclocal because configure.ac does not define AC_CONFIG_MACRO_DIRS, and even if it did, it would only use -I../config I guess the same applies for several other subdirs. So in general how do we make sure autoregen.py uses the right flags? Or what prevents us from just using autoreconf -f? If that does not work because configure.ac/Makeline.am and others have bugs, maybe we should fix those bugs instead? which makes me think about Eric's reply: > `autoreconf -f` works fine in individual subdirectories, the problem > is that the top-level configure.ac doesn't use the AC_CONFIG_SUBDIRS > macro to specify its subdirectories, but rather uses its own > hand-rolled method of specifying subdirectories that autoreconf > doesn't know about. This means that autoreconf won't automatically > recurse into all the necessary subdirectories by itself automatically, > and instead has to be run manually in each subdirectory separately. It's not clear to me if that "problem" is a bug, or a design decision we must take into account when writing tools to help regeneration? > Also the various subdirectories are inconsistent about whether they > have a rule for running it (autoreconf) from the Makefile or not, should that be considered a bug, and fixed? > which usually comes down to whether the subdirectory uses automake for > its Makefile or not (the top-level Makefile doesn't; it uses its own > weird autogen-based regeneration method instead, which means that it > misses out on all the built-in rules that automake would implicitly > generate, including ones related to build system regeneration). Thanks, Christophe > Christophe > > > > > > > > The bot I want to put in place would regenerate things as they are > > > > supposed to be, then build and run the testsuite to make sure that > > > > what is supposed to be committed would work (if the committer > > > > regenerates everything correctly) > > > > > > For your job, would it be fine to just force-regenerate
[gcc r14-9807] modula2: Add m2.install-dvi in gcc/m2/Make-lang.in
https://gcc.gnu.org/g:6f1005649ff5f544eefba29ba4fb121dba0c6683 commit r14-9807-g6f1005649ff5f544eefba29ba4fb121dba0c6683 Author: Christophe Lyon Date: Thu Apr 4 16:15:12 2024 + modula2: Add m2.install-dvi in gcc/m2/Make-lang.in m2 has a m2.dvi build rule, but lacks the m2.install-dvi one. 2024-04-04 Christophe Lyon gcc/m2/ * Make-lang.in (m2.install-dvi): New rule. Diff: --- gcc/m2/Make-lang.in | 12 1 file changed, 12 insertions(+) diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in index e56240b4c44..0abd8ce1455 100644 --- a/gcc/m2/Make-lang.in +++ b/gcc/m2/Make-lang.in @@ -162,6 +162,18 @@ m2.dvi: doc/m2.dvi doc/m2.dvi: $(TEXISRC) $(objdir)/m2/images/gnu.eps $(TEXI2DVI) -c -I $(objdir)/m2 -I $(srcdir)/doc/include -o $@ $(srcdir)/doc/gm2.texi +M2_DVIFILES = doc/m2.dvi + +m2.install-dvi: $(M2_DVIFILES) + @$(NORMAL_INSTALL) + test -z "$(dvidir)/gcc" || $(mkinstalldirs) "$(DESTDIR)$(dvidir)/gcc" + @list='$(M2_DVIFILES)'; for p in $$list; do \ + if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ + f=$(dvi__strip_dir) \ + echo " $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(dvidir)/gcc/$$f'"; \ + $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(dvidir)/gcc/$$f"; \ + done + doc/m2.ps: doc/m2.dvi dvips -o $@ $<
Re: Patches submission policy change
On Thu, 4 Apr 2024 at 10:12, Jan Beulich wrote: > > On 03.04.2024 15:11, Christophe Lyon wrote: > > On Wed, 3 Apr 2024 at 10:30, Jan Beulich wrote: > >> > >> On 03.04.2024 10:22, Christophe Lyon wrote: > >>> Dear release managers and developers, > >>> > >>> TL;DR: For the sake of improving precommit CI coverage and simplifying > >>> workflows, I’d like to request a patch submission policy change, so > >>> that we now include regenerated files. This was discussed during the > >>> last GNU toolchain office hours meeting [1] (2024-03-28). > >>> > >>> Benefits or this change include: > >>> - Increased compatibility with precommit CI > >>> - No need to manually edit patches before submitting, thus the “git > >>> send-email” workflow is simplified > >>> - Patch reviewers can be confident that the committed patch will be > >>> exactly what they approved > >>> - Precommit CI can test exactly what has been submitted > >>> > >>> Any concerns/objections? > >> > >> Yes: Patch size. And no, not sending patches inline is bad practice. > > Not sure what you mean? Do you mean sending patches as attachments is > > bad practice? > > Yes. It makes it difficult to reply to them (with proper reply context). Agreed. > > >> Even assuming sending patches bi-modal (inline and as attachment) works > >> (please indicate whether that's the case), it would mean extra work on > >> the sending side. > >> > > For the CI perspective, we use what patchwork is able to detect as patches. > > Looking at recent patches submissions, it seems patchwork is able to > > cope with the output of git format-patch/git send-email, as well as > > attachments. > > There are cases where patchwork is not able to detect the patch, but I > > don't know patchwork's exact specifications. > > Question was though: If a patch was sent inline plus attachment, what > would CI use as the patch to apply? IOW would it be an option to > attach the un-stripped patch, while inlining the stripped one? > Sorry, I don't know how patchwork would handle such a case. Thanks, Christophe > Jan >
Re: Patches submission policy change
Hi Mark, On 4/4/24 23:35, Mark Wielaard wrote: Hi Christophe, On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon via Gdb wrote: TL;DR: For the sake of improving precommit CI coverage and simplifying workflows, I’d like to request a patch submission policy change, so that we now include regenerated files. This was discussed during the last GNU toolchain office hours meeting [1] (2024-03-28). Benefits or this change include: - Increased compatibility with precommit CI - No need to manually edit patches before submitting, thus the “git send-email” workflow is simplified - Patch reviewers can be confident that the committed patch will be exactly what they approved - Precommit CI can test exactly what has been submitted Any concerns/objections? I am all for it. It will make testing patches easier for everyone. I do think we still need a better way to make sure all generated files can be regenerated. If only to check that the files were generated correctly with the correct versions. The autoregen buildbots are able to catch some, but not all such mistakes. wrt to the mailinglists maybe getting larger patches, I think most will still be under 400K and I wouldn't raise the limit (because most such larger emails are really just spam). But we might want to get more mailinglist moderators. gcc-patches, binutils and gdb-patches all have only one moderator (Jeff, Ian and Thiago). It would probably be good if there were more. Any volunteers? It shouldn't be more than 1 to 3 emails a week (sadly most of them spam). I'm happy to help with moderation of any/all of these 3 lists. Thanks, Christophe Cheers, Mark
[gcc r14-9800] go: Add go.install-dvi rule in go/Make-lang.in
https://gcc.gnu.org/g:12b04452b40d49bb5322653cb5716b1ebf71b73d commit r14-9800-g12b04452b40d49bb5322653cb5716b1ebf71b73d Author: Christophe Lyon Date: Thu Apr 4 16:18:52 2024 + go: Add go.install-dvi rule in go/Make-lang.in go has a go.dvi build rule, but lacks the go.install-dvi one. 2024-04-04 Christophe Lyon gcc/go/ * Make-lang.in (go.install-dvi): New rule. Diff: --- gcc/go/Make-lang.in | 10 ++ 1 file changed, 10 insertions(+) diff --git a/gcc/go/Make-lang.in b/gcc/go/Make-lang.in index 9a31eafa219..5c569a40389 100644 --- a/gcc/go/Make-lang.in +++ b/gcc/go/Make-lang.in @@ -175,6 +175,16 @@ go.install-pdf: doc/gccgo.pdf $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(pdfdir)/gcc/$$f"; \ done +go.install-dvi: doc/gccgo.dvi + @$(NORMAL_INSTALL) + test -z "$(dvidir)" || $(mkinstalldirs) "$(DESTDIR)$(dvidir)/gcc" + @for p in doc/gccgo.dvi; do \ + if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ + f=$(dvi__strip_dir) \ + echo " $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(dvidir)/gcc/$$f'"; \ + $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(dvidir)/gcc/$$f"; \ + done + go.install-html: $(build_htmldir)/go @$(NORMAL_INSTALL) test -z "$(htmldir)" || $(mkinstalldirs) "$(DESTDIR)$(htmldir)"
[PATCH] rust: Add rust.install-dvi and rust.install-html rules
rust has the (empty) rust.dvi and rust.html rules, but lacks the (empty) rust.install-dvi and rust.install-html ones. 2024-04-04 Christophe Lyon gcc/rust/ * Make-lang.in (rust.install-dvi, rust.install-html): New rules. --- gcc/rust/Make-lang.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gcc/rust/Make-lang.in b/gcc/rust/Make-lang.in index 4d646018792..4d73412739d 100644 --- a/gcc/rust/Make-lang.in +++ b/gcc/rust/Make-lang.in @@ -342,6 +342,8 @@ selftest-rust-valgrind: $(RUST_SELFTEST_DEPS) # should have dependencies on info files that should be installed. rust.install-info: +rust.install-dvi: +rust.install-html: rust.install-pdf: # Install man pages for the front end. This target should ignore errors. -- 2.34.1
[PATCH] modula2: Add m2.install-dvi in gcc/m2/Make-lang.in
m2 has a m2.dvi build rule, but lacks the m2.install-dvi one. 2024-04-04 Christophe Lyon gcc/m2/ * Make-lang.in (m2.install-dvi): New rule. --- gcc/m2/Make-lang.in | 12 1 file changed, 12 insertions(+) diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in index e56240b4c44..0abd8ce1455 100644 --- a/gcc/m2/Make-lang.in +++ b/gcc/m2/Make-lang.in @@ -162,6 +162,18 @@ m2.dvi: doc/m2.dvi doc/m2.dvi: $(TEXISRC) $(objdir)/m2/images/gnu.eps $(TEXI2DVI) -c -I $(objdir)/m2 -I $(srcdir)/doc/include -o $@ $(srcdir)/doc/gm2.texi +M2_DVIFILES = doc/m2.dvi + +m2.install-dvi: $(M2_DVIFILES) + @$(NORMAL_INSTALL) + test -z "$(dvidir)/gcc" || $(mkinstalldirs) "$(DESTDIR)$(dvidir)/gcc" + @list='$(M2_DVIFILES)'; for p in $$list; do \ + if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ + f=$(dvi__strip_dir) \ + echo " $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(dvidir)/gcc/$$f'"; \ + $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(dvidir)/gcc/$$f"; \ + done + doc/m2.ps: doc/m2.dvi dvips -o $@ $< -- 2.34.1
[PATCH] go: Add go.install-dvi rule in go/Make-lang.in
go has a go.dvi build rule, but lacks the go.install-dvi one. 2024-04-04 Christophe Lyon gcc/go/ * Make-lang.in (go.install-dvi): New rule. --- gcc/go/Make-lang.in | 10 ++ 1 file changed, 10 insertions(+) diff --git a/gcc/go/Make-lang.in b/gcc/go/Make-lang.in index 9a31eafa219..5c569a40389 100644 --- a/gcc/go/Make-lang.in +++ b/gcc/go/Make-lang.in @@ -175,6 +175,16 @@ go.install-pdf: doc/gccgo.pdf $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(pdfdir)/gcc/$$f"; \ done +go.install-dvi: doc/gccgo.dvi + @$(NORMAL_INSTALL) + test -z "$(dvidir)" || $(mkinstalldirs) "$(DESTDIR)$(dvidir)/gcc" + @for p in doc/gccgo.dvi; do \ + if test -f "$$p"; then d=; else d="$(srcdir)/"; fi; \ + f=$(dvi__strip_dir) \ + echo " $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(dvidir)/gcc/$$f'"; \ + $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(dvidir)/gcc/$$f"; \ + done + go.install-html: $(build_htmldir)/go @$(NORMAL_INSTALL) test -z "$(htmldir)" || $(mkinstalldirs) "$(DESTDIR)$(htmldir)" -- 2.34.1
Re: Patches submission policy change
On Wed, 3 Apr 2024 at 14:59, Joel Sherrill wrote: > > Another possible issue which may be better now than in years past > is that the versions of autoconf/automake required often had to be > installed by hand. I think newlib has gotten better but before the > rework on its Makefile/configure, I had a special install of autotools > which precisely matched what it required. > > And that led to very few people being able to successfully regenerate. > > Is that avoidable? > > OTOH the set of people touching these files may be small enough that > pain isn't an issue. > For binutils/gcc/gdb we still have to use specific versions which are generally not the distro's ones. So indeed, the number of people having to update autotools-related files is relatively small, but there are other files which are regenerated during the build process when maintainer-mode is enabled (for instance parts of the gcc documentation, or opcodes tables in binutils, and these are modified by more people. Thanks, Christophe > --joel > > On Wed, Apr 3, 2024 at 5:22 AM Jan Beulich via Gcc wrote: >> >> On 03.04.2024 10:57, Richard Biener wrote: >> > On Wed, 3 Apr 2024, Jan Beulich wrote: >> >> On 03.04.2024 10:45, Jakub Jelinek wrote: >> >>> On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote: >> >>>> Any concerns/objections? >> >>> >> >>> I'm all for it, in fact I've been sending it like that myself for years >> >>> even when the policy said not to. In most cases, the diff for the >> >>> regenerated files is very small and it helps even in patch review to >> >>> actually check if the configure.ac/m4 etc. changes result just in the >> >>> expected changes and not some unrelated ones (e.g. caused by user using >> >>> wrong version of autoconf/automake etc.). >> >>> There can be exceptions, e.g. when in GCC we update from a new version >> >>> of Unicode, the regenerated ucnid.h diff can be large and >> >>> uname2c.h can be huge, such that it can trigger the mailing list size >> >>> limits even when the patch is compressed, see e.g. >> >>> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636427.html >> >>> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636426.html >> >>> But I think most configure or Makefile changes should be pretty small, >> >>> usual changes shouldn't rewrite everything in those files. >> >> >> >> Which may then call for a policy saying "include generate script diff-s, >> >> but don't include generated data file ones"? At least on the binutils >> >> side, dealing (for CI) with what e.g. opcodes/*-gen produce ought to be >> >> possible by having something along the lines of "maintainer mode light". >> > >> > I'd say we should send generated files when it fits the mailing list >> > limits (and possibly simply lift those limits?). >> >> Well, that would allow patches making it through, but it would still >> severely increase overall size. I'm afraid more people than not also >> fail to cut down reply context, so we'd further see (needlessly) huge >> replies to patches as well. >> >> Additionally - how does one up front determine "fits the mailing list >> limits"? My mail UI (Thunderbird) doesn't show me the size of a message >> until I've actually sent it. >> >> > As a last resort >> > do a series splitting the re-generation out (but I guess this would >> > confuse the CI as well and of course for the push you want to squash >> > again). >> >> Yeah, unless the CI would only ever test full series, this wouldn't help. >> It's also imo even more cumbersome than simply stripping the generated >> file parts from emails. >> >> Jan
Re: Patches submission policy change
On Wed, 3 Apr 2024 at 12:21, Jan Beulich wrote: > > On 03.04.2024 10:57, Richard Biener wrote: > > On Wed, 3 Apr 2024, Jan Beulich wrote: > >> On 03.04.2024 10:45, Jakub Jelinek wrote: > >>> On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon wrote: > >>>> Any concerns/objections? > >>> > >>> I'm all for it, in fact I've been sending it like that myself for years > >>> even when the policy said not to. In most cases, the diff for the > >>> regenerated files is very small and it helps even in patch review to > >>> actually check if the configure.ac/m4 etc. changes result just in the > >>> expected changes and not some unrelated ones (e.g. caused by user using > >>> wrong version of autoconf/automake etc.). > >>> There can be exceptions, e.g. when in GCC we update from a new version > >>> of Unicode, the regenerated ucnid.h diff can be large and > >>> uname2c.h can be huge, such that it can trigger the mailing list size > >>> limits even when the patch is compressed, see e.g. > >>> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636427.html > >>> https://gcc.gnu.org/pipermail/gcc-patches/2023-November/636426.html > >>> But I think most configure or Makefile changes should be pretty small, > >>> usual changes shouldn't rewrite everything in those files. > >> > >> Which may then call for a policy saying "include generate script diff-s, > >> but don't include generated data file ones"? At least on the binutils > >> side, dealing (for CI) with what e.g. opcodes/*-gen produce ought to be > >> possible by having something along the lines of "maintainer mode light". > > > > I'd say we should send generated files when it fits the mailing list > > limits (and possibly simply lift those limits?). > > Well, that would allow patches making it through, but it would still > severely increase overall size. I'm afraid more people than not also > fail to cut down reply context, so we'd further see (needlessly) huge > replies to patches as well. > > Additionally - how does one up front determine "fits the mailing list > limits"? My mail UI (Thunderbird) doesn't show me the size of a message > until I've actually sent it. > > > As a last resort > > do a series splitting the re-generation out (but I guess this would > > confuse the CI as well and of course for the push you want to squash > > again). > > Yeah, unless the CI would only ever test full series, this wouldn't help. > It's also imo even more cumbersome than simply stripping the generated > file parts from emails. > Our CI starts by testing the full series, then iterates by dropping the top-most patches one by one, to make sure no patch breaks something that is fixed in a later patch. This is meant to be additional information for patch reviewers, if they use patchwork to assist them. Other CIs may behave differently though. Thanks, Christophe > Jan
Re: Patches submission policy change
On Wed, 3 Apr 2024 at 10:30, Jan Beulich wrote: > > On 03.04.2024 10:22, Christophe Lyon wrote: > > Dear release managers and developers, > > > > TL;DR: For the sake of improving precommit CI coverage and simplifying > > workflows, I’d like to request a patch submission policy change, so > > that we now include regenerated files. This was discussed during the > > last GNU toolchain office hours meeting [1] (2024-03-28). > > > > Benefits or this change include: > > - Increased compatibility with precommit CI > > - No need to manually edit patches before submitting, thus the “git > > send-email” workflow is simplified > > - Patch reviewers can be confident that the committed patch will be > > exactly what they approved > > - Precommit CI can test exactly what has been submitted > > > > Any concerns/objections? > > Yes: Patch size. And no, not sending patches inline is bad practice. Not sure what you mean? Do you mean sending patches as attachments is bad practice? > Even assuming sending patches bi-modal (inline and as attachment) works > (please indicate whether that's the case), it would mean extra work on > the sending side. > For the CI perspective, we use what patchwork is able to detect as patches. Looking at recent patches submissions, it seems patchwork is able to cope with the output of git format-patch/git send-email, as well as attachments. There are cases where patchwork is not able to detect the patch, but I don't know patchwork's exact specifications. Thanks, Christophe > Jan
Patches submission policy change
Dear release managers and developers, TL;DR: For the sake of improving precommit CI coverage and simplifying workflows, I’d like to request a patch submission policy change, so that we now include regenerated files. This was discussed during the last GNU toolchain office hours meeting [1] (2024-03-28). Benefits or this change include: - Increased compatibility with precommit CI - No need to manually edit patches before submitting, thus the “git send-email” workflow is simplified - Patch reviewers can be confident that the committed patch will be exactly what they approved - Precommit CI can test exactly what has been submitted Any concerns/objections? As discussed on the lists and during the meeting, we have been facing issues with testing a class of patches: those which imply regenerating some files. Indeed, for binutils and gcc, the current patch submission policy is to *not* include the regenerated files (IIUC the policy is different for gdb [2]). This means that precommit CI receives an incomplete patch, leading to wrong and misleading regression reports, and complaints/frustration. (our notifications now include a warning, making it clear that we do not regenerate files ;-) ) I thought the solution was as easy as adding –enable-maintainer-mode to the configure arguments but this has proven to be broken (random failures with highly parallel builds). I tried to workaround that by adding new “regenerate” rules in the makefiles, that we could build at -j1 before running the real build with a higher parallelism level, but this is not ideal, not to mention that in the case of gcc, configuring target libraries requires having built all-gcc before, which is quite slow at -j1. Another approach used in binutils and gdb builtbots is a dedicated script (aka autoregen.py) which calls autotools as appropriate. It could be extended to update other types of files, but this can be a bit tricky (eg. some opcodes files require to build a generator first, some doc fragments also use non-trivial build sequences), and it creates a maintenance issue: the build recipe is duplicated in the script and in the makefiles. Such a script has proven to be useful though in postcommit CI, to catch regeneration errors. Having said that, it seems that for the sake of improving usefulness of precommit CI, the simplest way forward is to change the policy to include regenerated files. This does not seem to be a burden for developers, since they have to regenerate the files before pushing their patches anyway, and it also enables reviewers to make sure the generated files are correct. Said differently, if you want to increase the chances of having your patches tested by precommit CI, make sure to include all the regenerated files, otherwise you might receive failure notifications. Any concerns/objections? Thanks, Christophe [1] https://gcc.gnu.org/wiki/OfficeHours#Meeting:_2024-03-28_.40_1100h_EST5EDT [2] https://inbox.sourceware.org/gdb/cc0a5c86-a041-429a-9890-efd393760...@simark.ca/
[gcc r14-9755] aarch64: Fix typo in comment about FEATURE_STRING
https://gcc.gnu.org/g:d5aa2ca06aa7a6a2f826c4da19204b6db1402995
commit r14-9755-gd5aa2ca06aa7a6a2f826c4da19204b6db1402995
Author: Christophe Lyon
Date: Fri Mar 29 14:25:05 2024 +
aarch64: Fix typo in comment about FEATURE_STRING
Fix the comment to document FEATURE_STRING instead of FEAT_STRING.
2024-03-29 Christophe Lyon
gcc/
* config/aarch64/aarch64-option-extensions.def: Fix comment.
Diff:
---
gcc/config/aarch64/aarch64-option-extensions.def | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/gcc/config/aarch64/aarch64-option-extensions.def
b/gcc/config/aarch64/aarch64-option-extensions.def
index 061a145e9e7..aa3cd99f791 100644
--- a/gcc/config/aarch64/aarch64-option-extensions.def
+++ b/gcc/config/aarch64/aarch64-option-extensions.def
@@ -54,14 +54,14 @@
If a feature A appears in this list then the list implicitly includes
any features that are transitively dependent on A (according to REQUIRES).
- - FEAT_STRING is a string containing the entries in the 'Features' field of
- /proc/cpuinfo on a GNU/Linux system that correspond to this architecture
- extension being available. Sometimes multiple entries are needed to
enable
- the extension (for example, the 'crypto' extension depends on four
- entries: aes, pmull, sha1, sha2 being present). In that case this field
- should contain a space (" ") separated list of the strings in 'Features'
- that are required. Their order is not important. An empty string means
- do not detect this feature during auto detection.
+ - FEATURE_STRING is a string containing the entries in the 'Features' field
+ of /proc/cpuinfo on a GNU/Linux system that correspond to this
+ architecture extension being available. Sometimes multiple entries are
+ needed to enable the extension (for example, the 'crypto' extension
+ depends on four entries: aes, pmull, sha1, sha2 being present). In that
+ case this field should contain a space (" ") separated list of the strings
+ in 'Features' that are required. Their order is not important. An empty
+ string means do not detect this feature during auto detection.
- OPT_FLAGS is a list of feature IDENTS that should be enabled (along with
their transitive dependencies) when the specified FMV feature is present.
[gcc r14-9734] modula2: Fix m2.install-info in gcc/m2/Make-lang.in
https://gcc.gnu.org/g:14d0c863aa9415f5d78047910233d67d91f4ecf5 commit r14-9734-g14d0c863aa9415f5d78047910233d67d91f4ecf5 Author: Christophe Lyon Date: Fri Mar 29 17:59:38 2024 + modula2: Fix m2.install-info in gcc/m2/Make-lang.in Fix a few typos: the generated filename is m2.info (not gm2.info, and gm2$(exeext) is a file not a directory (so test -d would always fail). 2024-03-29 Christophe Lyon gcc/m2/ * Make-lang.in (m2.install-info): Fix rule. Diff: --- gcc/m2/Make-lang.in | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in index 2d8a47a1b1f..e56240b4c44 100644 --- a/gcc/m2/Make-lang.in +++ b/gcc/m2/Make-lang.in @@ -400,20 +400,20 @@ m2.install-common: installdirs done m2.install-info: installdirs - if [ -d gm2$(exeext) ] ; then \ - if [ -f $(objdir)/doc/gm2.info ]; then \ - rm -f $(DESTDIR)$(infodir)/gm2.info*; \ - for f in $(objdir)/doc/gm2.info*; do \ + if [ -f gm2$(exeext) ] ; then \ + if [ -f $(objdir)/doc/m2.info ]; then \ + rm -f $(DESTDIR)$(infodir)/m2.info*; \ + for f in $(objdir)/doc/m2.info*; do \ realfile=`echo $$f | sed -e 's|.*/\([^/]*\)$$|\1|'`; \ rm -f $(DESTDIR)$(infodir)/`basename $$realfile`; \ $(INSTALL_DATA) $$f $(DESTDIR)$(infodir)/`basename $$realfile`; \ done; \ - chmod a-x $(DESTDIR)$(infodir)/gm2.info*; \ + chmod a-x $(DESTDIR)$(infodir)/m2.info*; \ else true; fi; \ else true; fi - -if [ -f gm2$(exeext) ] && [ -f $(DESTDIR)$(infodir)/gm2.info ]; then \ + -if [ -f gm2$(exeext) ] && [ -f $(DESTDIR)$(infodir)/m2.info ]; then \ if $(SHELL) -c 'install-info --version' >/dev/null 2>&1; then \ - install-info --dir-file=$(infodir)/dir $(DESTDIR)$(infodir)/gm2.info; \ + install-info --dir-file=$(infodir)/dir $(DESTDIR)$(infodir)/m2.info; \ else true; fi; \ else true; fi
[gcc r14-9733] modula2: Add m2.install-html rule to gcc/m2/Make-lang.in
https://gcc.gnu.org/g:ec2c15f14f2278d431756f3d05e6ab7f436bea5e commit r14-9733-gec2c15f14f2278d431756f3d05e6ab7f436bea5e Author: Christophe Lyon Date: Fri Mar 29 17:10:36 2024 + modula2: Add m2.install-html rule to gcc/m2/Make-lang.in This rule was missing, and 'make install-html' was failing. It is copied from the corresponding one in fortran. 2024-03-29 Christophe Lyon gcc/m2/ * Make-lang.in (install-html): New rule. Diff: --- gcc/m2/Make-lang.in | 19 +++ 1 file changed, 19 insertions(+) diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in index ef6990ce617..2d8a47a1b1f 100644 --- a/gcc/m2/Make-lang.in +++ b/gcc/m2/Make-lang.in @@ -206,6 +206,25 @@ $(build_htmldir)/m2/index.html: $(TEXISRC) $(objdir)/m2/images/gnu.eps rm -f $(@D)/* $(TEXI2HTML) -I $(objdir)/m2 -I $(srcdir)/m2 -I $(gcc_docdir)/include -o $(@D) $< +M2_HTMLFILES = $(build_htmldir)/m2 + +m2.install-html: $(M2_HTMLFILES) + @$(NORMAL_INSTALL) + test -z "$(htmldir)" || $(mkinstalldirs) "$(DESTDIR)$(htmldir)" + @list='$(M2_HTMLFILES)'; for p in $$list; do \ + if test -f "$$p" || test -d "$$p"; then d=""; else d="$(srcdir)/"; fi; \ + f=$(html__strip_dir) \ + if test -d "$$d$$p"; then \ + echo " $(mkinstalldirs) '$(DESTDIR)$(htmldir)/$$f'"; \ + $(mkinstalldirs) "$(DESTDIR)$(htmldir)/$$f" || exit 1; \ + echo " $(INSTALL_DATA) '$$d$$p'/* '$(DESTDIR)$(htmldir)/$$f'"; \ + $(INSTALL_DATA) "$$d$$p"/* "$(DESTDIR)$(htmldir)/$$f"; \ + else \ + echo " $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(htmldir)/$$f'"; \ + $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(htmldir)/$$f"; \ + fi; \ + done + # gm2-libs.texi m2/gm2-libs.texi: gm2-libs.texi-check; @true
[PATCH 2/2] modula2: Fix m2.install-info in gcc/m2/Make-lang.in
Fix a few typos: the generated filename is m2.info (not gm2.info, and gm2$(exeext) is a file not a directory (so test -d would always fail). 2024-03-29 Christophe Lyon gcc/m2/ * Make-lang.in (m2.install-info): Fix rule. --- gcc/m2/Make-lang.in | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in index 2d8a47a1b1f..e56240b4c44 100644 --- a/gcc/m2/Make-lang.in +++ b/gcc/m2/Make-lang.in @@ -400,20 +400,20 @@ m2.install-common: installdirs done m2.install-info: installdirs - if [ -d gm2$(exeext) ] ; then \ - if [ -f $(objdir)/doc/gm2.info ]; then \ - rm -f $(DESTDIR)$(infodir)/gm2.info*; \ - for f in $(objdir)/doc/gm2.info*; do \ + if [ -f gm2$(exeext) ] ; then \ + if [ -f $(objdir)/doc/m2.info ]; then \ + rm -f $(DESTDIR)$(infodir)/m2.info*; \ + for f in $(objdir)/doc/m2.info*; do \ realfile=`echo $$f | sed -e 's|.*/\([^/]*\)$$|\1|'`; \ rm -f $(DESTDIR)$(infodir)/`basename $$realfile`; \ $(INSTALL_DATA) $$f $(DESTDIR)$(infodir)/`basename $$realfile`; \ done; \ - chmod a-x $(DESTDIR)$(infodir)/gm2.info*; \ + chmod a-x $(DESTDIR)$(infodir)/m2.info*; \ else true; fi; \ else true; fi - -if [ -f gm2$(exeext) ] && [ -f $(DESTDIR)$(infodir)/gm2.info ]; then \ + -if [ -f gm2$(exeext) ] && [ -f $(DESTDIR)$(infodir)/m2.info ]; then \ if $(SHELL) -c 'install-info --version' >/dev/null 2>&1; then \ - install-info --dir-file=$(infodir)/dir $(DESTDIR)$(infodir)/gm2.info; \ + install-info --dir-file=$(infodir)/dir $(DESTDIR)$(infodir)/m2.info; \ else true; fi; \ else true; fi -- 2.34.1
[PATCH 1/2] modula2: Add m2.install-html rule to gcc/m2/Make-lang.in
This rule was missing, and 'make install-html' was failing. It is copied from the corresponding one in fortran. 2024-03-29 Christophe Lyon gcc/m2/ * Make-lang.in (install-html): New rule. --- gcc/m2/Make-lang.in | 19 +++ 1 file changed, 19 insertions(+) diff --git a/gcc/m2/Make-lang.in b/gcc/m2/Make-lang.in index ef6990ce617..2d8a47a1b1f 100644 --- a/gcc/m2/Make-lang.in +++ b/gcc/m2/Make-lang.in @@ -206,6 +206,25 @@ $(build_htmldir)/m2/index.html: $(TEXISRC) $(objdir)/m2/images/gnu.eps rm -f $(@D)/* $(TEXI2HTML) -I $(objdir)/m2 -I $(srcdir)/m2 -I $(gcc_docdir)/include -o $(@D) $< +M2_HTMLFILES = $(build_htmldir)/m2 + +m2.install-html: $(M2_HTMLFILES) + @$(NORMAL_INSTALL) + test -z "$(htmldir)" || $(mkinstalldirs) "$(DESTDIR)$(htmldir)" + @list='$(M2_HTMLFILES)'; for p in $$list; do \ + if test -f "$$p" || test -d "$$p"; then d=""; else d="$(srcdir)/"; fi; \ + f=$(html__strip_dir) \ + if test -d "$$d$$p"; then \ + echo " $(mkinstalldirs) '$(DESTDIR)$(htmldir)/$$f'"; \ + $(mkinstalldirs) "$(DESTDIR)$(htmldir)/$$f" || exit 1; \ + echo " $(INSTALL_DATA) '$$d$$p'/* '$(DESTDIR)$(htmldir)/$$f'"; \ + $(INSTALL_DATA) "$$d$$p"/* "$(DESTDIR)$(htmldir)/$$f"; \ + else \ + echo " $(INSTALL_DATA) '$$d$$p' '$(DESTDIR)$(htmldir)/$$f'"; \ + $(INSTALL_DATA) "$$d$$p" "$(DESTDIR)$(htmldir)/$$f"; \ + fi; \ + done + # gm2-libs.texi m2/gm2-libs.texi: gm2-libs.texi-check; @true -- 2.34.1
[committed] [aarch64, testsuite]: Fix lrcpc3 testcase
There was a typo in the testcase, with GCC_CPUINFO pointing to the
wrong file.
Committed as obvious.
2024-03-29 Christophe Lyon
gcc/testsuite/
* gcc.target/aarch64/cpunative/native_cpu_24.c: Fix GCC_CPUINFO.
---
gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
index 05dc870885f..3a720cc8552 100644
--- a/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
+++ b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
@@ -1,5 +1,5 @@
/* { dg-do compile { target { { aarch64*-*-linux*} && native } } } */
-/* { dg-set-compiler-env-var GCC_CPUINFO
"$srcdir/gcc.target/aarch64/cpunative/info_23" } */
+/* { dg-set-compiler-env-var GCC_CPUINFO
"$srcdir/gcc.target/aarch64/cpunative/info_24" } */
/* { dg-additional-options "-mcpu=native --save-temps " } */
int main()
--
2.34.1
[gcc r14-9725] Fix lrcpc3 testcase
https://gcc.gnu.org/g:28dca4be504dda29f55eafe958cdf299ec89b94e
commit r14-9725-g28dca4be504dda29f55eafe958cdf299ec89b94e
Author: Christophe Lyon
Date: Fri Mar 29 14:19:59 2024 +
Fix lrcpc3 testcase
There was a typo in the testcase, with GCC_CPUINFO pointing to the
wrong file.
2024-03-29 Christophe Lyon
gcc/testsuite/
* gcc.target/aarch64/cpunative/native_cpu_24.c: Fix GCC_CPUINFO.
Diff:
---
gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
index 05dc870885f..3a720cc8552 100644
--- a/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
+++ b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_24.c
@@ -1,5 +1,5 @@
/* { dg-do compile { target { { aarch64*-*-linux*} && native } } } */
-/* { dg-set-compiler-env-var GCC_CPUINFO
"$srcdir/gcc.target/aarch64/cpunative/info_23" } */
+/* { dg-set-compiler-env-var GCC_CPUINFO
"$srcdir/gcc.target/aarch64/cpunative/info_24" } */
/* { dg-additional-options "-mcpu=native --save-temps " } */
int main()
[PATCH] aarch64: Fix typo in comment about FEATURE_STRING
Fix the comment to document FEATURE_STRING instead of FEAT_STRING.
2024-03-29 Christophe Lyon
gcc/
* config/aarch64/aarch64-option-extensions.def: Fix comment.
---
gcc/config/aarch64/aarch64-option-extensions.def | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/gcc/config/aarch64/aarch64-option-extensions.def
b/gcc/config/aarch64/aarch64-option-extensions.def
index 061a145e9e7..aa3cd99f791 100644
--- a/gcc/config/aarch64/aarch64-option-extensions.def
+++ b/gcc/config/aarch64/aarch64-option-extensions.def
@@ -54,14 +54,14 @@
If a feature A appears in this list then the list implicitly includes
any features that are transitively dependent on A (according to REQUIRES).
- - FEAT_STRING is a string containing the entries in the 'Features' field of
- /proc/cpuinfo on a GNU/Linux system that correspond to this architecture
- extension being available. Sometimes multiple entries are needed to
enable
- the extension (for example, the 'crypto' extension depends on four
- entries: aes, pmull, sha1, sha2 being present). In that case this field
- should contain a space (" ") separated list of the strings in 'Features'
- that are required. Their order is not important. An empty string means
- do not detect this feature during auto detection.
+ - FEATURE_STRING is a string containing the entries in the 'Features' field
+ of /proc/cpuinfo on a GNU/Linux system that correspond to this
+ architecture extension being available. Sometimes multiple entries are
+ needed to enable the extension (for example, the 'crypto' extension
+ depends on four entries: aes, pmull, sha1, sha2 being present). In that
+ case this field should contain a space (" ") separated list of the strings
+ in 'Features' that are required. Their order is not important. An empty
+ string means do not detect this feature during auto detection.
- OPT_FLAGS is a list of feature IDENTS that should be enabled (along with
their transitive dependencies) when the specified FMV feature is present.
--
2.34.1
Re: Building Single Tree for a Specific Set of CFLAGS
On 3/27/24 20:07, Joel Sherrill wrote: On Wed, Mar 27, 2024 at 3:53 AM Christophe Lyon via Gcc <mailto:gcc@gcc.gnu.org>> wrote: Hi! On 3/26/24 22:52, Joel Sherrill via Gcc wrote: > Hi > > For RTEMS, we normally build a multilib'ed gcc+newlib, but I have a case > where the CPU model is something not covered by our multilibs and not one > we are keen to add. I've looked around but not found anything that makes me > feel confident. > > What's the magic for building a gcc+newlib with a single set of libraries > that are built for a specific CPU CFLAGS? > > I am trying --disable-multlibs on the gcc configure and adding > CFLAGS_FOR_TARGET to make. > > Advice appreciated. > I would configure GCC with --disable-multilibs --with-cpu=XXX --with-mode=XXX --with-float=XXX [maybe --with-fpu=XXX] This way GCC defaults to what you want. Thanks. Is there any documentation or even a good example? I found --with-mode=[arm|thumb] but am having trouble mapping the others back to GCC options. I don't know of any good doc/example. I look in gcc/config.gcc to check what is supported. I have this for CFLAGS_FOR_TARGET "-mcpu=cortex-m7 -mthumb -mlittle-endian -mfloat-abi=hard -mfpu=fpv5-sp-d16 -march=armv7e-m+fpv5" I think that means... --with-mode=thumb for -mthumb --with-cpu=cortex-m7 for -mcortex-m7 --with-float=hard for -mfloat-abi=hard That leaves a few options I don't know how to map. You can see that for arm: supported_defaults="arch cpu float tune fpu abi mode tls" so there's a --with-XXX for any of the above, meaning that there's no --with-endian (default endianness on arm is derived from the target triplet eg. armeb-* vs arm-*) Also note that config.gcc checks that you don't provide both --with-cpu and --with-arch or --with-cpu and --with-tune HTH, Christophe --joel Thanks, Christophe > Thanks. > > --joel
Re: [RFC] add regenerate Makefile target
Hi! On Mon, 25 Mar 2024 at 15:19, Christophe Lyon wrote: > > On Thu, 21 Mar 2024 at 15:32, Christophe Lyon > wrote: > > > > On Wed, 20 Mar 2024 at 16:34, Simon Marchi wrote: > > > > > > On 3/18/24 13:25, Christophe Lyon wrote: > > > > Well the rule to regenerate Makefile.in (eg in in opcodes/) is a bit > > > > more complex > > > > than just calling automake. IIUC it calls automake --foreign it any of > > > > *.m4 file from $(am__configure_deps) that is newer than Makefile.in > > > > (with an early exit in the loop), does nothing if Makefile.am or > > > > doc/local.mk are newer than Makefile.in, and then calls 'automake > > > > --foreign Makefile' > > > > > > The rules looks complex because they've been generated by automake, this > > > Makefile.in is not written by hand. And I guess automake has put > > > `--foreign` there because foreign is used in Makefile.am: > > Yes, I know :-) > > > > > > > > AUTOMAKE_OPTIONS = foreign no-dist > > > > > > But a simple call so `automake -f` (or `autoreconf -f`) just works, as > > > automake picks up the foreign option from AUTOMAKE_OPTIONS, so a human > > > or an external script who wants to regenerate things would probably just > > > use that. > > > > Indeed. I guess my concern is: if some change happens to > > Makefile.am/Makefile.in which would imply that 'autoreconf -f' would > > not work, how do we make sure autoregen.py (or whatever script) is > > updated accordingly? Or maybe whatever change is made to > > Makefile.am/Makefile.in, 'autoreconf -f' is supposed to handle it > > without additional flag? > > > I think I've just noticed a variant of this: if you look at > opcodes/Makefile.in, you can see that aclocal.m4 depends on > configure.ac (among others). So if configure.ac is updated, a > maintainer-mode rule in Makefile.in will call aclocal and regenerate > aclocal.m4. > > However, autoregen.py calls aclocal only if configure.ac contains > AC_CONFIG_MACRO_DIRS, which is not the case here. > > That's probably a bug in opcode/configure.ac, but still the current > Makefile.in machinery would update aclocal.m4 as needed when > autoregen.py will not. > > I haven't audited all configure.ac but there are probably other > occurrences of this. > As another follow-up on this topic, while working on a tentative GCC patch to implement this, I realized an obvious issue: all target libraries configure steps depend on 'all-gcc' (of course, we need a compiler to build the libs...) So they idea of doing roughly: - configure --enable-maintainer-mode - make regenerate -j1 (to avoid current race conditions in maintainer-mode) - make all -jXXX means that the regenerate step will trigger the configure step for all host and target subdirs as needed, and configuring target-libs requires building 'all-gcc', which would happen at -j1 ! sigh :-) Looks like we should handle binutils, gdb, and gcc differently for the sake of precommit CI. Thanks, Christophe > Christophe > > > > > > > > The bot I want to put in place would regenerate things as they are > > > > supposed to be, then build and run the testsuite to make sure that > > > > what is supposed to be committed would work (if the committer > > > > regenerates everything correctly) > > > > > > For your job, would it be fine to just force-regenerate everything and > > > ignore timestamps (just like the buildbot's autoregen job wants to do)? > > > It would waste a few cycles, but it would be much simpler. > > > > > Yes, that would achieve the purpose: be able to handle as many patches > > as possible in precommit-CI. > > And as described earlier, for binutils this currently means: > > autoregen > > confgure --enable-maintainer-mode > > make all (with a low -j value otherwise we have random build failures) > > and my proposal to workaround the problem with -j is to do > > make all-bfd all-libiberty regenerate -j1 > > make all -j XXX > > > > Another possibility would be a policy change in how patches are > > submitted, to require that they contain all the autogenerated files. > > > > > > > Simon
Re: [RFC] add regenerate Makefile target
On Tue, 26 Mar 2024 at 16:42, Jens Remus wrote: > > Am 15.03.2024 um 09:50 schrieb Christophe Lyon: > > On Thu, 14 Mar 2024 at 19:10, Simon Marchi wrote: > >> On 2024-03-13 04:02, Christophe Lyon via Gdb wrote: > ... > >> There's just the issue of files that are generated using tools that are > >> compiled. When experimenting with maintainer mode the other day, I > >> stumbled on the opcodes/i386-gen, for instance. I don't have a good > >> solution to that, except to rewrite these tools in a scripting language > >> like Python. > > > > So for opcodes, it currently means rewriting such programs for i386, > > aarch64, ia64 and luckily msp430/rl78/rx share the same opc2c > > generator. > > Not sure how to find volunteers? > > Why are those generated source files checked into the repository and not > generated at build-time? Would there be a reason for s390 do so as well > (opcodes/s390-opc.tab is generated at build-time from > opcodes/s390-opc.txt using s390-mkopc built from opcodes/s390-mkopc.c)? > I remember someone mentioned a requirement of being able to rebuild with the sources on a read-only filesystem. I don't know if there's a requirement that such generated files should be part of the source tree though. Is opcodes/s390-opc.tab in builddir or in srcdir? I think there are other motivations but I can't remember them at the moment :-) Thanks, Christophe > Thanks and regards, > Jens > -- > Jens Remus > Linux on Z Development (D3303) and z/VSE Support > +49-7031-16-1128 Office > jre...@de.ibm.com > > IBM > > IBM Deutschland Research & Development GmbH; Vorsitzender des > Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der > Gesellschaft: Böblingen; Registergericht: Amtsgericht Stuttgart, HRB 243294 > IBM Data Privacy Statement: https://www.ibm.com/privacy/
Re: Building Single Tree for a Specific Set of CFLAGS
Hi! On 3/26/24 22:52, Joel Sherrill via Gcc wrote: Hi For RTEMS, we normally build a multilib'ed gcc+newlib, but I have a case where the CPU model is something not covered by our multilibs and not one we are keen to add. I've looked around but not found anything that makes me feel confident. What's the magic for building a gcc+newlib with a single set of libraries that are built for a specific CPU CFLAGS? I am trying --disable-multlibs on the gcc configure and adding CFLAGS_FOR_TARGET to make. Advice appreciated. I would configure GCC with --disable-multilibs --with-cpu=XXX --with-mode=XXX --with-float=XXX [maybe --with-fpu=XXX] This way GCC defaults to what you want. Thanks, Christophe Thanks. --joel
Re: [RFC] add regenerate Makefile target
On Thu, 21 Mar 2024 at 15:32, Christophe Lyon wrote: > > On Wed, 20 Mar 2024 at 16:34, Simon Marchi wrote: > > > > On 3/18/24 13:25, Christophe Lyon wrote: > > > Well the rule to regenerate Makefile.in (eg in in opcodes/) is a bit > > > more complex > > > than just calling automake. IIUC it calls automake --foreign it any of > > > *.m4 file from $(am__configure_deps) that is newer than Makefile.in > > > (with an early exit in the loop), does nothing if Makefile.am or > > > doc/local.mk are newer than Makefile.in, and then calls 'automake > > > --foreign Makefile' > > > > The rules looks complex because they've been generated by automake, this > > Makefile.in is not written by hand. And I guess automake has put > > `--foreign` there because foreign is used in Makefile.am: > Yes, I know :-) > > > > > AUTOMAKE_OPTIONS = foreign no-dist > > > > But a simple call so `automake -f` (or `autoreconf -f`) just works, as > > automake picks up the foreign option from AUTOMAKE_OPTIONS, so a human > > or an external script who wants to regenerate things would probably just > > use that. > > Indeed. I guess my concern is: if some change happens to > Makefile.am/Makefile.in which would imply that 'autoreconf -f' would > not work, how do we make sure autoregen.py (or whatever script) is > updated accordingly? Or maybe whatever change is made to > Makefile.am/Makefile.in, 'autoreconf -f' is supposed to handle it > without additional flag? > I think I've just noticed a variant of this: if you look at opcodes/Makefile.in, you can see that aclocal.m4 depends on configure.ac (among others). So if configure.ac is updated, a maintainer-mode rule in Makefile.in will call aclocal and regenerate aclocal.m4. However, autoregen.py calls aclocal only if configure.ac contains AC_CONFIG_MACRO_DIRS, which is not the case here. That's probably a bug in opcode/configure.ac, but still the current Makefile.in machinery would update aclocal.m4 as needed when autoregen.py will not. I haven't audited all configure.ac but there are probably other occurrences of this. Christophe > > > > > The bot I want to put in place would regenerate things as they are > > > supposed to be, then build and run the testsuite to make sure that > > > what is supposed to be committed would work (if the committer > > > regenerates everything correctly) > > > > For your job, would it be fine to just force-regenerate everything and > > ignore timestamps (just like the buildbot's autoregen job wants to do)? > > It would waste a few cycles, but it would be much simpler. > > > Yes, that would achieve the purpose: be able to handle as many patches > as possible in precommit-CI. > And as described earlier, for binutils this currently means: > autoregen > confgure --enable-maintainer-mode > make all (with a low -j value otherwise we have random build failures) > and my proposal to workaround the problem with -j is to do > make all-bfd all-libiberty regenerate -j1 > make all -j XXX > > Another possibility would be a policy change in how patches are > submitted, to require that they contain all the autogenerated files. > > > > Simon
Re: [PATCH] libgcc: arm: fix build for FDPIC target
Hi, On 3/22/24 21:14, Max Filippov wrote: libgcc/ * unwind-arm-common.inc (__gnu_personality_sigframe_fdpic): Cast last argument of _Unwind_VRS_Set to void *. --- libgcc/unwind-arm-common.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libgcc/unwind-arm-common.inc b/libgcc/unwind-arm-common.inc index 5453f38186b5..576f7e93e8a8 100644 --- a/libgcc/unwind-arm-common.inc +++ b/libgcc/unwind-arm-common.inc @@ -248,7 +248,7 @@ __gnu_personality_sigframe_fdpic (_Unwind_State state, + ARM_SIGCONTEXT_R0; /* Restore regs saved on stack by the kernel. */ for (i = 0; i < 16; i++) - _Unwind_VRS_Set (context, _UVRSC_CORE, i, _UVRSD_UINT32, sp + 4 * i); + _Unwind_VRS_Set (context, _UVRSC_CORE, i, _UVRSD_UINT32, (void *)(sp + 4 * i)); LGTM (but I'm not a maintainer). Thanks, Christophe return _URC_CONTINUE_UNWIND; }
Re: [RFC] add regenerate Makefile target
On Wed, 20 Mar 2024 at 16:34, Simon Marchi wrote: > > On 3/18/24 13:25, Christophe Lyon wrote: > > Well the rule to regenerate Makefile.in (eg in in opcodes/) is a bit > > more complex > > than just calling automake. IIUC it calls automake --foreign it any of > > *.m4 file from $(am__configure_deps) that is newer than Makefile.in > > (with an early exit in the loop), does nothing if Makefile.am or > > doc/local.mk are newer than Makefile.in, and then calls 'automake > > --foreign Makefile' > > The rules looks complex because they've been generated by automake, this > Makefile.in is not written by hand. And I guess automake has put > `--foreign` there because foreign is used in Makefile.am: Yes, I know :-) > > AUTOMAKE_OPTIONS = foreign no-dist > > But a simple call so `automake -f` (or `autoreconf -f`) just works, as > automake picks up the foreign option from AUTOMAKE_OPTIONS, so a human > or an external script who wants to regenerate things would probably just > use that. Indeed. I guess my concern is: if some change happens to Makefile.am/Makefile.in which would imply that 'autoreconf -f' would not work, how do we make sure autoregen.py (or whatever script) is updated accordingly? Or maybe whatever change is made to Makefile.am/Makefile.in, 'autoreconf -f' is supposed to handle it without additional flag? > > > The bot I want to put in place would regenerate things as they are > > supposed to be, then build and run the testsuite to make sure that > > what is supposed to be committed would work (if the committer > > regenerates everything correctly) > > For your job, would it be fine to just force-regenerate everything and > ignore timestamps (just like the buildbot's autoregen job wants to do)? > It would waste a few cycles, but it would be much simpler. > Yes, that would achieve the purpose: be able to handle as many patches as possible in precommit-CI. And as described earlier, for binutils this currently means: autoregen confgure --enable-maintainer-mode make all (with a low -j value otherwise we have random build failures) and my proposal to workaround the problem with -j is to do make all-bfd all-libiberty regenerate -j1 make all -j XXX Another possibility would be a policy change in how patches are submitted, to require that they contain all the autogenerated files. > Simon
Re: [RFC] add regenerate Makefile target
Hi, On Mon, 18 Mar 2024 at 18:25, Christophe Lyon wrote: > > On Sat, 16 Mar 2024 at 18:16, Simon Marchi wrote: > > > > > > > > On 2024-03-15 04:50, Christophe Lyon via Gdb wrote: > > > On Thu, 14 Mar 2024 at 19:10, Simon Marchi wrote: > > >> My first thought it: why is it a Makefile target, instead of some script > > >> on the side (like autoregen.sh). It would be nice / useful to be > > >> able to it without configuring / building anything. For instance, the > > >> autoregen buildbot job could run it without configuring anything. > > >> Ideally, the buildbot wouldn't maintain its own autoregen.py file on the > > >> side, it would just use whatever is in the repo. > > > > > > Firstly because of what you mention later: some regeneration steps > > > require building host tools first, like the XXX-gen in opcodes. > > > > "build" and not "host", I think? > > yes, sorry > > > > Since the existing Makefiles already contain the rules to autoregen > > > all these files, it seemed natural to me to reuse them, to avoid > > > reinventing the wheel with the risk of introducing new bugs. > > > > I understand. Although one advantage of moving the actual code out of > > the Makefile (even if there's still a Makefile rule calling the external > > script), is that it's much easier to maintain. Editors are much more > > useful when editing a standalone shell script than editing shell code in > > a Makefile target. It doesn't have to be this big one liner if you want > > to use variables, you don't need to escape $, you can run it through > > linters, you can call it by hand, etc. This is what I did here, for > > instance: > > > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f39632d9579d3c97f1e50a728efed3c5409747d2 > > > > So I think there's value in any case of moving the regeneration logic > > out of the Makefiles per se. > > > In this case, the generation rules look simple enough indeed. > But as mentioned elsewhere in the thread, there are more complex > cases, which involve building helper tools, which have dependencies on > bfd and libiberty for instance. I'm not sure that's easily/naturally > scriptable? > There's also 'chew' in bfd/ > > > > This involves changes in places where I've never looked at before, so > > > I'd rather reuse as much existing support as possible. > > > > > > For instance, there are the generators in opcodes/, but also things in > > > sim/, bfd/, updates to the docs and potfiles. In gcc, there's also > > > something "unusual" in fixincludes/ and libgfortran/ > > > > > > In fact, I considered also including 'configure', 'Makefile.in', > > > etc... in the 'regenerate' target, it does not seem natural to me to > > > invoke a script on the side, where you have to replicate the behaviour > > > of existing Makefiles, possibly getting out-of-sync when someone > > > forgets to update either Makefile or autoregen.py. > > > > I'm not sure I follow. Are you referring to the rules that automake > > automatically puts to re-generate Makefile.in and others when > > Makefile.am has changed? Your regenerate target would depend on those > > builtin rules? > Yes, "regenerate" would include "configure, Makeifile.in, configh" > (as/if needed) in its list of dependencies. > > > > > Let's say my generate-autostuff.sh script does: > > > > aclocal --some-flags > > automake --some-other-flags > > autoconf --some-other-other-flags > > > > And the checked-in Makefile.in is regenerated based on that. Wouldn't > > the built-in rules just call aclocal/automake/autoconf with those same > > flags? I don't see why they would get out of sync. > Well the rule to regenerate Makefile.in (eg in in opcodes/) is a bit > more complex > than just calling automake. IIUC it calls automake --foreign it any of > *.m4 file from $(am__configure_deps) that is newer than Makefile.in > (with an early exit in the loop), does nothing if Makefile.am or > doc/local.mk are newer than Makefile.in, and then calls 'automake > --foreign Makefile' > > I've never looked closely at that rule (I suppose he does what it's > intended to do ;-) ), but why not call automake once in $srcdir then > once in $top_srcdir? > TBH I'd rather not spend ages figuring out all this magic :-) > > But yeah, maybe some careful looking at these rules might lead to a > couple of simple shell lines. > I looked a bit more closely at gcc, and noticed
Re: [PATCH v2 08/13] aarch64: Add Cygwin and MinGW environments for AArch64
On Mon, 18 Mar 2024 at 22:35, Evgeny Karpov wrote: > > Monday, March 18, 2024 2:27 PM > Christophe Lyon wrote: > > > > +/* Disable SEH and declare the required SEH-related macros that are > > > +still needed for compilation. */ #undef TARGET_SEH #define > > > +TARGET_SEH 0 > > > + > > > +#define SSE_REGNO_P(N) 0 > > > +#define GENERAL_REGNO_P(N) 0 > > I think you forgot to add a comment to explain the above two lines. > > (it was requested during v1 review) > > > > Thanks, > > > > Christophe > > Hi Christophe, > > Thank you for the review! > The comment regarding SEH and SEH-related macros has been added two lines > above. > It may not be obvious, but these macros are needed to emit SEH data in > mingw/winnt.cc. > This group is separated by an empty line; however, it still relates to > SEH-related macros. > Thanks for the clarification, I thought that comment only applied to the two lines about TARGET_SEH. Christophe > Regards, > Evgeny
[gcc r14-9537] arm: [MVE intrinsics] Fix support for loads [PR target/114323]
https://gcc.gnu.org/g:167ec6df7fd8deb67759acd5dbe72c1982a55873
commit r14-9537-g167ec6df7fd8deb67759acd5dbe72c1982a55873
Author: Christophe Lyon
Date: Fri Mar 15 19:55:43 2024 +
arm: [MVE intrinsics] Fix support for loads [PR target/114323]
The testcase in this PR shows that we would load from an uninitialized
location, because the vld1 instrinsics are reported as "const". This
is because function_instance::reads_global_state_p() does not take
CP_READ_MEMORY into account. Fixing this gives vld1 the "pure"
attribute instead, and solves the problem.
2024-03-15 Christophe Lyon
PR target/114323
gcc/
* config/arm/arm-mve-builtins.cc
(function_instance::reads_global_state_p): Take CP_READ_MEMORY
into account.
gcc/testsuite/
* gcc.target/arm/mve/pr114323.c: New.
Diff:
---
gcc/config/arm/arm-mve-builtins.cc | 2 +-
gcc/testsuite/gcc.target/arm/mve/pr114323.c | 22 ++
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/gcc/config/arm/arm-mve-builtins.cc
b/gcc/config/arm/arm-mve-builtins.cc
index c533d0e93ae..7e8217666fe 100644
--- a/gcc/config/arm/arm-mve-builtins.cc
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -657,7 +657,7 @@ function_instance::reads_global_state_p () const
if (flags & CP_READ_FPCR)
return true;
- return false;
+ return flags & CP_READ_MEMORY;
}
/* Return true if calls to the function could modify some form of
diff --git a/gcc/testsuite/gcc.target/arm/mve/pr114323.c
b/gcc/testsuite/gcc.target/arm/mve/pr114323.c
new file mode 100644
index 000..bd9127b886a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/pr114323.c
@@ -0,0 +1,22 @@
+/* { dg-do run } */
+/* { dg-require-effective-target arm_mve_hw } */
+/* { dg-options "-O2" } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
+
+#include
+
+__attribute__((noipa))
+uint32x4_t foo (void) {
+ uint32x4_t V0 = vld1q_u32(((const uint32_t[4]){1, 2, 3, 4}));
+ return V0;
+}
+
+int main(void)
+{
+ uint32_t buf[4];
+ vst1q_u32 (buf, foo());
+
+ for (int i = 0; i < 4; i++)
+if (buf[i] != i+1)
+ __builtin_abort ();
+}
Re: [RFC] add regenerate Makefile target
On Fri, 15 Mar 2024 at 15:25, Tom Tromey wrote: > > > "Eric" == Eric Gallager writes: > > Eric> Also there are the files generated by cgen, too, which no one seems to > Eric> know how to regenerate, either. > > I thought I sent out some info on this a while ago. > > Anyway what I do is make a symlink to the cgen source tree in the > binutils-gdb source tree, then configure with --enable-cgen-maint. > Then I make sure to build with 'make GUILE=guile3.0'. > > It could be better but that would require someone to actually work on > cgen. > > Eric> And then in bfd there's that chew > Eric> program in the doc subdir. And then in the binutils subdirectory > Eric> proper there's that sysinfo tool for generating sysroff.[ch]. > > gdb used to use a mish-mash of different approaches, some quite strange, > but over the last few years we standardized on Python scripts that > generate files. They're written to be seamless -- just invoke in the > source dir; the output is then just part of your patch. No special > configure options are needed. On the whole this has been a big > improvement. > Good to know that this is perceived as a big improvement, that's a strong argument for moving to a script. I'm not up-to-date with gdb's policy about patches: are they supposed to be posted with or without the regenerated parts included? IIUC they are not included in patch submissions for binutils and gcc, which makes the pre-commit CI miss some patches. Thanks, Christophe > Tom
Re: [RFC] add regenerate Makefile target
On Sat, 16 Mar 2024 at 18:16, Simon Marchi wrote: > > > > On 2024-03-15 04:50, Christophe Lyon via Gdb wrote: > > On Thu, 14 Mar 2024 at 19:10, Simon Marchi wrote: > >> My first thought it: why is it a Makefile target, instead of some script > >> on the side (like autoregen.sh). It would be nice / useful to be > >> able to it without configuring / building anything. For instance, the > >> autoregen buildbot job could run it without configuring anything. > >> Ideally, the buildbot wouldn't maintain its own autoregen.py file on the > >> side, it would just use whatever is in the repo. > > > > Firstly because of what you mention later: some regeneration steps > > require building host tools first, like the XXX-gen in opcodes. > > "build" and not "host", I think? yes, sorry > > Since the existing Makefiles already contain the rules to autoregen > > all these files, it seemed natural to me to reuse them, to avoid > > reinventing the wheel with the risk of introducing new bugs. > > I understand. Although one advantage of moving the actual code out of > the Makefile (even if there's still a Makefile rule calling the external > script), is that it's much easier to maintain. Editors are much more > useful when editing a standalone shell script than editing shell code in > a Makefile target. It doesn't have to be this big one liner if you want > to use variables, you don't need to escape $, you can run it through > linters, you can call it by hand, etc. This is what I did here, for > instance: > > https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f39632d9579d3c97f1e50a728efed3c5409747d2 > > So I think there's value in any case of moving the regeneration logic > out of the Makefiles per se. > In this case, the generation rules look simple enough indeed. But as mentioned elsewhere in the thread, there are more complex cases, which involve building helper tools, which have dependencies on bfd and libiberty for instance. I'm not sure that's easily/naturally scriptable? There's also 'chew' in bfd/ > > This involves changes in places where I've never looked at before, so > > I'd rather reuse as much existing support as possible. > > > > For instance, there are the generators in opcodes/, but also things in > > sim/, bfd/, updates to the docs and potfiles. In gcc, there's also > > something "unusual" in fixincludes/ and libgfortran/ > > > > In fact, I considered also including 'configure', 'Makefile.in', > > etc... in the 'regenerate' target, it does not seem natural to me to > > invoke a script on the side, where you have to replicate the behaviour > > of existing Makefiles, possibly getting out-of-sync when someone > > forgets to update either Makefile or autoregen.py. > > I'm not sure I follow. Are you referring to the rules that automake > automatically puts to re-generate Makefile.in and others when > Makefile.am has changed? Your regenerate target would depend on those > builtin rules? Yes, "regenerate" would include "configure, Makeifile.in, configh" (as/if needed) in its list of dependencies. > > Let's say my generate-autostuff.sh script does: > > aclocal --some-flags > automake --some-other-flags > autoconf --some-other-other-flags > > And the checked-in Makefile.in is regenerated based on that. Wouldn't > the built-in rules just call aclocal/automake/autoconf with those same > flags? I don't see why they would get out of sync. Well the rule to regenerate Makefile.in (eg in in opcodes/) is a bit more complex than just calling automake. IIUC it calls automake --foreign it any of *.m4 file from $(am__configure_deps) that is newer than Makefile.in (with an early exit in the loop), does nothing if Makefile.am or doc/local.mk are newer than Makefile.in, and then calls 'automake --foreign Makefile' I've never looked closely at that rule (I suppose he does what it's intended to do ;-) ), but why not call automake once in $srcdir then once in $top_srcdir? TBH I'd rather not spend ages figuring out all this magic :-) But yeah, maybe some careful looking at these rules might lead to a couple of simple shell lines. > > > What is currently > > missing is a way to easily regenerate files without having to run a > > full 'make all' (which currently takes care of calling autoconf & > > friends to update configure/Makefile.in). > > > > But yeah, having to configure before being able to regenerate files is > > a bit awkward too :-) > > I understand the constraints your are working with, and I guess that > doing: > > ./configure && make regenerate > > is not too bad. The buildbot could probably do
Re: [RFC] add regenerate Makefile target
On Fri, 15 Mar 2024 at 15:13, Eric Gallager wrote: > > On Fri, Mar 15, 2024 at 4:53 AM Christophe Lyon via Gcc > wrote: > > > > On Thu, 14 Mar 2024 at 19:10, Simon Marchi wrote: > > > > > > > > > > > > On 2024-03-13 04:02, Christophe Lyon via Gdb wrote: > > > > Hi! > > > > > > > > After recent discussions on IRC and on the lists about maintainer-mode > > > > and various problems with auto-generated source files, I've written > > > > this small prototype. > > > > > > > > Based on those discussions, I assumed that people generally want to > > > > update autotools files using a script similar to autoregen.py, which > > > > takes care of running aclocal, autoheader, automake and autoconf as > > > > appropriate. > > > > > > > > What is currently missing is a "simple" way of regenerating other > > > > files, which happens normally with --enable-maintainer-mode (which is > > > > reportedly broken). This patch as a "regenerate" Makefile target > > > > which can be called to update those files, provided > > > > --enable-maintainer-mode is used. > > > > > > > > I tried this approach with the following workflow for binutils/gdb: > > > > - run autoregen.py in srcdir > > > > - cd builddir > > > > - configure --enable-maintainer-mode > > > > - make all-bfd all-libiberty regenerate -j1 > > > > - for gdb: make all -C gdb/data-directory -j1 > > > > - make all -jXXX > > > > > > > > Making 'all' in bfd and libiberty is needed by some XXX-gen host > > > > programs in opcodes. > > > > > > > > The advantage (for instance for CI) is that we can regenerate files at > > > > -j1, thus avoiding the existing race conditions, and build the rest > > > > with -j XXX. > > > > > > > > Among drawbacks: > > > > - most sub-components use Makefile.am, but gdb does not: this may make > > > > maintenance more complex (different rules for different projects) > > > > - maintaining such ad-hoc "regenerate" rules would require special > > > > attention from maintainers/reviewers > > > > - dependency on -all-bfd and all-libiberty is probably not fully > > > >intuitive, but should not be a problem if the "regenerate" rules > > > >are used after a full build for instance > > > > > > > > Of course Makefile.def/Makefile.tpl would need further cleanup as I > > > > didn't try to take gcc into account is this patch. > > > > > > > > Thoughts? > > > > > > My first thought it: why is it a Makefile target, instead of some script > > > on the side (like autoregen.sh). It would be nice / useful to be > > > able to it without configuring / building anything. For instance, the > > > autoregen buildbot job could run it without configuring anything. > > > Ideally, the buildbot wouldn't maintain its own autoregen.py file on the > > > side, it would just use whatever is in the repo. > > > > Firstly because of what you mention later: some regeneration steps > > require building host tools first, like the XXX-gen in opcodes. > > > > Since the existing Makefiles already contain the rules to autoregen > > all these files, it seemed natural to me to reuse them, to avoid > > reinventing the wheel with the risk of introducing new bugs. > > > > This involves changes in places where I've never looked at before, so > > I'd rather reuse as much existing support as possible. > > > > For instance, there are the generators in opcodes/, but also things in > > sim/, bfd/, updates to the docs and potfiles. In gcc, there's also > > something "unusual" in fixincludes/ and libgfortran/ > > > > In fact, I considered also including 'configure', 'Makefile.in', > > etc... in the 'regenerate' target, it does not seem natural to me to > > invoke a script on the side, where you have to replicate the behaviour > > of existing Makefiles, possibly getting out-of-sync when someone > > forgets to update either Makefile or autoregen.py. What is currently > > missing is a way to easily regenerate files without having to run a > > full 'make all' (which currently takes care of calling autoconf & > > friends to update configure/Makefile.in). > > > > But yeah, having to configure before being able to regenerate files is > > a bi
Re: [PATCH v2 00/13] Add aarch64-w64-mingw32 target
On Thu, 7 Mar 2024 at 21:48, Evgeny Karpov wrote: > > Monday, March 4, 2024 > Evgeny Karpov wrote: > > > > > Changes from v1 to v2: > > Adjust the target name to aarch64-*-mingw* to exclude the big-endian target > > from support. > > Exclude 64-bit ISA. > > Rename enum calling_abi to aarch64_calling_abi. > > Move AArch64 MS ABI definitions FIXED_REGISTERS, > > CALL_REALLY_USED_REGISTERS, and STATIC_CHAIN_REGNUM from aarch64.h > > to aarch64-abi-ms.h. > > Rename TARGET_ARM64_MS_ABI to TARGET_AARCH64_MS_ABI. > > Exclude TARGET_64BIT from the aarch64 target. > > Exclude HAVE_GAS_WEAK. > > Set HAVE_GAS_ALIGNED_COMM to 1 by default. > > Use a reference from "x86 Windows Options" to "Cygwin and MinGW > > Options". > > Update commit descriptions to follow standard style. > > Rebase from 4th March 2024. > > Hello, > > It looks like the initial feedback has been addressed. I had a look at the v2 series, and besides a minor comment patch #8, ISTM than all the comments your received about v1 have been addressed, indeed. > While unit testing for the x86_64-w64-mingw32 target is still in > progress, the first 4 patches do not obviously change other > targets, including aarch64-linux-gnu. > Could they be merged once stage 1 starts, > or could it be done even now? What would be the benefit of committing only the first 4 patches? (whether now or when stage 1 reopens) Thanks, Christophe > Thanks! > > Regards, > Evgeny >
Re: [PATCH v2 08/13] aarch64: Add Cygwin and MinGW environments for AArch64
Hi!
On Mon, 4 Mar 2024 at 18:44, Evgeny Karpov wrote:
>
> From: Zac Walker
> Date: Fri, 1 Mar 2024 10:49:28 +0100
> Subject: [PATCH v2 08/13] aarch64: Add Cygwin and MinGW environments for
> AArch64
>
> Define Cygwin and MinGW environment such as types, SEH definitions,
> shared libraries, etc.
>
> gcc/ChangeLog:
>
> * config.gcc: Add Cygwin and MinGW difinitions.
> * config/aarch64/aarch64-protos.h
> (mingw_pe_maybe_record_exported_symbol): Declare functions
> which are used in Cygwin and MinGW environment.
> (mingw_pe_section_type_flags): Likewise.
> (mingw_pe_unique_section): Likewise.
> (mingw_pe_encode_section_info): Likewise.
> * config/aarch64/cygming.h: New file.
> ---
> gcc/config.gcc | 4 +
> gcc/config/aarch64/aarch64-protos.h | 5 +
> gcc/config/aarch64/cygming.h| 175
> 3 files changed, 184 insertions(+)
> create mode 100644 gcc/config/aarch64/cygming.h
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 3aca257c322..4471599454b 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -1267,7 +1267,11 @@ aarch64*-*-linux*)
> aarch64-*-mingw*)
> tm_file="${tm_file} aarch64/aarch64-abi-ms.h"
> tm_file="${tm_file} aarch64/aarch64-coff.h"
> + tm_file="${tm_file} aarch64/cygming.h"
> + tm_file="${tm_file} mingw/mingw32.h"
> + tm_file="${tm_file} mingw/mingw-stdint.h"
> tmake_file="${tmake_file} aarch64/t-aarch64"
> + target_gtfiles="$target_gtfiles \$(srcdir)/config/mingw/winnt.cc"
> case ${enable_threads} in
> "" | yes | win32)
> thread_file='win32'
> diff --git a/gcc/config/aarch64/aarch64-protos.h
> b/gcc/config/aarch64/aarch64-protos.h
> index bd719b992a5..759e1a0f9da 100644
> --- a/gcc/config/aarch64/aarch64-protos.h
> +++ b/gcc/config/aarch64/aarch64-protos.h
> @@ -1110,6 +1110,11 @@ extern void aarch64_output_patchable_area (unsigned
> int, bool);
>
> extern void aarch64_adjust_reg_alloc_order ();
>
> +extern void mingw_pe_maybe_record_exported_symbol (tree, const char *, int);
> +extern unsigned int mingw_pe_section_type_flags (tree, const char *, int);
> +extern void mingw_pe_unique_section (tree, int);
> +extern void mingw_pe_encode_section_info (tree, rtx, int);
> +
> bool aarch64_optimize_mode_switching (aarch64_mode_entity);
> void aarch64_restore_za (rtx);
>
> diff --git a/gcc/config/aarch64/cygming.h b/gcc/config/aarch64/cygming.h
> new file mode 100644
> index 000..2f239c42a89
> --- /dev/null
> +++ b/gcc/config/aarch64/cygming.h
> @@ -0,0 +1,175 @@
> +/* Operating system specific defines to be used when targeting GCC for
> + hosting on Windows32, using a Unix style C library and tools.
> + Copyright (C) 1995-2024 Free Software Foundation, Inc.
> +
> +This file is part of GCC.
> +
> +GCC is free software; you can redistribute it and/or modify
> +it under the terms of the GNU General Public License as published by
> +the Free Software Foundation; either version 3, or (at your option)
> +any later version.
> +
> +GCC is distributed in the hope that it will be useful,
> +but WITHOUT ANY WARRANTY; without even the implied warranty of
> +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> +GNU General Public License for more details.
> +
> +You should have received a copy of the GNU General Public License
> +along with GCC; see the file COPYING3. If not see
> +
[PATCH] arm: [MVE intrinsics] Fix support for loads [PR target/114323]
The testcase in this PR shows that we would load from an uninitialized
location, because the vld1 instrinsics are reported as "const". This
is because function_instance::reads_global_state_p() does not take
CP_READ_MEMORY into account. Fixing this gives vld1 the "pure"
attribute instead, and solves the problem.
2024-03-15 Christophe Lyon
PR target/114323
gcc/
* config/arm/arm-mve-builtins.cc
(function_instance::reads_global_state_p): Take CP_READ_MEMORY
into account.
gcc/testsuite/
* gcc.target/arm/mve/pr114323.c: New.
---
gcc/config/arm/arm-mve-builtins.cc | 2 +-
gcc/testsuite/gcc.target/arm/mve/pr114323.c | 22 +
2 files changed, 23 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/arm/mve/pr114323.c
diff --git a/gcc/config/arm/arm-mve-builtins.cc
b/gcc/config/arm/arm-mve-builtins.cc
index 2f2c0f4a02a..6a5775c67e5 100644
--- a/gcc/config/arm/arm-mve-builtins.cc
+++ b/gcc/config/arm/arm-mve-builtins.cc
@@ -746,7 +746,7 @@ function_instance::reads_global_state_p () const
if (flags & CP_READ_FPCR)
return true;
- return false;
+ return flags & CP_READ_MEMORY;
}
/* Return true if calls to the function could modify some form of
diff --git a/gcc/testsuite/gcc.target/arm/mve/pr114323.c
b/gcc/testsuite/gcc.target/arm/mve/pr114323.c
new file mode 100644
index 000..bd9127b886a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/mve/pr114323.c
@@ -0,0 +1,22 @@
+/* { dg-do run } */
+/* { dg-require-effective-target arm_mve_hw } */
+/* { dg-options "-O2" } */
+/* { dg-add-options arm_v8_1m_mve_fp } */
+
+#include
+
+__attribute__((noipa))
+uint32x4_t foo (void) {
+ uint32x4_t V0 = vld1q_u32(((const uint32_t[4]){1, 2, 3, 4}));
+ return V0;
+}
+
+int main(void)
+{
+ uint32_t buf[4];
+ vst1q_u32 (buf, foo());
+
+ for (int i = 0; i < 4; i++)
+if (buf[i] != i+1)
+ __builtin_abort ();
+}
--
2.34.1
Re: [PATCH] aarch64: Add +lse128 architectural extension command-line flag
On Fri, 15 Mar 2024 at 12:15, Victor Do Nascimento
wrote:
>
> Given how, at present, the choice of using LSE128 atomic instructions
> by the toolchain is delegated to run-time selection in the form of
> Libatomic ifuncs, responsible for querying target support, the
> `+lse128' target architecture compile-time flag is absent from GCC.
>
> This, however, contrasts with the Binutils implementation, which gates
> LSE128 instructions behind the `+lse128' flag. This can lead to
> problems in GCC for certain use-cases. One such example is in the use
> of inline assembly, whereby the inability of enabling the feature in
> the command-line prevents the compiler from automatically issuing the
> necessary LSE128 `.arch' directive.
>
> This patch therefore brings GCC into alignment with LLVM and Binutils
> in adding support for the `+lse128' architectural extension flag.
>
> gcc/ChangeLog:
>
> * config/aarch64/aarch64-option-extensions.def: Add LSE128
> AARCH64_OPT_EXTENSION, adding it as a dependency for the D128
> feature.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/aarch64/lse128-flag.c: New.
> * gcc.target/aarch64/cpunative/info_23: Likewise.
> * gcc.target/aarch64/cpunative/native_cpu_23.c: Likewise.
> ---
> gcc/config/aarch64/aarch64-option-extensions.def | 4 +++-
> gcc/testsuite/gcc.target/aarch64/cpunative/info_23| 8
> .../gcc.target/aarch64/cpunative/native_cpu_23.c | 11 +++
> gcc/testsuite/gcc.target/aarch64/lse128-flag.c| 10 ++
> 4 files changed, 32 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.target/aarch64/cpunative/info_23
> create mode 100644 gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_23.c
> create mode 100644 gcc/testsuite/gcc.target/aarch64/lse128-flag.c
>
> diff --git a/gcc/config/aarch64/aarch64-option-extensions.def
> b/gcc/config/aarch64/aarch64-option-extensions.def
> index 1a3b91c68cf..ac54b899a06 100644
> --- a/gcc/config/aarch64/aarch64-option-extensions.def
> +++ b/gcc/config/aarch64/aarch64-option-extensions.def
> @@ -275,7 +275,9 @@ AARCH64_OPT_EXTENSION("mops", MOPS, (), (), (), "")
>
> AARCH64_OPT_EXTENSION("cssc", CSSC, (), (), (), "cssc")
>
> -AARCH64_OPT_EXTENSION("d128", D128, (), (), (), "d128")
> +AARCH64_OPT_EXTENSION("lse128", LSE128, (LSE), (), (), "lse128")
> +
> +AARCH64_OPT_EXTENSION("d128", D128, (LSE128), (), (), "d128")
>
FWIW, looks good to me, I noticed that now we'll also have the
dependency of d128 on lse128, although d128 didn't have the (implicit)
dependency on lse before.
Christophe
> AARCH64_OPT_EXTENSION("the", THE, (), (), (), "the")
>
> diff --git a/gcc/testsuite/gcc.target/aarch64/cpunative/info_23
> b/gcc/testsuite/gcc.target/aarch64/cpunative/info_23
> new file mode 100644
> index 000..d77c25d2f61
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/cpunative/info_23
> @@ -0,0 +1,8 @@
> +processor : 0
> +BogoMIPS : 100.00
> +Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 asimddp atomics
> lse128
> +CPU implementer: 0xfe
> +CPU architecture: 8
> +CPU variant: 0x0
> +CPU part : 0xd08
> +CPU revision : 2
> \ No newline at end of file
> diff --git a/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_23.c
> b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_23.c
> new file mode 100644
> index 000..8a1e235d8ab
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/cpunative/native_cpu_23.c
> @@ -0,0 +1,11 @@
> +/* { dg-do compile { target { { aarch64*-*-linux*} && native } } } */
> +/* { dg-set-compiler-env-var GCC_CPUINFO
> "$srcdir/gcc.target/aarch64/cpunative/info_23" } */
> +/* { dg-additional-options "-mcpu=native" } */
> +
> +int main()
> +{
> + return 0;
> +}
> +
> +/* { dg-final { scan-assembler {\.arch
> armv8-a\+dotprod\+crc\+crypto\+lse128} } } */
> +/* Test one where lse128 is available and so should be emitted. */
> diff --git a/gcc/testsuite/gcc.target/aarch64/lse128-flag.c
> b/gcc/testsuite/gcc.target/aarch64/lse128-flag.c
> new file mode 100644
> index 000..71339c3af6d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/lse128-flag.c
> @@ -0,0 +1,10 @@
> +/* { dg-do compile { target { aarch64*-*-*} } } */
> +/* { dg-additional-options "-march=armv9.4-a+lse128" } */
> +
> +int main()
> +{
> + return 0;
> +}
> +
> +/* { dg-final { scan-assembler {\.arch armv9\.4-a\+crc\+lse128} } } */
> +/* Test a normal looking procinfo. */
> --
> 2.34.1
>
Re: [RFC] add regenerate Makefile target
On Thu, 14 Mar 2024 at 19:10, Simon Marchi wrote: > > > > On 2024-03-13 04:02, Christophe Lyon via Gdb wrote: > > Hi! > > > > After recent discussions on IRC and on the lists about maintainer-mode > > and various problems with auto-generated source files, I've written > > this small prototype. > > > > Based on those discussions, I assumed that people generally want to > > update autotools files using a script similar to autoregen.py, which > > takes care of running aclocal, autoheader, automake and autoconf as > > appropriate. > > > > What is currently missing is a "simple" way of regenerating other > > files, which happens normally with --enable-maintainer-mode (which is > > reportedly broken). This patch as a "regenerate" Makefile target > > which can be called to update those files, provided > > --enable-maintainer-mode is used. > > > > I tried this approach with the following workflow for binutils/gdb: > > - run autoregen.py in srcdir > > - cd builddir > > - configure --enable-maintainer-mode > > - make all-bfd all-libiberty regenerate -j1 > > - for gdb: make all -C gdb/data-directory -j1 > > - make all -jXXX > > > > Making 'all' in bfd and libiberty is needed by some XXX-gen host > > programs in opcodes. > > > > The advantage (for instance for CI) is that we can regenerate files at > > -j1, thus avoiding the existing race conditions, and build the rest > > with -j XXX. > > > > Among drawbacks: > > - most sub-components use Makefile.am, but gdb does not: this may make > > maintenance more complex (different rules for different projects) > > - maintaining such ad-hoc "regenerate" rules would require special > > attention from maintainers/reviewers > > - dependency on -all-bfd and all-libiberty is probably not fully > >intuitive, but should not be a problem if the "regenerate" rules > >are used after a full build for instance > > > > Of course Makefile.def/Makefile.tpl would need further cleanup as I > > didn't try to take gcc into account is this patch. > > > > Thoughts? > > My first thought it: why is it a Makefile target, instead of some script > on the side (like autoregen.sh). It would be nice / useful to be > able to it without configuring / building anything. For instance, the > autoregen buildbot job could run it without configuring anything. > Ideally, the buildbot wouldn't maintain its own autoregen.py file on the > side, it would just use whatever is in the repo. Firstly because of what you mention later: some regeneration steps require building host tools first, like the XXX-gen in opcodes. Since the existing Makefiles already contain the rules to autoregen all these files, it seemed natural to me to reuse them, to avoid reinventing the wheel with the risk of introducing new bugs. This involves changes in places where I've never looked at before, so I'd rather reuse as much existing support as possible. For instance, there are the generators in opcodes/, but also things in sim/, bfd/, updates to the docs and potfiles. In gcc, there's also something "unusual" in fixincludes/ and libgfortran/ In fact, I considered also including 'configure', 'Makefile.in', etc... in the 'regenerate' target, it does not seem natural to me to invoke a script on the side, where you have to replicate the behaviour of existing Makefiles, possibly getting out-of-sync when someone forgets to update either Makefile or autoregen.py. What is currently missing is a way to easily regenerate files without having to run a full 'make all' (which currently takes care of calling autoconf & friends to update configure/Makefile.in). But yeah, having to configure before being able to regenerate files is a bit awkward too :-) > > Looking at the rule to re-generate copying.c in gdb for instance: > > # Make copying.c from COPYING > $(srcdir)/copying.c: @MAINTAINER_MODE_TRUE@ $(srcdir)/../COPYING3 > $(srcdir)/copying.awk >awk -f $(srcdir)/copying.awk \ >< $(srcdir)/../COPYING3 > $(srcdir)/copying.tmp >mv $(srcdir)/copying.tmp $(srcdir)/copying.c > > There is nothing in this code that requires having configured the source > tree. This code could for instance be moved to some > generate-copying-c.sh script. generate-copying-c.sh could be called by > an hypothetical autoregen.sh script, as well as the copying.c Makefile > target, if we want to continue supporting the maintainer mode. Wouldn't it be more obscure than now? Currently such build rules are all in the relevant Makefile. You'd have to open several scripts to discover what's involved with updating copy
[RFC] add regenerate Makefile target
Hi!
After recent discussions on IRC and on the lists about maintainer-mode
and various problems with auto-generated source files, I've written
this small prototype.
Based on those discussions, I assumed that people generally want to
update autotools files using a script similar to autoregen.py, which
takes care of running aclocal, autoheader, automake and autoconf as
appropriate.
What is currently missing is a "simple" way of regenerating other
files, which happens normally with --enable-maintainer-mode (which is
reportedly broken). This patch as a "regenerate" Makefile target
which can be called to update those files, provided
--enable-maintainer-mode is used.
I tried this approach with the following workflow for binutils/gdb:
- run autoregen.py in srcdir
- cd builddir
- configure --enable-maintainer-mode
- make all-bfd all-libiberty regenerate -j1
- for gdb: make all -C gdb/data-directory -j1
- make all -jXXX
Making 'all' in bfd and libiberty is needed by some XXX-gen host
programs in opcodes.
The advantage (for instance for CI) is that we can regenerate files at
-j1, thus avoiding the existing race conditions, and build the rest
with -j XXX.
Among drawbacks:
- most sub-components use Makefile.am, but gdb does not: this may make
maintenance more complex (different rules for different projects)
- maintaining such ad-hoc "regenerate" rules would require special
attention from maintainers/reviewers
- dependency on -all-bfd and all-libiberty is probably not fully
intuitive, but should not be a problem if the "regenerate" rules
are used after a full build for instance
Of course Makefile.def/Makefile.tpl would need further cleanup as I
didn't try to take gcc into account is this patch.
Thoughts?
Thanks,
Christophe
---
Makefile.def | 37 +-
Makefile.in | 1902 ++
Makefile.tpl |7 +
bfd/Makefile.am |1 +
bfd/Makefile.in |1 +
binutils/Makefile.am |1 +
binutils/Makefile.in |1 +
gas/Makefile.am |1 +
gas/Makefile.in |1 +
gdb/Makefile.in |1 +
gold/Makefile.am |2 +-
gold/Makefile.in |2 +-
gprof/Makefile.am|1 +
gprof/Makefile.in|1 +
ld/Makefile.am |1 +
ld/Makefile.in |1 +
opcodes/Makefile.am |2 +
opcodes/Makefile.in |2 +
18 files changed, 1952 insertions(+), 13 deletions(-)
diff --git a/Makefile.def b/Makefile.def
index 3e00a729a0c..42e71a9ffa2 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -39,7 +39,8 @@ host_modules= { module= binutils; bootstrap=true; };
host_modules= { module= bison; no_check_cross= true; };
host_modules= { module= cgen; };
host_modules= { module= dejagnu; };
-host_modules= { module= etc; };
+host_modules= { module= etc;
+missing= regenerate; };
host_modules= { module= fastjar; no_check_cross= true; };
host_modules= { module= fixincludes; bootstrap=true;
missing= TAGS;
@@ -73,7 +74,8 @@ host_modules= { module= isl; lib_path=.libs; bootstrap=true;
no_install= true; };
host_modules= { module= gold; bootstrap=true; };
host_modules= { module= gprof; };
-host_modules= { module= gprofng; };
+host_modules= { module= gprofng;
+missing= regenerate; };
host_modules= { module= gettext; bootstrap=true; no_install=true;
module_srcdir= "gettext/gettext-runtime";
// We always build gettext with pic, because some packages
(e.g. gdbserver)
@@ -95,7 +97,8 @@ host_modules= { module= tcl;
missing=mostlyclean; };
host_modules= { module= itcl; };
host_modules= { module= ld; bootstrap=true; };
-host_modules= { module= libbacktrace; bootstrap=true; };
+host_modules= { module= libbacktrace; bootstrap=true;
+missing= regenerate; };
host_modules= { module= libcpp; bootstrap=true; };
// As with libiconv, don't install any of libcody
host_modules= { module= libcody; bootstrap=true;
@@ -110,9 +113,11 @@ host_modules= { module= libcody; bootstrap=true;
missing= install-dvi;
missing=TAGS; };
host_modules= { module= libdecnumber; bootstrap=true;
- missing=TAGS; };
+ missing=TAGS;
+missing= regenerate; };
host_modules= { module= libgui; };
host_modules= { module= libiberty; bootstrap=true;
+missing= regenerate;
extra_configure_flags='@extra_host_libiberty_configure_flags@';};
// Linker plugins may need their own build of libiberty; see
// gcc/doc/install.texi. We take care that this build of libiberty doesn't get
@@ -134,16 +139,22 @@ host_modules= { module= libiconv;
missing= install-html;
missing= install-info; };
host_modules= { module= m4; };
-host_modules= { module= readline; };
+host_modules= { module= readline;
+missing= regenerate; };
host_modules= { module= sid; };
-host_modules= { module= sim;
Re: Help needed with maintainer-mode
On Mon, 4 Mar 2024 at 16:41, Richard Earnshaw wrote: > > > > On 04/03/2024 15:36, Richard Earnshaw (lists) wrote: > > On 04/03/2024 14:46, Christophe Lyon via Gcc wrote: > >> On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote: > >>> > >>> On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc > >>> wrote: > >>>> > >>>> Hi! > >>>> > >>>> On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge > >>>> wrote: > >>>>> > >>>>> Hi! > >>>>> > >>>>> On 2024-03-04T00:30:05+, Sam James wrote: > >>>>>> Mark Wielaard writes: > >>>>>>> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote: > >>>>>>>> [...], I read > >>>>>>>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration > >>>>>>>> <https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration> > >>>>>>>> which basically says "run autoreconf in every dir where there is a > >>>>>>>> configure script" > >>>>>>>> but this is not exactly what autoregen.py is doing. IIRC it is based > >>>>>>>> on a script from Martin Liska, do you know/remember why it follows a > >>>>>>>> different process? > >>>>>>> > >>>>>>> CCing Sam and Arsen who helped refine the autoregen.py script, who > >>>>>>> might remember more details. We wanted a script that worked for both > >>>>>>> gcc and binutils-gdb. And as far as I know autoreconf simply didn't > >>>>>>> work in all directories. We also needed to skip some directories that > >>>>>>> did contain a configure script, but that were imported (gotools, > >>>>>>> readline, minizip). > >>>>>> > >>>>>> What we really need to do is, for a start, land tschwinge/aoliva's > >>>>>> patches [0] > >>>>>> for AC_CONFIG_SUBDIRS. > >>>>> > >>>>> Let me allocate some time this week to get that one completed. > >>>>> > >>>>>> Right now, the current situation is janky and it's nowhere near > >>>>>> idiomatic autotools usage. It is not a comfortable experience > >>>>>> interacting with it even as someone who is familiar and happy with > >>>>>> using > >>>>>> autotools otherwise. > >>>>>> > >>>>>> I didn't yet play with maintainer-mode myself but I also didn't see > >>>>>> much > >>>>>> point given I knew of more fundamental problems like this. > >>>>>> > >>>>>> [0] > >>>>>> https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/ > >>>>>> > >>>>>> <https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/> > >>>>> > >>>> > >>>> Thanks for the background. I didn't follow that discussion at that time > >>>> :-) > >>>> > >>>> So... I was confused because I noticed many warnings when doing a simple > >>>> find . -name configure |while read f; do echo $f;d=$(dirname $f) && > >>>> autoreconf -f $d && echo $d; done > >>>> as suggested by https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration > >>>> <https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration> > >>>> > >>>> Then I tried with autoregen.py, and saw the same and now just > >>>> checked Sourceware's bot logs and saw the same numerous warnings at > >>>> least in GCC (didn't check binutils yet). Looks like this is > >>>> "expected" > >>>> > >>>> I started looking at auto-regenerating these files in our CI a couple > >>>> of weeks ago, after we received several "complaints" from contributors > >>>> saying that our precommit CI was useless / bothering since it didn't > >>>> regenerate files, leading to false alarms. > >>>> But now I'm wondering how such contributors regenerate the files > >>>> impacted by their patches before committing, they probably just > >>>> regenerate th
Re: Help needed with maintainer-mode
On Mon, 4 Mar 2024 at 12:25, Jonathan Wakely wrote: > > On Mon, 4 Mar 2024 at 10:44, Christophe Lyon via Gcc wrote: > > > > Hi! > > > > On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote: > > > > > > Hi! > > > > > > On 2024-03-04T00:30:05+, Sam James wrote: > > > > Mark Wielaard writes: > > > >> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote: > > > >>> [...], I read > > > >>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration > > > >>> which basically says "run autoreconf in every dir where there is a > > > >>> configure script" > > > >>> but this is not exactly what autoregen.py is doing. IIRC it is based > > > >>> on a script from Martin Liska, do you know/remember why it follows a > > > >>> different process? > > > >> > > > >> CCing Sam and Arsen who helped refine the autoregen.py script, who > > > >> might remember more details. We wanted a script that worked for both > > > >> gcc and binutils-gdb. And as far as I know autoreconf simply didn't > > > >> work in all directories. We also needed to skip some directories that > > > >> did contain a configure script, but that were imported (gotools, > > > >> readline, minizip). > > > > > > > > What we really need to do is, for a start, land tschwinge/aoliva's > > > > patches [0] > > > > for AC_CONFIG_SUBDIRS. > > > > > > Let me allocate some time this week to get that one completed. > > > > > > > Right now, the current situation is janky and it's nowhere near > > > > idiomatic autotools usage. It is not a comfortable experience > > > > interacting with it even as someone who is familiar and happy with using > > > > autotools otherwise. > > > > > > > > I didn't yet play with maintainer-mode myself but I also didn't see much > > > > point given I knew of more fundamental problems like this. > > > > > > > > [0] > > > > https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/ > > > > > > > Thanks for the background. I didn't follow that discussion at that time :-) > > > > So... I was confused because I noticed many warnings when doing a simple > > find . -name configure |while read f; do echo $f;d=$(dirname $f) && > > autoreconf -f $d && echo $d; done > > as suggested by https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration > > > > Then I tried with autoregen.py, and saw the same and now just > > checked Sourceware's bot logs and saw the same numerous warnings at > > least in GCC (didn't check binutils yet). Looks like this is > > "expected" > > > > I started looking at auto-regenerating these files in our CI a couple > > of weeks ago, after we received several "complaints" from contributors > > saying that our precommit CI was useless / bothering since it didn't > > regenerate files, leading to false alarms. > > But now I'm wondering how such contributors regenerate the files > > impacted by their patches before committing, they probably just > > regenerate things in their subdir of interest, not noticing the whole > > picture :-( > > > > As a first step, we can probably use autoregen.py too, and declare > > maintainer-mode broken. However, I do notice that besides the rules > > about regenerating configure/Makefile.in/..., maintainer-mode is also > > used to update some files. > > In gcc: > > fixincludes: fixincl.x > > libffi: doc/version.texi > > libgfortran: some stuff :-) > > libiberty: functions.texi > > My recently proposed patch adds the first of those to gcc_update, the > other should be done too. > https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647027.html > This script touches files such that they appear more recent than their dependencies, so IIUC even if one uses --enable-maintainer-mode, it will have no effect. For auto* files, this is "fine" as we can run autoreconf or autoregen.py before starting configure+build, but what about other files? For instance, if we have to test a patch which implies changes to fixincludes/fixincl.x, how should we proceed? 1- git checkout (with possibly "wrong" timestamps) 2- apply patch-to-test 3- contrib/gcc_update -t 4- configure --enable-maintainer-mode I guess --enable-maintainer-mode would be largely (if not completely) disabled by step 3 above? And we should
Re: Help needed with maintainer-mode
Hi!
On Mon, 4 Mar 2024 at 10:36, Thomas Schwinge wrote:
>
> Hi!
>
> On 2024-03-04T00:30:05+, Sam James wrote:
> > Mark Wielaard writes:
> >> On Fri, Mar 01, 2024 at 05:32:15PM +0100, Christophe Lyon wrote:
> >>> [...], I read
> >>> https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
> >>> which basically says "run autoreconf in every dir where there is a
> >>> configure script"
> >>> but this is not exactly what autoregen.py is doing. IIRC it is based
> >>> on a script from Martin Liska, do you know/remember why it follows a
> >>> different process?
> >>
> >> CCing Sam and Arsen who helped refine the autoregen.py script, who
> >> might remember more details. We wanted a script that worked for both
> >> gcc and binutils-gdb. And as far as I know autoreconf simply didn't
> >> work in all directories. We also needed to skip some directories that
> >> did contain a configure script, but that were imported (gotools,
> >> readline, minizip).
> >
> > What we really need to do is, for a start, land tschwinge/aoliva's patches
> > [0]
> > for AC_CONFIG_SUBDIRS.
>
> Let me allocate some time this week to get that one completed.
>
> > Right now, the current situation is janky and it's nowhere near
> > idiomatic autotools usage. It is not a comfortable experience
> > interacting with it even as someone who is familiar and happy with using
> > autotools otherwise.
> >
> > I didn't yet play with maintainer-mode myself but I also didn't see much
> > point given I knew of more fundamental problems like this.
> >
> > [0]
> > https://inbox.sourceware.org/gcc-patches/oril72c4yh@lxoliva.fsfla.org/
>
Thanks for the background. I didn't follow that discussion at that time :-)
So... I was confused because I noticed many warnings when doing a simple
find . -name configure |while read f; do echo $f;d=$(dirname $f) &&
autoreconf -f $d && echo $d; done
as suggested by https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration
Then I tried with autoregen.py, and saw the same and now just
checked Sourceware's bot logs and saw the same numerous warnings at
least in GCC (didn't check binutils yet). Looks like this is
"expected"
I started looking at auto-regenerating these files in our CI a couple
of weeks ago, after we received several "complaints" from contributors
saying that our precommit CI was useless / bothering since it didn't
regenerate files, leading to false alarms.
But now I'm wondering how such contributors regenerate the files
impacted by their patches before committing, they probably just
regenerate things in their subdir of interest, not noticing the whole
picture :-(
As a first step, we can probably use autoregen.py too, and declare
maintainer-mode broken. However, I do notice that besides the rules
about regenerating configure/Makefile.in/..., maintainer-mode is also
used to update some files.
In gcc:
fixincludes: fixincl.x
libffi: doc/version.texi
libgfortran: some stuff :-)
libiberty: functions.texi
in binutils/bfd:
gdb/sim
bfd/po/SRC-POTFILES.in
bfd/po/BLD-POTFILES.in
bfd/bfd-in2.h
bfd/libbfd.h
bfd/libcoff.h
binutils/po/POTFILES.in
gas/po/POTFILES.in
opcodes/i386*.h
gdb/copying.c
gdb/data-directory/*.xml
gold/po/POTFILES.in
gprof/po/POTFILES.in
gfprofng/doc/version.texi
ld/po/SRC-POTFILES.in
ld/po/BLD-POTFILES.in
ld: ldgram/ldlex... and all emulation sources
libiberty/functions.texi
opcodes/po/POTFILES.in
opcodes/aarch64-{asm,dis,opc}-2.c
opcodes/ia64 msp430 rl78 rx z8k decoders
How are these files "normally" expected to be updated? Do people just
manually uncomment the corresponding maintainer lines in the Makefiles
and update manually? In particular we hit issues several times with
files under opcodes, that we don't regenerate currently. Maybe we
could build binutils in maintainer-mode at -j1 but, well
README-maintainer-mode in binutils/gdb only mentions a problem with
'make distclean' and maintainer mode
binutils/README-how-to-make-a-release indicates to use
--enable-maintainer-mode, and the sample 'make' invocations do not
include any -j flag, is that an indication that only -j1 is supposed
to work?
Similarly, the src-release.sh script does not use -j.
Thanks,
Christophe
>
> Grüße
> Thomas
Re: Help needed with maintainer-mode
On Fri, 1 Mar 2024 at 14:08, Mark Wielaard wrote: > > Hi Christophe, > > On Thu, 2024-02-29 at 18:39 +0100, Christophe Lyon wrote: > > On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote: > > > That python script works across gcc/binutils/gdb: > > > https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py > > > > > > It is installed into a container file that has the exact autoconf and > > > automake version needed to regenerate the autotool files: > > > https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools > > > > > > And it was indeed done this way because that way the files are > > > regenerated in a reproducible way. Which wasn't the case when using > > > --enable-maintainer-mode (and autoreconfig also doesn't work). > > > > I see. So it is possibly incomplete, in the sense that it may lack > > some of the steps that maintainer-mode would perform? > > For instance, gas for aarch64 has some *opcodes*.c files that need > > regenerating before committing. The regeneration step is enabled in > > maintainer-mode, so I guess the autoregen bots on Sourceware would > > miss a problem with these files? > > Yes, it is certainly incomplete. But it is done this way because it is > my understanding that even the gcc release maintainers do the > automake/autoconf invocations by hand instead of running with configure > --enable-maintainer-mode. After a discussion on IRC, I read https://gcc.gnu.org/wiki/Regenerating_GCC_Configuration which basically says "run autoreconf in every dir where there is a configure script" but this is not exactly what autoregen.py is doing. IIRC it is based on a script from Martin Liska, do you know/remember why it follows a different process? Thanks, Christophe > > Note that another part that isn't caught at the moment are the > regeneration of the opt.urls files. There is a patch for that pending: > https://inbox.sourceware.org/buildbot/20231215005908.gc12...@gnu.wildebeest.org/ > > But that is waiting for the actual opt.urls to be regenerated correctly > first: > https://inbox.sourceware.org/gcc-patches/20240224174258.gd1...@gnu.wildebeest.org/ > Ping David? > > It would be nice to have all these "regeneration targets" in one script > that could be used by both the pre-commit and post-commit checkers. > > Cheers, > > Mark
Re: Help needed with maintainer-mode
On Fri, 1 Mar 2024 at 14:08, Mark Wielaard wrote: > > Hi Christophe, > > On Thu, 2024-02-29 at 18:39 +0100, Christophe Lyon wrote: > > On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote: > > > That python script works across gcc/binutils/gdb: > > > https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py > > > > > > It is installed into a container file that has the exact autoconf and > > > automake version needed to regenerate the autotool files: > > > https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools > > > > > > And it was indeed done this way because that way the files are > > > regenerated in a reproducible way. Which wasn't the case when using > > > --enable-maintainer-mode (and autoreconfig also doesn't work). > > > > I see. So it is possibly incomplete, in the sense that it may lack > > some of the steps that maintainer-mode would perform? > > For instance, gas for aarch64 has some *opcodes*.c files that need > > regenerating before committing. The regeneration step is enabled in > > maintainer-mode, so I guess the autoregen bots on Sourceware would > > miss a problem with these files? > > Yes, it is certainly incomplete. But it is done this way because it is > my understanding that even the gcc release maintainers do the > automake/autoconf invocations by hand instead of running with configure > --enable-maintainer-mode. Indeed, I've just discovered that earlier today :-) > > Note that another part that isn't caught at the moment are the > regeneration of the opt.urls files. There is a patch for that pending: Indeed. I hadn't thought of it either. And just noticed it requires the D frontend, which we don't build in CI. > https://inbox.sourceware.org/buildbot/20231215005908.gc12...@gnu.wildebeest.org/ > > But that is waiting for the actual opt.urls to be regenerated correctly > first: > https://inbox.sourceware.org/gcc-patches/20240224174258.gd1...@gnu.wildebeest.org/ > Ping David? > > It would be nice to have all these "regeneration targets" in one script > that could be used by both the pre-commit and post-commit checkers. > Agreed. > Cheers, > > Mark
Re: Help needed with maintainer-mode
On Thu, 29 Feb 2024 at 20:49, Thiago Jung Bauermann wrote: > > > Hello, > > Christophe Lyon writes: > > > I hoped improving this would be as simple as adding > > --enable-maintainer-mode when configuring, after making sure > > autoconf-2.69 and automake-1.15.1 were in the PATH (using our host's > > libtool and gettext seems OK). > > > > However, doing so triggered several problems, which look like race > > conditions in the build system (we build at -j160): > > - random build errors in binutils / gdb with messages like "No rule to > > make target 'po/BLD-POTFILES.in". I managed to reproduce something > > similar manually once, I noticed an empty Makefile; the build logs are > > of course difficult to read, so I couldn't figure out yet what could > > cause this. > > > > - random build failures in gcc in fixincludes. I think this is a race > > condition because fixincludes is updated concurrently both from > > /fixincludes and $buillddir/fixincludes. Probably fixable in gcc > > Makefiles. > > > > - I've seen other errors when building gcc like > > configure.ac:25: error: possibly undefined macro: AM_ENABLE_MULTILIB > > from libquadmath. I haven't investigated this yet. > > I don't know about the last one, but regarding the race conditions, one > workaround might be to define a make target that regenerates all files > (if one doesn't exist already, I don't know) and make the CI call it > with -j1 to avoid concurrency, and then do the regular build step with > -j160. > Yes, that's what I meant below with "magic" make target ;-) Thanks, Christophe > -- > Thiago
Re: Help needed with maintainer-mode
On Thu, 29 Feb 2024 at 12:00, Mark Wielaard wrote: > > Hi Christophe, > > On Thu, Feb 29, 2024 at 11:22:33AM +0100, Christophe Lyon via Gcc wrote: > > I've noticed that sourceware's buildbot has a small script > > "autoregen.py" which does not use the project's build system, but > > rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way. > > Should we replicate that? > > That python script works across gcc/binutils/gdb: > https://sourceware.org/cgit/builder/tree/builder/containers/autoregen.py > > It is installed into a container file that has the exact autoconf and > automake version needed to regenerate the autotool files: > https://sourceware.org/cgit/builder/tree/builder/containers/Containerfile-autotools > > And it was indeed done this way because that way the files are > regenerated in a reproducible way. Which wasn't the case when using > --enable-maintainer-mode (and autoreconfig also doesn't work). I see. So it is possibly incomplete, in the sense that it may lack some of the steps that maintainer-mode would perform? For instance, gas for aarch64 has some *opcodes*.c files that need regenerating before committing. The regeneration step is enabled in maintainer-mode, so I guess the autoregen bots on Sourceware would miss a problem with these files? Thanks, Christophe > > It is run on all commits and warns if it detects a change in the > (checked in) generated files. > https://builder.sourceware.org/buildbot/#/builders/gcc-autoregen > https://builder.sourceware.org/buildbot/#/builders/binutils-gdb-autoregen > > Cheers, > > Mark
Re: Help needed with maintainer-mode
On Thu, 29 Feb 2024 at 11:41, Richard Earnshaw (lists) wrote: > > On 29/02/2024 10:22, Christophe Lyon via Gcc wrote: > > Hi! > > > > Sorry for cross-posting, but I'm not sure the rules/guidelines are the > > same in gcc vs binutils/gdb. > > > > TL;DR: are there some guidelines about how to use/enable maintainer-mode? > > > > In the context of the Linaro CI, I've been looking at enabling > > maintainer-mode at configure time in our configurations where we test > > patches before they are committed (aka "precommit CI", which relies on > > patchwork). > > > > Indeed, auto-generated files are not part of patch submissions, and > > when a patch implies regenerating some files before building, we > > currently report wrong failures because we don't perform such updates. > > > > I hoped improving this would be as simple as adding > > --enable-maintainer-mode when configuring, after making sure > > autoconf-2.69 and automake-1.15.1 were in the PATH (using our host's > > libtool and gettext seems OK). > > > > However, doing so triggered several problems, which look like race > > conditions in the build system (we build at -j160): > > - random build errors in binutils / gdb with messages like "No rule to > > make target 'po/BLD-POTFILES.in". I managed to reproduce something > > similar manually once, I noticed an empty Makefile; the build logs are > > of course difficult to read, so I couldn't figure out yet what could > > cause this. > > > > - random build failures in gcc in fixincludes. I think this is a race > > condition because fixincludes is updated concurrently both from > > /fixincludes and $buillddir/fixincludes. Probably fixable in gcc > > Makefiles. > > > > - I've seen other errors when building gcc like > > configure.ac:25: error: possibly undefined macro: AM_ENABLE_MULTILIB > > from libquadmath. I haven't investigated this yet. > > > > I've read binutils' README-maintainer-mode, which contains a warning > > about distclean, but we don't use this: we start our builds from a > > scratch directory. > > > > So... I'm wondering if there are some "official" guidelines about how > > to regenerate files, and/or use maintainer-mode? Maybe I missed a > > "magic" make target (eg 'make autoreconf-all') that should be executed > > after configure and before 'make all'? > > > > I've noticed that sourceware's buildbot has a small script > > "autoregen.py" which does not use the project's build system, but > > rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way. > > Should we replicate that? > > > > Thanks, > > > > Christophe > > There are other potential gotchas as well, such as the manual copying of the > generated tm.texi back into the source repo due to relicensing. Perhaps we > haven't encountered that one because patches generally contain that > duplicated output. > It did happen a few weeks ago, with a patch that was updating the target hooks IIRC. > If we want a CI to work reliably, then perhaps we should reconsider our > policy of stripping out regenerated code. We have a number of developer > practices, such as replying to an existing patch with an updated version that > the CI can't handle easily (especially if the patch is part of a series), so > there may be space for a discussion on how to work smarter. > Sure, there are many things we can improve in the current workflow to make it more CI friendly ;-) But I was only asking how maintainer-mode is supposed to be used, so that I can replicate the process in CI. I couldn't find any documentation :-) Thanks, Christophe > My calendar says we have a toolchain office hours meeting today, perhaps this > would be worth bringing up. > > R. >
Help needed with maintainer-mode
Hi! Sorry for cross-posting, but I'm not sure the rules/guidelines are the same in gcc vs binutils/gdb. TL;DR: are there some guidelines about how to use/enable maintainer-mode? In the context of the Linaro CI, I've been looking at enabling maintainer-mode at configure time in our configurations where we test patches before they are committed (aka "precommit CI", which relies on patchwork). Indeed, auto-generated files are not part of patch submissions, and when a patch implies regenerating some files before building, we currently report wrong failures because we don't perform such updates. I hoped improving this would be as simple as adding --enable-maintainer-mode when configuring, after making sure autoconf-2.69 and automake-1.15.1 were in the PATH (using our host's libtool and gettext seems OK). However, doing so triggered several problems, which look like race conditions in the build system (we build at -j160): - random build errors in binutils / gdb with messages like "No rule to make target 'po/BLD-POTFILES.in". I managed to reproduce something similar manually once, I noticed an empty Makefile; the build logs are of course difficult to read, so I couldn't figure out yet what could cause this. - random build failures in gcc in fixincludes. I think this is a race condition because fixincludes is updated concurrently both from /fixincludes and $buillddir/fixincludes. Probably fixable in gcc Makefiles. - I've seen other errors when building gcc like configure.ac:25: error: possibly undefined macro: AM_ENABLE_MULTILIB from libquadmath. I haven't investigated this yet. I've read binutils' README-maintainer-mode, which contains a warning about distclean, but we don't use this: we start our builds from a scratch directory. So... I'm wondering if there are some "official" guidelines about how to regenerate files, and/or use maintainer-mode? Maybe I missed a "magic" make target (eg 'make autoreconf-all') that should be executed after configure and before 'make all'? I've noticed that sourceware's buildbot has a small script "autoregen.py" which does not use the project's build system, but rather calls aclocal/autoheader/automake/autoconf in an ad-hoc way. Should we replicate that? Thanks, Christophe
Re: [PATCH] c++: Fix ICE due to folding a call to constructor on cdtor_returns_this arches (aka arm32) [PR113083]
On Fri, 23 Feb 2024 at 10:13, Christophe Lyon
wrote:
>
> On Fri, 23 Feb 2024 at 09:42, Jakub Jelinek wrote:
> >
> > Hi!
> >
> > When targetm.cxx.cdtor_returns_this () (aka on arm32 TARGET_AAPCS_BASED)
> > constructor is supposed to return this pointer, but when we cp_fold such
> > a call, we don't take that into account and just INIT_EXPR the object,
> > so we can later ICE during gimplification, because the expression doesn't
> > have the right type.
> >
> > Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux and
> > tested with a cross to armv7-linux-gnueabi on the testcase, but
> > unfortunately there are no 32-bit arm boxes in cfarm and arm32 is gone from
> > Fedora for quite some time as well, so I have no easy way to test this.
> > Christophe, do you think you could test this? Thanks.
>
> Hi Jakub,
>
> Sadly our precommit CI could not apply your patch automatically (as
> you can see in patchwork).
>
> I'll test your patch manually.
>
I can now confirm that the new test passes on arm (native
armv8l-unknown-linux-gnueabihf), and no regression.
Thanks,
Christophe
> Thanks,
>
> Christophe
>
> >
> > 2024-02-23 Jakub Jelinek
> >
> > PR c++/113083
> > * cp-gimplify.cc (cp_fold): For targetm.cxx.cdtor_returns_this ()
> > wrap r into a COMPOUND_EXPR and return folded CALL_EXPR_ARG (x, 0).
> >
> > * g++.dg/cpp0x/constexpr-113083.C: New test.
> >
> > --- gcc/cp/cp-gimplify.cc.jj2024-02-22 21:45:09.663430066 +0100
> > +++ gcc/cp/cp-gimplify.cc 2024-02-22 22:30:23.481428242 +0100
> > @@ -3412,9 +3412,15 @@ cp_fold (tree x, fold_flags_t flags)
> > if (DECL_CONSTRUCTOR_P (callee))
> > {
> > loc = EXPR_LOCATION (x);
> > - tree s = build_fold_indirect_ref_loc (loc,
> > - CALL_EXPR_ARG (x, 0));
> > + tree a = CALL_EXPR_ARG (x, 0);
> > + bool return_this = targetm.cxx.cdtor_returns_this ();
> > + if (return_this)
> > + a = cp_save_expr (a);
> > + tree s = build_fold_indirect_ref_loc (loc, a);
> > r = cp_build_init_expr (s, r);
> > + if (return_this)
> > + r = build2_loc (loc, COMPOUND_EXPR, TREE_TYPE (x), r,
> > + fold_convert_loc (loc, TREE_TYPE (x), a));
> > }
> > x = r;
> > break;
> > --- gcc/testsuite/g++.dg/cpp0x/constexpr-113083.C.jj2024-01-13
> > 00:05:00.077372302 +0100
> > +++ gcc/testsuite/g++.dg/cpp0x/constexpr-113083.C 2024-02-22
> > 22:20:20.622618992 +0100
> > @@ -0,0 +1,16 @@
> > +// PR c++/113083
> > +// { dg-do compile { target c++11 } }
> > +// { dg-options "-Os" }
> > +
> > +struct A { constexpr A (); };
> > +
> > +void
> > +foo ()
> > +{
> > + A b;
> > +}
> > +
> > +constexpr
> > +A::A ()
> > +{
> > +}
> >
> > Jakub
> >
Re: [PATCH] c++: Fix ICE due to folding a call to constructor on cdtor_returns_this arches (aka arm32) [PR113083]
On Fri, 23 Feb 2024 at 09:42, Jakub Jelinek wrote:
>
> Hi!
>
> When targetm.cxx.cdtor_returns_this () (aka on arm32 TARGET_AAPCS_BASED)
> constructor is supposed to return this pointer, but when we cp_fold such
> a call, we don't take that into account and just INIT_EXPR the object,
> so we can later ICE during gimplification, because the expression doesn't
> have the right type.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux and
> tested with a cross to armv7-linux-gnueabi on the testcase, but
> unfortunately there are no 32-bit arm boxes in cfarm and arm32 is gone from
> Fedora for quite some time as well, so I have no easy way to test this.
> Christophe, do you think you could test this? Thanks.
Hi Jakub,
Sadly our precommit CI could not apply your patch automatically (as
you can see in patchwork).
I'll test your patch manually.
Thanks,
Christophe
>
> 2024-02-23 Jakub Jelinek
>
> PR c++/113083
> * cp-gimplify.cc (cp_fold): For targetm.cxx.cdtor_returns_this ()
> wrap r into a COMPOUND_EXPR and return folded CALL_EXPR_ARG (x, 0).
>
> * g++.dg/cpp0x/constexpr-113083.C: New test.
>
> --- gcc/cp/cp-gimplify.cc.jj2024-02-22 21:45:09.663430066 +0100
> +++ gcc/cp/cp-gimplify.cc 2024-02-22 22:30:23.481428242 +0100
> @@ -3412,9 +3412,15 @@ cp_fold (tree x, fold_flags_t flags)
> if (DECL_CONSTRUCTOR_P (callee))
> {
> loc = EXPR_LOCATION (x);
> - tree s = build_fold_indirect_ref_loc (loc,
> - CALL_EXPR_ARG (x, 0));
> + tree a = CALL_EXPR_ARG (x, 0);
> + bool return_this = targetm.cxx.cdtor_returns_this ();
> + if (return_this)
> + a = cp_save_expr (a);
> + tree s = build_fold_indirect_ref_loc (loc, a);
> r = cp_build_init_expr (s, r);
> + if (return_this)
> + r = build2_loc (loc, COMPOUND_EXPR, TREE_TYPE (x), r,
> + fold_convert_loc (loc, TREE_TYPE (x), a));
> }
> x = r;
> break;
> --- gcc/testsuite/g++.dg/cpp0x/constexpr-113083.C.jj2024-01-13
> 00:05:00.077372302 +0100
> +++ gcc/testsuite/g++.dg/cpp0x/constexpr-113083.C 2024-02-22
> 22:20:20.622618992 +0100
> @@ -0,0 +1,16 @@
> +// PR c++/113083
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-Os" }
> +
> +struct A { constexpr A (); };
> +
> +void
> +foo ()
> +{
> + A b;
> +}
> +
> +constexpr
> +A::A ()
> +{
> +}
>
> Jakub
>
Re: [PATCH] gcc/Makefile.in: Fix install-info target if BUILD_INFO is empty
On Mon, 12 Feb 2024 at 11:27, Jakub Jelinek wrote: > > On Mon, Feb 12, 2024 at 11:13:49AM +0100, Christophe Lyon wrote: > > On Sun, 11 Feb 2024 at 06:56, Alexandre Oliva wrote: > > > > > > Hello, Christophe, > > > > > > On Feb 10, 2024, Christophe Lyon wrote: > > > > > > > gcc/ > > > > * Makefile.in: Add no-info dependency. > > > > * configure.ac: Set BUILD_INFO=no-info if makeinfo is not > > > > available. > > > > * configure: Regenerate. > > > > > > Thank you, this is ok. > > > > > > Now, this doesn't fix a regression, does it? > > > > Of course not :-) > > > > > > > > I would support putting this in for GCC 14, but I would be overstepping > > > my authority if I approved even such a small and well-contained > > > improvement patch in the current stage, so I'm approving it for stage1, > > > but maybe some global maintainer or release manager will chime in in > > > support for earlier merging? (hint, hint ;-) > > > > Thanks! > > This is ok for GCC 14 as an exception, but if any issues related to that > are found, please be prepared to revert and resubmit for GCC 15. > Sure! Thanks, Christophe > Jakub >
Re: [PATCH] rtl-optimization/113597 - recover base term for argument pointers
On Mon, 12 Feb 2024 at 09:00, Richard Biener wrote:
>
> On Sat, Feb 10, 2024 at 10:21 PM Toon Moene wrote:
> >
> > I managed to try this patch on aarch64-linux-gnu:
> >
> > This is the test run without your patch:
> >
> > https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807637.html
> >
> > And this is the "result" with your patch:
> >
> > https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807645.html
>
> Interesting .. this looks like a miscompile of stage2. Note that the Linaro
> CI was happy:
>
> https://patchwork.sourceware.org/project/gcc/patch/20240209102649.09c543858...@sourceware.org/
>
Hi!
Indeed this is NOT a bootstrap build, we only have such checks in postcommit CI.
Thanks,
Christophe
> Richard.
>
> > For me, as for you, it works for x86_64-linux-gnu:
> >
> > https://gcc.gnu.org/pipermail/gcc-testresults/2024-February/807609.html
> >
> > I hope this helps.
> >
> > Kind regards,
> > Toon Moene.
> >
> > On 2/9/24 11:26, Richard Biener wrote:
> > > The following allows a base term to be derived from an existing
> > > MEM_EXPR, notably the points-to set of a MEM_REF base. For the
> > > testcase in the PR this helps RTL DSE elide stores to a stack
> > > temporary. This covers pointers to NONLOCAL which can be mapped
> > > to arg_base_value, helping to disambiguate against other special
> > > bases (ADDRESS) as well as PARM_DECL accesses.
> > >
> > > Bootstrapped and tested on x86_64-unknown-linux-gnu.
> > >
> > > This is an attempt to recover some of the losses from dumbing down
> > > find_base_{term,value}. I did give my ideas how to properly do
> > > this during stage1 a start, I will post a short incomplete RFC series
> > > later today.
> > >
> > > OK for trunk?
> > >
> > > I've included all languages in testing and also tested with -m32 but
> > > details of RTL alias analysis might escape me ...
> > >
> > > Thanks,
> > > Richard.
> > >
> > > PR rtl-optimization/113597
> > > * alias.cc (find_base_term): Add argument for the whole mem
> > > and derive a base term from its MEM_EXPR.
> > > (true_dependence_1): Pass down the MEMs to find_base_term.
> > > (write_dependence_p): Likewise.
> > > (may_alias_p): Likewise.
> > > ---
> > > gcc/alias.cc | 43 ---
> > > 1 file changed, 36 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/gcc/alias.cc b/gcc/alias.cc
> > > index 6fad4b29d31..e33c56b0e80 100644
> > > --- a/gcc/alias.cc
> > > +++ b/gcc/alias.cc
> > > @@ -40,6 +40,9 @@ along with GCC; see the file COPYING3. If not see
> > > #include "rtl-iter.h"
> > > #include "cgraph.h"
> > > #include "ipa-utils.h"
> > > +#include "stringpool.h"
> > > +#include "value-range.h"
> > > +#include "tree-ssanames.h"
> > >
> > > /* The aliasing API provided here solves related but different problems:
> > >
> > > @@ -190,6 +193,10 @@ static struct {
> > > arguments, since we do not know at this level whether accesses
> > > based on different arguments can alias. The ADDRESS has id 0.
> > >
> > > + This is solely useful to disambiguate against other ADDRESS
> > > + bases as we know incoming pointers cannot point to local
> > > + stack, frame or argument space.
> > > +
> > >2. stack_pointer_rtx, frame_pointer_rtx, hard_frame_pointer_rtx
> > > (if distinct from frame_pointer_rtx) and arg_pointer_rtx.
> > > Each of these rtxes has a separate ADDRESS associated with it,
> > > @@ -2113,12 +2120,34 @@ find_base_term (rtx x, vec > > to avoid visiting them multiple times. We unwind that changes here.
> > > */
> > >
> > > static rtx
> > > -find_base_term (rtx x)
> > > +find_base_term (rtx x, const_rtx mem = NULL_RTX)
> > > {
> > > auto_vec, 32>
> > > visited_vals;
> > > rtx res = find_base_term (x, visited_vals);
> > > for (unsigned i = 0; i < visited_vals.length (); ++i)
> > > visited_vals[i].first->locs = visited_vals[i].second;
> > > + if (!res && mem && MEM_EXPR (mem))
> > > +{
> > > + tree base = get_base_address (MEM_EXPR (mem));
> > > + if (TREE_CODE (base) == PARM_DECL
> > > + && DECL_RTL_SET_P (base))
> > > + /* We need to look at how we expanded a PARM_DECL. It might be in
> > > +the argument space (UNIQUE_BASE_VALUE_ARGP) or it might
> > > +be spilled (UNIQUE_BASE_VALUE_FP/UNIQUE_BASE_VALUE_HFP). */
> > > + res = find_base_term (DECL_RTL (base));
> > > + else if (TREE_CODE (base) == MEM_REF
> > > +&& TREE_CODE (TREE_OPERAND (base, 0)) == SSA_NAME
> > > +&& SSA_NAME_PTR_INFO (TREE_OPERAND (base, 0)))
> > > + {
> > > + auto pt = _NAME_PTR_INFO (TREE_OPERAND (base, 0))->pt;
> > > + if (pt->nonlocal
> > > + && !pt->anything
> > > + && !pt->escaped
> > > + && !pt->ipa_escaped
> > > + && bitmap_empty_p (pt->vars))
> > > + res = arg_base_value;
> > > + }
> > > +}
> > > return res;
>
Re: [PATCH] gcc/Makefile.in: Fix install-info target if BUILD_INFO is empty
On Sun, 11 Feb 2024 at 06:56, Alexandre Oliva wrote: > > Hello, Christophe, > > On Feb 10, 2024, Christophe Lyon wrote: > > > gcc/ > > * Makefile.in: Add no-info dependency. > > * configure.ac: Set BUILD_INFO=no-info if makeinfo is not > > available. > > * configure: Regenerate. > > Thank you, this is ok. > > Now, this doesn't fix a regression, does it? Of course not :-) > > I would support putting this in for GCC 14, but I would be overstepping > my authority if I approved even such a small and well-contained > improvement patch in the current stage, so I'm approving it for stage1, > but maybe some global maintainer or release manager will chime in in > support for earlier merging? (hint, hint ;-) Thanks! > > -- > Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ >Free Software Activist GNU Toolchain Engineer > Disinformation flourishes because many people care deeply about injustice but > very few check the facts. Think Assange & Stallman. The empires strike back
Re: [PATCH] gcc/Makefile.in: Fix install-info target if BUILD_INFO is empty
Hi! On Tue, 6 Feb 2024 at 06:37, Alexandre Oliva wrote: > > Hello, Christophe, > > Thanks for the patch. > > On Feb 5, 2024, Christophe Lyon wrote: > > > In order to save build time, our CI overrides BUILD_INFO="", which > > works when invoking 'make all' but not for 'make install' in case some > > info files need an update. > > Hmm, I don't think this would be desirable. We ship updated info files > in release tarballs, and it would be desirable to install them even if > makeinfo is not available in the build environment. > > > I noticed this when testing a patch posted on the gcc-patches list, > > leading to an error at 'make install' time after updating tm.texi (the > > build reported 'new text' in tm.texi and stopped). This is because > > 'install' depends on 'install-info', which depends on > > $(DESTDIR)$(infodir)/gccint.info (among others). > > Ideally, we'd detect and report info files that are out-of-date WRT > their ultimate sources, especially to catch tm.texi.in changes, but > doing so only at install time is clearly suboptimal. > > I mean, if we don't have the tools to build info files, it's fine if we > skip their building, and even refrain from installing info files that > are missing or outdated, but we should install prebuilt ones if they're > available, and we should probably *not* refrain from trying to satisfy > the dependencies for info files at build time, even if it turns out that > we can't build the info files themselves. > > This suggests to me that, rather than setting BUILD_INFO to the empty > string, we should set it to e.g. no-info, so that $(MAKEINFO) will not > be run because x$(BUILD_INFO) != xinfo, but so that we still get the > dependencies resolved, e.g. by making no-info depend on info. Or maybe > make it info-check-deps, and insert that between info and its current > deps. WDYT? I've just spent quite a bit of time looking at your suggestion, and well... I hadn't considered the case of makeinfo missing/too old, in our use case makeinfo is present and recent enough but we want to save a few minutes of build time during the CI loop. As I mentioned, we (tried to) do this by doing BUILD_INFO="" when invoking 'make', and it took me ages to realize it is not working as expected, because GCC's top-level Makefile does not propagate BUILD_INFO recursively, and this conflicted with the setting of BUILD_INFO=no-info (I wanted to try to support several values for BUILD_INFO: info, no-info and "", where "" would disable more things, but it seems to be too much hassle) So, the attached small patch implements your suggestion, and works as expected: it makeinfo is not available, we now detect problems with tm.texi.in at build time rather than install time. OK? Looking deeper, I realized that texi2dvi and texi2pdf belong to the texinfo package, like makeinfo, so the dvi and pdf rules should probably also depend on BUILD_INFO? To generate html, we call makeinfo --html so the html rules should also depend on BUILD_INFO. However, unlike install-man, the install-html, install-dvi and install-pdf are not part of the plain 'install' target, so maybe we can argue that if someone runs 'make install-pdf' without texinfo, then too bad for him? Thanks, Christophe > > -- > Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/ >Free Software Activist GNU Toolchain Engineer > Disinformation flourishes because many people care deeply about injustice but > very few check the facts. Think Assange & Stallman. The empires strike back From 7ec6ff8ead24eb7c07d011371347cf12db11faf5 Mon Sep 17 00:00:00 2001 From: Christophe Lyon Date: Sat, 10 Feb 2024 21:17:08 + Subject: [PATCH v3] gcc/Makefile.in: Always check info dependencies BUILD_INFO is currently a byproduct of checking makeinfo presence/version. INSTALL_INFO used to be defined similarly, but was removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df (svn r38141). In order to save build time, our CI overrides MAKEINFO=echo, which works when invoking 'make all' but not for 'make install' in case some info files need an update. I noticed this while testing a patch posted on the gcc-patches list, leading to an error at 'make install' time after updating tm.texi (the build reported 'new text' in tm.texi and stopped). This is because 'install' depends on 'install-info', which depends on $(DESTDIR)$(infodir)/gccint.info (among others). As discussed, it is better to detect this problem during 'make all' rather than 'make install', and we still want to detect it even if makeinfo is not available. This patch makes configure set BUILD_INFO=no-info in case makeinfo is missing/too old, which effectively makes the build rules no-ops (x$(BUILD_INFO) != xinfo),
Re: [PATCH] [testsuite] Fix pretty printers regexps for GDB output
ping?
On Thu, 25 Jan 2024 at 16:54, Christophe Lyon
wrote:
>
> On Wed, 24 Jan 2024 at 12:02, Jonathan Wakely wrote:
> >
> > On Wed, 24 Jan 2024 at 10:48, Christophe Lyon wrote:
> > >
> > > GDB emits end of lines as \r\n, we currently match the reverse \n\r,
> >
> > We currently match [\n\r]+ which should match any of \n, \r, \n\r or \r\n
> >
>
> Hmm, right, sorry I had this patch in my tree for quite some time, but
> wrote the description just now, so I read a bit too quickly.
>
> >
> > > possibly leading to mismatches under racy conditions.
> >
> > What do we incorrectly match? Is the problem that a \r\n sequence
> > might be incompletely printed, due to buffering, and so the regex only
> > sees (and matches) the \r which then leaves an unwanted \n in the
> > stream, which then interferes with the next match? I don't understand
> > why that problem wouldn't just result in a failed match with your new
> > regex though.
> >
> Exactly: READ1 forces read() to return 1 byte at a time, so we leave
> an unwanted \r in front of a string that should otherwise match the
> "got" case.
>
> >
> > >
> > > I noticed this while running the GCC testsuite using the equivalent of
> > > GDB's READ1 feature [1] which helps detecting bufferization issues.
> > >
> > > Adjusting the first regexp to match the right order implied fixing the
> > > second one, to skip the empty lines.
> >
> > At the very least, this part of the description is misleading. The
> > existing regex matches "the right order" already. The change is to
> > match *exactly* \r\n instead of any mix of CR and LF characters.
> > That's not about matching "the right order", it's being more precise
> > in what we match.
> >
> > But I'm still confused about what the failure scenario is and how the
> > change fixes it.
> >
>
> I followed what the GDB testsuite does (it matches \r\n at the end of
> many regexps), but in fact it seems it's not needed:
> it works if I update the "got" regexp like this (ie. accept any number
> of leading \r or \n):
> - -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> + -re {^[\n\r]*(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> and leave the "skipping" regexp as it is currently.
>
> Is the new attached version OK?
>
> Thanks,
>
> Christophe
>
> > >
> > > Tested on aarch64-linux-gnu.
> > >
> > > [1]
> > > https//github.com/bminor/binutils-gdb/blob/master/gdb/testsuite/README#L269
> > >
> > > 2024-01-24 Christophe Lyon
> > >
> > > libstdc++-v3/
> > > * testsuite/lib/gdb-test.exp (gdb-test): Fix regexps.
> > > ---
> > > libstdc++-v3/testsuite/lib/gdb-test.exp | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > b/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > index 31206f2fc32..0de8d9ee153 100644
> > > --- a/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > +++ b/libstdc++-v3/testsuite/lib/gdb-test.exp
> > > @@ -194,7 +194,7 @@ proc gdb-test { marker {selector {}} {load_xmethods
> > > 0} } {
> > >
> > > set test_counter 0
> > > remote_expect target [timeout_value] {
> > > - -re {^(type|\$([0-9]+)) = ([^\n\r]*)[\n\r]+} {
> > > + -re {^(type|\$([0-9]+)) = ([^\n\r]*)\r\n} {
> > > send_log "got: $expect_out(buffer)"
> > >
> > > incr test_counter
> > > @@ -250,7 +250,7 @@ proc gdb-test { marker {selector {}} {load_xmethods
> > > 0} } {
> > > return
> > > }
> > >
> > > - -re {^[^$][^\n\r]*[\n\r]+} {
> > > + -re {^[\r\n]*[^$][^\n\r]*\r\n} {
> > > send_log "skipping: $expect_out(buffer)"
> > > exp_continue
> > > }
> > > --
> > > 2.34.1
> > >
> >
Re: [PATCH] gcc/configure: Re-introduce INSTALL_INFO
On Fri, 2 Feb 2024 at 11:40, Christophe Lyon wrote: > > On Fri, 2 Feb 2024 at 11:10, wrote: > > > > On 1 February 2024 18:15:34 CET, Christophe Lyon > > wrote: > > >BUILD_INFO is currently a byproduct of checking makeinfo > > >presence/version. INSTALL_INFO used to be defined similarly, but was > > >removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df > > >(svn r38141). > > > > > >In order to save build time, our CI overrides BUILD_INFO="", which > > >works when invoking 'make all' but not for 'make install' in case some > > >info files need an update. > > > > Instead of resurrecting INSTALL_INFO maybe you could something along the > > lines of > > > > https://gcc.gnu.org/bugzilla/attachment.cgi?id=15038=edit > > Ha indeed something along these lines would work too. > Thanks for the archaeology :-) > > > > > not sure which approach would be considered cleaner.. > Not sure either. > > What do maintainers prefer? > Actually that leads to a small patch: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644957.html > > > > HTH
[PATCH] gcc/Makefile.in: Fix install-info target if BUILD_INFO is empty
BUILD_INFO is currently a byproduct of checking makeinfo presence/version. INSTALL_INFO used to be defined similarly, but was removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df (svn r38141). In order to save build time, our CI overrides BUILD_INFO="", which works when invoking 'make all' but not for 'make install' in case some info files need an update. I noticed this when testing a patch posted on the gcc-patches list, leading to an error at 'make install' time after updating tm.texi (the build reported 'new text' in tm.texi and stopped). This is because 'install' depends on 'install-info', which depends on $(DESTDIR)$(infodir)/gccint.info (among others). This patch makes the 'install-info' dependency in 'install' conditioned by BUILD_INFO. 2024-02-05 Christophe Lyon gcc/ * Makefile.in: Use install-info only if BUILD_INFO is not empty. --- gcc/Makefile.in | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 4d38b162307..6cb564cfd35 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -817,7 +817,6 @@ INSTALL_HEADERS=install-headers install-mkheaders # Control whether Info documentation is built and installed. BUILD_INFO = @BUILD_INFO@ -INSTALL_INFO = @INSTALL_INFO@ # Control flags for @contents placement in HTML output MAKEINFO_TOC_INLINE_FLAG = @MAKEINFO_TOC_INLINE_FLAG@ @@ -3786,9 +3785,13 @@ maintainer-clean: # Install the driver last so that the window when things are # broken is small. install: install-common $(INSTALL_HEADERS) \ -install-cpp install-man $(INSTALL_INFO) install-@POSUB@ \ +install-cpp install-man install-@POSUB@ \ install-driver install-lto-wrapper install-gcc-ar +ifneq ($(BUILD_INFO),) +install: install-info +endif + ifeq ($(enable_plugin),yes) install: install-plugin endif -- 2.34.1
Re: [PATCH] gcc/configure: Re-introduce INSTALL_INFO
On Fri, 2 Feb 2024 at 11:10, wrote: > > On 1 February 2024 18:15:34 CET, Christophe Lyon > wrote: > >BUILD_INFO is currently a byproduct of checking makeinfo > >presence/version. INSTALL_INFO used to be defined similarly, but was > >removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df > >(svn r38141). > > > >In order to save build time, our CI overrides BUILD_INFO="", which > >works when invoking 'make all' but not for 'make install' in case some > >info files need an update. > > Instead of resurrecting INSTALL_INFO maybe you could something along the > lines of > > https://gcc.gnu.org/bugzilla/attachment.cgi?id=15038=edit Ha indeed something along these lines would work too. Thanks for the archaeology :-) > > not sure which approach would be considered cleaner.. Not sure either. What do maintainers prefer? > > HTH
[PATCH] gcc/configure: Re-introduce INSTALL_INFO
BUILD_INFO is currently a byproduct of checking makeinfo presence/version. INSTALL_INFO used to be defined similarly, but was removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df (svn r38141). In order to save build time, our CI overrides BUILD_INFO="", which works when invoking 'make all' but not for 'make install' in case some info files need an update. I noticed this when testing a patch posted on the gcc-patches list, leading to an error at 'make install' time after updating tm.texi (the build reported 'new text' in tm.texi and stopped). This is because 'install' depends on 'install-info', which depends on $(DESTDIR)$(infodir)/gccint.info (among others). This patch replaces the 'install-info' dependency in 'install' with $(INSTALL_INFO), thus enabling to skip this step. 2024-02-01 Christophe Lyon gcc/ * Makefile.in: Add INSTALL_INFO. * configure.ac: Add INSTALL_INFO. * configure: Regenerate. --- gcc/Makefile.in | 3 ++- gcc/configure| 3 +++ gcc/configure.ac | 3 +++ 3 files changed, 8 insertions(+), 1 deletion(-) diff --git a/gcc/Makefile.in b/gcc/Makefile.in index 95caa54a52b..4d38b162307 100644 --- a/gcc/Makefile.in +++ b/gcc/Makefile.in @@ -817,6 +817,7 @@ INSTALL_HEADERS=install-headers install-mkheaders # Control whether Info documentation is built and installed. BUILD_INFO = @BUILD_INFO@ +INSTALL_INFO = @INSTALL_INFO@ # Control flags for @contents placement in HTML output MAKEINFO_TOC_INLINE_FLAG = @MAKEINFO_TOC_INLINE_FLAG@ @@ -3785,7 +3786,7 @@ maintainer-clean: # Install the driver last so that the window when things are # broken is small. install: install-common $(INSTALL_HEADERS) \ -install-cpp install-man install-info install-@POSUB@ \ +install-cpp install-man $(INSTALL_INFO) install-@POSUB@ \ install-driver install-lto-wrapper install-gcc-ar ifeq ($(enable_plugin),yes) diff --git a/gcc/configure b/gcc/configure index 4acb254d830..00f8c7ed6fb 100755 --- a/gcc/configure +++ b/gcc/configure @@ -826,6 +826,7 @@ FLEX GENERATED_MANPAGES MAKEINFO_TOC_INLINE_FLAG BUILD_INFO +INSTALL_INFO MAKEINFO have_mktemp_command make_compare_target @@ -8836,8 +8837,10 @@ $as_echo "$as_me: WARNING: *** Makeinfo is missing or too old. *** Info documentation will not be built." >&2;} BUILD_INFO= + INSTALL_INFO= else BUILD_INFO=info + INSTALL_INFO=install-info fi diff --git a/gcc/configure.ac b/gcc/configure.ac index d2ed14496c1..1041c2391fb 100644 --- a/gcc/configure.ac +++ b/gcc/configure.ac @@ -1246,10 +1246,13 @@ if test $gcc_cv_prog_makeinfo_modern = no; then *** Makeinfo is missing or too old. *** Info documentation will not be built.]) BUILD_INFO= + INSTALL_INFO= else BUILD_INFO=info + INSTALL_INFO=install-info fi AC_SUBST(BUILD_INFO) +AC_SUBST(INSTALL_INFO) # Determine whether makeinfo supports the CONTENTS_OUTPUT_LOCATION variable. # If it does, we want to pass it to makeinfo in order to restore the old -- 2.34.1
