Re: [PATCH v3] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

[Maciej W. Rozycki via Gcc-patches]

On Fri, 28 Aug 2020, Jakub Jelinek wrote:

> >  As far as `-fexceptions' and `-fasynchronous-unwind-tables' are concerned 
> > it aligns with my understanding, i.e. in this specific scenario we need 
> > `-fasynchronous-unwind-tables' for libcalls (all of them) so that an 
> 
> -fasynchronous-unwind-tables is solely about whether one can unwind through
> the code, but not necessarily that EH will work.  If it is not turned on,
> non-call exceptions will certainly not work properly, because unwind info
> if present at all will only be correct on call insns and not guaranteed on
> anything else.

 Ack, this is what my understanding has been.

> -fexceptions enables EH handling in whatever function it is turned on,
> entries in .gcc_except_table as well as a personality routine will be added
> for it, calls from it which can throw (including special calls like throw)
> will be marked there and cause EH regions, similarly EH pads will be added
> for anything where an exception needs to be caught or where a cleanup needs
> to be run before continuing with the unwinding (e.g. destructors or cleanup
> attribute).  But still, it only expects that call can throw, not arbitrary
> instructions, so those won't be covered necessarily in EH regions, in the IL
> there won't be EH edges etc.
> 
> -fnon-call-exceptions is like -fexceptions, except in addition to calls
> (that may throw) it considers also possibly trapping instructions as
> something that can throw.  So way too many more EH edges, EH regions etc.

 OK, I believe I have realised what we do here.

 Obviously there may be multiple `try'/`catch' blocks in a program, and in 
a given function even.  Catching an exception essentially means matching 
the PC recorded for execution resumption (the return PC of a callee or a 
signal handler, which may come from various places according to the psABI 
in use, like the link register, a stack slot in the frame below, etc.) 
against the PC range(s) associated with a `try' block and passing control 
to the associated `catch' block.  For that obviously a set of exception 
data tables is required.

 Now, where `-fexceptions' only has been used we only record return PCs of 
call instructions in exception data tables, rather than recording the PC 
span of the whole `try' block, which in the course of optimisation might 
have been split into multiple disjoint ranges.  This is I gather to reduce 
the size of the tables and consequently the amount of processing required 
in EH, but the downside is an exception triggering at another place still 
within the `try' block will not be caught and will instead be passed up 
the frame chain.

 So where we want to also catch exceptions on instructions other than 
calls the `-fnon-call-exceptions' option can be used, in which case PC 
values associated with instructions from additional classes as per 
`may_trap_p_1' will be added to exception tables, making them larger.

 Still there is no way to catch exceptions on absolutely all instructions 
within a `try' block, as we have no option for that, IIUC, but the caller 
of the enclosing function can with the use of a `try' block around the 
call.

 I wasn't aware we have such optimisations/simplifications/restrictions in 
place and I honestly thought a `try' block was always completely covered.  
That is what I remember language semantics implied, but it has been long 
since I last looked at that, and no doubt standards have evolved and may 
have given leeway for compilers to only partially cover `try' blocks as 
they see fit for performance gain.  It is not clear from the description 
of `-fexceptions' or `-fnon-call-exceptions' options in our manual either.

 Perhaps it is general knowledge supposed to be held by software 
developers that I somehow missed previously, but it seems to me like it 
wouldn't hurt if it was actually mentioned in the description of said 
options, so if you agree with me, than I'll think and propose an update.

> Now, I'd say if for some trapping instruction in a function we want to throw
> an exception from a signal handler, surely the signal handler needs to be
> built with -fexceptions, but as long as the function that contains the
> trapping instruction doesn't really need to catch the exception (including
> running a cleanup in it and continuing with the exception), i.e. when the
> exception is thrown from the signal handler and caught in some caller of the
> function with the trapping instruction, I'd say all that needs to be done
> is the function with the trapping instruction be compiled with
> -fasynchronous-unwind-tables and the callers of it that are still not meant
> to catch it should be compiled with -funwind-tables (or
> -fasynchronous-unwind-tables) and only the function that should catch it or
> run cleanups should be compiled with -fexceptions (no need for
> -fnon-call-exceptions in that case, but of course not disallowed).

 Right, given what you have written and my observations above, and that 

[WIP][PATCH] RISC-V: Add `-mgprel' option for GP-relative addressing

[Maciej W. Rozycki via Gcc-patches]

Implement `-mgprel', forcing `-mexplicit-relocs' whenever the option is 
active due to the lack of GAS macro support for GP-relative addressing.

gcc/
* riscv/riscv-protos.h (riscv_symbol_type): Add SYMBOL_GPREL 
enumeration constant.
* config/riscv/riscv.c (riscv_classify_symbol)
(riscv_symbolic_constant_p, riscv_symbol_insns)
(riscv_split_symbol_type, riscv_split_symbol, riscv_output_move)
(riscv_print_operand_reloc, riscv_option_override): Handle 
GP-relative addressing.
* config/riscv/riscv.md (unspec): Add UNSPEC_GPREL enumeration 
constant.
* config/riscv/riscv.opt (mgprel): New option.
---
Hi,

 This is very early stage really, just implementing basic GP-relative
relocation support, in preparation for FDPIC support discussed here:



I planned adding support to GAS macros such as LA next so that we don't 
have to force explicit relocations with `-mgprel' for this option to work, 
but I won't be able to continue with this effort now as I am leaving 
Western Digital today, so I am posting this in case someone finds it 
useful or wishes to continue the effort.

 No regressions in `riscv64-linux-gnu' testing, RV32/ilp32d ABI with QEMU 
in the Linux user emulation mode across all GCC frontends and libraries, 
except for an odd ICE with one of the Fortran test cases and a couple 
timeouts with GNAT test cases, which I put all on the version difference 
between the test runs (10.0.1 20200426 vs 11.0.0 20200827).  

 Unfortunately I lost several hours, because 11.0.0 20200829 has regressed 
enough compared to 11.0.0 20200827 for testing not to progress well enough 
in 15 hours where it usually completes in ~10 hours.  So I had to restart 
with an older snapshot and wouldn't get reference results in time (I only 
had libgo results with 11.0.0 20200827).  I think my assumption as to the 
nature of the regressions is right though.

 A corresponding binutils change has also been posted.

  Maciej
---
 gcc/config/riscv/riscv-protos.h |1 +
 gcc/config/riscv/riscv.c|   32 +---
 gcc/config/riscv/riscv.md   |1 +
 gcc/config/riscv/riscv.opt  |4 
 4 files changed, 35 insertions(+), 3 deletions(-)

gcc-riscv-gprel.diff
Index: gcc/gcc/config/riscv/riscv-protos.h
===
--- gcc.orig/gcc/config/riscv/riscv-protos.h
+++ gcc/gcc/config/riscv/riscv-protos.h
@@ -28,6 +28,7 @@ enum riscv_symbol_type {
   SYMBOL_ABSOLUTE,
   SYMBOL_PCREL,
   SYMBOL_GOT_DISP,
+  SYMBOL_GPREL,
   SYMBOL_TLS,
   SYMBOL_TLS_LE,
   SYMBOL_TLS_IE,
Index: gcc/gcc/config/riscv/riscv.c
===
--- gcc.orig/gcc/config/riscv/riscv.c
+++ gcc/gcc/config/riscv/riscv.c
@@ -559,7 +559,13 @@ riscv_classify_symbol (const_rtx x)
   if (GET_CODE (x) == SYMBOL_REF && flag_pic && !riscv_symbol_binds_local_p 
(x))
 return SYMBOL_GOT_DISP;
 
-  return riscv_cmodel == CM_MEDLOW ? SYMBOL_ABSOLUTE : SYMBOL_PCREL;
+  if (riscv_cmodel == CM_MEDLOW)
+return SYMBOL_ABSOLUTE;
+
+  if (LABEL_REF_P (x) || (SYMBOL_REF_P (x) && SYMBOL_REF_FUNCTION_P (x)))
+return SYMBOL_PCREL;
+
+  return TARGET_GPREL ? SYMBOL_GPREL : SYMBOL_PCREL;
 }
 
 /* Classify the base of symbolic expression X.  */
