[gcc r12-10633] [PR115565] cse: Don't use a valid regno for non-register in comparison_qty

[Maciej W. Rozycki via Gcc-cvs]

https://gcc.gnu.org/g:8d8f804b18e4a38671957b3e4c239ef625506317

commit r12-10633-g8d8f804b18e4a38671957b3e4c239ef625506317
Author: Maciej W. Rozycki 
Date:   Sat Jun 29 23:26:55 2024 +0100

[PR115565] cse: Don't use a valid regno for non-register in comparison_qty

Use INT_MIN rather than -1 in `comparison_qty' where a comparison is not
with a register, because the value of -1 is actually a valid reference
to register 0 in the case where it has not been assigned a quantity.

Using -1 makes `REG_QTY (REGNO (folded_arg1)) == ent->comparison_qty'
comparison in `fold_rtx' to incorrectly trigger in rare circumstances
and return true for a memory reference, making CSE consider a comparison
operation to evaluate to a constant expression and consequently make the
resulting code incorrectly execute or fail to execute conditional
blocks.

This has caused a miscompilation of rwlock.c from LinuxThreads for the
`alpha-linux-gnu' target, where `rwlock->__rw_writer != thread_self ()'
expression (where `thread_self' returns the thread pointer via a PALcode
call) has been decided to be always true (with `ent->comparison_qty'
using -1 for a reference to to `rwlock->__rw_writer', while register 0
holding the thread pointer retrieved by `thread_self') and code for the
false case has been optimized away where it mustn't have, causing
program lockups.

The issue has been observed as a regression from commit 08a692679fb8
("Undefined cse.c behaviour causes 3.4 regression on HPUX"),
, and up to
commit 932ad4d9b550 ("Make CSE path following use the CFG"),
, where CSE
has been restructured sufficiently for the issue not to trigger with the
original reproducer anymore.  However the original bug remains and can
trigger, because `comparison_qty' will still be assigned -1 for a memory
reference and the `reg_qty' member of a `cse_reg_info_table' entry will
still be assigned -1 for register 0 where the entry has not been
assigned a quantity, e.g. at initialization.

Use INT_MIN then as noted above, so that the value remains negative, for
consistency with the REGNO_QTY_VALID_P macro (even though not used on
`comparison_qty'), and then so that it should not ever match a valid
negated register number, fixing the regression with commit 08a692679fb8.

gcc/
PR rtl-optimization/115565
* cse.cc (record_jump_cond): Use INT_MIN rather than -1 for
`comparison_qty' if !REG_P.

(cherry picked from commit 69bc5fb97dc3fada81869e00fa65d39f7def6acf)

Diff:
---
 gcc/cse.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/cse.cc b/gcc/cse.cc
index ca53974810ed..32e8ea79980d 100644
--- a/gcc/cse.cc
+++ b/gcc/cse.cc
@@ -239,7 +239,7 @@ static int next_qty;
the constant being compared against, or zero if the comparison
is not against a constant.  `comparison_qty' holds the quantity
being compared against when the result is known.  If the comparison
-   is not with a register, `comparison_qty' is -1.  */
+   is not with a register, `comparison_qty' is INT_MIN.  */
 
 struct qty_table_elem
 {
@@ -4068,7 +4068,7 @@ record_jump_cond (enum rtx_code code, machine_mode mode, 
rtx op0,
   else
{
  ent->comparison_const = op1;
- ent->comparison_qty = -1;
+ ent->comparison_qty = INT_MIN;
}
 
   return;

[gcc r13-8932] [PR115565] cse: Don't use a valid regno for non-register in comparison_qty

[Maciej W. Rozycki via Gcc-cvs]

https://gcc.gnu.org/g:4ce7c81212c7819dfe6dbbe2399220fb12da6d71

commit r13-8932-g4ce7c81212c7819dfe6dbbe2399220fb12da6d71
Author: Maciej W. Rozycki 
Date:   Sat Jun 29 23:26:55 2024 +0100

[PR115565] cse: Don't use a valid regno for non-register in comparison_qty

Use INT_MIN rather than -1 in `comparison_qty' where a comparison is not
with a register, because the value of -1 is actually a valid reference
to register 0 in the case where it has not been assigned a quantity.

Using -1 makes `REG_QTY (REGNO (folded_arg1)) == ent->comparison_qty'
comparison in `fold_rtx' to incorrectly trigger in rare circumstances
and return true for a memory reference, making CSE consider a comparison
operation to evaluate to a constant expression and consequently make the
resulting code incorrectly execute or fail to execute conditional
blocks.

This has caused a miscompilation of rwlock.c from LinuxThreads for the
`alpha-linux-gnu' target, where `rwlock->__rw_writer != thread_self ()'
expression (where `thread_self' returns the thread pointer via a PALcode
call) has been decided to be always true (with `ent->comparison_qty'
using -1 for a reference to to `rwlock->__rw_writer', while register 0
holding the thread pointer retrieved by `thread_self') and code for the
false case has been optimized away where it mustn't have, causing
program lockups.

The issue has been observed as a regression from commit 08a692679fb8
("Undefined cse.c behaviour causes 3.4 regression on HPUX"),
, and up to
commit 932ad4d9b550 ("Make CSE path following use the CFG"),
, where CSE
has been restructured sufficiently for the issue not to trigger with the
original reproducer anymore.  However the original bug remains and can
trigger, because `comparison_qty' will still be assigned -1 for a memory
reference and the `reg_qty' member of a `cse_reg_info_table' entry will
still be assigned -1 for register 0 where the entry has not been
assigned a quantity, e.g. at initialization.

Use INT_MIN then as noted above, so that the value remains negative, for
consistency with the REGNO_QTY_VALID_P macro (even though not used on
`comparison_qty'), and then so that it should not ever match a valid
negated register number, fixing the regression with commit 08a692679fb8.

gcc/
PR rtl-optimization/115565
* cse.cc (record_jump_cond): Use INT_MIN rather than -1 for
`comparison_qty' if !REG_P.

(cherry picked from commit 69bc5fb97dc3fada81869e00fa65d39f7def6acf)

Diff:
---
 gcc/cse.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/cse.cc b/gcc/cse.cc
index 8fbda4ecc867..9a399e312f17 100644
--- a/gcc/cse.cc
+++ b/gcc/cse.cc
@@ -239,7 +239,7 @@ static int next_qty;
the constant being compared against, or zero if the comparison
is not against a constant.  `comparison_qty' holds the quantity
being compared against when the result is known.  If the comparison
-   is not with a register, `comparison_qty' is -1.  */
+   is not with a register, `comparison_qty' is INT_MIN.  */
 
 struct qty_table_elem
 {
@@ -4068,7 +4068,7 @@ record_jump_cond (enum rtx_code code, machine_mode mode, 
rtx op0,
   else
{
  ent->comparison_const = op1;
- ent->comparison_qty = -1;
+ ent->comparison_qty = INT_MIN;
}
 
   return;

[gcc r14-10485] [PR115565] cse: Don't use a valid regno for non-register in comparison_qty

[Maciej W. Rozycki via Gcc-cvs]

https://gcc.gnu.org/g:323d010fa5d433e6eb5ec5124544f19fb4b4eee6

commit r14-10485-g323d010fa5d433e6eb5ec5124544f19fb4b4eee6
Author: Maciej W. Rozycki 
Date:   Sat Jun 29 23:26:55 2024 +0100

[PR115565] cse: Don't use a valid regno for non-register in comparison_qty

Use INT_MIN rather than -1 in `comparison_qty' where a comparison is not
with a register, because the value of -1 is actually a valid reference
to register 0 in the case where it has not been assigned a quantity.

Using -1 makes `REG_QTY (REGNO (folded_arg1)) == ent->comparison_qty'
comparison in `fold_rtx' to incorrectly trigger in rare circumstances
and return true for a memory reference, making CSE consider a comparison
operation to evaluate to a constant expression and consequently make the
resulting code incorrectly execute or fail to execute conditional
blocks.

This has caused a miscompilation of rwlock.c from LinuxThreads for the
`alpha-linux-gnu' target, where `rwlock->__rw_writer != thread_self ()'
expression (where `thread_self' returns the thread pointer via a PALcode
call) has been decided to be always true (with `ent->comparison_qty'
using -1 for a reference to to `rwlock->__rw_writer', while register 0
holding the thread pointer retrieved by `thread_self') and code for the
false case has been optimized away where it mustn't have, causing
program lockups.

The issue has been observed as a regression from commit 08a692679fb8
("Undefined cse.c behaviour causes 3.4 regression on HPUX"),
, and up to
commit 932ad4d9b550 ("Make CSE path following use the CFG"),
, where CSE
has been restructured sufficiently for the issue not to trigger with the
original reproducer anymore.  However the original bug remains and can
trigger, because `comparison_qty' will still be assigned -1 for a memory
reference and the `reg_qty' member of a `cse_reg_info_table' entry will
still be assigned -1 for register 0 where the entry has not been
assigned a quantity, e.g. at initialization.

Use INT_MIN then as noted above, so that the value remains negative, for
consistency with the REGNO_QTY_VALID_P macro (even though not used on
`comparison_qty'), and then so that it should not ever match a valid
negated register number, fixing the regression with commit 08a692679fb8.

gcc/
PR rtl-optimization/115565
* cse.cc (record_jump_cond): Use INT_MIN rather than -1 for
`comparison_qty' if !REG_P.

(cherry picked from commit 69bc5fb97dc3fada81869e00fa65d39f7def6acf)

Diff:
---
 gcc/cse.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/cse.cc b/gcc/cse.cc
index c53deecbe547..65794ac5f2ca 100644
--- a/gcc/cse.cc
+++ b/gcc/cse.cc
@@ -239,7 +239,7 @@ static int next_qty;
the constant being compared against, or zero if the comparison
is not against a constant.  `comparison_qty' holds the quantity
being compared against when the result is known.  If the comparison
-   is not with a register, `comparison_qty' is -1.  */
+   is not with a register, `comparison_qty' is INT_MIN.  */
 
 struct qty_table_elem
 {
@@ -4058,7 +4058,7 @@ record_jump_cond (enum rtx_code code, machine_mode mode, 
rtx op0, rtx op1)
   else
{
  ent->comparison_const = op1;
- ent->comparison_qty = -1;
+ ent->comparison_qty = INT_MIN;
}
 
   return;

[gcc r15-1881] ada: Make the names of uninstalled cross-gnattools consistent across builds

[Maciej W. Rozycki via Gcc-cvs]

https://gcc.gnu.org/g:d364c4ced8823bc41fda84f182e1d64e7870549e

commit r15-1881-gd364c4ced8823bc41fda84f182e1d64e7870549e
Author: Maciej W. Rozycki 
Date:   Sun Jul 7 15:04:51 2024 +0100

ada: Make the names of uninstalled cross-gnattools consistent across builds

We suffer from an inconsistency in the names of uninstalled gnattools
executables in cross-compiler configurations.  The cause is a recipe we
have:

ada.all.cross:
for tool in $(ADA_TOOLS) ; do \
  if [ -f $$tool$(exeext) ] ; \
  then \
$(MV) $$tool$(exeext) $$tool-cross$(exeext); \
  fi; \
done

the intent of which is to give the names of gnattools executables the
'-cross' suffix, consistently with the compiler drivers: 'gcc-cross',
'g++-cross', etc.

A problem with the recipe is that this 'make' target is called too early
in the build process, before gnattools have been made.  Consequently no
renames happen and owing to that they are conditional on the presence of
the individual executables the recipe succeeds doing nothing.

However if a target is requested later on such as 'make pdf' that does
not cause gnattools executables to be rebuilt, then 'ada.all.cross' does
succeed in renaming the executables already present in the build tree.
Then if the 'gnat' testsuite is run later on which expects non-suffixed
'gnatmake' executable, it does not find the 'gnatmake-cross' executable
in the build tree and may either catastrophically fail or incorrectly
use a system-installed copy of 'gnatmake'.

Of course if a target is requested such as `make all' that does cause
gnattools executables to be rebuilt, then both suffixed and non-suffixed
uninstalled executables result.

Fix the problem by moving the renaming of gnattools to a separate 'make'
recipe, pasted into a new 'gnattools-cross-mv' target and the existing
legacy 'cross-gnattools' target.  Then invoke the new target explicitly
from the 'gnattools-cross' recipe in gnattools/.

Update the test harness accordingly, so that suffixed gnattools are used
in cross-compilation testsuite runs.

gcc/ada/
* gcc-interface/Make-lang.in (ada.all.cross): Move recipe to...
(GNATTOOLS_CROSS_MV): ... this new variable.
(cross-gnattools): Paste it here.
(gnattools-cross-mv): New target.

gnattools/
* Makefile.in (gnattools-cross): Also build 'gnattools-cross-mv'
in GCC_DIR.

gcc/testsuite/
* lib/gnat.exp (local_find_gnatmake, find_gnatclean): Use
'-cross' suffix where testing a cross-compiler.

Diff:
---
 gcc/ada/gcc-interface/Make-lang.in | 19 ---
 gcc/testsuite/lib/gnat.exp | 22 ++
 gnattools/Makefile.in  |  1 +
 3 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/gcc/ada/gcc-interface/Make-lang.in 
b/gcc/ada/gcc-interface/Make-lang.in
index ebf1f70de78..b2841104651 100644
--- a/gcc/ada/gcc-interface/Make-lang.in
+++ b/gcc/ada/gcc-interface/Make-lang.in
@@ -780,6 +780,7 @@ regnattools:
 cross-gnattools: force
$(MAKE) -C ada $(ADA_TOOLS_FLAGS_TO_PASS) gnattools1-re
$(MAKE) -C ada $(ADA_TOOLS_FLAGS_TO_PASS) gnattools2
+   $(GNATTOOLS_CROSS_MV)
 
 canadian-gnattools: force
$(MAKE) -C ada $(ADA_TOOLS_FLAGS_TO_PASS) gnattools1-re
@@ -795,19 +796,23 @@ gnatlib gnatlib-sjlj gnatlib-zcx gnatlib-shared: force
   FORCE_DEBUG_ADAFLAGS="$(FORCE_DEBUG_ADAFLAGS)" \
   $@
 
+gnattools-cross-mv:
+   $(GNATTOOLS_CROSS_MV)
+
+GNATTOOLS_CROSS_MV=\
+  for tool in $(ADA_TOOLS) ; do \
+if [ -f $$tool$(exeext) ] ; \
+then \
+  $(MV) $$tool$(exeext) $$tool-cross$(exeext); \
+fi; \
+  done
+
 # use only for native compiler
 gnatlib_and_tools: gnatlib gnattools
 
 # Build hooks:
 
 ada.all.cross:
-   for tool in $(ADA_TOOLS) ; do \
- if [ -f $$tool$(exeext) ] ; \
- then \
-   $(MV) $$tool$(exeext) $$tool-cross$(exeext); \
- fi; \
-   done
-
 ada.start.encap:
 ada.rest.encap:
 ada.man:
diff --git a/gcc/testsuite/lib/gnat.exp b/gcc/testsuite/lib/gnat.exp
index 471f83e9844..c278cb7f044 100644
--- a/gcc/testsuite/lib/gnat.exp
+++ b/gcc/testsuite/lib/gnat.exp
@@ -199,12 +199,19 @@ proc prune_gnat_output { text } {
 # which prevent multilib from working, so define a new one.
 
 proc local_find_gnatmake {} {
+global target_triplet
 global tool_root_dir
+global host_triplet
 
 if ![is_remote host] {
-set file [lookfor_file $tool_root_dir gnatmake]
+   if { "$host_triplet" == "$target_triplet" } {
+   set gnatmake gnatmake
+   } else {
+   set gnatmake gnatmake-cross
+   }
+   set file [lookfor_file $tool_root_dir $gnatmake]
 if { $file == "" } {
-   

[gcc r15-1724] [PR115565] cse: Don't use a valid regno for non-register in comparison_qty

[Maciej W. Rozycki via Gcc-cvs]

https://gcc.gnu.org/g:69bc5fb97dc3fada81869e00fa65d39f7def6acf

commit r15-1724-g69bc5fb97dc3fada81869e00fa65d39f7def6acf
Author: Maciej W. Rozycki 
Date:   Sat Jun 29 23:26:55 2024 +0100

[PR115565] cse: Don't use a valid regno for non-register in comparison_qty

Use INT_MIN rather than -1 in `comparison_qty' where a comparison is not
with a register, because the value of -1 is actually a valid reference
to register 0 in the case where it has not been assigned a quantity.

Using -1 makes `REG_QTY (REGNO (folded_arg1)) == ent->comparison_qty'
comparison in `fold_rtx' to incorrectly trigger in rare circumstances
and return true for a memory reference, making CSE consider a comparison
operation to evaluate to a constant expression and consequently make the
resulting code incorrectly execute or fail to execute conditional
blocks.

This has caused a miscompilation of rwlock.c from LinuxThreads for the
`alpha-linux-gnu' target, where `rwlock->__rw_writer != thread_self ()'
expression (where `thread_self' returns the thread pointer via a PALcode
call) has been decided to be always true (with `ent->comparison_qty'
using -1 for a reference to to `rwlock->__rw_writer', while register 0
holding the thread pointer retrieved by `thread_self') and code for the
false case has been optimized away where it mustn't have, causing
program lockups.

The issue has been observed as a regression from commit 08a692679fb8
("Undefined cse.c behaviour causes 3.4 regression on HPUX"),
, and up to
commit 932ad4d9b550 ("Make CSE path following use the CFG"),
, where CSE
has been restructured sufficiently for the issue not to trigger with the
original reproducer anymore.  However the original bug remains and can
trigger, because `comparison_qty' will still be assigned -1 for a memory
reference and the `reg_qty' member of a `cse_reg_info_table' entry will
still be assigned -1 for register 0 where the entry has not been
assigned a quantity, e.g. at initialization.

Use INT_MIN then as noted above, so that the value remains negative, for
consistency with the REGNO_QTY_VALID_P macro (even though not used on
`comparison_qty'), and then so that it should not ever match a valid
negated register number, fixing the regression with commit 08a692679fb8.

gcc/
PR rtl-optimization/115565
* cse.cc (record_jump_cond): Use INT_MIN rather than -1 for
`comparison_qty' if !REG_P.

Diff:
---
 gcc/cse.cc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/cse.cc b/gcc/cse.cc
index c53deecbe54..65794ac5f2c 100644
--- a/gcc/cse.cc
+++ b/gcc/cse.cc
@@ -239,7 +239,7 @@ static int next_qty;
the constant being compared against, or zero if the comparison
is not against a constant.  `comparison_qty' holds the quantity
being compared against when the result is known.  If the comparison
-   is not with a register, `comparison_qty' is -1.  */
+   is not with a register, `comparison_qty' is INT_MIN.  */
 
 struct qty_table_elem
 {
@@ -4058,7 +4058,7 @@ record_jump_cond (enum rtx_code code, machine_mode mode, 
rtx op0, rtx op1)
   else
{
  ent->comparison_const = op1;
- ent->comparison_qty = -1;
+ ent->comparison_qty = INT_MIN;
}
 
   return;

[gcc r15-844] VAX/doc: Fix issues with FP format option documentation

[Maciej W. Rozycki via Gcc-cvs]

https://gcc.gnu.org/g:314448fc65f40c98ee8bc02dfb54ea49d2f2c60d

commit r15-844-g314448fc65f40c98ee8bc02dfb54ea49d2f2c60d
Author: Maciej W. Rozycki 
Date:   Mon May 27 05:07:32 2024 +0100

VAX/doc: Fix issues with FP format option documentation

Use the correct names of the D_floating and G_floating data formats as
per the VAX ISA nomenclature[1].  Document the `-md', `-md-float', and
`-mg-float' options.

References:

[1] DEC STD 032-0 "VAX Architecture Standard", Digital Equipment
Corporation, A-DS-EL-00032-00-0 Rev J, December 15, 1989, Section
1.2 "Data Types", pp. 1-7, 1-9

gcc/
* doc/invoke.texi (Option Summary): Add `-md', `-md-float', and
`-mg-float' options.  Reorder, matching VAX Options.
(VAX Options): Reword the description of `-mg' option.  Add
`-md', `-md-float', and `-mg-float' options.

Diff:
---
 gcc/doc/invoke.texi | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index c9d8f6b37b6..2cba380718b 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -1429,7 +1429,7 @@ See RS/6000 and PowerPC Options.
 -mbig-switch}
 
 @emph{VAX Options}
-@gccoptlist{-mg  -mgnu  -munix  -mlra}
+@gccoptlist{-munix  -mgnu  -md  -md-float  -mg  -mg-float  -mlra}
 
 @emph{Visium Options}
 @gccoptlist{-mdebug  -msim  -mfpu  -mno-fpu  -mhard-float  -msoft-float
@@ -34129,9 +34129,19 @@ ranges.
 Do output those jump instructions, on the assumption that the
 GNU assembler is being used.
 
+@opindex md
+@opindex md-float
+@item -md
+@itemx -md-float
+Use the D_floating data format for double-precision floating-point numbers
+instead of G_floating.
+
 @opindex mg
+@opindex mg-float
 @item -mg
-Output code for G-format floating-point numbers instead of D-format.
+@itemx -mg-float
+Use the G_floating data format for double-precision floating-point numbers
+instead of D_floating.
 
 @opindex mlra
 @opindex mno-lra

[gcc r15-843] vax: Fix descriptions of the FP format options [PR79646]

[Maciej W. Rozycki via Gcc-cvs]

https://gcc.gnu.org/g:a7f6543f21303583356fd2d2d1805bffbecc1bc5

commit r15-843-ga7f6543f21303583356fd2d2d1805bffbecc1bc5
Author: Abe Skolnik 
Date:   Mon May 27 05:07:32 2024 +0100

vax: Fix descriptions of the FP format options [PR79646]

Replace "Target" with "Generate" consistently and place a hyphen in
"double-precision" as this is used as an adjective here.

gcc/ChangeLog:

PR target/79646
* config/vax/vax.opt (md, md-float, mg, mg-float): Correct
descriptions.

Diff:
---
 gcc/config/vax/vax.opt | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/gcc/config/vax/vax.opt b/gcc/config/vax/vax.opt
index 2cc66e543fe..fa2be78e9fa 100644
--- a/gcc/config/vax/vax.opt
+++ b/gcc/config/vax/vax.opt
@@ -20,19 +20,19 @@
 
 md
 Target RejectNegative InverseMask(G_FLOAT)
-Target DFLOAT double precision code.
+Generate DFLOAT double-precision code.
 
 md-float
 Target RejectNegative InverseMask(G_FLOAT)
-Target DFLOAT double precision code.
+Generate DFLOAT double-precision code.
 
 mg
 Target RejectNegative Mask(G_FLOAT)
-Generate GFLOAT double precision code.
+Generate GFLOAT double-precision code.
 
 mg-float
 Target RejectNegative Mask(G_FLOAT)
-Generate GFLOAT double precision code.
+Generate GFLOAT double-precision code.
 
 mgnu
 Target RejectNegative InverseMask(UNIX_ASM)

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: RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0'

[Maciej W. Rozycki via Gcc]

On Tue, 14 Jul 2020, Richard Biener wrote:

> > >  Arguably this might probably be called a deficiency in libgcc, however
> > > the objects are built with `-fexceptions -fnon-call-exceptions'
> >
> > I consider that broken.  It doesn't make any sense to build a lowlevel
> > runtime library like libgcc with exceptions.
> 
> Indeed - you only need to be able to unwind through those, so
> -fasynchronous-unwind-tables should be used.

 This is libgcc's default however, only overridden for a couple of ARM 
targets, for the very reason to avoid pulling in the unwinder, according 
to the associated comments.  This was added with commit fc6aa0a98a0c some 
3 months before commit b932f770f70d added `-fasynchronous-unwind-tables' 
as a supported compiler option, all back in 2001, so we've had it for 
quite a while now.

 The RISC-V target doesn't appear to produce any division overflow traps, 
which would necessarily have to be arranged by a software convention like 
with, say, the MIPS target, as the relevant hardware instructions do not 
trigger an exception under any conditions.

 By switching to `-fasynchronous-unwind-tables' the ARM override can also 
go presumably, right?

  Maciej

RISC-V: `ld.so' fails linking against `libgcc.a' built at `-O0' (was: Re: [PATCH] Allow memset local PLT reference for RISC-V.)

[Maciej W. Rozycki via Gcc]

On Sun, 12 Jul 2020, Maciej W. Rozycki wrote:

>  I don't think we have a way to redirect the reference to `__GI_memset'.

 Additionally, I need to mention that where `libgcc.a' has been built at 
`-O0', RV32 `ld.so' fails linking due to unresolved `malloc' and `free' 
references from numerous `libgcc.a' objects.  This is because those 
objects pull in the exception unwinder; specifically `__divdi3', 
`__moddi3', and `__umoddi3' all include a call to `_Unwind_Resume' each.

 Arguably this might probably be called a deficiency in libgcc, however 
the objects are built with `-fexceptions -fnon-call-exceptions' and at 
`-O0' GCC might not be able to see through code that no exception may 
happen there.  Therefore I am not sure offhand if this needs to be 
considered a GCC or glibc bug.

  Maciej

.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function 
`init_dwarf_reg_size_table':
.../src/gcc/libgcc/unwind-dw2.c:1572: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function `uw_init_context_1':
.../src/gcc/libgcc/unwind-dw2.c:1613: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function `uw_install_context_1':
.../src/gcc/libgcc/unwind-dw2.c:1694: undefined reference to `free'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../src/gcc/libgcc/unwind-dw2.c:1711: undefined reference to `free'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function 
`_Unwind_ForcedUnwind_Phase2':
.../src/gcc/libgcc/unwind.inc:152: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../src/gcc/libgcc/unwind.inc:163: undefined reference to `malloc'
.../bin/../lib/gcc/riscv64-linux-gnu/10.0.1/../../../../riscv64-linux-gnu/bin/ld:
 .../obj/glibc-boot/ilp32/elf/librtld.os: in function `_Unwind_DeleteException':
.../src/gcc/libgcc/unwind.inc:281: undefined reference to `free'
collect2: error: ld returned 1 exit status
Makefile:554: recipe for target '.../obj/glibc-boot/ilp32/elf/ld.so' failed
make[2]: *** [.../obj/glibc-boot/ilp32/elf/ld.so] Error 1

Re: dejagnu version update? [CORRECTION: not a regression in DejaGnu; GDB testsuite bug]

[Maciej W. Rozycki via Gcc]

[cc-ing Joel as the originator, and ]

On Tue, 9 Jun 2020, Jacob Bachmeyer wrote:

> >> I ran a quick bisection and the culprit turned out to be:
> >>
> >> ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit
> >> commit ba60272a5ac6f6a7012acca03f596a6ed003f044
> >> Author: Jacob Bachmeyer 
> >> Date:   Mon May 25 08:40:46 2020 -0600
> >>
> >>  Establish a default C compiler by evaluating [find_gcc] if no 
> >> other compiler is given.
> >>
> >>  So this regression has to be fixed before any new release is made.
> >
> > I will look into this.  So far, I have confirmed that the problem does 
> > occur and that setting the "compiler" board_info key in 
> > baseboards/unix.exp seems to avoid it.  It looks like the default is 
> > not being selected in all cases where it should be used.  I still need 
> > to find the exact problem to write a regression test to isolate this 
> > bug and make it stay squashed.
> 
> After further efforts, and a few hours wasted trying to figure out why 
> additional tracing code added to default_target_compile was not 
> producing output, I eventually decided to just make 
> default_target_compile throw a Tcl error -- and I did not get a Tcl 
> error when running the tests...
> 
> That is "very interesting" and a quick grep -R reveals the culprit:  the 
> GDB testsuite is overriding default_target_compile in 
> gdb/testsuite/lib/future.exp.  Comments indicate that that file was 
> intended to temporarily bundle certain features with the GDB testsuite 
> that had not yet been merged into upstream DejaGnu -- in 2004.  Now 
> DejaGnu core is continuing to develop, leaving the old code copied into 
> the GDB testsuite broken, and making this NOTOURBUG.

 Well, as the name suggests (regrettably there's no adequate documentation 
there) this procedure is there to be overridden.  The way it's done in GDB 
might perhaps be non-standard, as the standard way AFAICS would be by 
providing a `gdb_compile' handler, but I think this is tangential, and the 
chosen solution is there possibly because DejaGnu had no `${tool}_compile' 
knob back then (I haven't checked).  That does not really matter though, 
as the net effect would be the same.

> In short, this is not a regression in DejaGnu; this is code duplicated 
> into the GDB testsuite that was slated for removal from that location 
> years ago and needs to be removed from the GDB testsuite, or at least 
> made conditional on running under a version of DejaGnu old enough to 
> require it, if such versions are still supported for running the GDB 
> testsuite.  If that code has added features not present in upstream 
> DejaGnu over the years, now is the time to get those patches in.

 Well, it clearly is a functional regression as the interface has changed, 
even if not a formal one, and I would consider it a release stopper.

 As it happens there are about 2 users of DejaGnu there, which means any 
fatal regression would have been easily caught in the course of change 
verification (and running binutils/GDB and GCC test suites natively is 
about as easy as it can be: `configure && make && make check'), and indeed 
should have, and then sorted with the respective communities if indeed the 
interface change is unavoidable, with a transition period so that the 
users can prepare changes to their frameworks, including backports to 
various release branches if applicable, before the old interface is 
removed from DejaGnu.  My suggestion would be to revert the change, get 
the details sorted with GDB people and only reapply it when all parties 
are ready. 

 Anyway, I have completed the verification I have volunteered to do and 
therefore I'm done with my part.  Please sort it between the communities.  
I have other stuff to do I have committed to.

  Maciej

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Tue, 26 May 2020, Rob Savoye wrote:

> >  I'll run some RISC-V remote GCC/GDB testing and compare results for 
> > DejaGnu 1.6/1.6.1 vs trunk.  It will take several days though, as it takes 
> > many hours to go through these testsuite runs.
> 
>   That'd be great. I'd rather push out a stable release, than have to
> fix bugs right after it gets released.

 I have completed GCC and GDB testing now with the `riscv64-linux-gnu' 
target and the `x86_64-linux-gnu' host.

 GDB results obtained with real hardware are looking good, with the usual 
fluctuation due to intermittent failures caused by races in test cases:

@@ -63343,8 +63344,8 @@

=== gdb Summary ===

-# of expected passes   59902
-# of unexpected failures   778
+# of expected passes   59900
+# of unexpected failures   781
 # of unexpected successes  2
 # of expected failures 48
 # of unknown successes 5

 Similarly GCC test results taken with QEMU in the user emulation mode 
show a couple of intermittent discrepancies (not present on a rerun) 
within the libgo testsuite only:

@@ -912,12 +912,12 @@ Schedule of variations:

 Running target qemu-user-lp64d
 Running .../libgo/testsuite/libgo.testmain/testmain.exp ...
-FAIL: database/sql
+PASS: database/sql

=== libgo Summary ===

-# of unexpected failures   1
-Test run by macro on Thu Jun  4 04:29:42 2020
+# of expected passes   1
+Test run by macro on Wed Jun  3 01:38:10 2020
 Target is riscv64-unknown-linux-gnu
 Host   is riscv64-unknown-linux-gnu
 Build  is x86_64-pc-linux-gnu

and:

@@ -2239,12 +2239,12 @@ Schedule of variations:

 Running target qemu-user-lp64d
 Running .../libgo/testsuite/libgo.testmain/testmain.exp ...
-PASS: net/http/pprof
+FAIL: net/http/pprof

=== libgo Summary ===

-# of expected passes   1
-Test run by macro on Thu Jun  4 02:42:17 2020
+# of unexpected failures   1
+Test run by macro on Tue Jun  2 23:54:18 2020
 Target is riscv64-unknown-linux-gnu
 Host   is riscv64-unknown-linux-gnu
 Build  is x86_64-pc-linux-gnu

(the testsuite is run in a peculiar manner in the remote case, hence the 
individual per-test summaries) and are otherwise identical.

 However native `x86_64-linux-gnu' GDB testing does not work at all; all 
it gets is:

get_compiler_info: default_target_compile: No compiler to compile with
get_compiler_info: compiler_info not provided
get_compiler_info: got unexpected diagnostics
get_compiler_info: unknown
gdb compile failed, default_target_compile: No compiler to compile with

Conversely all things being equal DejaGnu 1.6 finds native `/usr/bin/gcc' 
just fine:

get_compiler_info: set compiler_info "unknown"
get_compiler_info: set compiler_info [join {gcc 9 2 1} -]
get_compiler_info: gcc-9-2-1

and in the verbose mode also:

Checking /home/macro/bin for gcc
Checking /home/macro/bin for gcc
Checking /usr/local/bin for gcc
Checking /usr/bin for gcc
Choosing /usr/bin/gcc

I ran a quick bisection and the culprit turned out to be:

ba60272a5ac6f6a7012acca03f596a6ed003f044 is the first bad commit
commit ba60272a5ac6f6a7012acca03f596a6ed003f044
Author: Jacob Bachmeyer 
Date:   Mon May 25 08:40:46 2020 -0600

 Establish a default C compiler by evaluating [find_gcc] if no other 
compiler is given.

 So this regression has to be fixed before any new release is made.

 HTH,

  Maciej

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Tue, 26 May 2020, Rob Savoye wrote:

>   I processed the patch backlog for DejaGnu, and have gone through the
> bug list. It'd be nice if somebody could try master with a more complex
> environment, etc... if I'm going to push out a release. For cross
> testing all I have is a PI and QEMU.

 I'll run some RISC-V remote GCC/GDB testing and compare results for 
DejaGnu 1.6/1.6.1 vs trunk.  It will take several days though, as it takes 
many hours to go through these testsuite runs.

  Maciej

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Sat, 16 May 2020, Rob Savoye wrote:

> >  Overall perhaps a patch management system might be good having to make 
> > chasing patches easier, such as patchwork, and we already use Git, so we 
> 
>  As an old GNU project, we're required to use what the FSF prefers,
> which is on savannah. https://savannah.gnu.org/patch/?group=dejagnu,

 Hmm, as a youngster who's been around for twenty-something years only (my 
first patch was for glibc, back in 1998) I haven't even heard of this 
patch service before.  It doesn't appear linked to our mailing list either 
and instead you need to go through the hoops of a web interface (and open 
an account first) to submit a change.

> Our
> bug tracker is there their too. We've used that for a long time. Yes,
> patches in email are harder to track.

 That's precisely what patchworks is for, which has been used to various 
extent for the GNU C library, GCC and GDB already.  All of which projects 
are of similar vintage to DejaGnu and I reckon rather important for the 
GNU project.  Given that our main patch submission channel is e-mail, 
what's the point in using a system that does not accept one?

  Maciej

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Thu, 14 May 2020, Rob Savoye wrote:

>   Right now working through patches is probably more important. :-)
> There's zero patches on the DejaGnu savannah site, so I'd ask anybody to
> submit them so I don't have to dig them out of email archives.

 I have reposted the single patch I have had outstanding.  Please review.  
I have a couple of new ones down the line.

 Overall perhaps a patch management system might be good having to make 
chasing patches easier, such as patchwork, and we already use Git, so we 
are set for using that tool.  Siddhesh has recently installed version 2.0 
for glibc and migrated all the old patchwork data, and might be able to 
give us some input.

 Siddhesh, would you care to tell us how much effort it would be to set up 
fresh patchwork?  The patch traffic is surely much lower with DejaGnu than 
it is with glibc, and there would be no data to migrate (but we might want 
to feed a couple of months' back worth of mailing list traffic).

 Just a suggestion.  See:  to get a 
feel.

  Maciej

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Thu, 14 May 2020, Rob Savoye wrote:

>   Personally, I tried to find funding to refactor DejaGnu in Python,
> since Tcl is unmaintained too, but nobody was interested.

 Thank you for your contribution to DejaGnu over the years and for your 
input on this occasion.

 However it does not appear to me to be right that Tcl is not maintained, 
as a stable 8.6.10 release has been made as recently as half a year ago. 
And then current development appears ongoing, ferociously indeed, with the 
last check in literally today (barring my time zone), as indicated here: 
.

 Other than that what would be the technical advantage from rewriting 
DejaGnu in Python (/me asking as a Python ignoramus)?

  Maciej

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

Hi Rainer,

> >  Versions 1.6 and 1.6.1 seem ubiquitous and coincidentally earlier this 
> > very week I have been chasing a phenomenon with Expect's `wait' semantics 
> > causing a reliable hang in remote testing if `ssh' to the target board 
> > stops responding for whatever reason.  I have come up with a solution 
> > (that I'd be happy to upstream, except that DejaGNU maintenance seems to 
> > have been dead for like a year now), which I have also confirmed to be 
> > required with current DejaGNU Git master so it must be a different one, 
> > and I would like to know how it might be related to the bug you mention.
> 
> I believe it's
> 
> commit b4e61f85ae26d215e8ad5d6e9fcda6c0745096a1
> Author: Richard Biener 
> Date:   Fri Jul 6 21:35:29 2018 +1000
> 
> * lib/remote.exp (close_wait_program): Use separate kill command
> for each pid.
> 
> Richard pointed me at the 1.6.2 release when I mentioned the issue
> somewhere on a gcc list, and it's his patch, so it's likely to be the
> one.

 Thanks; I have seen it and even backported it to my test environment.  
It does not affect my scenario at all however as the kill commands get 
killed just as Expect's `wait' succeeds and then the subsequent TCL 
`close' invocation made on the pipeline in the caller hangs on wait(2) 
indefinitely.  So it's all the same area, but different modes of failure.  
I'll wrap up on my patches then and post them soon.

> It went into DejaGnu immediately after the 1.6.1. release ;-(

 Well, 1.6.2 has been out for a while now so I guess distros might well 
upgrade.  I think it's one of those packages there is not need with to 
wait for code to settle, as it's for core developers' use.  OTOH it's not 
a big deal for the intended users to check out and install the top of 
trunk version anyway.

  Maciej

Re: dejagnu version update?

[Maciej W. Rozycki via Gcc]

On Wed, 13 May 2020, Rainer Orth wrote:

> > I'm in favour of requiring 1.5.3 or later, so 1.6 would be OK for me.
> 
> If we go beyond 1.5.x, we need to go all the way up to 1.6.2: 1.6 and
> 1.6.1 have an ugly bug that can miss timeouts, causing tests to hang
> indefinitely until one manually kills them.

 Would you mind sharing a reference such as a DejaGNU Git commit ID of the 
fix for the bug you mean?

 Versions 1.6 and 1.6.1 seem ubiquitous and coincidentally earlier this 
very week I have been chasing a phenomenon with Expect's `wait' semantics 
causing a reliable hang in remote testing if `ssh' to the target board 
stops responding for whatever reason.  I have come up with a solution 
(that I'd be happy to upstream, except that DejaGNU maintenance seems to 
have been dead for like a year now), which I have also confirmed to be 
required with current DejaGNU Git master so it must be a different one, 
and I would like to know how it might be related to the bug you mention.

  Maciej

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: Help, Where I can find proper libtool version?

[Maciej W. Rozycki via Gcc]

On Wed, 15 Apr 2020, 易会战 via Gcc wrote:

> I am trying to add a library into gcc source code tree. The gcc source 
> have used libtool 2.2.7a 1.1334. but I cannot find the version.

 It is "libtool (GNU libtool 1.3134 2009-11-30) 2.2.7a" AFAICT, that is 
1.3134 rather than 1.1334.  I take it there has been a typo there.

> So after runing autoreconf and make , I get "libtool: 
> Versionmismatcherror.".It is a curious version, the gnu 
> mirrors have no such version.

 It is a repository snapshot, there has been no such release.  For 1.3134 
you need to check out commit 2c9c38d8a12e ("Please C++ compilers when 
calling strrchr.") from the libtool Git repository.

 FWIW I think it would be good having a tarball of this snapshot, 
preferably made with `make dist' so that all the generated pieces are 
there, hosted somewhere, such as  or maybe 
 (there might be a better place).  Moving on to an 
actual libtool release, preferably less than 10 years old, would I think 
be a viable alternative too.

 HTH,

  Maciej

Re: Not usable email content encoding

[Maciej W. Rozycki via Gcc]

On Tue, 14 Apr 2020, Christopher Faylor wrote:

> >I think that means that dmarc_moderation_action: "Munge From" can
> >simply be switched off then (at least I don't see which other headers
> >e.g.  gcc@ is rewriting that would cause DMARC to scream; and if there
> >are any, then it would be better to disable those as well.  Same with
> >any potential body rewriting that might still happen).
> 
> It can't be switched off if we strip html attachments.

 Based on current usage would instead plain rejecting e-mail with any HTML 
attachments be a viable way to move forward?

> >I would offer help testing that this doesn't cause delivery issues, e.g. 
> >on some test email list, but it seems none of my domains is DMARC-infected 
> >:-/
> 
> Nevertheless, offers of help are appreciated (and rare).  :-)

 I'm in a `p=none' domain at this e-mail address, so technically I would 
say it has been quite reasonably configured and therefore none of our 
people should have to choose between suffering from `From' munging or 
persuading the postmasters to change the configuration or switching to 
another MTA for mailing list submissions.

 Therefore I'd be happy to participate in testing a solution for disabling 
`From' munging for `p=none' domains.

  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: Not usable email content encoding

[Maciej W. Rozycki via Gcc]

On Tue, 7 Apr 2020, Christopher Faylor wrote:

> >In a way that's amusing and just reinforces my p.o.v. that DMARC is 
> >bollocks.
> 
> Not that it means anything but I agree 100%.
> 
> It's like whoever made the "standard" just said "to hell with mailing
> lists".

 Maybe they just didn't know of their existence.  Seriously.

 I have actually been more and more astonished recently with the discovery 
of people living in some kind of a parallel reality of Internet standards 
and practices, who never heard of solutions and habits I have known since 
forever and considered obvious.  Especially as we now have an entirely new 
generation of IT people who never actually saw the Internet like it was 
back in 1990s and earlier on, simply because it was before they were born.

 Consequently things that used to work since forever start breaking and 
people you report such breakage to have no clue as to what you're talking 
about.

  Maciej

Re: Not usable email content encoding

[Maciej W. Rozycki via Gcc]

On Tue, 7 Apr 2020, Christopher Faylor wrote:

> >Can we please switch it off?  It's not like we really had a problem before 
> >the switch to mailman.
> 
> You can't really make statements like this which imply that you are
> aware of "problems" on sourceware when you're not a sourceware
> administrator.
> 
> We actually were munging the From on the old server and we were getting
> an increasing number of complaints to postmaster that people weren't
> receiving mail.

 Hmm, methinks these really ought to be bounced to the postmaster of the 
broken receiving site.  It is not that sourceware has been actually doing 
anything specific to make the recipient's MTA refuse e-mail.  Even if some 
spam prevention has been installed to block some kind of e-mail, whoever 
requested some kind of e-mail traffic need to have a way to whitelist the 
traffic requested, and I believe all list server software provides means 
for the recipient to identify the source, such as a `List-ID' header or 
suchlike.

  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: Not usable email content encoding

[Maciej W. Rozycki via Gcc]

Hi Frank,

> >  I am fairly sure it breaks `git am' too, requiring a `From' override in 
> > the change description for author attribution in patch application to work 
> > reliably (I tend to work on my outbox when applying my own patches, so I 
> > avoid this issue, but I am sure the issue will hit someone sooner or 
> > later).
> 
> That part is at least pretty easy: use
>   git format-patch --from "Real Name git "
> which will then force a second fake From: header into the body of
> the commit email, where git-am can find it.

 Sure, there are various ways to deal with that, both on the sender's and 
the receiver's side, however all require a manual intervention and are 
therefore prone to a human error.  Which will obviously happen sooner or 
later.

> > This is all silly, requiring the SMTP envelope sender to match the `From' 
> > header breaks even the most basic e-mail mechanisms like the use of a 
> > `.forward' file.  [...]
> 
> Unfortunately naive .forward based forwarding looks exactly like faked
> or spam email to a third party MTAs.

 And can certainly score a positive though not a definite rating in spam 
qualification.  I don't think we ought to encourage bad IT management 
practices by trying to adapt to them too hard and hurting ourselves (our 
workflow) in the process.

> > How come the Linux kernel people who do e-mail patch management on a
> > vastly larger scale than we do, both in terms of traffic and the
> > number of mailing list subscribers, can get away without all these
> > odd quirks in their list server management?  [...]
> 
> I'm not sure, but their mails tend to be laden with a vast number of
> Cc:'s, which bypass mailing list reflectors.

 Surely all the bots receive messages via a mailing list subscription 
though.  Cc's are solely for maintainers, reviewers or other explicitly 
interested parties.  Some maintainers actually require submissions to come 
via the relevant mailing list rather directly to them.  Somehow it works.

 Thank you for your input regardless!

  Maciej

Re: Not usable email content encoding

[Maciej W. Rozycki via Gcc]

On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote:

> > Out of curiousity, is this rewriting you are talking about the cause for a
> > lot of mails showing up as "From: GCC List" rather than their real senders?
> > This has become very annoying recently.
> 
> Yes, for emails from domains with declared interest in email
> cleanliness, via DMARC records in DNS.  We have observed mail
> -blocked- at third parties, even just days ago, when we failed to
> sufficiently authenticate outgoing reflected emails.
> 
> AIUI, all this effort is driven by wanting to defeat not just spammers
> but also real security problems like phishing enabled by forgery,
> including specifically the From: header.

 And it has actually broken GCC's patchwork: 
, which I used to use to 
track my patches.  Now I cannot do that anymore as patches submitted from 
my WDC address are marked as coming from , which 
obviously means they are not attributed to me.

 I am fairly sure it breaks `git am' too, requiring a `From' override in 
the change description for author attribution in patch application to work 
reliably (I tend to work on my outbox when applying my own patches, so I 
avoid this issue, but I am sure the issue will hit someone sooner or 
later).

 And of course I cannot use the `macro@' pattern anymore to select mailing 
list messages in my inbox that I sent myself.  Frankly it's the least of 
the annoyances, but still, and they all add up.

 This is all silly, requiring the SMTP envelope sender to match the `From' 
header breaks even the most basic e-mail mechanisms like the use of a 
`.forward' file.  Can we please do something about it?  Is functional 
regression the price we absolutely need to pay for progress?

 How come the Linux kernel people who do e-mail patch management on a 
vastly larger scale than we do, both in terms of traffic and the number of 
mailing list subscribers, can get away without all these odd quirks in 
their list server management?  Perhaps it would be good asking them how 
they handle their stuff?

  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