@@ -604,6 +610,7 @@ riscv_symbolic_constant_p (rtx x, enum r
 case SYMBOL_ABSOLUTE:
 case SYMBOL_PCREL:
 case SYMBOL_TLS_LE:
+case SYMBOL_GPREL:
   /* GAS rejects offsets outside the range [-2^31, 2^31-1].  */
   return sext_hwi (INTVAL (offset), 32) == INTVAL (offset);
 
@@ -622,6 +629,7 @@ static int riscv_symbol_insns (enum risc
 case SYMBOL_ABSOLUTE: return 2; /* LUI + the reference.  */
 case SYMBOL_PCREL: return 2; /* AUIPC + the reference.  */
 case SYMBOL_TLS_LE: return 3; /* LUI + ADD TP + the reference.  */
+case SYMBOL_GPREL: return 3; /* LUI + ADD GP + the reference.  */
 case SYMBOL_GOT_DISP: return 3; /* AUIPC + LD GOT + the reference.  */
 default: gcc_unreachable ();
 }
@@ -735,7 +743,9 @@ riscv_split_symbol_type (enum riscv_symb
   if (!TARGET_EXPLICIT_RELOCS)
 return false;
 
-  return symbol_type == SYMBOL_ABSOLUTE || symbol_type == SYMBOL_PCREL;
+  return (symbol_type == SYMBOL_ABSOLUTE
+ || symbol_type == SYMBOL_PCREL
+ || symbol_type == SYMBOL_GPREL);
 }
 
 /* Return true if a LO_SUM can address a value of mode MODE when the
@@ -1241,6 +1251,17 @@ riscv_split_symbol (rtx temp, rtx addr,
}
break;
 
+  case SYMBOL_GPREL:
+   {
+ rtx high = gen_rtx_HIGH (Pmode, copy_rtx (addr));
+ rtx gp = gen_rtx_REG (Pmode, GP_REGNUM);
+ high = riscv_force_temporary (temp, high, in_splitter);
+ rtx reg = gen_rtx_PLUS (Pmode, high, gp);
+ reg = riscv_force_temporary (temp, reg, in_splitter);
+ *low_out = 

[PATCH] RISC-V/libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

[Maciej W. Rozycki via Gcc-patches]

Use `-fasynchronous-unwind-tables' rather than `-fexceptions 
-fnon-call-exceptions' in LIB2_DIVMOD_FUNCS compilation flags so as to 
provide unwind tables for the affected functions while not pulling the 
unwinder proper, which is not required here.

Beyond saving program space it fixes a RISC-V glibc build error due to 
unsatisfied `malloc' and `free' references from the unwinder causing 
link errors with `ld.so' where libgcc has been built at -O0.

libgcc/
* config/riscv/t-elf (LIB2_DIVMOD_EXCEPTION_FLAGS): New 
variable.
---
Hi,

 As Mon, Aug 31st (a bank holiday in England) will be my last day at 
Western Digital and I won't be able to submit patches on behalf of the 
company afterwards here is a replacement change for RISC-V only in case 
the generic one discussed here:

Re: [PATCH v3] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

[Maciej W. Rozycki via Gcc-patches]

On Wed, 26 Aug 2020, Jakub Jelinek wrote:

> On Wed, Aug 26, 2020 at 01:08:00PM +0200, Richard Biener via Gcc-patches 
> wrote:
> > You only need -fexceptions for that, then you can throw; from a signal 
> > handler
> > for example.  If you want to be able to catch the exception somewhere up
> > the call chain all intermediate code needs to be compiled so that unwinding
> > from asynchronous events is possible - -fasynchronous-unwind-tables.
> > 
> > So -fasynchronous-unwind-tables is about unwinding.  -f[non-call]-exceptions
> > is about throw/catch.  Clearly libgcc does neither throw nor catch but with
> > async events we might need to unwind from inside it.

 Thank you for the clarification.

 As far as `-fexceptions' and `-fasynchronous-unwind-tables' are concerned 
it aligns with my understanding, i.e. in this specific scenario we need 
`-fasynchronous-unwind-tables' for libcalls (all of them) so that an 
exception thrown from a signal handler can unwind through our code, and it 
is the signal handler that needs `-fexceptions' to be able to throw an 
exception, and then another piece of code upwards the call chain also 
needs `-fexceptions' to catch it.

 I'm still unclear as to `-fnon-call-exceptions' as what you write,
combined with documentation for said option seems to imply that it causes
a signal handler to be installed for SIGBUS/SIGSEGV/SIGFPE, however I seem
unable to locate such code except for the Ada frontend.

 The option does cause certain instruction classes, as per `may_trap_p_1', 
to be annotated for exception handling and prevent them from being 
optimised away, but it is not clear to me what the difference is between 
the case where a piece of code has been built with `-fnon-call-exceptions' 
and `-fasynchronous-unwind-tables', and an instruction within (that hasn't 
been optimised away) traps into an exception handler that throws an 
exception.  I.e. what the extra annotation is used for (obviously being 
optimised away or not is a significat difference).

 IIUC in both cases the exact causing instruction can be identified, 
especially as I note that internally `-fnon-call-exceptions' implies 
`-fasynchronous-unwind-tables':

  if (flag_non_call_exceptions)
flag_asynchronous_unwind_tables = 1;

(which I suspect might be worth documenting).  

> In C code -f{,non-call-}exceptions is also about whether cleanup attribute
> will work or not.  But I think in libgcc we don't really use it, especially
> not in the division/modulo code, not even indirectly from libc headers like
> pthread_cleanup_* macros.

 Thank you for your observation, I didn't know of the cleanup attribute 
before.

 So what shall we do about my patch?

  Maciej

Re: [PATCH v3] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

[Maciej W. Rozycki via Gcc-patches]

Hi Kito,

> I just found the mail thread about div mod with -fnon-call-exceptions,
> I think keeping the default LIB2_DIVMOD_EXCEPTION_FLAGS unchanged
> should be the best way to go.
> 
> Non-call exceptions and libcalls
> https://gcc.gnu.org/legacy-ml/gcc/2001-06/msg01108.html
> 
> Non-call exceptions and libcalls Part 2
> https://gcc.gnu.org/legacy-ml/gcc/2001-07/msg00402.html

 Thank you for your input.  I believe I had a look at these commits before 
I posted my original proposal.  Please note however that they both predate 
the addition of `-fasynchronous-unwind-tables', so clearly the option 
could not have been considered at the time the changes were accepted into 
GCC.

 Please note that, as observed by Andreas and Richard here: 
 in no case we 
want to have full exception handling here, so we clearly need no 
`-fexceptions'; this libcall code won't itself ever call `throw'.

 Now it might be a bit unclear from documentation as to whether we want 
`-fnon-call-exceptions' or `-fasynchronous-unwind-tables', as it says that 
the former option makes GCC:

"Generate code that allows trapping instructions to throw
 exceptions.  Note that this requires platform-specific runtime
 support that does not exist everywhere.  Moreover, it only allows
 _trapping_ instructions to throw exceptions, i.e. memory references
 or floating-point instructions.  It does not allow exceptions to be
 thrown from arbitrary signal handlers such as 'SIGALRM'."

Note the observation that arbitrary signal handlers (invoked at more inner 
a frame level, and necessarily built with `-fexceptions') are still not 
allowed to throw exceptions.  For that, as far as I understand it, you 
actually need `-fasynchronous-unwind-tables', which makes GCC:

"Generate unwind table in DWARF format, if supported by target
 machine.  The table is exact at each instruction boundary, so it
 can be used for stack unwinding from asynchronous events (such as
 debugger or garbage collector)."

and therefore allows arbitrary signal handlers to throw exceptions, 
effectively making the option a superset of `-fexceptions'.  As libcall 
code can generally be implicitly invoked everywhere, we want people not to 
be restrained by it and let a exception thrown by e.g. a user-supplied 
SIGALRM handler propagate through the relevant libcall's stack frame, 
rather than just those exceptions the libcall itself might indirectly 
cause.

 Maybe I am missing something here, especially as `-fexceptions' mentions 
code generation, while `-fasynchronous-unwind-tables' only refers to 
unwind table generation, but then what would be the option to allow 
exceptions to be thrown from arbitrary signal handlers rather than those 
for memory references or floating-point instructions (where by a special 
provision integer division falls as well)?

 My understanding has been it is `-fasynchronous-unwind-tables', but I'll 
be gladly straightened out otherwise.  If I am indeed right, then perhaps 
the documentation could be clarified and expanded a bit.

 Barring evidence to the contrary I maintain the change I have proposed is 
correct, and not only removes the RISC-V `ld.so' build issue, but it fixes 
the handling of asynchronous events arriving in the middle of the relevant 
libcalls for all platforms as well.

 Please let me know if you have any further questions, comments or 
concerns.

  Maciej

Re: [PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

[Maciej W. Rozycki via Gcc-patches]

On Wed, 19 Aug 2020, Richard Earnshaw wrote:

> >  That said I'm of course happy to keep the ARM overrides if you consider 
> > them still necessary in the context of the generic change made.  Let me 
> > know what you prefer, and if required, I will submit v3 with the ARM 
> > pieces removed.
[...]
> So you've made a change to the Arm target, but not tested it.  And
> what's more didn't even bother to mention that fact.

 Well, I explicitly named the targets that have been tested, and it was 
clear ARM wasn't among them.

 I admit I forgot to cc ARM maintainers with v1, which I apologise for, 
and which mistake Richard B. has kindly corrected for me.  Nobody's 
perfect.

> If you make changes, you need to test them, particularly when there are
> likely to be target-specific implications.  If you can't test yourself
> then you need to make that very clear in your submission.
> 
> There are Arm targets in the testfarm, so it's not really an excuse for
> not doing testing.

 I think it's the port maintainer's role to verify their pet target; 
that's what I have been doing on the binutils/GDB side when I was an 
active port maintainer.  I did not require people to bend backwards and 
appreciated their effort to make the toolchain better.

 It takes a maintainer maybe a couple of seconds to pull a change and push 
it through their readily available automated verification system they 
surely have, while it may be a days' effort for someone who has to figure 
out all the details, choose all the configuration options required, avoid 
pitfalls, keep rebuilding until all is sound, etc.  And then repeat that 
for every new target possibly affected.

 As the change was intended to address an issue observed with RISC-V 
targets the ARM pieces are not needed.  I've sent v3 now, which keeps 
ARM-specific parts intact so that you won't have to be involved or 
otherwise spend your time on it.  You're free to pick the parts removed of 
course and do whatever you want with them according to the GNU GPL and 
keeping in mind my copyright assignment with FSF.

 NB it is actually the case that when the original ARM fix/workaround was 
submitted that has introduced LIB2_DIVMOD_EXCEPTION_FLAGS, the failure, 
clearly not ARM-specific, should have been properly analysed and a general 
solution like mine proposed so as to fix all targets that use these 
libcalls, rather than taking care of your own business only, and making a 
local fix for ARM and letting other target developers rediscover the same 
issue.

 I regret now that I bothered touching the ARM part; I'll follow the 
example from the paragraph above and in the future I will only take care 
of my business, avoid going the extra mile in the future where it could 
only cause me trouble and give no benefit.

 Thank you for your review anyway, it has taught me something.

  Maciej

[PATCH v3] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

[Maciej W. Rozycki via Gcc-patches]

Complement commit b932f770f70d ("x86_64 frame unwind info"), SVN r46374, 
, and replace 
`-fexceptions -fnon-call-exceptions' with `-fasynchronous-unwind-tables' 
in LIB2_DIVMOD_FUNCS compilation flags so as to provide unwind tables 
for the affected functions while not pulling the unwinder proper, which 
is not required here.

Beyond saving program space it fixes a RISC-V glibc build error due to 
unsatisfied `malloc' and `free' references from the unwinder causing 
link errors with `ld.so' where libgcc has been built at -O0.

gcc/
* testsuite/gcc.target/arm/div64-unwinding.c: Rename to...
* testsuite/gcc.dg/div64-unwinding.c: ... this.

libgcc/
* Makefile.in [!LIB2_DIVMOD_EXCEPTION_FLAGS]
(LIB2_DIVMOD_EXCEPTION_FLAGS): Replace `-fexceptions
-fnon-call-exceptions' with `-fasynchronous-unwind-tables'.
---
Hi,

 No change from v2 except for the removal of the ARM parts; hence no need 
to retest.  OK to apply?

  Maciej

Changes from v2:

- Removal of the ARM overrides removed.

Changes from v1:

- ChangeLog entries added.
---
 gcc/testsuite/gcc.dg/div64-unwinding.c |   25 +
 gcc/testsuite/gcc.target/arm/div64-unwinding.c |   25 -
 libgcc/Makefile.in |2 +-
 3 files changed, 26 insertions(+), 26 deletions(-)

gcc-libgcc-divmod-asynchronous-unwind-tables.diff
Index: gcc/gcc/testsuite/gcc.dg/div64-unwinding.c
===
--- /dev/null
+++ gcc/gcc/testsuite/gcc.dg/div64-unwinding.c
@@ -0,0 +1,25 @@
+/* Performing a 64-bit division should not pull in the unwinder.  */
+
+/* { dg-do run { target { { ! *-*-linux* } && { ! *-*-uclinux* } } } } */
+/* { dg-skip-if "load causes weak symbol resolution" { vxworks_kernel } } */
+/* { dg-options "-O0" } */
+
+#include 
+
+long long
+foo (long long c, long long d)
+{
+  return c/d;
+}
+
+long long x = 0;
+long long y = 1;
+
+extern int (*_Unwind_RaiseException) (void *) __attribute__((weak));
+
+int main(void)
+{
+  if (&_Unwind_RaiseException != NULL)
+abort ();;
+  return foo (x, y);
+}
Index: gcc/gcc/testsuite/gcc.target/arm/div64-unwinding.c
===
--- gcc.orig/gcc/testsuite/gcc.target/arm/div64-unwinding.c
+++ /dev/null
@@ -1,25 +0,0 @@
-/* Performing a 64-bit division should not pull in the unwinder.  */
-
-/* { dg-do run { target { { ! *-*-linux* } && { ! *-*-uclinux* } } } } */
-/* { dg-skip-if "load causes weak symbol resolution" { vxworks_kernel } } */
-/* { dg-options "-O0" } */
-
-#include 
-
-long long
-foo (long long c, long long d)
-{
-  return c/d;
-}
-
-long long x = 0;
-long long y = 1;
-
-extern int (*_Unwind_RaiseException) (void *) __attribute__((weak));
-
-int main(void)
-{
-  if (&_Unwind_RaiseException != NULL)
-abort ();;
-  return foo (x, y);
-}
Index: gcc/libgcc/Makefile.in
===
--- gcc.orig/libgcc/Makefile.in
+++ gcc/libgcc/Makefile.in
@@ -533,7 +533,7 @@ endif
 ifeq ($(LIB2_DIVMOD_EXCEPTION_FLAGS),)
 # Provide default flags for compiling divmod functions, if they haven't been
 # set already by a target-specific Makefile fragment.
-LIB2_DIVMOD_EXCEPTION_FLAGS := -fexceptions -fnon-call-exceptions
+LIB2_DIVMOD_EXCEPTION_FLAGS := -fasynchronous-unwind-tables
 endif
 
 # Build LIB2_DIVMOD_FUNCS.

Re: [PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

[Maciej W. Rozycki via Gcc-patches]

On Tue, 18 Aug 2020, Richard Earnshaw wrote:

> > Complement commit b932f770f70d ("x86_64 frame unwind info"), SVN r46374, 
> > , and replace 
> > `-fexceptions -fnon-call-exceptions' with `-fasynchronous-unwind-tables' 
> > in LIB2_DIVMOD_FUNCS compilation flags so as to provide unwind tables 
> > for the affected functions while not pulling the unwinder proper, which 
> > is not required here.
> > 
> > Remove the ARM overrides accordingly, retaining the hook infrastructure 
> > however, and make the ARM test case a generic one.
[...]
> From a quick glance, I'm not convinced this is right for Arm, since the
> Arm unwind format does not support anything other than call-based
> exceptions.  How did you test it?

 Surely no ARM target has been verified as I have no access to such 
configurations; I will appreciate if either you or someone else suitably 
equipped does that for the sake of cross-target code unification (= fewer 
special cases to maintain).  This has been regression-tested with RISC-V 
and x86-64 targets, as noted in the two submissions.

 Are you trying to say that `-fasynchronous-unwind-tables' has no effect 
on ARM?  This code does not throw exceptions, so any unwinding would only 
happen in contexts such as in GDB poking at this code or from a signal 
handler such as SIGALRM or SIGFPE (if ARM does ever send the latter signal 
for integer division operations; I don't know offhand).  The GCC option is 
generic and is supposed to fully support such use cases regardless of the 
target chosen, so shouldn't the ARM backend be wired appropriately so as 
to use whatever unwind format is required to handle the use cases, 
regardless of whether the minimal format usually used is supported by the 
psABI or not?

 There is indeed a documented provision for not supporting the option: 
"Generate unwind table in DWARF format, if supported by target machine." 
however I infer that refers to the support of the DWARF format as a whole 
rather than specifically minimal unwind tables, that is if the DWARF 
format is supported (as opposed to say stabs or mdebug only), then the 
option shall generate an unwind table in that format.

 That said I'm of course happy to keep the ARM overrides if you consider 
them still necessary in the context of the generic change made.  Let me 
know what you prefer, and if required, I will submit v3 with the ARM 
pieces removed.

  Maciej

[PING][PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

[Maciej W. Rozycki via Gcc-patches]

On Thu, 6 Aug 2020, Maciej W. Rozycki wrote:

> Complement commit b932f770f70d ("x86_64 frame unwind info"), SVN r46374, 
> , and replace 
> `-fexceptions -fnon-call-exceptions' with `-fasynchronous-unwind-tables' 
> in LIB2_DIVMOD_FUNCS compilation flags so as to provide unwind tables 
> for the affected functions while not pulling the unwinder proper, which 
> is not required here.
> 
> Remove the ARM overrides accordingly, retaining the hook infrastructure 
> however, and make the ARM test case a generic one.
> 
> Beyond saving program space it fixes a RISC-V glibc build error due to 
> unsatisfied `malloc' and `free' references from the unwinder causing 
> link errors with `ld.so' where libgcc has been built at -O0.

 Ping for: 



  Maciej

[PATCH v2] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

[Maciej W. Rozycki via Gcc-patches]

Complement commit b932f770f70d ("x86_64 frame unwind info"), SVN r46374, 
, and replace 
`-fexceptions -fnon-call-exceptions' with `-fasynchronous-unwind-tables' 
in LIB2_DIVMOD_FUNCS compilation flags so as to provide unwind tables 
for the affected functions while not pulling the unwinder proper, which 
is not required here.

Remove the ARM overrides accordingly, retaining the hook infrastructure 
however, and make the ARM test case a generic one.

Beyond saving program space it fixes a RISC-V glibc build error due to 
unsatisfied `malloc' and `free' references from the unwinder causing 
link errors with `ld.so' where libgcc has been built at -O0.

gcc/
* testsuite/gcc.target/arm/div64-unwinding.c: Rename to...
* testsuite/gcc.dg/div64-unwinding.c: ... this.

libgcc/
* Makefile.in [!LIB2_DIVMOD_EXCEPTION_FLAGS]
(LIB2_DIVMOD_EXCEPTION_FLAGS): Replace `-fexceptions
-fnon-call-exceptions' with `-fasynchronous-unwind-tables'.
* config/arm/t-bpabi (LIB2_DIVMOD_EXCEPTION_FLAGS): Remove
variable.
* config/arm/t-netbsd-eabi (LIB2_DIVMOD_EXCEPTION_FLAGS):
Likewise.
---
Hi,

 I realised we still use handwritten ChangeLog entries (I got confused 
with now different policies each of the various pieces of the GNU 
toolchain has), so here's v2 of the change with a fix for that problem 
being the only update.

 Also I have since run verification with the `riscv64-linux-gnu' target 
and the ilp32d multilib as more representative for the change being made.
No problems were observed, although the now enabled test case scored:

UNSUPPORTED: gcc.dg/div64-unwinding.c

of course with the target failing the `! *-*-linux*' condition.

 Given that for the `riscv64-linux-gnu' target and the ilp32d multilib 
glibc currently fails to link against libgcc.a built at -O0 I first ran 
reference testing with target libraries built at -O2, but comparing that 
to change-under-test -O2 results revealed another issue with GCC target 
libraries built at -O0 causing link failures across testsuites, namely 
libgcov.a referring atomic primitives where libatomic.a has not been 
linked in.  I haven't figured out yet if the issue is in libgcov, the 
testsuite or the specs.  Examples of failures:

.../bin/riscv64-linux-gnu-ld: 
.../gcc/testsuite/g++/../../lib32/ilp32d/libgcov.a(_gcov_indirect_call_profiler_v4.o):
 in function `__gcov_topn_values_profiler_body': 
.../libgcc/libgcov-profiler.c:116: undefined reference to `__atomic_fetch_add_8'
.../bin/riscv64-linux-gnu-ld: .../libgcc/libgcov-profiler.c:129: undefined 
reference to `__atomic_fetch_add_8'
.../bin/riscv64-linux-gnu-ld: .../libgcc/libgcov-profiler.c:150: undefined 
reference to `__atomic_fetch_sub_8'
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: g++.dg/other/pr55650.C  -std=gnu++98 (test for excess errors)

There were some odd Fortran failures too, with test cases failing to link, 
making the results difficult to interpret.  Therefore I decided to arrange 
for a special build with first stage GCC built with its target libraries 
at -O2, so that first stage glibc builds, and then second stage GCC built 
with its target libraries at -O0 and second stage glibc omitted.  That 
removed the extra Fortran failures regardless of whether this change has 
been applied or not, but we may consider looking overall into why a full 
`riscv64-linux-gnu' build at -O0 has regressions against -O2 at least in 
the ilp32d multilib.

 Meanwhile, OK to apply?

  Maciej

Changes from v1:

- ChangeLog entries added.
---
 gcc/testsuite/gcc.dg/div64-unwinding.c |   25 +
 gcc/testsuite/gcc.target/arm/div64-unwinding.c |   25 -
 libgcc/Makefile.in |2 +-
 libgcc/config/arm/t-bpabi  |5 -
 libgcc/config/arm/t-netbsd-eabi|5 -
 5 files changed, 26 insertions(+), 36 deletions(-)

gcc-libgcc-divmod-asynchronous-unwind-tables.diff
Index: gcc/gcc/testsuite/gcc.dg/div64-unwinding.c
===
--- /dev/null
+++ gcc/gcc/testsuite/gcc.dg/div64-unwinding.c
@@ -0,0 +1,25 @@
+/* Performing a 64-bit division should not pull in the unwinder.  */
+
+/* { dg-do run { target { { ! *-*-linux* } && { ! *-*-uclinux* } } } } */
+/* { dg-skip-if "load causes weak symbol resolution" { vxworks_kernel } } */
+/* { dg-options "-O0" } */
+
+#include 
+
+long long
+foo (long long c, long long d)
+{
+  return c/d;
+}
+
+long long x = 0;
+long long y = 1;
+
+extern int (*_Unwind_RaiseException) (void *) __attribute__((weak));
+
+int main(void)
+{
+  if (&_Unwind_RaiseException != NULL)
+abort ();;
+  return foo (x, y);
+}
Index: gcc/gcc/testsuite/gcc.target/arm/div64-unwinding.c
===
--- 

Re: [PATCH] RISC-V/libgcc: Reduce the size of RV64 millicode by 6 bytes

[Maciej W. Rozycki via Gcc-patches]

On Thu, 30 Jul 2020, Andrew Waterman wrote:

> IIRC, I didn't use this approach originally because I wanted to avoid
> the additional dynamic instruction.  But I agree that code size is the
> more important metric for users of this feature.  LGTM.

 Applied now, thanks for your review.

  Maciej

[PATCH] RISC-V/libgcc: Reduce the size of RV64 millicode by 6 bytes

[Maciej W. Rozycki via Gcc-patches]

Rewrite code sequences throughout the 64-bit RISC-V `__riscv_save_*' 
routines replacing `li t1, -48', `li t1, -64', and `li t1, -80', 
instructions, which do not have a compressed encoding, respectively with 
`li t1, 3', `li t1, 4', and `li t1, 4', which do, and then adjusting the 
remaining code accordingly observing that `sub sp, sp, t1' takes the 
same amount of space as an `slli t1, t1, 4'/`add sp, sp, t1' instruction 
pair does, again due to the use of compressed encodings, saving 6 bytes 
total.

This change does increase code size by 4 bytes for RISC-V processors 
lacking the compressed instruction set, however their users couldn't 
care about the code size or they would have chosen an implementation 
that does have the compressed instructions, wouldn't they?

libgcc/
* config/riscv/save-restore.S [__riscv_xlen == 64] 
(__riscv_save_10, __riscv_save_8, __riscv_save_6, __riscv_save_4)
(__riscv_save_2): Replace negative immediates used for the final 
stack pointer adjustment with positive ones, right-shifted by 4.
---
Hi,

 This is hopefully functionally obviously correct.  There were also no 
regressions in `riscv64-linux-gnu' lp64d multilib testing across all our 
testsuites (with QEMU run in the Linux user emulation mode) where target 
libraries, including glibc, have been built with `-Os -msave-restore', 
that is with millicode enabled.

 OK to apply?

  Maciej
---
 libgcc/config/riscv/save-restore.S |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

gcc-riscv-libgcc-save-sll.diff
Index: gcc/libgcc/config/riscv/save-restore.S
===
--- gcc.orig/libgcc/config/riscv/save-restore.S
+++ gcc/libgcc/config/riscv/save-restore.S
@@ -45,7 +45,7 @@ FUNC_BEGIN (__riscv_save_10)
   .cfi_restore 27
   addi sp, sp, -112
   .cfi_def_cfa_offset 112
-  li t1, -16
+  li t1, 1
 .Ls10:
   sd s10, 16(sp)
   .cfi_offset 26, -96
@@ -60,7 +60,7 @@ FUNC_BEGIN (__riscv_save_8)
   .cfi_restore 27
   addi sp, sp, -112
   .cfi_def_cfa_offset 112
-  li t1, -32
+  li t1, 2
 .Ls8:
   sd s8, 32(sp)
   .cfi_offset 24, -80
@@ -77,7 +77,7 @@ FUNC_BEGIN (__riscv_save_6)
   .cfi_restore 27
   addi sp, sp, -112
   .cfi_def_cfa_offset 112
-  li t1, -48
+  li t1, 3
 .Ls6:
   sd s6, 48(sp)
   .cfi_offset 22, -64
@@ -99,7 +99,7 @@ FUNC_BEGIN (__riscv_save_4)
   .cfi_restore 27
   addi sp, sp, -112
   .cfi_def_cfa_offset 112
-  li t1, -64
+  li t1, 4
 .Ls4:
   sd s4, 64(sp)
   .cfi_offset 20, -48
@@ -123,7 +123,7 @@ FUNC_BEGIN (__riscv_save_2)
   .cfi_restore 27
   addi sp, sp, -112
   .cfi_def_cfa_offset 112
-  li t1, -80
+  li t1, 5
 .Ls2:
   sd s2, 80(sp)
   .cfi_offset 18, -32
@@ -133,9 +133,10 @@ FUNC_BEGIN (__riscv_save_2)
   .cfi_offset 8, -16
   sd ra, 104(sp)
   .cfi_offset 1, -8
+  slli t1, t1, 4
   # CFA info is not correct in next 2 instruction since t1's
   # value is depend on how may register really save.
-  sub sp, sp, t1
+  add sp, sp, t1
   jr t0
   .cfi_endproc
 FUNC_END (__riscv_save_12)

[PATCH] libgcc: Use `-fasynchronous-unwind-tables' for LIB2_DIVMOD_FUNCS

[Maciej W. Rozycki via Gcc-patches]

Complement commit b932f770f70d ("x86_64 frame unwind info"), SVN r46374, 
, and replace 
`-fexceptions -fnon-call-exceptions' with `-fasynchronous-unwind-tables' 
in LIB2_DIVMOD_FUNCS compilation flags so as to provide unwind tables 
for the affected functions while not pulling the unwinder proper, which 
is not required here.

Remove the ARM overrides accordingly, retaining the hook infrastructure 
however, and make the ARM test case a generic one.

Beyond saving program space it fixes a RISC-V glibc build error due to 
unsatisfied `malloc' and `free' references from the unwinder causing 
link errors with `ld.so' where libgcc has been built at -O0.
---
Hi,

 As discussed: .  

 This has been regression-tested with all the GCC compiler testsuites with 
the `x86_64-linux' native configuration, which in particular means the 
moved ARM test case scored the UNSUPPORTED result.  I have no access to a 
non-Linux configuration right now, so I cannot verify this test case, but 
in principle I expect it to work across the relevant targets (and the 
irrelevant ones can be excluded as they are discovered).

 OK to apply then?  It may make sense to backport this fix too to the 
active release branches; please let me know if to do so.

 NB the original commit referred appears to contain more than just the 
corresponding mailing list posting; it looks like several patches were 
folded together before comitting, so this is as good as you can get.

  Maciej
---
 gcc/testsuite/gcc.dg/div64-unwinding.c |   25 +
 gcc/testsuite/gcc.target/arm/div64-unwinding.c |   25 -
 libgcc/Makefile.in |2 +-
 libgcc/config/arm/t-bpabi  |5 -
 libgcc/config/arm/t-netbsd-eabi|5 -
 5 files changed, 26 insertions(+), 36 deletions(-)

gcc-libgcc-divmod-asynchronous-unwind-tables.diff
Index: gcc/gcc/testsuite/gcc.dg/div64-unwinding.c
===
--- /dev/null
+++ gcc/gcc/testsuite/gcc.dg/div64-unwinding.c
@@ -0,0 +1,25 @@
+/* Performing a 64-bit division should not pull in the unwinder.  */
+
+/* { dg-do run { target { { ! *-*-linux* } && { ! *-*-uclinux* } } } } */
+/* { dg-skip-if "load causes weak symbol resolution" { vxworks_kernel } } */
+/* { dg-options "-O0" } */
+
+#include 
+
+long long
+foo (long long c, long long d)
+{
+  return c/d;
+}
+
+long long x = 0;
+long long y = 1;
+
+extern int (*_Unwind_RaiseException) (void *) __attribute__((weak));
+
+int main(void)
+{
+  if (&_Unwind_RaiseException != NULL)
+abort ();;
+  return foo (x, y);
+}
Index: gcc/gcc/testsuite/gcc.target/arm/div64-unwinding.c
===
--- gcc.orig/gcc/testsuite/gcc.target/arm/div64-unwinding.c
+++ /dev/null
@@ -1,25 +0,0 @@
-/* Performing a 64-bit division should not pull in the unwinder.  */
-
-/* { dg-do run { target { { ! *-*-linux* } && { ! *-*-uclinux* } } } } */
-/* { dg-skip-if "load causes weak symbol resolution" { vxworks_kernel } } */
-/* { dg-options "-O0" } */
-
-#include 
-
-long long
-foo (long long c, long long d)
-{
-  return c/d;
-}
-
-long long x = 0;
-long long y = 1;
-
-extern int (*_Unwind_RaiseException) (void *) __attribute__((weak));
-
-int main(void)
-{
-  if (&_Unwind_RaiseException != NULL)
-abort ();;
-  return foo (x, y);
-}
Index: gcc/libgcc/Makefile.in
===
--- gcc.orig/libgcc/Makefile.in
+++ gcc/libgcc/Makefile.in
@@ -533,7 +533,7 @@ endif
 ifeq ($(LIB2_DIVMOD_EXCEPTION_FLAGS),)
 # Provide default flags for compiling divmod functions, if they haven't been
 # set already by a target-specific Makefile fragment.
-LIB2_DIVMOD_EXCEPTION_FLAGS := -fexceptions -fnon-call-exceptions
+LIB2_DIVMOD_EXCEPTION_FLAGS := -fasynchronous-unwind-tables
 endif
 
 # Build LIB2_DIVMOD_FUNCS.
Index: gcc/libgcc/config/arm/t-bpabi
===
--- gcc.orig/libgcc/config/arm/t-bpabi
+++ gcc/libgcc/config/arm/t-bpabi
@@ -13,8 +13,3 @@ LIB2ADDEH = $(srcdir)/config/arm/unwind-
 
 # Add the BPABI names.
 SHLIB_MAPFILES += $(srcdir)/config/arm/libgcc-bpabi.ver
-
-# On ARM, specifying -fnon-call-exceptions will needlessly pull in
-# the unwinder in simple programs which use 64-bit division.  Omitting
-# the option is safe.
-LIB2_DIVMOD_EXCEPTION_FLAGS := -fexceptions
Index: gcc/libgcc/config/arm/t-netbsd-eabi
===
--- gcc.orig/libgcc/config/arm/t-netbsd-eabi
+++ gcc/libgcc/config/arm/t-netbsd-eabi
@@ -11,8 +11,3 @@ LIB2ADDEH =
 
 # Add the BPABI names.
 SHLIB_MAPFILES += $(srcdir)/config/arm/libgcc-bpabi.ver
-
-# On ARM, specifying -fnon-call-exceptions will needlessly pull in
-# the unwinder in simple programs 

Re: [PATCH v5 GCC] libffi/test: Fix compilation for build sysroot

[Maciej W. Rozycki via Gcc-patches]

On Wed, 22 Apr 2020, Jeff Law wrote:

> > libffi/
> > * Makefile.am (DISTCLEANFILES): New variable.
> > * configure.ac: Produce `local.exp'.
> > * Makefile.in: Regenerate.
> > * configure: Regenerate.
> > * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
> > variable.
> > * testsuite/Makefile.in: Regenerate.
> OK
> jeff

 Committed now then, according to schedule, thanks for your review.  We 
may revisit the backport of improvements I previously proposed when/if the 
upstream libffi maintainer decides to accept them.

  Maciej

[PATCH v5 GCC] libffi/test: Fix compilation for build sysroot

[Maciej W. Rozycki via Gcc-patches]

Fix a problem with the libffi testsuite using a method to determine the 
compiler to use resulting in the tool being different from one the 
library has been built with, and causing a catastrophic failure from the 
inability to actually choose any compiler at all in a cross-compilation 
configuration.

Address this problem by providing a DejaGNU configuration file defining 
the compiler to use, via the CC_FOR_TARGET TCL variable, set from $CC by 
autoconf, which will have all the required options set for the target 
compiler to build executables in the environment configured, removing 
failures like:

FAIL: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 (test for excess errors)
Excess errors:
default_target_compile: No compiler to compile with
UNRESOLVED: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 compilation 
failed to produce executable

and bringing overall test results for the `riscv64-linux-gnu' target 
(here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user 
emulation mode as the target board) from:

=== libffi Summary ===

# of unexpected failures708
# of unresolved testcases   708
# of unsupported tests  30

to:

=== libffi Summary ===

# of expected passes1934
# of unsupported tests  28

This is a combined backport of the relevant parts of upstream libffi 
changes as follows:

- commit 8308984e479e ("[PATCH] Make sure we're running dejagnu tests 
  with the right compiler."),

- commit 2d9b3939751b ("[PATCH] Fix for closures with sunpro compiler"),

- commit 0c3824702d3d ("[PATCH] Always set CC_FOR_TARGET for dejagnu, to
  make the testsuite respect $CC"),

- commit 7d698125b1f0 ("[PATCH] Use the proper C++ compiler to run C++
  tests"),

- commit 6b6df1a7bb37 ("[PATCH] Adds `local.exp` to CLEANFILES"),

- commit 6cf0dea78a5a ("[PATCH] Change CLEANFILES to DISTCLEANFILES")

libffi/
* Makefile.am (DISTCLEANFILES): New variable.
* configure.ac: Produce `local.exp'.
* Makefile.in: Regenerate.
* configure: Regenerate.
* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
variable.
* testsuite/Makefile.in: Regenerate.
---
Hi,

 As you may recall I have proposed a clean solution for the problem 
discussed here, which I posted for inclusion with upstream libffi, with an 
intent to have it backported to GCC as soon as it has been accepted by the 
maintainer, as a part of patch series that have been archived here: 
.

 I have pinged the series last week:
, 
and then again just now: 
.

 I think with the GCC 10 release about to be rolled out we need a 
contingency plan, so I propose that, unless my proposed libffi changes 
have been accepted upstream real soon now, such as by the end of this 
coming Friday AoE, we include this change instead.

 Therefore, OK to apply once Friday AoE has passed and the upstream libffi 
changes have gone nowhere?

  Maciej

[Change log corrected to include history before v4.]

Changes from v4:

- Replace with a backport of the partially complete solution already 
  present upstream.

Changes from v3:

- Replace with a backport of a change submitted upstream.

Changes from v2:

- Revert to v1.

- Rename testsuite/libffi-test-support.exp.in to
  testsuite/libffi-site-extra.exp.in.

Changes from v1:

- Remove testsuite/libffi-test-support.exp.in and the associated changes.

- Pass $(CC) via `--tool_exec' in $(AM_RUNTESTFLAGS).
---
 libffi/Makefile.am   |3 +++
 libffi/Makefile.in   |4 
 libffi/configure |5 +
 libffi/configure.ac  |5 +
 libffi/testsuite/Makefile.am |2 ++
 libffi/testsuite/Makefile.in |1 +
 6 files changed, 20 insertions(+)

gcc-test-libffi-cc-for-target.diff
Index: gcc/libffi/Makefile.am
===
--- gcc.orig/libffi/Makefile.am
+++ gcc/libffi/Makefile.am
@@ -15,6 +15,9 @@ EXTRA_DIST = LICENSE ChangeLog.v1 Change
libffi.xcodeproj/project.pbxproj\
libtool-ldflags
 
+# local.exp is generated by configure
+DISTCLEANFILES = local.exp
+
 # Automake Documentation:
 # If your package has Texinfo files in many directories, you can use the
 # variable TEXINFO_TEX to tell Automake where to find the canonical
Index: gcc/libffi/Makefile.in
===
--- gcc.orig/libffi/Makefile.in
+++ gcc/libffi/Makefile.in
@@ -454,6 +454,9 @@ EXTRA_DIST = LICENSE ChangeLog.v1 Change
libtool-ldflags
 
 
+# local.exp is generated by configure
+DISTCLEANFILES = local.exp
+
 # Automake Documentation:
 # If your package has Texinfo files in many directories, you can use the
 # variable TEXINFO_TEX 

Re: [PATCH] Do not use HAVE_DOS_BASED_FILE_SYSTEM for Cygwin.

[Maciej W. Rozycki via Gcc-patches]

On Thu, 16 Apr 2020, Martin Li?ka wrote:

> The patch is fix for Cygwin where we should not define 
> HAVE_DOS_BASED_FILE_SYSTEM
> and use back slashes as a path component separator.
[...]
> diff --git a/ltmain.sh b/ltmain.sh
> index 79f9ba89af5..8ad183010f0 100644
> --- a/ltmain.sh
> +++ b/ltmain.sh
> @@ -3425,7 +3425,7 @@ int setenv (const char *, const char *, int);
>  # define PATH_SEPARATOR ':'
>  #endif
>  
> -#if defined (_WIN32) || defined (__MSDOS__) || defined (__DJGPP__) || \
> +#if (defined (_WIN32) && ! defined(__CYGWIN__)) || defined (__MSDOS__) || 
> defined (__DJGPP__) || \
>defined (__OS2__)
>  # define HAVE_DOS_BASED_FILE_SYSTEM
>  # define FOPEN_WB "wb"

 This part needs to go upstream so as to let us avoid local clutter.  Also 
this does not fit in 80 columns and has to be reformatted.

  Maciej

Re: [PING][PATCH][wwwdocs] GCC 10: Document RISC-V target's requirement for binutils 2.30

[Maciej W. Rozycki via Gcc-patches]

On Thu, 9 Apr 2020, Jeff Law wrote:

> > > Match GCC commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather 
> > > than fmv.x.s/fmv.s.x") and commit 879bc686a0aa ("doc: RISC-V: Update 
> > > binutils requirement to 2.30").
> > 
> >  Ping for:
> > 
> > 
> OK.  Do we need any configure magic to detect what assembler version is being
> used and warn/error if it's too old?

 I discussed this with Jim (cc-ed) who thinks there is no need for that; 
cf. .

 Patch now applied, thanks for your review.

  Maciej

[PING][PATCH][wwwdocs] GCC 10: Document RISC-V target's requirement for binutils 2.30

[Maciej W. Rozycki via Gcc-patches]

On Thu, 2 Apr 2020, Maciej W. Rozycki wrote:

> Match GCC commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather 
> than fmv.x.s/fmv.s.x") and commit 879bc686a0aa ("doc: RISC-V: Update 
> binutils requirement to 2.30").

 Ping for:



  Maciej

Re: [PATCH v4 1/5] libatomic/test: Fix compilation for build sysroot

[Maciej W. Rozycki via Gcc-patches]

On Mon, 6 Apr 2020, Jeff Law wrote:

> > libatomic/
> > * configure.ac: Add testsuite/libatomic-site-extra.exp to output 
> > files.
> > * configure: Regenerate.
> > * libatomic/testsuite/libatomic-site-extra.exp.in: New file.
> > * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
> > variable.
> > * testsuite/Makefile.in: Regenerate.
> OK
> jeff

 Committed now, thanks for your review.

  Maciej

Re: [PATCH v4 5/5] libgomp/test: Remove a build sysroot fix regression

[Maciej W. Rozycki via Gcc-patches]

On Mon, 6 Apr 2020, Jeff Law wrote:

> > libgomp/
> > * configure.ac: Add testsuite/libgomp-site-extra.exp to output 
> > files.
> > * configure: Regenerate.
> > * testsuite/libgomp-site-extra.exp.in: New file.
> > * testsuite/libgomp-test-support.exp.in (GCC_UNDER_TEST): Remove 
> > variable.
> > * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New
> > variable.
> > * testsuite/Makefile.in: Regenerate.
> OK
> jeff

 Committed now, thanks for your review.

  Maciej

Re: [PATCH v4 GCC 2/5] libffi/test: Fix compilation for build sysroot

[Maciej W. Rozycki via Gcc-patches]

On Mon, 6 Apr 2020, Jeff Law wrote:

> > libffi/
> > * configure.ac: Add testsuite/local.exp to output files.
> > * configure: Regenerate.
> > * testsuite/local.exp.in: New file.
> > * testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
> > variable.
> > * testsuite/Makefile.in: Regenerate.
> Oh, I see it now.  THe patches I ack'd were actually for upstream libffi.
> 
> You should actually wait for a libffi maintainer to ack those, not me :-)  
> Sorry
> for the confusion.

 Sorry to make it unclear.  I chose to cc the other mailing list with the 
libffi part of both submissions so as to give a chance to chime in to 
members of both communities.  We are quite tightly coupled with each other 
here after all and my experience over the many years I have been involved 
has been that the bits related to Autotools are often quite tricky and 
hard to get right (Autotools are fine tools in my experience, it's just 
you need to be thorough with them as they tend not to forgive a cursory 
approach).

> Both backports are OK once they're upstreamed.

 Thanks for your ack; it was my intent to get these upstream first, and I 
realise there can be changes requested that will require the GCC backport 
to be adjusted accordingly (and reviewed again).

  Maciej

[PATCH v4 5/5] libgomp/test: Remove a build sysroot fix regression

[Maciej W. Rozycki via Gcc-patches]

Fix a problem with commit c8e759b4215b ("libgomp/test: Fix compilation 
for build sysroot") that caused a regression in some standalone test 
environments where testsuite/libgomp-test-support.exp is used, but the 
compiler is expected to be determined by `[find_gcc]', and set the 
GCC_UNDER_TEST TCL variable in testsuite/libgomp-site-extra.exp instead.

libgomp/
* configure.ac: Add testsuite/libgomp-site-extra.exp to output 
files.
* configure: Regenerate.
* testsuite/libgomp-site-extra.exp.in: New file.
* testsuite/libgomp-test-support.exp.in (GCC_UNDER_TEST): Remove 
variable.
* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New
variable.
* testsuite/Makefile.in: Regenerate.
---
No changes from v3.

Changes from v2:

- Do not use `--tool_exec' with AM_RUNTESTFLAGS.

- Move the definition of GCC_UNDER_TEST from 
  testsuite/libgomp-test-support.exp to 
  testsuite/libgomp-site-extra.exp.

Applies on top of v1.
---
 libgomp/configure |3 +++
 libgomp/configure.ac  |1 +
 libgomp/testsuite/Makefile.am |2 ++
 libgomp/testsuite/Makefile.in |6 +-
 libgomp/testsuite/libgomp-site-extra.exp.in   |1 +
 libgomp/testsuite/libgomp-test-support.exp.in |2 --
 6 files changed, 12 insertions(+), 3 deletions(-)

gcc-test-libgomp-site-extra.diff
Index: gcc/libgomp/configure
===
--- gcc.orig/libgomp/configure
+++ gcc/libgomp/configure
@@ -17047,6 +17047,8 @@ ac_config_files="$ac_config_files Makefi
 
 ac_config_files="$ac_config_files 
testsuite/libgomp-test-support.pt.exp:testsuite/libgomp-test-support.exp.in"
 
+ac_config_files="$ac_config_files testsuite/libgomp-site-extra.exp"
+
 cat >confcache <<\_ACEOF
 # This file is a shell script that caches the results of configure
 # tests run on this system so they can be shared between configure
@@ -18200,6 +18202,7 @@ do
 "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
 "libgomp.spec") CONFIG_FILES="$CONFIG_FILES libgomp.spec" ;;
 "testsuite/libgomp-test-support.pt.exp") CONFIG_FILES="$CONFIG_FILES 
testsuite/libgomp-test-support.pt.exp:testsuite/libgomp-test-support.exp.in" ;;
+"testsuite/libgomp-site-extra.exp") CONFIG_FILES="$CONFIG_FILES 
testsuite/libgomp-site-extra.exp" ;;
 
   *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
   esac
Index: gcc/libgomp/configure.ac
===
--- gcc.orig/libgomp/configure.ac
+++ gcc/libgomp/configure.ac
@@ -436,4 +436,5 @@ GCC_BASE_VER
 AC_CONFIG_FILES(omp.h omp_lib.h omp_lib.f90 libgomp_f.h)
 AC_CONFIG_FILES(Makefile testsuite/Makefile libgomp.spec)
 
AC_CONFIG_FILES([testsuite/libgomp-test-support.pt.exp:testsuite/libgomp-test-support.exp.in])
+AC_CONFIG_FILES([testsuite/libgomp-site-extra.exp])
 AC_OUTPUT
Index: gcc/libgomp/testsuite/Makefile.am
===
--- gcc.orig/libgomp/testsuite/Makefile.am
+++ gcc/libgomp/testsuite/Makefile.am
@@ -12,6 +12,8 @@ _RUNTEST = $(shell if test -f $(top_srcd
 echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir
 
+EXTRA_DEJAGNU_SITE_CONFIG = libgomp-site-extra.exp
+
 # Instead of directly in ../testsuite/libgomp-test-support.exp.in, the
 # following variables have to be "routed through" this Makefile, for expansion
 # of the several (Makefile) variables used therein.
Index: gcc/libgomp/testsuite/Makefile.in
===
--- gcc.orig/libgomp/testsuite/Makefile.in
+++ gcc/libgomp/testsuite/Makefile.in
@@ -111,7 +111,8 @@ am__configure_deps = $(am__aclocal_m4_de
 DIST_COMMON = $(srcdir)/Makefile.am
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/config.h
-CONFIG_CLEAN_FILES = libgomp-test-support.pt.exp
+CONFIG_CLEAN_FILES = libgomp-test-support.pt.exp \
+   libgomp-site-extra.exp
 CONFIG_CLEAN_VPATH_FILES =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -310,6 +311,7 @@ _RUNTEST = $(shell if test -f $(top_srcd
 echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 
 RUNTESTDEFAULTFLAGS = --tool $$tool --srcdir $$srcdir
+EXTRA_DEJAGNU_SITE_CONFIG = libgomp-site-extra.exp
 all: all-am
 
 .SUFFIXES:
@@ -344,6 +346,8 @@ $(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(
 $(am__aclocal_m4_deps):
 libgomp-test-support.pt.exp: $(top_builddir)/config.status 
$(srcdir)/libgomp-test-support.exp.in
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
+libgomp-site-extra.exp: $(top_builddir)/config.status 
$(srcdir)/libgomp-site-extra.exp.in
+   cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
 
 mostlyclean-libtool:
-rm -f *.lo
Index: 

[PATCH v4 GCC 3/5] libffi/test: Make `libffi-init' use $CC_FOR_TARGET

[Maciej W. Rozycki via Gcc-patches]

Update code in `libffi-init' to use $CC_FOR_TARGET in determining the 
value of $ld_library_path, as using a different compiler location from 
one actually used in testing may have odd consequences.

As this obviously loses the setting of $gccdir provide a replacement way 
to determine the directory if feasible, however prefer the location of 
shared libgcc over static libgcc.  This helps in configurations where 
shared libgcc is, unlike libgcc, a location that is not specific to the 
compiler version, a common scenario.  It does not address the scenario 
however where there is a shared libgcc symlink installed pointing to the 
actual run-time library installed elsewhere; this would have to be dealt 
with in a board description file specific to the installation.

Use `remote_exec host' rather than `exec' to invoke the compiler so as 
to support remote configurations and also avoid the latter procedure's 
path length limitation that prevents execution in some actual scenarios.

As using `remote_exec host' precludes the use of our existing file name 
globbing to examine directory contents reuse, with minor modifications 
needed to adjust to our structure, the piece I previously contributed to 
GCC with commit d42b84f427e4 ("testsuite: Fix run-time tracking down 
of `libgcc_s'").

libffi/
* testsuite/lib/libffi.exp (libffi-init): Use CC_FOR_TARGET.
Update the determination of `ld_library_path' accordingly.
---
This is a backport of combined upstream libffi changes as recorded here: 
 and 
here:  
(there's no point to introduce indentation breakage only to fix it with 
the next change).

New change in v4.
---
 libffi/testsuite/lib/libffi.exp |   72 ++--
 1 file changed, 54 insertions(+), 18 deletions(-)

gcc-test-libffi-init-compiler.diff
Index: gcc/libffi/testsuite/lib/libffi.exp
===
--- gcc.orig/libffi/testsuite/lib/libffi.exp
+++ gcc/libffi/testsuite/lib/libffi.exp
@@ -99,7 +99,7 @@ proc libffi-init { args } {
 global blddirffi
 global objdir
 global blddircxx
-global TOOL_OPTIONS
+global CC_FOR_TARGET
 global tool
 global libffi_include
 global libffi_link_flags
@@ -114,26 +114,62 @@ proc libffi-init { args } {
 
 set compiler_vendor "gnu"
 
-set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a]
-if {$gccdir != ""} {
-   set gccdir [file dirname $gccdir]
-}
-verbose "gccdir $gccdir"
+if { [string match $compiler_vendor "gnu"] } {
+   if [info exists CC_FOR_TARGET] then {
+   set compiler "$CC_FOR_TARGET"
+   set libgcc_a_x [remote_exec host "$compiler" \
+   "-print-file-name=libgcc.a"]
+   if { [lindex $libgcc_a_x 0] == 0 } {
+   set gccdir [file dirname [lindex $libgcc_a_x 1]]
+   } else {
+   set gccdir ""
+   }
+   } else {
+   set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a]
+   if {$gccdir != ""} {
+   set gccdir [file dirname $gccdir]
+   }
+   set compiler "${gccdir}/xgcc"
+   }
+   verbose "gccdir $gccdir"
 
-set ld_library_path "."
-append ld_library_path ":${gccdir}"
+   set shlib_ext [get_shlib_extension]
+   set libgcc_s_x [remote_exec host "$compiler" \
+   "-print-file-name=libgcc_s.${shlib_ext}"]
+   if { [lindex $libgcc_s_x 0] == 0 } {
+   set libgcc_dir [file dirname [lindex $libgcc_s_x 1]]
+   } else {
+   set libgcc_dir $gccdir
+   }
+   verbose "libgcc_dir $libgcc_dir"
 
-set compiler "${gccdir}/xgcc"
-if { [is_remote host] == 0 && [which $compiler] != 0 } {
-   foreach i "[exec $compiler --print-multi-lib]" {
-   set mldir ""
-   regexp -- "\[a-z0-9=_/\.-\]*;" $i mldir
-   set mldir [string trimright $mldir "\;@"]
-   if { "$mldir" == "." } {
-   continue
+   set ld_library_path "."
+   append ld_library_path ":${gccdir}"
+
+   set multi_dir_x [remote_exec host "$compiler" "-print-multi-directory"]
+   set multi_lib_x [remote_exec host "$compiler" "-print-multi-lib"]
+   if { [lindex $multi_dir_x 0] == 0 && [lindex $multi_lib_x 0] == 0 } {
+   set multi_dir [string trim [lindex $multi_dir_x 1]]
+   set multi_lib [string trim [lindex $multi_lib_x 1]]
+   if { "$multi_dir" == "." } {
+   set multi_root "$libgcc_dir"
+   } else {
+   set multi_match [string last "/$multi_dir" "$libgcc_dir"]
+   if { "$multi_match" >= 0 } {
+   set multi_root [string range "$libgcc_dir" \
+   0 [expr $multi_match - 1]]
+   } else {
+   set multi_lib ""
+ 

[PATCH v4 4/5] libgo/test: Complement compilation fix for build sysroot

[Maciej W. Rozycki via Gcc-patches]

Complement commit b72813a68c94 ("libgo: fix DejaGNU testsuite compiler 
when using build sysroot") and move testsuite/libgo-test-support.exp.in 
to testsuite/libgo-site-extra.exp.in.  Update testsuite/lib/libgo.exp to 
handle the `--tool_exec' option to `runtest' as with other top-level GCC 
target libraries, by using the TOOL_EXECUTABLE TCL variable.

libgo/
* configure.ac: Produce testsuite/libgo-site-extra.exp rather 
than testsuite/libgo-test-support.exp.
* configure: Regenerate.
* testsuite/libgo-test-support.exp.in: Rename file to...
* testsuite/libgo-site-extra.exp.in: ... this.
* testsuite/Makefile.am: Use libgo-site-extra.exp rather than 
libgo-test-support.exp.
* testsuite/Makefile.in: Regenerate.
* testsuite/lib/libgo.exp: Handle TOOL_EXECUTABLE.
---
No changes from v3.

Changes from v2:

- Rename testsuite/libgo-test-support.exp.in to 
  testsuite/libgo-site-extra.exp.in.

Applies on top of v1.
---
 libgo/configure   |4 ++--
 libgo/configure.ac|2 +-
 libgo/testsuite/Makefile.am   |2 +-
 libgo/testsuite/Makefile.in   |6 +++---
 libgo/testsuite/lib/libgo.exp |   12 
 libgo/testsuite/libgo-site-extra.exp.in   |   17 +
 libgo/testsuite/libgo-test-support.exp.in |   17 -
 7 files changed, 32 insertions(+), 28 deletions(-)

gcc-test-libgo-site-extra.diff
Index: gcc/libgo/configure
===
--- gcc.orig/libgo/configure
+++ gcc/libgo/configure
@@ -15893,7 +15893,7 @@ else
   multilib_arg=
 fi
 
-ac_config_files="$ac_config_files Makefile testsuite/Makefile 
testsuite/libgo-test-support.exp"
+ac_config_files="$ac_config_files Makefile testsuite/Makefile 
testsuite/libgo-site-extra.exp"
 
 
 ac_config_commands="$ac_config_commands default"
@@ -17074,7 +17074,7 @@ do
 "libtool") CONFIG_COMMANDS="$CONFIG_COMMANDS libtool" ;;
 "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
 "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
-"testsuite/libgo-test-support.exp") CONFIG_FILES="$CONFIG_FILES 
testsuite/libgo-test-support.exp" ;;
+"testsuite/libgo-site-extra.exp") CONFIG_FILES="$CONFIG_FILES 
testsuite/libgo-site-extra.exp" ;;
 "default") CONFIG_COMMANDS="$CONFIG_COMMANDS default" ;;
 
   *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
Index: gcc/libgo/configure.ac
===
--- gcc.orig/libgo/configure.ac
+++ gcc/libgo/configure.ac
@@ -895,7 +895,7 @@ else
   multilib_arg=
 fi
 
-AC_CONFIG_FILES(Makefile testsuite/Makefile testsuite/libgo-test-support.exp)
+AC_CONFIG_FILES(Makefile testsuite/Makefile testsuite/libgo-site-extra.exp)
 
 AC_CONFIG_COMMANDS([default],
 [if test -n "$CONFIG_FILES"; then
Index: gcc/libgo/testsuite/Makefile.am
===
--- gcc.orig/libgo/testsuite/Makefile.am
+++ gcc/libgo/testsuite/Makefile.am
@@ -11,7 +11,7 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
   echo $(top_srcdir)/../dejagnu/runtest ; \
else echo runtest; fi`
 
-EXTRA_DEJAGNU_SITE_CONFIG = libgo-test-support.exp
+EXTRA_DEJAGNU_SITE_CONFIG = libgo-site-extra.exp
 
 # When running the tests we set GCC_EXEC_PREFIX to the install tree so that
 # files that have already been installed there will be found.  The -B option
Index: gcc/libgo/testsuite/Makefile.in
===
--- gcc.orig/libgo/testsuite/Makefile.in
+++ gcc/libgo/testsuite/Makefile.in
@@ -107,7 +107,7 @@ am__configure_deps = $(am__aclocal_m4_de
 DIST_COMMON = $(srcdir)/Makefile.am
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/config.h
-CONFIG_CLEAN_FILES = libgo-test-support.exp
+CONFIG_CLEAN_FILES = libgo-site-extra.exp
 CONFIG_CLEAN_VPATH_FILES =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -300,7 +300,7 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
   echo $(top_srcdir)/../dejagnu/runtest ; \
else echo runtest; fi`
 
-EXTRA_DEJAGNU_SITE_CONFIG = libgo-test-support.exp
+EXTRA_DEJAGNU_SITE_CONFIG = libgo-site-extra.exp
 
 # When running the tests we set GCC_EXEC_PREFIX to the install tree so that
 # files that have already been installed there will be found.  The -B option
@@ -340,7 +340,7 @@ $(top_srcdir)/configure: @MAINTAINER_MOD
 $(ACLOCAL_M4): @MAINTAINER_MODE_TRUE@ $(am__aclocal_m4_deps)
cd $(top_builddir) && $(MAKE) $(AM_MAKEFLAGS) am--refresh
 $(am__aclocal_m4_deps):
-libgo-test-support.exp: $(top_builddir)/config.status 
$(srcdir)/libgo-test-support.exp.in
+libgo-site-extra.exp: $(top_builddir)/config.status 
$(srcdir)/libgo-site-extra.exp.in
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@
 
 

[PATCH v4 GCC 2/5] libffi/test: Fix compilation for build sysroot

[Maciej W. Rozycki via Gcc-patches]

Fix a problem with the libffi testsuite using a method to determine the 
compiler to use resulting in the tool being different from one the 
library has been built with, and causing a catastrophic failure from the 
inability to actually choose any compiler at all in a cross-compilation 
configuration.

Address this problem by providing a DejaGNU configuration file defining 
the compiler to use, via the CC_FOR_TARGET TCL variable, set from $CC by 
autoconf, which will have all the required options set for the target 
compiler to build executables in the environment configured, removing 
failures like:

FAIL: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 (test for excess errors)
Excess errors:
default_target_compile: No compiler to compile with
UNRESOLVED: libffi.call/closure_fn0.c -W -Wall -Wno-psabi -O0 compilation 
failed to produce executable

and bringing overall test results for the `riscv64-linux-gnu' target 
(here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user 
emulation mode as the target board) from:

=== libffi Summary ===

# of unexpected failures708
# of unresolved testcases   708
# of unsupported tests  30

to:

=== libffi Summary ===

# of expected passes1934
# of unsupported tests  28

libffi/
* configure.ac: Add testsuite/local.exp to output files.
* configure: Regenerate.
* testsuite/local.exp.in: New file.
* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
variable.
* testsuite/Makefile.in: Regenerate.
---
This is a backport of upstream libffi change as recorded here: 
.

New change in v4.
---
 libffi/configure  |3 ++-
 libffi/configure.ac   |2 +-
 libffi/testsuite/Makefile.am  |2 ++
 libffi/testsuite/Makefile.in  |5 -
 libffi/testsuite/local.exp.in |2 ++
 5 files changed, 11 insertions(+), 3 deletions(-)

gcc-test-libffi-cc-for-target-template.diff
Index: gcc/libffi/configure
===
--- gcc.orig/libffi/configure
+++ gcc/libffi/configure
@@ -16662,7 +16662,7 @@ ac_config_commands="$ac_config_commands
 ac_config_links="$ac_config_links 
include/ffitarget.h:src/$TARGETDIR/ffitarget.h"
 
 
-ac_config_files="$ac_config_files include/Makefile include/ffi.h Makefile 
testsuite/Makefile man/Makefile libffi.pc"
+ac_config_files="$ac_config_files include/Makefile include/ffi.h Makefile 
testsuite/Makefile testsuite/local.exp man/Makefile libffi.pc"
 
 
 cat >confcache <<\_ACEOF
@@ -17829,6 +17829,7 @@ do
 "include/ffi.h") CONFIG_FILES="$CONFIG_FILES include/ffi.h" ;;
 "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
 "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
+"testsuite/local.exp") CONFIG_FILES="$CONFIG_FILES testsuite/local.exp" ;;
 "man/Makefile") CONFIG_FILES="$CONFIG_FILES man/Makefile" ;;
 "libffi.pc") CONFIG_FILES="$CONFIG_FILES libffi.pc" ;;
 
Index: gcc/libffi/configure.ac
===
--- gcc.orig/libffi/configure.ac
+++ gcc/libffi/configure.ac
@@ -377,6 +377,6 @@ test -d src/$TARGETDIR || mkdir src/$TAR
 
 AC_CONFIG_LINKS(include/ffitarget.h:src/$TARGETDIR/ffitarget.h)
 
-AC_CONFIG_FILES(include/Makefile include/ffi.h Makefile testsuite/Makefile 
man/Makefile libffi.pc)
+AC_CONFIG_FILES(include/Makefile include/ffi.h Makefile testsuite/Makefile 
testsuite/local.exp man/Makefile libffi.pc)
 
 AC_OUTPUT
Index: gcc/libffi/testsuite/Makefile.am
===
--- gcc.orig/libffi/testsuite/Makefile.am
+++ gcc/libffi/testsuite/Makefile.am
@@ -13,6 +13,8 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
 
 AM_RUNTESTFLAGS =
 
+EXTRA_DEJAGNU_SITE_CONFIG = local.exp
+
 CLEANFILES = *.exe core* *.log *.sum
 
 EXTRA_DIST = config/default.exp libffi.call/cls_19byte.c   \
Index: gcc/libffi/testsuite/Makefile.in
===
--- gcc.orig/libffi/testsuite/Makefile.in
+++ gcc/libffi/testsuite/Makefile.in
@@ -106,7 +106,7 @@ am__configure_deps = $(am__aclocal_m4_de
 DIST_COMMON = $(srcdir)/Makefile.am
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/fficonfig.h
-CONFIG_CLEAN_FILES =
+CONFIG_CLEAN_FILES = local.exp
 CONFIG_CLEAN_VPATH_FILES =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -279,6 +279,7 @@ RUNTEST = `if [ -f $(top_srcdir)/../deja
   echo $(top_srcdir)/../dejagnu/runtest ; \
else echo runtest; fi`
 
+EXTRA_DEJAGNU_SITE_CONFIG = local.exp
 CLEANFILES = *.exe core* *.log *.sum
 EXTRA_DIST = config/default.exp libffi.call/cls_19byte.c   \
 libffi.call/cls_align_longdouble_split.c   \
@@ -390,6 +391,8 @@ 

[PATCH v4 1/5] libatomic/test: Fix compilation for build sysroot

[Maciej W. Rozycki via Gcc-patches]

Fix a problem with the libatomic testsuite using a method to determine 
the compiler to use resulting in the tool being different from one the 
library has been built with, and causing a catastrophic failure from the 
lack of a suitable `--sysroot=' option where the `--with-build-sysroot=' 
configuration option has been used to build the compiler resulting in 
the inability to link executables.

Address this problem by providing a DejaGNU configuration file defining 
the compiler to use, via the GCC_UNDER_TEST TCL variable, set from $CC 
by autoconf, which will have all the required options set for the target 
compiler to build executables in the environment configured, removing 
failures like:

.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm
collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: libatomic.c/atomic-compare-exchange-1.c (test for excess errors)
Excess errors:
.../bin/riscv64-linux-gnu-ld: cannot find crt1.o: No such file or directory
.../bin/riscv64-linux-gnu-ld: cannot find -lm

UNRESOLVED: libatomic.c/atomic-compare-exchange-1.c compilation failed to 
produce executable

and bringing overall test results for the `riscv64-linux-gnu' target 
(here with the `x86_64-linux-gnu' host and RISC-V QEMU in the Linux user 
emulation mode as the target board) from:

=== libatomic Summary ===

# of unexpected failures27
# of unresolved testcases   27

to:

=== libatomic Summary ===

# of expected passes54

libatomic/
* configure.ac: Add testsuite/libatomic-site-extra.exp to output 
files.
* configure: Regenerate.
* libatomic/testsuite/libatomic-site-extra.exp.in: New file.
* testsuite/Makefile.am (EXTRA_DEJAGNU_SITE_CONFIG): New 
variable.
* testsuite/Makefile.in: Regenerate.
---
No change from v3.

Changes from v2:

- Revert to v1.

- Rename testsuite/libatomic-test-support.exp.in to 
  testsuite/libatomic-site-extra.exp.in.

Changes from v1:

- Remove testsuite/libatomic-test-support.exp.in and the associated
  changes.

- Pass $(CC) via `--tool_exec' in $(AM_RUNTESTFLAGS).
---
 libatomic/configure |3 +++
 libatomic/configure.ac  |1 +
 libatomic/testsuite/Makefile.am |2 ++
 libatomic/testsuite/Makefile.in |5 -
 libatomic/testsuite/libatomic-site-extra.exp.in |1 +
 5 files changed, 11 insertions(+), 1 deletion(-)

gcc-test-libatomic-gcc-under-test.diff
Index: gcc/libatomic/configure
===
--- gcc.orig/libatomic/configure
+++ gcc/libatomic/configure
@@ -15728,6 +15728,8 @@ fi
 
 ac_config_files="$ac_config_files Makefile testsuite/Makefile"
 
+ac_config_files="$ac_config_files testsuite/libatomic-site-extra.exp"
+
 cat >confcache <<\_ACEOF
 # This file is a shell script that caches the results of configure
 # tests run on this system so they can be shared between configure
@@ -16799,6 +16801,7 @@ do
 "gstdint.h") CONFIG_COMMANDS="$CONFIG_COMMANDS gstdint.h" ;;
 "Makefile") CONFIG_FILES="$CONFIG_FILES Makefile" ;;
 "testsuite/Makefile") CONFIG_FILES="$CONFIG_FILES testsuite/Makefile" ;;
+"testsuite/libatomic-site-extra.exp") CONFIG_FILES="$CONFIG_FILES 
testsuite/libatomic-site-extra.exp" ;;
 
   *) as_fn_error $? "invalid argument: \`$ac_config_target'" "$LINENO" 5;;
   esac
Index: gcc/libatomic/configure.ac
===
--- gcc.orig/libatomic/configure.ac
+++ gcc/libatomic/configure.ac
@@ -288,4 +288,5 @@ else
 fi
 
 AC_CONFIG_FILES(Makefile testsuite/Makefile)
+AC_CONFIG_FILES(testsuite/libatomic-site-extra.exp)
 AC_OUTPUT
Index: gcc/libatomic/testsuite/Makefile.am
===
--- gcc.orig/libatomic/testsuite/Makefile.am
+++ gcc/libatomic/testsuite/Makefile.am
@@ -11,3 +11,5 @@ EXPECT = $(shell if test -f $(top_buildd
 _RUNTEST = $(shell if test -f $(top_srcdir)/../dejagnu/runtest; then \
 echo $(top_srcdir)/../dejagnu/runtest; else echo runtest; fi)
 RUNTEST = $(_RUNTEST) $(AM_RUNTESTFLAGS)
+
+EXTRA_DEJAGNU_SITE_CONFIG = libatomic-site-extra.exp
Index: gcc/libatomic/testsuite/Makefile.in
===
--- gcc.orig/libatomic/testsuite/Makefile.in
+++ gcc/libatomic/testsuite/Makefile.in
@@ -109,7 +109,7 @@ am__configure_deps = $(am__aclocal_m4_de
 DIST_COMMON = $(srcdir)/Makefile.am
 mkinstalldirs = $(SHELL) $(top_srcdir)/../mkinstalldirs
 CONFIG_HEADER = $(top_builddir)/auto-config.h
-CONFIG_CLEAN_FILES =
+CONFIG_CLEAN_FILES = libatomic-site-extra.exp
 CONFIG_CLEAN_VPATH_FILES =
 AM_V_P = $(am__v_P_@AM_V@)
 am__v_P_ = $(am__v_P_@AM_DEFAULT_V@)
@@ -278,6 +278,7 @@ _RUNTEST = $(shell if test -f $(top_srcd
 echo 

[PATCH v4 0/5] Fix library testsuite compilation for build sysroot

[Maciej W. Rozycki via Gcc-patches]

Hi,

 This is v4 of patch series, originally posted here:






v2 posted here:






and v3 posted here:






meant to address a problem with the testsuite compiler being set up across 
libatomic, libffi, libgo, libgomp with no correlation whatsoever to the 
target compiler being used in GCC compilation.  Consequently there in no 
arrangement made to set up the compilation sysroot according to the build 
sysroot specified for GCC compilation, causing a catastrophic failure 
across the testsuites affected from the inability to link executables.

 In the course of discussion it has been determined it might be the best 
if we sync with libffi rather than providing our replacement solution, as 
the upstream version has it addressed, although in a slightly messy way.  
I have therefore decided to clean it up with upstream libffi and propose a 
corresponding backport of the change to be included with our version.  
This has resulted in two patches actually, replacing 2/4 from the original 
series.  The remaining changes are the same as in v3, however Chung-Lin 
has since confirmed the libgomp change proposed here has addressed issues 
with testing in his environment (thank you, Chung-Lin!).

 Verified with a cross-compiler configured for the `riscv-linux-gnu' 
target and the `x86_64-linux-gnu' host and using RISC-V/Linux QEMU in the 
user emulation mode as the target board.  Also no change in results with 
`x86_64-linux-gnu' native regression testing.

 See individual change descriptions for details.

 I'm assuming Ian will take care of the 4/5 libgo change (Ian, it's up to 
you if you want to have it or not).

 Any objections about 1/5 previously approved by Jeff, and OK to apply 2/5 
and 3/5 (if the corresponding changes have been accepted into upstream 
libffi), as well as 5/5 to the GCC repo?

  Maciej

[PATCH libffi 3/4] Make `libffi-init' use $CC_FOR_TARGET

[Maciej W. Rozycki via Gcc-patches]

Update code in `libffi-init' to use $CC_FOR_TARGET in determining the 
value of $ld_library_path, as using a different compiler location from 
one actually used in testing may have odd consequences.

As this obviously loses the setting of $gccdir provide a replacement way 
to determine the directory if feasible, however prefer the location of 
shared libgcc over static libgcc.  This helps in configurations where 
shared libgcc is, unlike libgcc, a location that is not specific to the 
compiler version, a common scenario.  It does not address the scenario 
however where there is a shared libgcc symlink installed pointing to the 
actual run-time library installed elsewhere; this would have to be dealt 
with in a board description file specific to the installation.

Use `remote_exec host' rather than `exec' to invoke the compiler so as 
to support remote configurations and also avoid the latter procedure's 
path length limitation that prevents execution in some actual scenarios.

As using `remote_exec host' precludes the use of our existing file name 
globbing to examine directory contents, reuse, with minor modifications 
needed to adjust to our structure, the piece I previously contributed to 
GCC with commit d42b84f427e4 ("testsuite: Fix run-time tracking down 
of `libgcc_s'").
---
Hi,

 This has its limitation in that it still doesn't default to the same 
compiler as `target_compile' (`default_target_compile') from target.exp in 
DejaGNU does, but I believe it is a step in the right direction.  That 
will only affect standalone (e.g. installed) testing iff $CC_FOR_TARGET 
hasn't been set.

 Also for C++ compilation our carefully crafted $ld_library_path is 
unfortunately overridden by `g++_link_flags' from libgloss.exp in DejaGNU 
called in `default_target_compile'.  This actually does cause test 
failures in my `riscv64-linux-gnu' cross-compilation setup:

FAIL: libffi.closures/unwindtest.cc -W -Wall -Wno-psabi -O0 execution test
FAIL: libffi.closures/unwindtest.cc -W -Wall -Wno-psabi -O2 execution test
FAIL: libffi.closures/unwindtest_ffi_call.cc -W -Wall -Wno-psabi -O0 execution 
test
FAIL: libffi.closures/unwindtest_ffi_call.cc -W -Wall -Wno-psabi -O2 execution 
test

and I am currently not sure how to best address it, i.e. whether to change
DejaGNU's `g++_link_flags' or to take advantage of a TCL's feature and 
provide our own copy of the procedure.  Something to consider sometime.

 NB I chose not to correct obvious indentation issues with lines not 
touched by this change so as not to obfuscate the patch unnecessarily.  A 
complementing formatting change follows.

  Maciej
---
 testsuite/lib/libffi.exp |   68 +++
 1 file changed, 51 insertions(+), 17 deletions(-)

Index: libffi/testsuite/lib/libffi.exp
===
--- libffi.orig/testsuite/lib/libffi.exp
+++ libffi/testsuite/lib/libffi.exp
@@ -272,7 +272,7 @@ proc libffi-init { args } {
 global srcdir
 global blddirffi
 global objdir
-global TOOL_OPTIONS
+global CC_FOR_TARGET
 global tool
 global libffi_include
 global libffi_link_flags
@@ -287,29 +287,63 @@ proc libffi-init { args } {
 verbose "libffi $blddirffi"
 
 if { [string match $compiler_vendor "gnu"] } {
-set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a]
-if {$gccdir != ""} {
-   set gccdir [file dirname $gccdir]
-}
+   if [info exists CC_FOR_TARGET] then {
+   set compiler "$CC_FOR_TARGET"
+   set libgcc_a_x [remote_exec host "$compiler" \
+   "-print-file-name=libgcc.a"]
+   if { [lindex $libgcc_a_x 0] == 0 } {
+   set gccdir [file dirname [lindex $libgcc_a_x 1]]
+   } else {
+   set gccdir ""
+   }
+   } else {
+   set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a]
+   if {$gccdir != ""} {
+   set gccdir [file dirname $gccdir]
+   }
+   set compiler "${gccdir}/xgcc"
+   }
 verbose "gccdir $gccdir"
 
+   set shlib_ext [get_shlib_extension]
+   set libgcc_s_x [remote_exec host "$compiler" \
+   "-print-file-name=libgcc_s.${shlib_ext}"]
+   if { [lindex $libgcc_s_x 0] == 0 } {
+   set libgcc_dir [file dirname [lindex $libgcc_s_x 1]]
+   } else {
+   set libgcc_dir $gccdir
+   }
+   verbose "libgcc_dir $libgcc_dir"
+
 set ld_library_path "."
 append ld_library_path ":${gccdir}"
 
-set compiler "${gccdir}/xgcc"
-if { [is_remote host] == 0 && [which $compiler] != 0 } {
-   foreach i "[exec $compiler --print-multi-lib]" {
-   set mldir ""
-   regexp -- "\[a-z0-9=_/\.-\]*;" $i mldir
-   set mldir [string trimright $mldir "\;@"]
-   if { "$mldir" == "." } {
+   set multi_dir_x [remote_exec host "$compiler" 

[PATCH libffi 4/4] Correct indentation throughout `libffi-init'

[Maciej W. Rozycki via Gcc-patches]

---
 testsuite/lib/libffi.exp |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

libffi-init-whitespace.diff
Index: libffi/testsuite/lib/libffi.exp
===
--- libffi.orig/testsuite/lib/libffi.exp
+++ libffi/testsuite/lib/libffi.exp
@@ -303,7 +303,7 @@ proc libffi-init { args } {
}
set compiler "${gccdir}/xgcc"
}
-verbose "gccdir $gccdir"
+   verbose "gccdir $gccdir"
 
set shlib_ext [get_shlib_extension]
set libgcc_s_x [remote_exec host "$compiler" \
@@ -315,8 +315,8 @@ proc libffi-init { args } {
}
verbose "libgcc_dir $libgcc_dir"
 
-set ld_library_path "."
-append ld_library_path ":${gccdir}"
+   set ld_library_path "."
+   append ld_library_path ":${gccdir}"
 
set multi_dir_x [remote_exec host "$compiler" "-print-multi-directory"]
set multi_lib_x [remote_exec host "$compiler" "-print-multi-lib"]

[PATCH libffi 2/4] Use a documented way to pass $compiler_vendor to DejaGNU

[Maciej W. Rozycki via Gcc-patches]

Use Autoconf substitution in the template used for extra DejaGNU site 
configuration, which is a documented supported way to pass information 
from the `configure' script, rather than resorting to a hack with 
extracting an undocumented internal setting from `config.log' to pass 
the compiler vendor to DejaGNU.  No functional change (and no risk of 
breakage with some Autoconf version anymore).

Use AM_SUBST_NOTMAKE with the new substitution so as not to place it in 
Makefile.in files, where it is not needed, and set the Autmoake version 
requirement accordingly.
---
Hi,

 I chose to use AM_SUBST_NOTMAKE so as not to clutter Makefile.in files 
with the new variable as Automake does that by default.  That however 
requires the use of Automake 1.11 or newer.  By the look of our sources 
that shouldn't be an issue as far as I can tell, but the macro invocation 
can be dropped along with the requirement if it would.

  Maciej
---
 Makefile.am  |3 ++-
 configure.ac |2 ++
 testsuite/lib/libffi.exp |4 
 testsuite/local.exp.in   |1 +
 4 files changed, 5 insertions(+), 5 deletions(-)

libffi-compiler-vendor.diff
Index: libffi/Makefile.am
===
--- libffi.orig/Makefile.am
+++ libffi/Makefile.am
@@ -1,6 +1,7 @@
 ## Process this with automake to create Makefile.in
 
-AUTOMAKE_OPTIONS = foreign subdir-objects
+# Automake 1.11 needed for AM_SUBST_NOTMAKE.
+AUTOMAKE_OPTIONS = 1.11 foreign subdir-objects
 
 ACLOCAL_AMFLAGS = -I m4
 
Index: libffi/configure.ac
===
--- libffi.orig/configure.ac
+++ libffi/configure.ac
@@ -45,6 +45,8 @@ AC_CONFIG_MACRO_DIR([m4])
 AC_CHECK_SIZEOF([size_t])
 
 AX_COMPILER_VENDOR
+AC_SUBST([compiler_vendor], [$ax_cv_c_compiler_vendor])
+AM_SUBST_NOTMAKE([compiler_vendor])
 AX_CC_MAXOPT
 # The AX_CFLAGS_WARN_ALL macro doesn't currently work for sunpro
 # compiler.
Index: libffi/testsuite/lib/libffi.exp
===
--- libffi.orig/testsuite/lib/libffi.exp
+++ libffi/testsuite/lib/libffi.exp
@@ -286,10 +286,6 @@ proc libffi-init { args } {
 
 verbose "libffi $blddirffi"
 
-# Which compiler are we building with?
-set tmp [grep "$blddirffi/config.log" "^ax_cv_c_compiler_vendor.*$"]
-regexp -- {^[^=]*=(.*)$} $tmp nil compiler_vendor
-
 if { [string match $compiler_vendor "gnu"] } {
 set gccdir [lookfor_file $tool_root_dir gcc/libgcc.a]
 if {$gccdir != ""} {
Index: libffi/testsuite/local.exp.in
===
--- libffi.orig/testsuite/local.exp.in
+++ libffi/testsuite/local.exp.in
@@ -1,2 +1,3 @@
 set CC_FOR_TARGET "@CC@"
 set CXX_FOR_TARGET "@CXX@"
+set compiler_vendor "@compiler_vendor@"

[PATCH libffi 1/4] Use a template to pass $CC and $CXX to DejaGNU

[Maciej W. Rozycki via Gcc-patches]

Use an Autoconf template rather an inline piece of scriptery to set 
DejaGNU's $CC_FOR_TARGET and $CXX_FOR_TARGET variables from $CC and $CXX 
respectively, making it easier to maintain and making it take advantage 
of Automake's dependency and rule generation.  Relocate the generated 
`local.exp' file to within testsuite/ so as to make its regeneration 
rule to actually work, i.e. (in testsuite/Makefile.in):

EXTRA_DEJAGNU_SITE_CONFIG = local.exp
site.exp: Makefile $(EXTRA_DEJAGNU_SITE_CONFIG)
[...]
local.exp: $(top_builddir)/config.status $(srcdir)/local.exp.in
cd $(top_builddir) && $(SHELL) ./config.status $(subdir)/$@

It wouldn't work if the regeneration rule was placed in the top-level 
Makefile.in, which is what Automake would faithfully do if `local.exp' 
stayed in the top level directory.
---
Hi,

 I think having individual AC_CONFIG_FILES macro invocations for each 
output file or group of files would make this change (and code itself) 
more readable, however it hasn't been done before and I decided not to 
change the style on this occasion.  It may make sense as a follow-up 
clean-up.

  Maciej
---
 Makefile.am|3 ---
 configure.ac   |7 +--
 testsuite/Makefile.am  |2 +-
 testsuite/local.exp.in |2 ++
 4 files changed, 4 insertions(+), 10 deletions(-)

libffi-test-cc-for-target-template.diff
Index: libffi/Makefile.am
===
--- libffi.orig/Makefile.am
+++ libffi/Makefile.am
@@ -23,9 +23,6 @@ EXTRA_DIST = LICENSE ChangeLog.old
\
libtool-ldflags libtool-version configure.host README.md\
libffi.map.in LICENSE-BUILDTOOLS msvc_build make_sunver.pl  
 
-# local.exp is generated by configure
-DISTCLEANFILES = local.exp
-
 # Subdir rules rely on $(FLAGS_TO_PASS)
 FLAGS_TO_PASS = $(AM_MAKEFLAGS)
 
Index: libffi/configure.ac
===
--- libffi.orig/configure.ac
+++ libffi/configure.ac
@@ -56,11 +56,6 @@ if test "x$GCC" = "xyes"; then
   CFLAGS="$CFLAGS -fexceptions"
 fi
 
-cat > local.exp <

[PATCH libffi 0/4] Robustify compiler and library path selection in the testsuite

[Maciej W. Rozycki via Gcc-patches]

Hi,

 In the course of a discussion at one of the GCC mailing lists here: 
 I have 
realised that some parts related to libffi testing have not been merged to 
GCC, and they are needed to choose the right compiler in a cross-compiler 
build environment where the build root option has been used.

 Additionally the right target run-time loader's library path has to be 
set via the LD_LIBRARY_PATH environment variable for running the test 
suite in a cross-compilation environment where the location of the host 
libraries is obviously irrelevant.

 We are keen to keep the GCC's copy of libffi as close as possible to the 
upstream version however while usable the current solution has some issues 
which we would rather avoid.  I have therefore decided to address some of 
them with the intent to have the result backported to GCC.  As it stands 
I'm told the current version of libffi cannot be fully merged to GCC, as 
there have been an ABI change that will require technical evaluation.  So 
the intent has been to backport the changes proposed here individually.

 See the individual change descriptions and any further discussion 
included for full details of each patch proposed.

 These changes have been regression-tested with the `x86_64-linux-gnu' 
native configuration, and also the `x86_64-linux-gnu' host and the 
`riscv64-linux-gnu' target using RISC-V QEMU in the Linux user emulation 
mode as the target board.  In the latter case I actually dropped libffi 
into GCC as a replacement of the version included there, with a minor 
update like below (+script regeneration) to add multilib support.

 Any questions, comments, or concerns?  Otherwise, please apply.

  Maciej

Index: gcc/libffi/Makefile.am
===
--- gcc.orig/libffi/Makefile.am
+++ gcc/libffi/Makefile.am
@@ -2,7 +2,7 @@
 
 AUTOMAKE_OPTIONS = foreign subdir-objects
 
-ACLOCAL_AMFLAGS = -I m4
+ACLOCAL_AMFLAGS = -I m4 -I ../config
 
 SUBDIRS = include testsuite man
 if BUILD_DOCS
@@ -158,3 +158,12 @@ AM_CCASFLAGS = $(AM_CPPFLAGS)
if [ -d $(top_srcdir)/.git ] ; then (cd $(top_srcdir); git log 
--no-decorate) ; else echo 'See git log for history.' ; fi > 
$(distdir)/ChangeLog
s=`awk '/was released on/{ print NR; exit}' $(top_srcdir)/README.md`; 
tail -n +$$(($$s-1)) $(top_srcdir)/README.md > $(distdir)/README.md
 
+# Multilib support.  Automake should provide these on its own.
+all-recursive: all-multi
+install-recursive: install-multi
+mostlyclean-recursive: mostlyclean-multi
+clean-recursive: clean-multi
+distclean-recursive: distclean-multi
+maintainer-clean-recursive: maintainer-clean-multi
+
+include $(top_srcdir)/../multilib.am
Index: gcc/libffi/configure.ac
===
--- gcc.orig/libffi/configure.ac
+++ gcc/libffi/configure.ac
@@ -5,6 +5,8 @@ AC_PREREQ(2.68)
 AC_INIT([libffi], [3.3], [http://github.com/libffi/libffi/issues])
 AC_CONFIG_HEADERS([fficonfig.h])
 
+AM_ENABLE_MULTILIB(, ..)
+
 AC_CANONICAL_SYSTEM
 target_alias=${target_alias-$host_alias}
 

Re: [PATCH] doc: RISC-V: Update binutils requirement to 2.30

[Maciej W. Rozycki via Gcc-patches]

On Thu, 2 Apr 2020, Maciej W. Rozycki wrote:

> > OK.  Can you also update gcc-10/changes.html?
> 
>  Change now applied, thank you for your review, and patch posted for 
> wwwdocs [I meant to give a link to the message in the archive here, but it 
> seems behind by ~2.5 hours; something to look into and fix too, perhaps?  
> The old archive was live as messages went through.].

 I confused the archives, not being used to the new layout, so the message 
may have actually been recorded in a timely manner.  Sorry about that.  
Patch is here: 
.

  Maciej

Re: [PATCH] doc: RISC-V: Update binutils requirement to 2.30

[Maciej W. Rozycki via Gcc-patches]

On Thu, 2 Apr 2020, Richard Biener wrote:

> > >  Our installation instructions state binutils 2.28 as the requirement for
> > > all the RISC-V targets, however the change for fmv.x.w/fmv.w.x instruction
> > > support was only added in the binutils 2.30 development cycle.
> >
> >  Here's the resulting change.  Verified with `make info' and `make check'.
> > OK to apply?
> 
> OK.  Can you also update gcc-10/changes.html?

 Change now applied, thank you for your review, and patch posted for 
wwwdocs [I meant to give a link to the message in the archive here, but it 
seems behind by ~2.5 hours; something to look into and fix too, perhaps?  
The old archive was live as messages went through.].

  Maciej

[PATCH][wwwdocs] GCC 10: Document RISC-V target's requirement for binutils 2.30

[Maciej W. Rozycki via Gcc-patches]

Match GCC commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather 
than fmv.x.s/fmv.s.x") and commit 879bc686a0aa ("doc: RISC-V: Update 
binutils requirement to 2.30").
---
Hi,

 OK to apply?

  Maciej
---
 htdocs/gcc-10/changes.html | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 3d8e0ba9..809bbb4d 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -725,7 +725,13 @@ a work-in-progress.
   
 
 
-
+RISC-V
+
+  
+The riscv*-*-* targets now require GNU binutils version 2.30
+or later, to support new assembly instructions produced by GCC.
+  
+
 
 
 

[committed][wwwdocs] GCC 10: Reorder S/390 target alphabetically

[Maciej W. Rozycki via Gcc-patches]

---
Hi,

 Committed as obvious.

  Maciej
---
 htdocs/gcc-10/changes.html | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index 1e1eaf43..3d8e0ba9 100644
--- a/htdocs/gcc-10/changes.html
+++ b/htdocs/gcc-10/changes.html
@@ -725,12 +725,12 @@ a work-in-progress.
   
 
 
-
-
 
 
 
 
+
+
 
 
 

[PATCH] doc: RISC-V: Update binutils requirement to 2.30

[Maciej W. Rozycki via Gcc-patches]

Complement commit bfe78b08471f ("RISC-V: Using fmv.x.w/fmv.w.x rather 
than fmv.x.s/fmv.s.x") and document a binutils 2.30 requirement in the 
installation manual, matching the addition of fmv.x.w/fmv.w.x mnemonics 
to GAS.

gcc/
* doc/install.texi (Specific) 
: Update binutils requirement to 
2.30.
---
On Wed, 18 Mar 2020, Maciej W. Rozycki wrote:

> > >  At the very least I think we ought to document the minimum version of
> > > binutils now required by GCC for RISC-V support.
> > 
> > The new opcodes were added to gas in 2017-09-27, and I can't recommend
> > using any binutils or gcc release that predates 2018-01-01 because
> > they are all known to be buggy, or incompatible with the current ISA
> > definition.  So I don't see any need for a configure test for this
> > change.  Anyone missing the new instructions in gas has bigger
> > problems to worry about.
[...]
>  Our installation instructions state binutils 2.28 as the requirement for 
> all the RISC-V targets, however the change for fmv.x.w/fmv.w.x instruction 
> support was only added in the binutils 2.30 development cycle.

 Here's the resulting change.  Verified with `make info' and `make check'.
OK to apply?

  Maciej
---
 gcc/doc/install.texi |   12 
 1 file changed, 4 insertions(+), 8 deletions(-)

gcc-riscv-binutils-version.diff
Index: gcc/gcc/doc/install.texi
===
--- gcc.orig/gcc/doc/install.texi
+++ gcc/gcc/doc/install.texi
@@ -4545,8 +4545,7 @@ This configuration is intended for embed
 @heading riscv32-*-elf
 The RISC-V RV32 instruction set.
 This configuration is intended for embedded systems.
-This (and all other RISC-V) targets are supported upstream as of the
-binutils 2.28 release.
+This (and all other RISC-V) targets require the binutils 2.30 release.
 
 @html
 
@@ -4554,8 +4553,7 @@ binutils 2.28 release.
 @anchor{riscv32-x-linux}
 @heading riscv32-*-linux
 The RISC-V RV32 instruction set running GNU/Linux.
-This (and all other RISC-V) targets are supported upstream as of the
-binutils 2.28 release.
+This (and all other RISC-V) targets require the binutils 2.30 release.
 
 @html
 
@@ -4564,8 +4562,7 @@ binutils 2.28 release.
 @heading riscv64-*-elf
 The RISC-V RV64 instruction set.
 This configuration is intended for embedded systems.
-This (and all other RISC-V) targets are supported upstream as of the
-binutils 2.28 release.
+This (and all other RISC-V) targets require the binutils 2.30 release.
 
 @html
 
@@ -4573,8 +4570,7 @@ binutils 2.28 release.
 @anchor{riscv64-x-linux}
 @heading riscv64-*-linux
 The RISC-V RV64 instruction set running GNU/Linux.
-This (and all other RISC-V) targets are supported upstream as of the
-binutils 2.28 release.
+This (and all other RISC-V) targets require the binutils 2.30 release.
 
 @html
 

Re: [PATCH v3 4/4] libgomp/test: Remove a build sysroot fix regression

[Maciej W. Rozycki via Gcc-patches]

On Thu, 26 Mar 2020, Chung-Lin Tang wrote:

> > Changes from v2:
> > 
> > - Do not use `--tool_exec' with AM_RUNTESTFLAGS.
> > 
> > - Move the definition of GCC_UNDER_TEST from
> >testsuite/libgomp-test-support.exp to
> >testsuite/libgomp-site-extra.exp.
> 
> Hi Maciej,
> sorry, I didn't notice you were blocked on input from us.

 No worries; I'm glad you are all right!

> I tested our testing with this patch and can confirm it works for us; 
> didn't notice any breakage.

 Thank you!  I'll be posting a revised series shortly for a libffi update; 
no change to the libgomp part on this occasion now that it works for you.

  Maciej

Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

[Maciej W. Rozycki via Gcc-patches]

On Mon, 30 Mar 2020, Mike Stump wrote:

> > I have actually considered extracting the bits already, but I hesitated 
> > putting that forward that as having looked at the part that we require I 
> > have thought it to be very messy:
> 
> Yeah, sometimes it's like that.  I glanced at the work, if you think 
> it's a step forward, I'd support importing it, my take, import from 
> upstream isn't a bad way to go.

 So I looked into it some more and interestingly enough all the commits I 
have listed in the previous message have already been made as of libffi's 
commit c82cc159426d ("Merge pull request #166 from chevah/master") that we 
imported with our commit b1760f7f915a ("Merge libffi to upstream commit 
c82cc159426d8d4402375fa1ae3f045b9cf82e16").

 That merge was extensively discussed starting from: 
, however no 
mention was as to why the local.exp part had been omitted from the merge.  
Perhaps it was considered not necessary for integrating with the GCC tree, 
although I would think that keeping the divergence to the minimum is 
preferable, and it looks to me that our requirements boil down essentially 
to adding multilib support and making some further, minor tweaks to match 
the rest of the tree.  Whereas the diff between the Makefile systems as at 
libffi's commit c82cc159426d and our commit b1760f7f915a looks to me quite 
substantial.

 Perhaps Richard will be able to provide some input here.

> > So I am in favour of retaining the mechanism rather than using my earlier 
> > proposal, however I'm in two minds as to how to proceed.  Integrating the 
> > change as it is will make us having clutter left in the tree after `make 
> > distclean', but we can do it right away.
> 
> I'd support this.  distclean is one rm -rf away from being clean enough.  
> I'd not let that gate or hold up the import.

 While doing further work on finding a solution that would be acceptable 
(to me anyway), I actually found two further upstream libffi commits:

- commit 6b6df1a7bb37 ("[PATCH] Adds `local.exp` to CLEANFILES"),

- commit 6cf0dea78a5a ("[PATCH] Change CLEANFILES to DISTCLEANFILES"),

both beyond our merge point, that fix this shortcoming.  Still there's no 
Makefile dependency, so if configure.ac is patched or local.exp removed, 
then it is not regenerated, and all that would not be required if what 
automake provides was used.

> If there is work that we want that's more to do with in tree building 
> and testing (sys root fun, multilibs), while not ideal, we can deviate 
> from upstream to support that.  Though, if there is a way to naturally 
> support that, that upstream can accept, that'd be better.

 I did some work now to reduce the divergence and will be posting patch 
series shortly to both upstream libffi and our version.  Hopefully that'll 
be acceptable, at least the initial, minimal change from each series.

 If not, for a reference, here's an updated version of the patch I posted 
last time.  It includes the two upstream libffi commits I have mentioned 
above.

 Let's see how it goes.  Thank you for your input.

  Maciej
---
 libffi/Makefile.am   |3 +++
 libffi/Makefile.in   |4 
 libffi/configure |5 +
 libffi/configure.ac  |5 +
 libffi/testsuite/Makefile.am |2 ++
 libffi/testsuite/Makefile.in |1 +
 6 files changed, 20 insertions(+)

gcc-test-libffi-cc-for-target.diff
Index: gcc/libffi/Makefile.am
===
--- gcc.orig/libffi/Makefile.am
+++ gcc/libffi/Makefile.am
@@ -15,6 +15,9 @@ EXTRA_DIST = LICENSE ChangeLog.v1 Change
libffi.xcodeproj/project.pbxproj\
libtool-ldflags
 
+# local.exp is generated by configure
+DISTCLEANFILES = local.exp
+
 # Automake Documentation:
 # If your package has Texinfo files in many directories, you can use the
 # variable TEXINFO_TEX to tell Automake where to find the canonical
Index: gcc/libffi/Makefile.in
===
--- gcc.orig/libffi/Makefile.in
+++ gcc/libffi/Makefile.in
@@ -454,6 +454,9 @@ EXTRA_DIST = LICENSE ChangeLog.v1 Change
libtool-ldflags
 
 
+# local.exp is generated by configure
+DISTCLEANFILES = local.exp
+
 # Automake Documentation:
 # If your package has Texinfo files in many directories, you can use the
 # variable TEXINFO_TEX to tell Automake where to find the canonical
@@ -1674,6 +1677,7 @@ installcheck: installcheck-recursive
-rm -f src/x86/$(am__dirstamp)
-rm -f src/xtensa/$(DEPDIR)/$(am__dirstamp)
-rm -f src/xtensa/$(am__dirstamp)
+   -test -z "$(DISTCLEANFILES)" || rm -f $(DISTCLEANFILES)
 
 maintainer-clean-generic:
@echo "This command is intended for maintainers to use"
Index: gcc/libffi/configure
===
--- gcc.orig/libffi/configure
+++ 

Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

[Maciej W. Rozycki via Gcc-patches]

On Tue, 24 Mar 2020, Mike Stump wrote:

> > Have we made any conclusions WRT the way to move forward with this stuff?  
> > Things remain broken and I'd prefer to get the issues off the plate while 
> > the stuff is hot, or at least mildly warm.  I'm about to get distracted 
> > with other work.
> 
> It's unfortunate that upstream has anything that prevents it from us 
> just importing it all and calling it done.
> 
> Anyway, if you see a path forward for grabbing all the Makefile/config 
> stuff and leaving the abi changing stuff out, and just important that, 
> we can do a partial import.  I say this without reviewing the diffs from 
> upstream and how many there are and what's in them.  I'm hoping things 
> are nicely segregated and reasonably small otherwise.

 Thank you for your input.

 I have actually considered extracting the bits already, but I hesitated 
putting that forward that as having looked at the part that we require I 
have thought it to be very messy: the .exp file is handcrafted with an 
inline piece of scriptery buried in `configure.ac' and never cleaned, not 
even with `make distclean', nor equipped with any Makefile dependencies.  
Clearly it must have been written by someone who hasn't been accustomed to 
working with GNU autotools.

 The ultimate change is very small, but it has only been created gradually 
with four commits in the upstream libffi repository, none of which applies
cleanly to ours and most of which include unrelated stuff.  They are:

- commit 8308984e479e ("[PATCH] Make sure we're running dejagnu tests with 
  the right compiler."),

- commit 2d9b3939751b ("[PATCH] Fix for closures with sunpro compiler"),

- commit 0c3824702d3d ("[PATCH] Always set CC_FOR_TARGET for dejagnu, to 
  make the testsuite respect $CC"),

- commit 7d698125b1f0 ("[PATCH] Use the proper C++ compiler to run C++ 
  tests") -- not yet needed in our libffi version as no tests are marked
  C++.

-- at .  I have now extracted the 
relevant bits from the four commits and the result is below.

 I have pushed it through my testing and it fixes the test results just 
like my earlier proposal; in fact libffi.log files are the same modulo 
timestamps and one number that is randomly generated.  It is worth noting 
however that the multilib discovery logic in `libffi-init' has not been 
updated unlike with my proposal and it continues using the compiler 
hardcoded within rather than one set with CC_FOR_TARGET/CXX_FOR_TARGET.

 That uses a mechanism (*_FOR_TARGET, interpreted within `target_compile') 
different from one we do (*_UNDER_TEST, used to set `compiler=' in the 
invocation of `target_compile'), and ignores TOOL_EXECUTABLE altogether.  
It makes sense however semantically to me for a standalone library test 
suite to consider the compiler just a tool in testing and not the object 
under test.  Plus it makes it easy to define compilers for the various 
languages required.

 So I am in favour of retaining the mechanism rather than using my earlier 
proposal, however I'm in two minds as to how to proceed.  Integrating the 
change as it is will make us having clutter left in the tree after `make 
distclean', but we can do it right away.  Fixing the problems with the 
change upstream in libffi first and then merging the result back into our 
tree will avoid getting the clutter, but will likely take time.

 I'll sleep on it yet, and meanwhile I'll be happy to hear suggestions.  
I have also cc-ed the libffi mailing list for a possible further insight.

  Maciej

---
 libffi/configure |5 +
 libffi/configure.ac  |5 +
 libffi/testsuite/Makefile.am |2 ++
 libffi/testsuite/Makefile.in |1 +
 4 files changed, 13 insertions(+)

Index: gcc/libffi/configure
===
--- gcc.orig/libffi/configure
+++ gcc/libffi/configure
@@ -14961,6 +14961,11 @@ _ACEOF
 
 
 
+cat > local.exp <&5
 $as_echo_n "checking whether to enable maintainer-specific portions of 
Makefiles... " >&6; }
Index: gcc/libffi/configure.ac
===
--- gcc.orig/libffi/configure.ac
+++ gcc/libffi/configure.ac
@@ -61,6 +61,11 @@ AC_PROG_LIBTOOL
 # Test for 64-bit build.
 AC_CHECK_SIZEOF([size_t])
 
+cat > local.exp <

Re: [PATCH] RISC-V: Using fmv.x.w/fmv.w.x rather than fmv.x.s/fmv.s.x

[Maciej W. Rozycki via Gcc-patches]

On Wed, 18 Mar 2020, Jim Wilson wrote:

> >  The new mnemonics have been supported by GAS for a little while now and
> > the old ones have been retained, however this is still a change that
> > breaks backwards compatibility.  So I wonder if we shouldn't have an
> > autoconf test included for this feature, and either resort to wiring GCC
> > to keep using the old mnemonics or bail out at GCC compilation time if
> > GAS is found not to handle the new ones.
> >
> >  At the very least I think we ought to document the minimum version of
> > binutils now required by GCC for RISC-V support.
> 
> The new opcodes were added to gas in 2017-09-27, and I can't recommend
> using any binutils or gcc release that predates 2018-01-01 because
> they are all known to be buggy, or incompatible with the current ISA
> definition.  So I don't see any need for a configure test for this
> change.  Anyone missing the new instructions in gas has bigger
> problems to worry about.

 Fair enough.

> As for the minimum binutils version, I would strongly recommend the
> most recent one released before the gcc release that you are using,
> though it is likely than anything back to 2018-01-01 would work, just
> not as well.

 For me it's not an issue as I actively work on the toolchain and keep all 
checkouts close to the current tips of the respective master branches.  
However binary package maintainers or end users of the toolchain need to 
know the dependencies between component versions whether they want to 
build the pieces from sources or combine them from prebuilt packages.

 Our installation instructions state binutils 2.28 as the requirement for 
all the RISC-V targets, however the change for fmv.x.w/fmv.w.x instruction 
support was only added in the binutils 2.30 development cycle.

  Maciej

Re: [PATCH v3 2/4] libffi/test: Fix compilation for build sysroot

[Maciej W. Rozycki via Gcc-patches]

On Fri, 28 Feb 2020, H.J. Lu wrote:

> > > >  However that hack has been actually made to address this very problem
> > > > discussed with this submission, so why not simply sync our copy of 
> > > > libffi
> > > > with the upstream version?  Then we can decide if changing the hack into
> > > > something cleaner is worth the hassle.
> > >
> > > I'd love to sync with upstream libffi.  In fact, I have done it on my
> > > users/hjl/cet/master
> > > branch:
> > >
> > > https://gitlab.com/x86-gcc/gcc/-/commit/9090e840b8464ce0f684e305eb75ff4655d05deb
> > I think we'd like to update as well, but isn't there an ABI change in libffi
> > that has to be fixed first?
> 
> Libffi 3.4 ABI was changed to support CET.  But it isn't the first
> time ABI change for libffi,

 Have we made any conclusions WRT the way to move forward with this stuff?  
Things remain broken and I'd prefer to get the issues off the plate while 
the stuff is hot, or at least mildly warm.  I'm about to get distracted 
with other work.

  Maciej

Re: [PATCH] RISC-V: Using fmv.x.w/fmv.w.x rather than fmv.x.s/fmv.s.x

[Maciej W. Rozycki via Gcc-patches]

On Tue, 18 Feb 2020, Kito Cheng wrote:

>  - fmv.x.s/fmv.s.x renamed to fmv.x.w/fmv.w.x in the latest RISC-V ISA
>manual.

 The new mnemonics have been supported by GAS for a little while now and 
the old ones have been retained, however this is still a change that 
breaks backwards compatibility.  So I wonder if we shouldn't have an 
autoconf test included for this feature, and either resort to wiring GCC 
to keep using the old mnemonics or bail out at GCC compilation time if 
GAS is found not to handle the new ones.

 At the very least I think we ought to document the minimum version of 
binutils now required by GCC for RISC-V support.

  Maciej