Re: [PATCH] expansion: FIx up infinite recusion due to double-word modulo optimization

[Richard Biener]

On Tue, 1 Dec 2020, Jakub Jelinek wrote:

> Hi!
> 
> Jeff has reported that my earlier patch broke rl78-elf, e.g. with
> unsigned short foo (unsigned short x) { return x % 7; }
> when compiled with -O2 -mg14.  The problem is that rl78 is a BITS_PER_WORD
> == 8 target which doesn't have 8-bit modulo or divmod optab, but has instead
> 16-bit divmod, so my patch attempted to optimize it, then called
> expand_divmod to do 8-bit modulo and that in turn tried to do 16-bit modulo
> again.
> 
> The following patch fixes it in two ways.
> One is to not perform the optimization when we have {u,s}divmod_optab
> handler for the double-word mode, in that case it is IMHO better to just
> do whatever we used to do before.  This alone should fix the infinite
> recursion.  But I'd be afraid some other target might have similar problem
> and might not have a divmod pattern, but only say a library call.
> So the patch also introduces a methods argument to expand_divmod such that
> normally we allow everything that was allowed before (using libcalls and
> widening), but when called from these expand_doubleword*mod routines we
> restrict it to no widening and no libcalls.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Thanks,
Richard.

> 2020-12-01  Jakub Jelinek  
> 
>   * expmed.h (expand_divmod): Only declare if GCC_OPTABS_H is defined.
>   Add enum optabs_method argument defaulted to OPTAB_LIB_WIDEN.
>   * expmed.c: Include expmed.h after optabs.h.
>   (expand_divmod): Add methods argument, if it is not OPTAB_{,LIB_}WIDEN,
>   don't choose a wider mode, and pass it to other calls instead of
>   hardcoded OPTAB_LIB_WIDEN.  Avoid emitting libcalls if not
>   OPTAB_LIB or OPTAB_LIB_WIDEN.
>   * optabs.c: Include expmed.h after optabs.h.
>   (expand_doubleword_mod, expand_doubleword_divmod): Pass OPTAB_DIRECT
>   as last argument to expand_divmod.
>   (expand_binop): Punt if {s,u}divmod_optab has handler for double-word
>   int_mode.
>   * expr.c: Include expmed.h after optabs.h.
>   * explow.c: Include expmed.h after optabs.h.
> 
> --- gcc/expmed.h.jj   2020-01-12 11:54:36.56545 +0100
> +++ gcc/expmed.h  2020-12-01 19:25:55.117128688 +0100
> @@ -716,8 +716,10 @@ extern rtx expand_variable_shift (enum t
> rtx, tree, rtx, int);
>  extern rtx expand_shift (enum tree_code, machine_mode, rtx, poly_int64, rtx,
>int);
> +#ifdef GCC_OPTABS_H
>  extern rtx expand_divmod (int, enum tree_code, machine_mode, rtx, rtx,
> -   rtx, int);
> +   rtx, int, enum optab_methods = OPTAB_LIB_WIDEN);
> +#endif
>  #endif
>  
>  extern void store_bit_field (rtx, poly_uint64, poly_uint64,
> --- gcc/expmed.c.jj   2020-08-10 10:44:20.659560695 +0200
> +++ gcc/expmed.c  2020-12-01 19:30:40.993941266 +0100
> @@ -31,8 +31,8 @@ along with GCC; see the file COPYING3.
>  #include "predict.h"
>  #include "memmodel.h"
>  #include "tm_p.h"
> -#include "expmed.h"
>  #include "optabs.h"
> +#include "expmed.h"
>  #include "regs.h"
>  #include "emit-rtl.h"
>  #include "diagnostic-core.h"
> @@ -4193,7 +4193,8 @@ expand_sdiv_pow2 (scalar_int_mode mode,
>  
>  rtx
>  expand_divmod (int rem_flag, enum tree_code code, machine_mode mode,
> -rtx op0, rtx op1, rtx target, int unsignedp)
> +rtx op0, rtx op1, rtx target, int unsignedp,
> +enum optab_methods methods)
>  {
>machine_mode compute_mode;
>rtx tquotient;
> @@ -4299,17 +4300,22 @@ expand_divmod (int rem_flag, enum tree_c
>optab2 = (op1_is_pow2 ? optab1
>   : (unsignedp ? udivmod_optab : sdivmod_optab));
>  
> -  FOR_EACH_MODE_FROM (compute_mode, mode)
> -if (optab_handler (optab1, compute_mode) != CODE_FOR_nothing
> - || optab_handler (optab2, compute_mode) != CODE_FOR_nothing)
> -  break;
> -
> -  if (compute_mode == VOIDmode)
> -FOR_EACH_MODE_FROM (compute_mode, mode)
> -  if (optab_libfunc (optab1, compute_mode)
> -   || optab_libfunc (optab2, compute_mode))
> +  if (methods == OPTAB_WIDEN || methods == OPTAB_LIB_WIDEN)
> +{
> +  FOR_EACH_MODE_FROM (compute_mode, mode)
> +  if (optab_handler (optab1, compute_mode) != CODE_FOR_nothing
> +   || optab_handler (optab2, compute_mode) != CODE_FOR_nothing)
>   break;
>  
> +  if (compute_mode == VOIDmode && methods == OPTAB_LIB_WIDEN)
> + FOR_EACH_MODE_FROM (compute_mode, mode)
> +   if (optab_libfunc (optab1, compute_mode)
> +   || optab_libfunc (optab2, compute_mode))
> + break;
> +}
> +  else
> +compute_mode = mode;
> +
>/* If we still couldn't find a mode, use MODE, but expand_binop will
>   probably die.  */
>if (compute_mode == VOIDmode)
> @@ -4412,8 +4418,7 @@ expand_divmod (int rem_flag, enum tree_c
>   remainder
> = expand_binop (int_mode, and_optab, op0,
> 

Re: [PATCH] expansion: Further improve double-word modulo, division and divmod [PR97459]

[Richard Biener]

On Tue, 1 Dec 2020, Jakub Jelinek wrote:

> Hi!
> 
> The following patch implements what Thomas wrote about, in particular
> that we can handle also double-word divison by the constants for which
> the earlier patch optimized modulo (if it would be otherwise a library
> call) and that we can also easily handle such constants shifted to the left.
> Unfortunately, seems CSE isn't able to optimize away the two almost
> identical sequences (one to compute remainder, one to compute quotient),
> probably because of the ADD_OVERFLOW introduced jumps, so the patch also
> adjusts expand_DIVMOD.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

OK.

Richard.

> 2020-12-01  Jakub Jelinek  
> 
>   PR rtl-optimization/97459
>   * optabs.h (expand_doubleword_divmod): Declare.
>   * optabs.c (expand_doubleword_divmod): New function.
>   (expand_binop): Use it.
>   * internal-fn.c (expand_DIVMOD): Likewise.
> 
>   * gcc.target/i386/pr97282.c (foo): Use 123456 divisor instead of
>   10.
>   * gcc.dg/pr97459-1.c (TESTS): Add tests for 10, 12 and
>   6144.
>   * gcc.dg/pr97459-2.c (TESTS): Likewise.
>   * gcc.dg/pr97459-3.c: New test.
>   * gcc.dg/pr97459-4.c: New test.
>   * gcc.dg/pr97459-5.c: New test.
>   * gcc.dg/pr97459-6.c: New test.
> 
> --- gcc/optabs.h.jj   2020-12-01 13:19:12.831127718 +0100
> +++ gcc/optabs.h  2020-12-01 17:40:08.783137431 +0100
> @@ -183,6 +183,8 @@ extern bool force_expand_binop (machine_
>   enum optab_methods);
>  extern rtx expand_vector_broadcast (machine_mode, rtx);
>  
> +extern rtx expand_doubleword_divmod (machine_mode, rtx, rtx, rtx *, bool);
> +
>  /* Generate code for a simple binary or unary operation.  "Simple" in
> this case means "can be unambiguously described by a (mode, code)
> pair and mapped to a single optab."  */
> --- gcc/optabs.c.jj   2020-12-01 16:25:01.56773 +0100
> +++ gcc/optabs.c  2020-12-01 18:11:12.878230572 +0100
> @@ -1118,6 +1118,99 @@ expand_doubleword_mod (machine_mode mode
>  }
>return NULL_RTX;
>  }
> +
> +/* Similarly to the above function, but compute both quotient and remainder.
> +   Quotient can be computed from the remainder as:
> +   rem = op0 % op1;  // Handled using expand_doubleword_mod
> +   quot = (op0 - rem) * inv; // inv is multiplicative inverse of op1 modulo
> +  // 2 * BITS_PER_WORD
> +
> +   We can also handle cases where op1 is a multiple of power of two constant
> +   and constant handled by expand_doubleword_mod.
> +   op11 = 1 << __builtin_ctz (op1);
> +   op12 = op1 / op11;
> +   rem1 = op0 % op12;  // Handled using expand_doubleword_mod
> +   quot1 = (op0 - rem1) * inv; // inv is multiplicative inverse of op12 
> modulo
> +// 2 * BITS_PER_WORD
> +   rem = (quot1 % op11) * op12 + rem1;
> +   quot = quot1 / op11;  */
> +
> +rtx
> +expand_doubleword_divmod (machine_mode mode, rtx op0, rtx op1, rtx *rem,
> +   bool unsignedp)
> +{
> +  *rem = NULL_RTX;
> +
> +  /* Negative dividend should have been optimized into positive,
> + similarly modulo by 1 and modulo by power of two is optimized
> + differently too.  */
> +  if (INTVAL (op1) <= 1 || pow2p_hwi (INTVAL (op1)))
> +return NULL_RTX;
> +
> +  rtx op11 = const1_rtx;
> +  rtx op12 = op1;
> +  if ((INTVAL (op1) & 1) == 0)
> +{
> +  int bit = ctz_hwi (INTVAL (op1));
> +  op11 = GEN_INT (HOST_WIDE_INT_1 << bit);
> +  op12 = GEN_INT (INTVAL (op1) >> bit);
> +}
> +
> +  rtx rem1 = expand_doubleword_mod (mode, op0, op12, unsignedp);
> +  if (rem1 == NULL_RTX)
> +return NULL_RTX;
> +
> +  int prec = 2 * BITS_PER_WORD;
> +  wide_int a = wide_int::from (INTVAL (op12), prec + 1, UNSIGNED);
> +  wide_int b = wi::shifted_mask (prec, 1, false, prec + 1);
> +  wide_int m = wide_int::from (wi::mod_inv (a, b), prec, UNSIGNED);
> +  rtx inv = immed_wide_int_const (m, mode);
> +
> +  rtx_insn *last = get_last_insn ();
> +  rtx quot1 = expand_simple_binop (mode, MINUS, op0, rem1,
> +NULL_RTX, unsignedp, OPTAB_DIRECT);
> +  if (quot1 == NULL_RTX)
> +return NULL_RTX;
> +
> +  quot1 = expand_simple_binop (mode, MULT, quot1, inv,
> +NULL_RTX, unsignedp, OPTAB_DIRECT);
> +  if (quot1 == NULL_RTX)
> +return NULL_RTX;
> +
> +  if (op11 != const1_rtx)
> +{
> +  rtx rem2 = expand_divmod (1, TRUNC_MOD_EXPR, mode, quot1, op11,
> + NULL_RTX, unsignedp);
> +  if (rem2 == NULL_RTX)
> + return NULL_RTX;
> +
> +  rem2 = expand_simple_binop (mode, MULT, rem2, op12, NULL_RTX,
> +   unsignedp, OPTAB_DIRECT);
> +  if (rem2 == NULL_RTX)
> + return NULL_RTX;
> +
> +  rem2 = expand_simple_binop (mode, PLUS, rem2, rem1, NULL_RTX,
> +   unsignedp, OPTAB_DIRECT);
> +  if (rem2 == NULL_RTX)
> + return N

Re: [PATCH] Remove misleading debug line entries

[Richard Biener]

On Tue, 1 Dec 2020, Bernd Edlinger wrote:

> Hi!
> 
> 
> This removes gimple_debug stmts without block info after a
> NULL INLINE_ENTRY.
> 
> The line numbers from these stmts are from the inline function,
> but since the inline function is completely optimized away,
> there will be no DW_TAG_inlined_subroutine so the debugger has
> no callstack available at this point, and therefore those
> line table entries are not helpful to the user.
> 
> 2020-11-20  Bernd Edlinger  
> 
>   * cfgexpand.c (expand_gimple_basic_block): Remove debug_begin_stmts
>   following a removed debug_inline_entry.
> 
> 
> Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
> Is it OK for trunk?

So are those visited by clear_unused_block_pointer?  If so wouldn't
it be more appropriate to remove those there, when we elide the
inlined block scope?

Thanks,
Richard.

> 
> Thanks
> Bernd.
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)

Re: [PATCH] IBM Z: Use llihf and oilf to load large immediates into GPRs

[Andreas Krebbel via Gcc-patches]

On 12/2/20 2:34 AM, Ilya Leoshkevich wrote:
> Bootstrapped and regtesed on s390x-redhat-linux.  There are slight
> improvements in all SPEC benchmarks, no regressions that could not be
> "fixed" by adding nops.  Ok for master?
> 
> 
> 
> Currently GCC loads large immediates into GPRs from the literal pool,
> which is not as efficient as loading two halves with llihf and oilf.
> 
> gcc/ChangeLog:
> 
> 2020-11-30  Ilya Leoshkevich  
> 
>   * config/s390/s390-protos.h (s390_const_int_pool_entry_p): New
>   function.
>   * config/s390/s390.c (s390_const_int_pool_entry_p): New
>   function.
>   * config/s390/s390.md: Add define_peephole2 that produces llihf
>   and oilf.
> 
> gcc/testsuite/ChangeLog:
> 
> 2020-11-30  Ilya Leoshkevich  
> 
>   * gcc.target/s390/load-imm64-1.c: New test.
>   * gcc.target/s390/load-imm64-2.c: New test.
> ---
>  gcc/config/s390/s390-protos.h|  1 +
>  gcc/config/s390/s390.c   | 31 
>  gcc/config/s390/s390.md  | 22 ++
>  gcc/testsuite/gcc.target/s390/load-imm64-1.c | 10 +++
>  gcc/testsuite/gcc.target/s390/load-imm64-2.c | 10 +++
>  5 files changed, 74 insertions(+)
>  create mode 100644 gcc/testsuite/gcc.target/s390/load-imm64-1.c
>  create mode 100644 gcc/testsuite/gcc.target/s390/load-imm64-2.c
> 
> diff --git a/gcc/config/s390/s390-protos.h b/gcc/config/s390/s390-protos.h
> index ad2f7f77c18..eb10c3f4bbb 100644
> --- a/gcc/config/s390/s390-protos.h
> +++ b/gcc/config/s390/s390-protos.h
> @@ -135,6 +135,7 @@ extern void s390_split_access_reg (rtx, rtx *, rtx *);
>  extern void print_operand_address (FILE *, rtx);
>  extern void print_operand (FILE *, rtx, int);
>  extern void s390_output_pool_entry (rtx, machine_mode, unsigned int);
> +extern bool s390_const_int_pool_entry_p (rtx, HOST_WIDE_INT *);
>  extern int s390_label_align (rtx_insn *);
>  extern int s390_agen_dep_p (rtx_insn *, rtx_insn *);
>  extern rtx_insn *s390_load_got (void);
> diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
> index 02f18366aa1..e3d68d3543b 100644
> --- a/gcc/config/s390/s390.c
> +++ b/gcc/config/s390/s390.c
> @@ -9400,6 +9400,37 @@ s390_output_pool_entry (rtx exp, machine_mode mode, 
> unsigned int align)
>  }
>  }
>  
> +/* Return true if MEM refers to an integer constant in the literal pool.  If
> +   VAL is not nullptr, then also fill it with the constant's value.  */
> +
> +bool
> +s390_const_int_pool_entry_p (rtx mem, HOST_WIDE_INT *val)
> +{
> +  /* Try to match the following:
> + - (mem (unspec [(symbol_ref) (reg)] UNSPEC_LTREF)).
> + - (mem (symbol_ref)).  */
> +
> +  if (!MEM_P (mem))
> +return false;
> +
> +  rtx addr = XEXP (mem, 0);
> +  rtx sym;
> +  if (GET_CODE (addr) == UNSPEC && XINT (addr, 1) == UNSPEC_LTREF)
> +sym = XVECEXP (addr, 0, 0);
> +  else
> +sym = addr;
> +
> +  if (GET_CODE (sym) != SYMBOL_REF || !CONSTANT_POOL_ADDRESS_P (sym))
!SYMBOL_REF_P (sym)

> +return false;
> +
> +  rtx val_rtx = get_pool_constant (sym);
> +  if (!CONST_INT_P (val_rtx))
> +return false;
> +
> +  if (val != nullptr)
> +*val = INTVAL (val_rtx);
> +  return true;
> +}
Alternatively you probably could have returned the RTX instead and use 
gen_highpart / gen_lowpart in
the peephole. But no need to change that.

>  
>  /* Return an RTL expression representing the value of the return address
> for the frame COUNT steps up from the current frame.  FRAME is the
> diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
> index 910415a5974..79e9a75ba2f 100644
> --- a/gcc/config/s390/s390.md
> +++ b/gcc/config/s390/s390.md
> @@ -2116,6 +2116,28 @@ (define_peephole2
>[(set (match_dup 0) (plus:DI (match_dup 1) (match_dup 2)))]
>"")
>  
> +; Split loading of 64-bit constants into GPRs into llihf + oilf -
> +; counterintuitively, using oilf is faster than iilf.  oilf clobbers
> +; cc, so cc must be dead.
> +(define_peephole2
> +  [(set (match_operand:DI 0 "register_operand" "")
> +(match_operand:DI 1 "memory_operand" ""))]
> +  "TARGET_64BIT
> +   && TARGET_EXTIMM
> +   && GENERAL_REG_P (operands[0])
> +   && s390_const_int_pool_entry_p (operands[1], nullptr)
> +   && peep2_reg_dead_p (1, gen_rtx_REG (CCmode, CC_REGNUM))"
> +  [(set (match_dup 0) (match_dup 2))
> +   (parallel
> +[(set (match_dup 0) (ior:DI (match_dup 0) (match_dup 3)))
> + (clobber (reg:CC CC_REGNUM))])]
> +{
> +  HOST_WIDE_INT val;
> +  gcc_assert (s390_const_int_pool_entry_p (operands[1], &val));

This probably breaks with checking disabled.

> +  operands[2] = gen_rtx_CONST_INT (DImode, val & 0x);
> +  operands[3] = gen_rtx_CONST_INT (DImode, val & 0x);

ULL for the constants?

> +})
> +
>  ;
>  ; movsi instruction pattern(s).
>  ;
> diff --git a/gcc/testsuite/gcc.target/s390/load-imm64-1.c 
> b/gcc/testsuite/gcc.target/s390/load-imm64-1.c
> new file mode 100644
> index 000..db0a89395aa
> --- 

Re: [PING] [PATCH] libstdc++: Pretty printers for std::_Bit_reference, std::_Bit_iterator and std::_Bit_const_iterator

[Michael Weghorn via Gcc-patches]

On 01/12/2020 22.37, Jonathan Wakely wrote:

On 27/11/20 16:33 +, Jonathan Wakely wrote:

On 25/11/20 15:05 +0100, Michael Weghorn via Libstdc++ wrote:

I'd like to ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553870.html


Thanks, I'll take another look next week.


I've applied the patch now, thanks.

I adjusted it slightly, to add a test for const_iterator to the C++98
test, simple.cc, consistent with the C++11 one, simple11.cc


Thanks!



Tested powerpc64le-linux, committed to trunk.

Thanks again for the patch, and your patience.



Michael

On 11/10/2020 19.22, Michael Weghorn via Gcc-patches wrote:

On 22/09/2020 12.04, Jonathan Wakely wrote:

On 14/09/20 16:49 +0200, Michael Weghorn via Libstdc++ wrote:

Hi,

the attached patch implements pretty printers relevant for iteration
over std::vector, thus handling the TODO
added in commit 36d0dada6773d7fd7c5ace64c90e723930a3b81e
("Have std::vector printer's iterator return bool for vector",
2019-06-19):

   TODO add printer for vector's _Bit_iterator and
_Bit_const_iterator

Tested on x86_64-pc-linux-gnu (Debian testing).

I haven't filed any copyright assignment for GCC yet, but I'm 
happy to

do so when pointed to the right place.


Thanks for the patch! I'll send you the form to start the copyuright
assignment process.




Thanks! The copyright assignment is done now. Is there anything else to
do from my side at the moment?

options.exp: unsupport tests that depend on missing language

[Alexandre Oliva]

There's a help.exp test that checks that the help message for
-Wabsolute-value mentions it's available in C and ObjC, when compiling
a C++ program.

However, if GCC is built with the C++ language disabled, the
.cc file is compiled as C, and the message [available in C...] becomes
[disabled] instead, because that's the default for the flag in C.

I suppose it might also be possible to disable the C language, and
then the multitude of help.exp tests that name c as the source
language will fail.

This patch avoids these fails: it detects the message "compiler not
installed" in the compiler output, and bails out as "unsupported".

Regstrapped on x86_64-linux-gnu; also tested with a cross compiler to
arm-eabi with C++ disabled.  Ok to install?


for  gcc/testsuite/ChangeLog

* lib/options.exp (check_for_options_with_filter): Detect
unavailable compiler for the selected language, and bail out
as unsupported.
---
 gcc/testsuite/lib/options.exp |5 +
 1 file changed, 5 insertions(+)

diff --git a/gcc/testsuite/lib/options.exp b/gcc/testsuite/lib/options.exp
index c7f7316943e41..7700144fd440b 100644
--- a/gcc/testsuite/lib/options.exp
+++ b/gcc/testsuite/lib/options.exp
@@ -59,6 +59,11 @@ proc check_for_options_with_filter { language gcc_options 
exclude \
 set gcc_output [gcc_target_compile $srcfname $filebase.x executable 
$gcc_options]
 remote_file build delete $srcfname $filebase.x $filebase.gcno
 
+if {[regexp -- "compiler not installed on this system" $gcc_output]} {
+   unsupported "$test: $language compiler not available"
+   return
+}
+
 if { $exclude != "" } {
set lines [split $gcc_output "\n"]
set gcc_output ""


-- 
Alexandre Oliva, happy hacker  https://FSFLA.org/blogs/lxo/
   Free Software Activist GNU Toolchain Engineer
Vim, Vi, Voltei pro Emacs -- GNUlius Caesar

Re: [PATCH 1/2] Add TARGET_COMPUTE_MULTILIB hook to override multi-lib result.

[Kito Cheng]

Hi Jeff:

Defer to gcc-12 is OK to me, we could hold this on downstream :)

On Wed, Dec 2, 2020 at 1:27 PM Jeff Law  wrote:

>
>
> On 12/1/20 2:29 AM, Kito Cheng wrote:
> > Create a new hook to let target could override the multi-lib result,
> > the motivation is RISC-V might have very complicated multi-lib re-use
> > rule*, which is hard to maintain and use current multi-lib scripts,
> > we even hit the "argument list too long" error when we tried to add more
> > multi-lib reuse rule.
> >
> > So I think it would be great to have a target specific way to determine
> > the multi-lib re-use rule, then we could write those rule in C, instead
> > of expand every possible case in MULTILIB_REUSE.
> >
> > * Here is an example for RISC-V multi-lib rules:
> > https://gist.github.com/kito-cheng/0289cd42d9a756382e5afeb77b42b73b
> >
> > gcc/ChangeLog:
> >
> >   * common/common-target.def (compute_multilib): New.
> >   * common/common-targhooks.c (default_compute_multilib): New.
> >   * doc/tm.texi.in (TARGET_COMPUTE_MULTILIB): New.
> >   * doc/tm.texi: Regen.
> >   * gcc.c: Include common/common-target.h.
> >   (set_multilib_dir) Call targetm_common.compute_multilib.
> >   (SWITCH_LIVE): Move to opts.h.
> >   (SWITCH_FALSE): Ditto.
> >   (SWITCH_IGNORE): Ditto.
> >   (SWITCH_IGNORE_PERMANENTLY): Ditto.
> >   (SWITCH_KEEP_FOR_GCC): Ditto.
> >   (struct switchstr): Ditto.
> >   * opts.h (SWITCH_LIVE): Move from gcc.c.
> >   (SWITCH_FALSE): Ditto.
> >   (SWITCH_IGNORE): Ditto.
> >   (SWITCH_IGNORE_PERMANENTLY): Ditto.
> >   (SWITCH_KEEP_FOR_GCC): Ditto.
> >   (struct switchstr): Ditto.
> Can this defer to gcc-12?  We're well into stage3 at this point.
>
> jeff
>
>

Re: [PATCH 1/2] Add TARGET_COMPUTE_MULTILIB hook to override multi-lib result.

[Jeff Law via Gcc-patches]

On 12/1/20 2:29 AM, Kito Cheng wrote:
> Create a new hook to let target could override the multi-lib result,
> the motivation is RISC-V might have very complicated multi-lib re-use
> rule*, which is hard to maintain and use current multi-lib scripts,
> we even hit the "argument list too long" error when we tried to add more
> multi-lib reuse rule.
>
> So I think it would be great to have a target specific way to determine
> the multi-lib re-use rule, then we could write those rule in C, instead
> of expand every possible case in MULTILIB_REUSE.
>
> * Here is an example for RISC-V multi-lib rules:
> https://gist.github.com/kito-cheng/0289cd42d9a756382e5afeb77b42b73b
>
> gcc/ChangeLog:
>
>   * common/common-target.def (compute_multilib): New.
>   * common/common-targhooks.c (default_compute_multilib): New.
>   * doc/tm.texi.in (TARGET_COMPUTE_MULTILIB): New.
>   * doc/tm.texi: Regen.
>   * gcc.c: Include common/common-target.h.
>   (set_multilib_dir) Call targetm_common.compute_multilib.
>   (SWITCH_LIVE): Move to opts.h.
>   (SWITCH_FALSE): Ditto.
>   (SWITCH_IGNORE): Ditto.
>   (SWITCH_IGNORE_PERMANENTLY): Ditto.
>   (SWITCH_KEEP_FOR_GCC): Ditto.
>   (struct switchstr): Ditto.
>   * opts.h (SWITCH_LIVE): Move from gcc.c.
>   (SWITCH_FALSE): Ditto.
>   (SWITCH_IGNORE): Ditto.
>   (SWITCH_IGNORE_PERMANENTLY): Ditto.
>   (SWITCH_KEEP_FOR_GCC): Ditto.
>   (struct switchstr): Ditto.
Can this defer to gcc-12?  We're well into stage3 at this point.

jeff

Re: [PATCH 2/2] reset edge probibility and BB-count for peeled/unrolled loop

[Jeff Law via Gcc-patches]

On 10/9/20 4:12 AM, guojiufu via Gcc-patches wrote:
> Hi,
> PR68212 mentioned that the COUNT of unrolled loop was not correct, and
> comments of this PR also mentioned that loop become 'cold'.
>
> This patch fixes the wrong COUNT/PROB of unrolled loop.  And the
> patch handles the case where unrolling in unreliable count number can
> cause a loop to no longer look hot and therefor not get aligned.  This
> patch scale by profile_probability::likely () if unrolled count gets
> unrealistically small.
>
> Bootstrap/regtest on powerpc64le with no new regressions. Ok for trunk?
>
> Jiufu Guo
>
> gcc/ChangeLog:
> 2020-10-09  Jiufu Guo   
>   Pat Haugen  
>
>   PR rtl-optimization/68212
>   * cfgloopmanip.c (duplicate_loop_to_header_edge): Reset probablity
>   of unrolled/peeled loop.
>
> testsuite/ChangeLog:
> 2020-10-09  Jiufu Guo   
>   Pat Haugen  
>   PR rtl-optimization/68212
>   * gcc.dg/pr68212.c: New test.
OK
jeff

Re: Import AMD HSA API headers

[Jeff Law via Gcc-patches]

On 11/24/20 9:16 AM, Andrew Stubbs wrote:
> Hi David, All,
>
> As previously discussed, we need import some new headers for the
> ROC/HSA Runtime (for the amdgcn GPU port).
>
> These are the same files that can be found in the ROCr sources and
> install, but AMD have kindly relicensed them using Boost for use in
> GCC (the original license was Illinois, which has a troublesome
> attribution clause).
>
> The import has already been approved in principle by RMS, so I'm
> really just asking if I need to add/update any new README/COPYING, or
> move them to a different location, or something.
>
> OK to commit?
>
> Thanks
>
> Andrew
>
> P.S. I will follow up with a patch to actually use the new features in
> the near future.
>
> 201124-hsa-header.patch
>
> Import HSA header files from AMD
>
> These are the same header files that exist in the Radeon Open Compute Runtime
> project (as of October 2020), but they have been specially relicensed by AMD
> for use in GCC.
>
> The header files retain AMD copyright.
>
> include/ChangeLog:
>
>   * hsa.h: Replace whole file.
>   * hsa_ext_amd.h: New file.
>   * hsa_ext_image.h: New file.
>
> libgomp/ChangeLog:
>
>   * plugin/plugin-gcn.c: Include hsa_ext_amd.h.
>   (HSA_AMD_AGENT_INFO_COMPUTE_UNIT_COUNT): Delete redundant definition.
OK.  I was concerned about AMD keeping the copyright and the fact that
the copyright is not [L]GPL.  But if RMS has OK'd it from that
standpoint, then I think we're for pushing into the trunk.

Jeff

Re: PING^5 [PATCH] Use the section flag 'o' for __patchable_function_entries

[Jeff Law via Gcc-patches]

On 11/18/20 7:00 AM, H.J. Lu wrote:
> On Sat, Nov 7, 2020 at 7:47 AM H.J. Lu  wrote:
>> On Sat, Oct 31, 2020 at 5:01 AM H.J. Lu  wrote:
>>> On Fri, Oct 23, 2020 at 5:41 AM H.J. Lu  wrote:
 On Fri, Oct 2, 2020 at 6:00 AM H.J. Lu  wrote:
> On Thu, Feb 6, 2020 at 6:57 PM H.J. Lu  wrote:
>> This commit in GNU binutils 2.35:
>>
>> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=b7d072167715829eed0622616f6ae0182900de3e
>>
>> added the section flag 'o' to .section directive:
>>
>> .section __patchable_function_entries,"awo",@progbits,foo
>>
>> which specifies the symbol name which the section references.  Assembler
>> creates a unique __patchable_function_entries section with the section,
>> where foo is defined, as its linked-to section.  Linker keeps a section
>> if its linked-to section is kept during garbage collection.
>>
>> This patch checks assembler support for the section flag 'o' and uses
>> it to implement __patchable_function_entries section.  Since Solaris may
>> use GNU assembler with Solairs ld.  Even if GNU assembler supports the
>> section flag 'o', it doesn't mean that Solairs ld supports it.  This
>> feature is disabled for Solairs targets.
>>
>> gcc/
>>
>> PR middle-end/93195
>> PR middle-end/93197
>> * configure.ac (HAVE_GAS_SECTION_LINK_ORDER): New.  Define if
>> the assembler supports the section flag 'o' for specifying
>> section with link-order.
>> * dwarf2out.c (output_comdat_type_unit): Pass 0 as flags2
>> to targetm.asm_out.named_section.
>> * config/sol2.c (solaris_elf_asm_comdat_section): Likewise.
>> * output.h (SECTION2_LINK_ORDER): New.
>> (switch_to_section): Add an unsigned int argument.
>> (default_no_named_section): Likewise.
>> (default_elf_asm_named_section): Likewise.
>> * target.def (asm_out.named_section): Likewise.
>> * targhooks.c (default_print_patchable_function_entry): Pass
>> current_function_decl to get_section and SECTION2_LINK_ORDER
>> to switch_to_section.
>> * varasm.c (default_no_named_section): Add an unsigned int
>> argument.
>> (default_elf_asm_named_section): Add an unsigned int argument,
>> flags2.  Use 'o' flag for SECTION2_LINK_ORDER if assembler
>> supports it.
>> (switch_to_section): Add an unsigned int argument and pass it
>> to targetm.asm_out.named_section.
>> (handle_vtv_comdat_section): Pass 0 to
>> targetm.asm_out.named_section.
>> * config.in: Regenerated.
>> * configure: Likewise.
>> * doc/tm.texi: Likewise.
>>
>> gcc/testsuite/
>>
>> PR middle-end/93195
>> * g++.dg/pr93195a.C: New test.
>> * g++.dg/pr93195b.C: Likewise.
>> * lib/target-supports.exp
>> (check_effective_target_o_flag_in_section): New proc.
> PING
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-February/539963.html
 PING.

>>> PING.
>>>
>> PING.
> Here is a simpler patch.  OK for master?
>
> This commit in GNU binutils 2.35:
>
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=b7d072167715
> 829eed0622616f6ae0182900de3e
>
> added the section flag 'o' to .section directive:
>
> .section __patchable_function_entries,"awo",@progbits,foo
>
> which specifies the symbol name which the section references.  Assembler
> creates a unique __patchable_function_entries section with the section,
> where foo is defined, as its linked-to section.  Linker keeps a section
> if its linked-to section is kept during garbage collection.
>
> This patch checks assembler support for the section flag 'o' and uses
> it to implement __patchable_function_entries section.  Since Solaris may
> use GNU assembler with Solairs ld.  Even if GNU assembler supports the
> section flag 'o', it doesn't mean that Solairs ld supports it.  This
> feature is disabled for Solairs targets.
>
> gcc/
>
> PR middle-end/93195
> PR middle-end/93197
> * configure.ac (HAVE_GAS_SECTION_LINK_ORDER): New.  Define 1 if
> the assembler supports the section flag 'o' for specifying
> section with link-order.
> * output.h (SECTION_LINK_ORDER): New.  Defined to 0x400.
> (SECTION_MACH_DEP): Changed from 0x400 to 0x800.
> * targhooks.c (default_print_patchable_function_entry): Pass
> SECTION_LINK_ORDER to switch_to_section if the section flag 'o'
> works.  Pass current_function_decl to switch_to_section.
> * varasm.c (default_elf_asm_named_section): Use 'o' flag for
> SECTION_LINK_ORDER if assembler supports it.
> * config.in: Regenerated.
> * configure: Likewise.
>
> gcc/testsuite/
>
> PR middle-end/93195
> * g++.dg/pr93195a.C: New test.
> * g++.dg/pr93195b.C: Likewise.
> * 

Re: [10/23] Tweak the way that is_a is implemented

[Jeff Law via Gcc-patches]

On 11/13/20 1:16 AM, Richard Sandiford via Gcc-patches wrote:
> At the moment, class hierarchies that use is_a are expected
> to define specialisations like:
>
>   template <>
>   template <>
>   inline bool
>   is_a_helper ::test (symtab_node *p)
>   {
> return p->type == SYMTAB_FUNCTION;
>   }
>
> But this doesn't scale well to larger hierarchies, because it only
> defines ::test for an argument that is exactly “symtab_node *”
> (and not for example “const symtab_node *” or something that
> comes between cgraph_node and symtab_node in the hierarchy).
>
> For example:
>
>   struct A { int x; };
>   struct B : A {};
>   struct C : B {};
>
>   template <>
>   template <>
>   inline bool
>   is_a_helper ::test (A *a)
>   {
> return a->x == 1;
>   }
>
>   bool f(B *b) { return is_a (b); }
>
> gives:
>
>   warning: inline function ‘static bool is_a_helper::test(U*) [with U = B; 
> T = C*]’ used but never defined
>
> and:
>
>   bool f(const A *a) { return is_a (a); }
>
> gives:
>
>   warning: inline function ‘static bool is_a_helper::test(U*) [with U = 
> const A; T = const C*]’ used but never defined
>
> This patch instead allows is_a to be implemented by specialising
> is_a_helper as a whole, for example:
>
>   template<>
>   struct is_a_helper : static_is_a_helper
>   {
> static inline bool test (const A *a) { return a->x == 1; }
>   };
>
> It also adds a general specialisation of is_a_helper for const
> pointers.  Together, this makes both of the above examples work.
>
> gcc/
>   * is-a.h (reinterpret_is_a_helper): New class.
>   (static_is_a_helper): Likewise.
>   (is_a_helper): Inherit from reinterpret_is_a_helper.
>   (is_a_helper): New specialization.
OK

Jeff

[committed] Use add/sub/neg insns to eliminate compare/test insns on H8

[Jeff Law via Gcc-patches]

So this is the first in an unknown number of patches to start optimizing
away unnecessary compares and test insns on the H8.    I originally had
distinct insns for setting the flags and I still use those patches for
comparison purposes, but this patch uses define_subst rather than
creating distinct patterns.

This particular patch enables using addition, subtraction and negation
insns to remove redundant compare and test instructions.  It actually
does a better job than we ever did with the old cc0 scheme.  It's got
reasonable tests for add and subtract.  Negation is a bit tougher to
build simple tests for, but I'm confident it works as instrumentation
has shown it triggering.

There is one case where I think this patch could regress the generated
code.  Specifically it over-computes the size of an addition by +-4 by 2
bytes when the addition is not used for removing a compare/test insn. 
As a result we could end up generating a longer branch than is strictly
necessary.  If this turns out to be a problem, we can certainly account
for that special case in the length computation if we need to.

Naturally this does not trigger any regressions in the testsuite.

Committed to the trunk.

Jeff
commit 7da97411b048cdd4e7941b311514f46ea53fe3a2
Author: Jeff Law 
Date:   Tue Dec 1 21:48:10 2020 -0700

Use add/sub/neg insns to eliminate compare/test insns on H8

gcc/

* config/h8300/addsub.md (addqi3_clobber_flags): Rename to
addqi3_flags and annotate with a  for define_subst.
(addhi3_h8sx_clobber_flags): Likewise.
(subqi3_clobber_flags, sub3_clobber_flags): Likewise.
(neg_clobber_flags): Similarly.
(addsi3_clobber_flags): Similarly.  Update last argument to
output_plussi to distinguish when we need flags or do not need
flags.
(addhi3_clobber_flags): Similarly.  Twiddle code for cases
+-1, +-2 and +-4.
* config/h8300/h8300.md: Define iterators, mode attributes and
substitutions for use in compare/test elimination.
* config/h8300/jumpcall.md (branch, branch_1): Use H8cc mode
iterator to cover the different modes for the CC register.
(branch_1_false): Likewise.

gcc/testsuite
* gcc.target/h8300/add.c: New test.
* gcc.target/h8300/add-2.c: New test.
* gcc.target/h8300/add-3.c: New test.
* gcc.target/h8300/sub.c: New test.
* gcc.target/h8300/sub-2.c: New test.
* gcc.target/h8300/sub-3.c: New test.

diff --git a/gcc/config/h8300/addsub.md b/gcc/config/h8300/addsub.md
index d0877c008bf..3585bffa9fc 100644
--- a/gcc/config/h8300/addsub.md
+++ b/gcc/config/h8300/addsub.md
@@ -19,7 +19,7 @@
   [(parallel [(set (match_dup 0) (plus:QI (match_dup 1) (match_dup 2)))
  (clobber (reg:CC CC_REG))])])
 
-(define_insn "*addqi3_clobber_flags"
+(define_insn "*addqi3_flags"
   [(set (match_operand:QI 0 "h8300_dst_operand" "=rQ")
(plus:QI (match_operand:QI 1 "h8300_dst_operand" "%0")
 (match_operand:QI 2 "h8300_src_operand" "rQi")))
@@ -38,18 +38,41 @@
   [(parallel [(set (match_dup 0) (plus:HI (match_dup 1) (match_dup 2)))
  (clobber (reg:CC CC_REG))])])
 
-(define_insn "*addhi3_clobber_flags"
+(define_insn "*addhi3_flags"
   [(set (match_operand:HI 0 "register_operand" "=r,r,r,r,r")
(plus:HI (match_operand:HI 1 "register_operand" "%0,0,0,0,0")
-(match_operand:HI 2 "h8300_src_operand" "L,N,J,n,r")))
+(match_operand:HI 2 "h8300_src_operand" "M,O,J,n,r")))
(clobber (reg:CC CC_REG))]
   "reload_completed && !TARGET_H8300SX"
-  "@
-   adds%2,%S0
-   subs%G2,%S0
-   add.b   %t2,%t0
-   add.w   %T2,%T0
-   add.w   %T2,%T0"
+  "*
+  {
+switch (which_alternative)
+  {
+  case 0:
+   return \"inc %T2,%T0\";
+  case 1:
+   return \"dec %G2,%T0\";
+  case 2:
+   return \"add.b  %t2,%t0\";
+  case 3:
+   {
+ /* If the constant is 4 or -4 and we do not need the
+flags, then we can use adds/subs which is two bytes
+shorter.  */
+ rtx x = XVECEXP (PATTERN (insn), 0, 1);
+ bool clobber = GET_CODE (x) == CLOBBER;
+ if (clobber && INTVAL (operands[2]) == 4)
+   return \"adds   %2,%S0\";
+ if (clobber && INTVAL (operands[2]) == -4)
+   return \"subs   %G2,%S0\";
+ return \"add.w%T2,%T0\";
+   }
+  case 4:
+   return \"add.w  %T2,%T0\";
+  default:
+   gcc_unreachable ();
+  }
+  }"
   [(set_attr "length" "2,2,2,4,2")])
 
 (define_insn_and_split "*addhi3_h8sx"
@@ -62,7 +85,7 @@
   [(parallel [(set (match_dup 0) (plus:HI (match_dup 1) (match_dup 2)))
  (clobber (reg:CC CC_REG))])])
 
-(define_insn "*addhi3_h8sx_clobber_flags"
+(define_insn "*addhi3_h8sx_flags"
   [(set (match_operand:HI 0 "h830

[committed] loop-iv: Fix typo in `iv_analyze_expr' description

[Maciej W. Rozycki]

gcc/
* loop-iv.c: Fix a typo, s/bu/by/, in the `iv_analyze_expr' 
description in the introduction.
---
 gcc/loop-iv.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: gcc/gcc/loop-iv.c
===
--- gcc.orig/gcc/loop-iv.c
+++ gcc/gcc/loop-iv.c
@@ -44,7 +44,7 @@ along with GCC; see the file COPYING3.
iv_analyze_result (insn, def, iv):  Stores to IV the description of the iv
  corresponding to DEF, which is a register defined in INSN.
iv_analyze_expr (insn, mode, expr, iv):  Stores to IV the description of iv
- corresponding to expression EXPR evaluated at INSN.  All registers used bu
+ corresponding to expression EXPR evaluated at INSN.  All registers used by
  EXPR must also be used in INSN.  MODE is the mode of EXPR.
 */
 

[r11-5622 Regression] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for warnings, line 292) on Linux/x86_64

[sunil.k.pandey via Gcc-patches]

On Linux/x86_64,

d02c41dd414dcc65a08bc82f312f7808b5d90028 is the first bad commit
commit d02c41dd414dcc65a08bc82f312f7808b5d90028
Author: Martin Sebor 
Date:   Tue Dec 1 13:38:08 2020 -0700

PR middle-end/97373 - missing warning on sprintf into allocated destination

caused

FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-11.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-11.c  (test for warnings, line 210)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c second (test for warnings, line 
120)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c second (test for warnings, line 
122)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-18.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test for excess errors)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 119)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 121)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 125)
FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-1.c  (test for warnings, line 292)

with GCC configured with

../../gcc/configure 
--prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r11-5622/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/builtin-sprintf-warn-11.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/builtin-sprintf-warn-11.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/builtin-sprintf-warn-18.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/builtin-sprintf-warn-18.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/builtin-sprintf-warn-1.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="tree-ssa.exp=gcc.dg/tree-ssa/builtin-sprintf-warn-1.c 
--target_board='unix{-m32\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at skpgkp2 at gmail dot com)

Go testsuite patch committed: Permit */ at end of ERROR line

[Ian Lance Taylor via Gcc-patches]

This patch to the Go testsuite driver go-test.exp permits a */ at the
end of a ERROR line.  This will be used for a test that has no final
newline.  Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.

Ian

* go.test/go-test.exp (errchk): Permit trailing */ on ERROR line.
b906750ff826bb40cee7db1490e08449f439e333
diff --git a/gcc/testsuite/go.test/go-test.exp 
b/gcc/testsuite/go.test/go-test.exp
index 51f9b381d67..067f309a296 100644
--- a/gcc/testsuite/go.test/go-test.exp
+++ b/gcc/testsuite/go.test/go-test.exp
@@ -105,7 +105,7 @@ proc errchk { test opts } {
set copy_line $out_line
}
 
-   regsub "// \(GCCGO_\)?ERROR \"\(\[^\"\]*\)\".*$" $copy_line "// \{ 
dg-error \"\\2\" \}" out_line
+   regsub "// \(GCCGO_\)?ERROR \"\(\[^\"\]*\)\" *\(\\*/\)?$" $copy_line 
"// \{ dg-error \"\\2\" \}\\3" out_line
if [string match "*dg-error*\\\[*" $out_line] {
set index [string first "dg-error" $out_line]
regsub -start $index -all "\\\[" $out_line "\\\[" 
out_line

[PATCH RESEND] tree-ssa-threadbackward.c (profitable_jump_thread_path): Do not allow __builtin_constant_p.

[Ilya Leoshkevich via Gcc-patches]

On Tue, 2020-12-01 at 15:34 -0700, Jeff Law wrote:
> 
> No strong opinions.  I think whichever is less invasive in terms of
> code
> quality is probably the way to go.  What we want to avoid is
> suppressing
> threading unnecessarily as that often leads to false positives from
> middle-end based warnings.  Suppressing threading can also lead to
> build
> failures in the kernel due to the way they use b_c_p.

I think v1 is better then.  Would you mind approving the following?
That's the same code as in v1, but with the improved commit message and
comments.



Linux Kernel (specifically, drivers/leds/trigger/ledtrig-cpu.c) build
with GCC 10 fails on s390 with "impossible constraint".

Explanation by Jeff Law:

```
So what we have is a b_c_p at the start of an if-else chain.  Subsequent
tests on the "true" arm of the the b_c_p test may throw us off the
constant path (because the constants are out of range).  Once all the
tests are passed (it's constant and the constant is in range) the true
arm's terminal block has a special asm that requires a constant
argument.   In the case where we get to the terminal block on the true
arm, the argument to the b_c_p is used as the constant argument to the
special asm.

At first glace jump threading seems to be doing the right thing.  Except
that we end up with two paths to that terminal block with the special
asm, one for each of the two constant arguments to the b_c_p call.
Naturally since that same value is used in the asm, we have to introduce
a PHI to select between them at the head of the terminal block.   Now
the argument in the asm is no longer constant and boom we fail.
```

Fix by disallowing __builtin_constant_p on threading paths.

gcc/ChangeLog:

2020-06-03  Ilya Leoshkevich  

* tree-ssa-threadbackward.c (thread_jumps::profitable_jump_thread_path):
Do not allow __builtin_constant_p on a threading path.

gcc/testsuite/ChangeLog:

2020-06-03  Ilya Leoshkevich  

* gcc.target/s390/builtin-constant-p-threading.c: New test.
---
 .../s390/builtin-constant-p-threading.c   | 46 +++
 gcc/tree-ssa-threadbackward.c |  7 ++-
 2 files changed, 52 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.target/s390/builtin-constant-p-threading.c

diff --git a/gcc/testsuite/gcc.target/s390/builtin-constant-p-threading.c 
b/gcc/testsuite/gcc.target/s390/builtin-constant-p-threading.c
new file mode 100644
index 000..5f0acdce0b0
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/builtin-constant-p-threading.c
@@ -0,0 +1,46 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -march=z196 -mzarch" } */
+
+typedef struct
+{
+  int counter;
+} atomic_t;
+
+static inline __attribute__ ((__gnu_inline__)) int
+__atomic_add (int val, int *ptr)
+{
+  int old;
+  asm volatile("laa %[old],%[val],%[ptr]\n"
+  : [old] "=d" (old), [ptr] "+Q"(*ptr)
+  : [val] "d" (val)
+  : "cc", "memory");
+  return old;
+}
+
+static inline __attribute__ ((__gnu_inline__)) void
+__atomic_add_const (int val, int *ptr)
+{
+  asm volatile("asi %[ptr],%[val]\n"
+  : [ptr] "+Q" (*ptr)
+  : [val] "i" (val)
+  : "cc", "memory");
+}
+
+static inline __attribute__ ((__gnu_inline__)) void
+atomic_add (int i, atomic_t *v)
+{
+  if (__builtin_constant_p (i) && (i > -129) && (i < 128))
+{
+  __atomic_add_const (i, &v->counter);
+  return;
+}
+  __atomic_add (i, &v->counter);
+}
+
+static atomic_t num_active_cpus = { (0) };
+
+void
+ledtrig_cpu (_Bool is_active)
+{
+  atomic_add (is_active ? 1 : -1, &num_active_cpus);
+}
diff --git a/gcc/tree-ssa-threadbackward.c b/gcc/tree-ssa-threadbackward.c
index 327628f1662..30f692672d9 100644
--- a/gcc/tree-ssa-threadbackward.c
+++ b/gcc/tree-ssa-threadbackward.c
@@ -259,8 +259,13 @@ thread_jumps::profitable_jump_thread_path (basic_block 
bbi, tree name,
   !gsi_end_p (gsi);
   gsi_next_nondebug (&gsi))
{
+ /* Do not allow OpenACC loop markers and __builtin_constant_p on
+threading paths.  The latter is disallowed, because an
+expression might be constant on two threading paths, and
+become non-constant (i.e.: phi) when they merge.  */
  gimple *stmt = gsi_stmt (gsi);
- if (gimple_call_internal_p (stmt, IFN_UNIQUE))
+ if (gimple_call_internal_p (stmt, IFN_UNIQUE)
+ || gimple_call_builtin_p (stmt, BUILT_IN_CONSTANT_P))
{
  m_path.pop ();
  return NULL;
-- 
2.25.4

Re: [PATCH] [Refactor] [AVX512] Combine VI12_AVX512VL with VI48_AVX512VL into VI_AVX512VLBW

[Hongtao Liu via Gcc-patches]

On Wed, Dec 2, 2020 at 8:28 AM Jeff Law  wrote:
>
>
>
> On 11/30/20 10:17 PM, Hongtao Liu via Gcc-patches wrote:
> > Hi:
> > There're many pairs of define_insn/define_expand that are very similar
> > to each other except mode iterator and condition. For these patterns
> > VI12_AVX512VL are used under condition TARGET_AVX512BW, and
> > VI48_AVX512VL are used under condition TARGET_AVX512F.
> >
> > This patch is about to introduce a new iterator VI_AVX512VLBW to
> > combine a pair of those patterns into one.
> >
> > There are no functional changes, just code refactoring.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> >
> > gcc/ChangeLog
> >
> > * config/i386/sse.md (VI_AVX512VLBW): New mode iterator.
> > (_ucmp3): Combine
> > two patterns with mode iterator VI12_AVX512VL and VI48_AVX512VL
> > into one pattern with mode iterator VI_AVX512VLBW.
> > (vec_cmpu): Ditto.
> > (_cvt2mask): Ditto.
> > (_cvtmask2): Ditto.
> > (*_cvtmask2): Ditto.
> > (3_mask): Ditto.
> > (*3_mask): Ditto.
> > (_eq3): Ditto.
> > (_eq3_1): Ditto.
> > (_gt3): Ditto.
> > (_andnot3_mask): Ditto.
> > (abs2_mask): Ditto.
> > (*_3): Combine from ...
> > (*avx512f_3)
> > and (3).
> I'd suggest deferring to gcc-12 unless there is a strong need for this
> cleanup to make fixing a bug easier.
>
> jeff
>

Sure, I'll wait for GCC-12.

-- 
BR,
Hongtao

[PATCH] IBM Z: Use llihf and oilf to load large immediates into GPRs

[Ilya Leoshkevich via Gcc-patches]

Bootstrapped and regtesed on s390x-redhat-linux.  There are slight
improvements in all SPEC benchmarks, no regressions that could not be
"fixed" by adding nops.  Ok for master?



Currently GCC loads large immediates into GPRs from the literal pool,
which is not as efficient as loading two halves with llihf and oilf.

gcc/ChangeLog:

2020-11-30  Ilya Leoshkevich  

* config/s390/s390-protos.h (s390_const_int_pool_entry_p): New
function.
* config/s390/s390.c (s390_const_int_pool_entry_p): New
function.
* config/s390/s390.md: Add define_peephole2 that produces llihf
and oilf.

gcc/testsuite/ChangeLog:

2020-11-30  Ilya Leoshkevich  

* gcc.target/s390/load-imm64-1.c: New test.
* gcc.target/s390/load-imm64-2.c: New test.
---
 gcc/config/s390/s390-protos.h|  1 +
 gcc/config/s390/s390.c   | 31 
 gcc/config/s390/s390.md  | 22 ++
 gcc/testsuite/gcc.target/s390/load-imm64-1.c | 10 +++
 gcc/testsuite/gcc.target/s390/load-imm64-2.c | 10 +++
 5 files changed, 74 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/s390/load-imm64-1.c
 create mode 100644 gcc/testsuite/gcc.target/s390/load-imm64-2.c

diff --git a/gcc/config/s390/s390-protos.h b/gcc/config/s390/s390-protos.h
index ad2f7f77c18..eb10c3f4bbb 100644
--- a/gcc/config/s390/s390-protos.h
+++ b/gcc/config/s390/s390-protos.h
@@ -135,6 +135,7 @@ extern void s390_split_access_reg (rtx, rtx *, rtx *);
 extern void print_operand_address (FILE *, rtx);
 extern void print_operand (FILE *, rtx, int);
 extern void s390_output_pool_entry (rtx, machine_mode, unsigned int);
+extern bool s390_const_int_pool_entry_p (rtx, HOST_WIDE_INT *);
 extern int s390_label_align (rtx_insn *);
 extern int s390_agen_dep_p (rtx_insn *, rtx_insn *);
 extern rtx_insn *s390_load_got (void);
diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index 02f18366aa1..e3d68d3543b 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -9400,6 +9400,37 @@ s390_output_pool_entry (rtx exp, machine_mode mode, 
unsigned int align)
 }
 }
 
+/* Return true if MEM refers to an integer constant in the literal pool.  If
+   VAL is not nullptr, then also fill it with the constant's value.  */
+
+bool
+s390_const_int_pool_entry_p (rtx mem, HOST_WIDE_INT *val)
+{
+  /* Try to match the following:
+ - (mem (unspec [(symbol_ref) (reg)] UNSPEC_LTREF)).
+ - (mem (symbol_ref)).  */
+
+  if (!MEM_P (mem))
+return false;
+
+  rtx addr = XEXP (mem, 0);
+  rtx sym;
+  if (GET_CODE (addr) == UNSPEC && XINT (addr, 1) == UNSPEC_LTREF)
+sym = XVECEXP (addr, 0, 0);
+  else
+sym = addr;
+
+  if (GET_CODE (sym) != SYMBOL_REF || !CONSTANT_POOL_ADDRESS_P (sym))
+return false;
+
+  rtx val_rtx = get_pool_constant (sym);
+  if (!CONST_INT_P (val_rtx))
+return false;
+
+  if (val != nullptr)
+*val = INTVAL (val_rtx);
+  return true;
+}
 
 /* Return an RTL expression representing the value of the return address
for the frame COUNT steps up from the current frame.  FRAME is the
diff --git a/gcc/config/s390/s390.md b/gcc/config/s390/s390.md
index 910415a5974..79e9a75ba2f 100644
--- a/gcc/config/s390/s390.md
+++ b/gcc/config/s390/s390.md
@@ -2116,6 +2116,28 @@ (define_peephole2
   [(set (match_dup 0) (plus:DI (match_dup 1) (match_dup 2)))]
   "")
 
+; Split loading of 64-bit constants into GPRs into llihf + oilf -
+; counterintuitively, using oilf is faster than iilf.  oilf clobbers
+; cc, so cc must be dead.
+(define_peephole2
+  [(set (match_operand:DI 0 "register_operand" "")
+(match_operand:DI 1 "memory_operand" ""))]
+  "TARGET_64BIT
+   && TARGET_EXTIMM
+   && GENERAL_REG_P (operands[0])
+   && s390_const_int_pool_entry_p (operands[1], nullptr)
+   && peep2_reg_dead_p (1, gen_rtx_REG (CCmode, CC_REGNUM))"
+  [(set (match_dup 0) (match_dup 2))
+   (parallel
+[(set (match_dup 0) (ior:DI (match_dup 0) (match_dup 3)))
+ (clobber (reg:CC CC_REGNUM))])]
+{
+  HOST_WIDE_INT val;
+  gcc_assert (s390_const_int_pool_entry_p (operands[1], &val));
+  operands[2] = gen_rtx_CONST_INT (DImode, val & 0x);
+  operands[3] = gen_rtx_CONST_INT (DImode, val & 0x);
+})
+
 ;
 ; movsi instruction pattern(s).
 ;
diff --git a/gcc/testsuite/gcc.target/s390/load-imm64-1.c 
b/gcc/testsuite/gcc.target/s390/load-imm64-1.c
new file mode 100644
index 000..db0a89395aa
--- /dev/null
+++ b/gcc/testsuite/gcc.target/s390/load-imm64-1.c
@@ -0,0 +1,10 @@
+/* Test that large 64-bit constants are loaded with llihf + oilf when lgrl is
+   not available.  */
+
+/* { dg-do compile } */
+/* { dg-options "-O3 -march=z9-109" } */
+
+unsigned long magic (void) { return 0x3f08c5392f756cd; }
+
+/* { dg-final { scan-assembler-times {\n\tllihf\t} 1 { target lp64 } } } */
+/* { dg-final { scan-assembler-times {\n\toilf\t} 1 { target lp64 } } } */
diff --git a/gcc/testsuite/gcc.target/s390/load-imm64-2.c 
b

Re: [PATCH] Add feature test macro for atomic::wait

[Jonathan Wakely via Gcc-patches]

On 01/12/20 15:45 -0800, Thomas Rodgers via Libstdc++ wrote:

Tested x86_64-pc-linux-gnu, committed to trunk.


This does a couple more #ifdef -> #if changes.

Tested powerpc64le-linux, committed to trunk.

commit 670f5095e4aacc30099f6b73c1e67c06df76f36b
Author: Jonathan Wakely 
Date:   Wed Dec 2 00:39:22 2020

libstdc++: Make preprocessor checks for __cpp_lib_atomic_wait consistent

This changes some #ifdef checks to use #if instead.

libstdc++-v3/ChangeLog:

* include/bits/atomic_timed_wait.h: Use #if instead of #ifdef.
* include/bits/semaphore_base.h: Likewise.
* include/std/version: Remove trailing whitespace.

diff --git a/libstdc++-v3/include/bits/atomic_timed_wait.h b/libstdc++-v3/include/bits/atomic_timed_wait.h
index 6dd1a145e69..83438ae31ed 100644
--- a/libstdc++-v3/include/bits/atomic_timed_wait.h
+++ b/libstdc++-v3/include/bits/atomic_timed_wait.h
@@ -34,7 +34,7 @@
 
 #include 
 
-#ifdef __cpp_lib_atomic_wait
+#if __cpp_lib_atomic_wait
 #include 
 
 #include 
diff --git a/libstdc++-v3/include/bits/semaphore_base.h b/libstdc++-v3/include/bits/semaphore_base.h
index 0ed1f5895af..e4e57de4acf 100644
--- a/libstdc++-v3/include/bits/semaphore_base.h
+++ b/libstdc++-v3/include/bits/semaphore_base.h
@@ -33,7 +33,7 @@
 #pragma GCC system_header
 
 #include 
-#ifdef __cpp_lib_atomic_wait 
+#if __cpp_lib_atomic_wait
 #include 
 
 #include 
diff --git a/libstdc++-v3/include/std/version b/libstdc++-v3/include/std/version
index 4bb45b7805c..25f628f399d 100644
--- a/libstdc++-v3/include/std/version
+++ b/libstdc++-v3/include/std/version
@@ -219,7 +219,7 @@
 #ifdef _GLIBCXX_HAS_GTHREADS
 # define __cpp_lib_jthread 201911L
 #endif
-#if __cpp_lib_atomic_wait 
+#if __cpp_lib_atomic_wait
 # define __cpp_lib_latch 201907L
 #endif
 #define __cpp_lib_list_remove_return_type 201806L
@@ -231,7 +231,7 @@
 #if __cpp_lib_concepts
 # define __cpp_lib_ranges 201911L
 #endif
-#if __cpp_lib_atomic_wait 
+#if __cpp_lib_atomic_wait
 # define __cpp_lib_semaphore 201907L
 #endif
 #define __cpp_lib_shift 201806L

[committed] libstdc++: Fix filesystem::path pretty printer test failure

[Jonathan Wakely via Gcc-patches]

On some systems libstdc++-prettyprinters/cxx17.cc FAILs with this error:

skipping: Python Exception  'gdb.Type' object 
has no attribute 'name': ^M
got: $27 = filesystem::path "/dir/."^M
FAIL: libstdc++-prettyprinters/cxx17.cc print path2

The gdb.Type.name attribute isn't present in GDB 7.6, so we get an
exception from StdPathPrinter._iterator.__next__ trying to use it.
The StdPathPrinter._iterator is already passed the type's name in its
constructor, so we can just store that and use it instead of
gdb.Type.name.

libstdc++-v3/ChangeLog:

* python/libstdcxx/v6/printers.py (StdExpPathPrinter): Store the
name of the type and pass it to the iterator.
(StdPathPrinter): Likewise.
* testsuite/libstdc++-prettyprinters/filesystem-ts.cc: New test.

Tested powerpc64le-linux. Committed to trunk.

commit a70384f94c83895f97179b45c1a8d66202132af8
Author: Jonathan Wakely 
Date:   Wed Dec 2 00:39:21 2020

libstdc++: Fix filesystem::path pretty printer test failure

On some systems libstdc++-prettyprinters/cxx17.cc FAILs with this error:

skipping: Python Exception  'gdb.Type' 
object has no attribute 'name': ^M
got: $27 = filesystem::path "/dir/."^M
FAIL: libstdc++-prettyprinters/cxx17.cc print path2

The gdb.Type.name attribute isn't present in GDB 7.6, so we get an
exception from StdPathPrinter._iterator.__next__ trying to use it.
The StdPathPrinter._iterator is already passed the type's name in its
constructor, so we can just store that and use it instead of
gdb.Type.name.

libstdc++-v3/ChangeLog:

* python/libstdcxx/v6/printers.py (StdExpPathPrinter): Store the
name of the type and pass it to the iterator.
(StdPathPrinter): Likewise.
* testsuite/libstdc++-prettyprinters/filesystem-ts.cc: New test.

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py 
b/libstdc++-v3/python/libstdcxx/v6/printers.py
index 478e44eefdf..4176f739004 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -1294,6 +1294,7 @@ class StdExpPathPrinter:
 
 def __init__ (self, typename, val):
 self.val = val
+self.typename = typename
 start = self.val['_M_cmpts']['_M_impl']['_M_start']
 finish = self.val['_M_cmpts']['_M_impl']['_M_finish']
 self.num_cmpts = int (finish - start)
@@ -1312,10 +1313,11 @@ class StdExpPathPrinter:
 t = self._path_type()
 if t:
 path = '%s [%s]' % (path, t)
-return "filesystem::path %s" % path
+return "experimental::filesystem::path %s" % path
 
 class _iterator(Iterator):
-def __init__(self, cmpts):
+def __init__(self, cmpts, pathtype):
+self.pathtype = pathtype
 self.item = cmpts['_M_impl']['_M_start']
 self.finish = cmpts['_M_impl']['_M_finish']
 self.count = 0
@@ -1331,13 +1333,13 @@ class StdExpPathPrinter:
 self.count = self.count + 1
 self.item = self.item + 1
 path = item['_M_pathname']
-t = StdExpPathPrinter(item.type.name, item)._path_type()
+t = StdExpPathPrinter(self.pathtype, item)._path_type()
 if not t:
 t = count
 return ('[%s]' % t, path)
 
 def children(self):
-return self._iterator(self.val['_M_cmpts'])
+return self._iterator(self.val['_M_cmpts'], self.typename)
 
 class StdPathPrinter:
 "Print a std::filesystem::path"
@@ -1370,6 +1372,7 @@ class StdPathPrinter:
 
 class _iterator(Iterator):
 def __init__(self, impl, pathtype):
+self.pathtype = pathtype
 if impl:
 # We can't access _Impl::_M_size because _Impl is incomplete
 # so cast to int* to access the _M_size member at offset zero,
@@ -1402,7 +1405,7 @@ class StdPathPrinter:
 self.count = self.count + 1
 self.item = self.item + 1
 path = item['_M_pathname']
-t = StdPathPrinter(item.type.name, item)._path_type()
+t = StdPathPrinter(self.pathtype, item)._path_type()
 if not t:
 t = count
 return ('[%s]' % t, path)
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/filesystem-ts.cc 
b/libstdc++-v3/testsuite/libstdc++-prettyprinters/filesystem-ts.cc
new file mode 100644
index 000..692d79fa5a6
--- /dev/null
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/filesystem-ts.cc
@@ -0,0 +1,39 @@
+// { dg-options "-g -O0 -lstdc++fs" }
+// { dg-do run { target c++11 } }
+// { dg-require-filesystem-ts "" }
+
+// Copyright (C) 2020 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library.  This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Fou

Re: V3 [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions

[Jeff Law via Gcc-patches]

On 12/1/20 5:36 PM, H.J. Lu wrote:
> On Tue, Dec 1, 2020 at 4:04 PM Jeff Law  wrote:
>>
>>
>> On 11/17/20 6:20 AM, H.J. Lu via Gcc-patches wrote:
>>> On Mon, Nov 16, 2020 at 7:59 PM Hans-Peter Nilsson  
>>> wrote:
 On Fri, 13 Nov 2020, H.J. Lu via Gcc-patches wrote:
> Done.  Here is the updated patch.
 Hi.  I see a test-case for this kind of construct:

  int foo __attribute__((__used__, __section__ (".bar"))) = 42;

 and IIUC that it's handled as I'd hope (setting "R" on the named
 section, not another derived section), good.

 Could you also add a test-case that the same construct
 *without* a specific initializer is handled the same way?
 I.e.:
  int foo __attribute__((__used__, __section__ (".bar")));

>>> Done.  The only changes are
>>>
>>> /* { dg-final { scan-assembler ".data.used_bar_sec,\"awR\"" } } */
>>> ...
>>> int __attribute__((used,section(".data.used_bar_sec"))) used_bar;
>>>
>>> and 2 additional tests for -fcommon.
>>>
>>> Thanks.
>>>
>>>
>>> 0001-Use-SHF_GNU_RETAIN-to-preserve-symbol-definitions.patch
>>>
>>> From d19f2e2ec7f0f47121a2a4c05ffe20af8972c1bb Mon Sep 17 00:00:00 2001
>>> From: "H.J. Lu" 
>>> Date: Mon, 3 Feb 2020 11:55:43 -0800
>>> Subject: [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions
>>>
>>> In assemly code, the section flag 'R' sets the SHF_GNU_RETAIN flag to
>>> indicate that the section must be preserved by the linker.
>>>
>>> Add SECTION_RETAIN to indicate a section should be retained by the linker
>>> and set SECTION_RETAIN on section for the preserved symbol if assembler
>>> supports SHF_GNU_RETAIN.  All retained symbols are placed in separate
>>> sections with
>>>
>>>   .section .data.rel.local.preserved_symbol,"awR"
>>> preserved_symbol:
>>> ...
>>>   .section .data.rel.local,"aw"
>>> not_preserved_symbol:
>>> ...
>>>
>>> to avoid
>>>
>>>   .section .data.rel.local,"awR"
>>> preserved_symbol:
>>> ...
>>> not_preserved_symbol:
>>> ...
>>>
>>> which places not_preserved_symbol definition in the SHF_GNU_RETAIN
>>> section.
>>>
>>> gcc/
>>>
>>> 2020-11-XX  H.J. Lu  
>>>
>>>   * configure.ac (HAVE_GAS_SHF_GNU_RETAIN): New.  Define 1 if
>>>   the assembler supports marking sections with SHF_GNU_RETAIN flag.
>>>   * output.h (SECTION_RETAIN): New.  Defined as 0x400.
>>>   (SECTION_MACH_DEP): Changed from 0x400 to 0x800.
>>>   (default_unique_section): Add a bool argument.
>>>   * varasm.c (get_section): Set SECTION_RETAIN for the preserved
>>>   symbol with HAVE_GAS_SHF_GNU_RETAIN.
>>>   (resolve_unique_section): Used named section for the preserved
>>>   symbol if assembler supports SHF_GNU_RETAIN.
>>>   (get_variable_section): Handle the preserved common symbol with
>>>   HAVE_GAS_SHF_GNU_RETAIN.
>>>   (default_elf_asm_named_section): Require the full declaration and
>>>   use the 'R' flag for SECTION_RETAIN.
>>>   * config.in: Regenerated.
>>>   * configure: Likewise.
>>>
>>> gcc/testsuite/
>>>
>>> 2020-11-XX  H.J. Lu  
>>>   Jozef Lawrynowicz  
>>>
>>>   * c-c++-common/attr-used.c: Check the 'R' flag.
>>>   * c-c++-common/attr-used-2.c: Likewise.
>>>   * c-c++-common/attr-used-3.c: New test.
>>>   * c-c++-common/attr-used-4.c: Likewise.
>>>   * gcc.c-torture/compile/attr-used-retain-1.c: Likewise.
>>>   * gcc.c-torture/compile/attr-used-retain-2.c: Likewise.
>>>   * gcc.c-torture/compile/attr-used-retain-3.c: Likewise.
>>>   * gcc.c-torture/compile/attr-used-retain-4.c: Likewise.
>>>   * lib/target-supports.exp
>>>   (check_effective_target_R_flag_in_section): New proc.
>> Can we try to avoid the #if stuff, particulary in varasm.c.  We worked
>> pretty hard to reduce the amount of conditionally compiled code through
>> the years and we should try to avoid adding new instances.
>>
>> HAVE_GAS_SHF_GNU_RETAIN is going to be a compile-time constant, so it
>> should be just as efficient to do things like
>>
>> if (HAVE_GAS_SHF_GNU_RETAIN)
>>... whatever ...
> Fixed.
>
>> This has the advantage that the same code is presented to the
>> front-ends, so we're at lot less likely to stumble over set-but-not-used
>> warnings and the like that were so problematical a few years back.  In
>> fact, you use that style elsewhere in varasm.c :-)
>>
>>
>> I think you need to document the new effective target check in
>> doc/sourcebuild.texi
> Fixed.
>
>> With those changes this should be fine.
>>
> Here is the updated patch.   OK for master?
>
> Thanks.
>
>
> 0001-Use-SHF_GNU_RETAIN-to-preserve-symbol-definitions.patch
>
> From 5b31f3fdc891480da499049869cd5d0e2529ebd0 Mon Sep 17 00:00:00 2001
> From: "H.J. Lu" 
> Date: Mon, 3 Feb 2020 11:55:43 -0800
> Subject: [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions
>
> In assemly code, the section flag 'R' sets the SHF_GNU_RETAIN flag to
> indicate that the section must be preserved by the linker.
>
> Add SECTION_RETAIN to indicate a 

V3 [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions

[H.J. Lu via Gcc-patches]

On Tue, Dec 1, 2020 at 4:04 PM Jeff Law  wrote:
>
>
>
> On 11/17/20 6:20 AM, H.J. Lu via Gcc-patches wrote:
> > On Mon, Nov 16, 2020 at 7:59 PM Hans-Peter Nilsson  
> > wrote:
> >> On Fri, 13 Nov 2020, H.J. Lu via Gcc-patches wrote:
> >>> Done.  Here is the updated patch.
> >> Hi.  I see a test-case for this kind of construct:
> >>
> >>  int foo __attribute__((__used__, __section__ (".bar"))) = 42;
> >>
> >> and IIUC that it's handled as I'd hope (setting "R" on the named
> >> section, not another derived section), good.
> >>
> >> Could you also add a test-case that the same construct
> >> *without* a specific initializer is handled the same way?
> >> I.e.:
> >>  int foo __attribute__((__used__, __section__ (".bar")));
> >>
> > Done.  The only changes are
> >
> > /* { dg-final { scan-assembler ".data.used_bar_sec,\"awR\"" } } */
> > ...
> > int __attribute__((used,section(".data.used_bar_sec"))) used_bar;
> >
> > and 2 additional tests for -fcommon.
> >
> > Thanks.
> >
> >
> > 0001-Use-SHF_GNU_RETAIN-to-preserve-symbol-definitions.patch
> >
> > From d19f2e2ec7f0f47121a2a4c05ffe20af8972c1bb Mon Sep 17 00:00:00 2001
> > From: "H.J. Lu" 
> > Date: Mon, 3 Feb 2020 11:55:43 -0800
> > Subject: [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions
> >
> > In assemly code, the section flag 'R' sets the SHF_GNU_RETAIN flag to
> > indicate that the section must be preserved by the linker.
> >
> > Add SECTION_RETAIN to indicate a section should be retained by the linker
> > and set SECTION_RETAIN on section for the preserved symbol if assembler
> > supports SHF_GNU_RETAIN.  All retained symbols are placed in separate
> > sections with
> >
> >   .section .data.rel.local.preserved_symbol,"awR"
> > preserved_symbol:
> > ...
> >   .section .data.rel.local,"aw"
> > not_preserved_symbol:
> > ...
> >
> > to avoid
> >
> >   .section .data.rel.local,"awR"
> > preserved_symbol:
> > ...
> > not_preserved_symbol:
> > ...
> >
> > which places not_preserved_symbol definition in the SHF_GNU_RETAIN
> > section.
> >
> > gcc/
> >
> > 2020-11-XX  H.J. Lu  
> >
> >   * configure.ac (HAVE_GAS_SHF_GNU_RETAIN): New.  Define 1 if
> >   the assembler supports marking sections with SHF_GNU_RETAIN flag.
> >   * output.h (SECTION_RETAIN): New.  Defined as 0x400.
> >   (SECTION_MACH_DEP): Changed from 0x400 to 0x800.
> >   (default_unique_section): Add a bool argument.
> >   * varasm.c (get_section): Set SECTION_RETAIN for the preserved
> >   symbol with HAVE_GAS_SHF_GNU_RETAIN.
> >   (resolve_unique_section): Used named section for the preserved
> >   symbol if assembler supports SHF_GNU_RETAIN.
> >   (get_variable_section): Handle the preserved common symbol with
> >   HAVE_GAS_SHF_GNU_RETAIN.
> >   (default_elf_asm_named_section): Require the full declaration and
> >   use the 'R' flag for SECTION_RETAIN.
> >   * config.in: Regenerated.
> >   * configure: Likewise.
> >
> > gcc/testsuite/
> >
> > 2020-11-XX  H.J. Lu  
> >   Jozef Lawrynowicz  
> >
> >   * c-c++-common/attr-used.c: Check the 'R' flag.
> >   * c-c++-common/attr-used-2.c: Likewise.
> >   * c-c++-common/attr-used-3.c: New test.
> >   * c-c++-common/attr-used-4.c: Likewise.
> >   * gcc.c-torture/compile/attr-used-retain-1.c: Likewise.
> >   * gcc.c-torture/compile/attr-used-retain-2.c: Likewise.
> >   * gcc.c-torture/compile/attr-used-retain-3.c: Likewise.
> >   * gcc.c-torture/compile/attr-used-retain-4.c: Likewise.
> >   * lib/target-supports.exp
> >   (check_effective_target_R_flag_in_section): New proc.
> Can we try to avoid the #if stuff, particulary in varasm.c.  We worked
> pretty hard to reduce the amount of conditionally compiled code through
> the years and we should try to avoid adding new instances.
>
> HAVE_GAS_SHF_GNU_RETAIN is going to be a compile-time constant, so it
> should be just as efficient to do things like
>
> if (HAVE_GAS_SHF_GNU_RETAIN)
>... whatever ...

Fixed.

> This has the advantage that the same code is presented to the
> front-ends, so we're at lot less likely to stumble over set-but-not-used
> warnings and the like that were so problematical a few years back.  In
> fact, you use that style elsewhere in varasm.c :-)
>
>
> I think you need to document the new effective target check in
> doc/sourcebuild.texi

Fixed.

> With those changes this should be fine.
>

Here is the updated patch.   OK for master?

Thanks.

-- 
H.J.
From 5b31f3fdc891480da499049869cd5d0e2529ebd0 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" 
Date: Mon, 3 Feb 2020 11:55:43 -0800
Subject: [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions

In assemly code, the section flag 'R' sets the SHF_GNU_RETAIN flag to
indicate that the section must be preserved by the linker.

Add SECTION_RETAIN to indicate a section should be retained by the linker
and set SECTION_RETAIN on section for the preserved symbol if assembler
supports SHF_GNU_RETAIN.  All 

Re: [PATCH] [Refactor] [AVX512] Combine VI12_AVX512VL with VI48_AVX512VL into VI_AVX512VLBW

[Jeff Law via Gcc-patches]

On 11/30/20 10:17 PM, Hongtao Liu via Gcc-patches wrote:
> Hi:
> There're many pairs of define_insn/define_expand that are very similar
> to each other except mode iterator and condition. For these patterns
> VI12_AVX512VL are used under condition TARGET_AVX512BW, and
> VI48_AVX512VL are used under condition TARGET_AVX512F.
>
> This patch is about to introduce a new iterator VI_AVX512VLBW to
> combine a pair of those patterns into one.
>
> There are no functional changes, just code refactoring.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> gcc/ChangeLog
>
> * config/i386/sse.md (VI_AVX512VLBW): New mode iterator.
> (_ucmp3): Combine
> two patterns with mode iterator VI12_AVX512VL and VI48_AVX512VL
> into one pattern with mode iterator VI_AVX512VLBW.
> (vec_cmpu): Ditto.
> (_cvt2mask): Ditto.
> (_cvtmask2): Ditto.
> (*_cvtmask2): Ditto.
> (3_mask): Ditto.
> (*3_mask): Ditto.
> (_eq3): Ditto.
> (_eq3_1): Ditto.
> (_gt3): Ditto.
> (_andnot3_mask): Ditto.
> (abs2_mask): Ditto.
> (*_3): Combine from ...
> (*avx512f_3)
> and (3).
I'd suggest deferring to gcc-12 unless there is a strong need for this
cleanup to make fixing a bug easier.

jeff

Re: [PATCH] diagnostics: ignore -fmax-errors for ICE

[Jeff Law via Gcc-patches]

On 12/1/20 9:35 AM, Martin Liška wrote:
> Right now I see:
>
> ./xgcc -B. ~/Programming/testcases/json.i -c -O2 -fmax-errors=1
> /home/marxin/Programming/testcases/json.i: In function
> ‘json_variant_type’:
> /home/marxin/Programming/testcases/json.i:22:1: error: non-integral
> type switch statement
>    22 | }
>   | ^
> int *
> switch (v_2(D))  [INV], case 0B:  [INV], case 5B:
>  [INV], case 6B:  [INV], case 7B:  [INV], case 8B:
>  [INV]>
> compilation terminated due to -fmax-errors=1.
>
> with the patch I get:
>
> ./xgcc -B. ~/Programming/testcases/json.i -c -O2 -fmax-errors=1 -c
> /home/marxin/Programming/testcases/json.i: In function
> ‘json_variant_type’:
> /home/marxin/Programming/testcases/json.i:22:1: error: non-integral
> type switch statement
>    22 | }
>   | ^
> int *
> switch (v_2(D))  [INV], case 0B:  [INV], case 5B:
>  [INV], case 6B:  [INV], case 7B:  [INV], case 8B:
>  [INV]>
> during GIMPLE pass: iftoswitch
> /home/marxin/Programming/testcases/json.i:22:1: internal compiler
> error: verify_gimple failed
> 0xe4478c verify_gimple_in_cfg(function*, bool)
> /home/marxin/Programming/gcc/gcc/tree-cfg.c:5467
> 0xd201cf execute_function_todo
> /home/marxin/Programming/gcc/gcc/passes.c:2042
> 0xd2101c do_per_function
> /home/marxin/Programming/gcc/gcc/passes.c:1687
> 0xd2101c execute_todo
> /home/marxin/Programming/gcc/gcc/passes.c:2096
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
>
> gcc/ChangeLog:
>
> * diagnostic.c (diagnostic_report_diagnostic): ICE causes to
> terminate compiler immediately, so I guess it should be printed
> always.
OK
jeff

Re: [00/23] Make fwprop use an on-the-side RTL SSA representation

[Jeff Law via Gcc-patches]

On 11/30/20 5:03 PM, Michael Matz wrote:
> Hello,
>
> On Mon, 30 Nov 2020, Jeff Law wrote:
>
 So, then let's start with one of 
 the prime examples of SSA deconstruction problems, the lost swap, and how 
 it comes to be: we start with a swap:

   x = ..., y = ...
   if (cond)
 tmp=x, x=y, y=tmp

 (1) into SSA:

   x0 = ..., y0 = ...
   if (cond)
 tmp = x0, x1=y0, y1=tmp;
   x2 = PHI(x0,x1),  y2 = PHI(y0,y1)

 (2) copy-prop:

   x0 = ..., y0 = ...
   if (cond)
 ;
   x2 = PHI(x0,y0),  y2 = PHI(y0,x0)
>>> So the point is that this isn't what the RTL would look like even
>>> when using RTL SSA.  Putting y0 in x2 PHI and x0 in the y2 PHI is
>>> representationally invalid.
>>>
>>> Like I say, this isn't a “native” SSA form: it's just using SSA
>>> constructs to represent dataflow in normal RTL.
>> It appears that the PHI arguments have to be different instances of the
>> result.  So the case above can't happen, which helps, but I'm not sure
>> it's necessarily sufficient to avoid all the problems in this space.
>> IIRC you can get into a similar scenario by transformations that result
>> in overlapping lifetimes for different instances of the same object. 
>> They didn't necessarily overlap when the SSA form was created, but may
>> after things like CSE or copy propagation.
> I think the reasoning why this can't (or should not) happen is the 
> following: if different instances of the same objects (say, one before, 
> one after a modification) exist, they must necessarily be stored in 
> different pseudos (otherwise the RTL transformation itself was already 
> invalid), and that causes them to be invalid operands of the same PHI 
> node.  Ala:
>
> input:
>
>regA =  /1
>use1(regA)  /2
>regA += ... /3
>use2(regA)  /4
>
> let's try creating different instances of regA (from point 2 and 4) that 
> overlap, e.g. by swapping insns 2 and 3.  We _have_ to rename regA from 
> insn 3 into a new pseudo, otherwise the uses of 2 and 4 can't be 
> differentiated anymore, so:
>
>regA  =  /1
>regA' = regA
>regA' += /3'
>use1(regA)   /2
>use2(regA')  /4'
>
> So if Richards model constrains the pseudo PHI nodes such that regA and 
> regA' can't be operands of one, that might solve the issue, as both the 
> lost copy and the swap problem need overlaps of different values to occur.
Right.  I was thinking about cases where something like CSE on this form
transforms the RHS of some operation into an instance of a pseudo.  That
insn is now a copy and we propagate the RHS into the uses of the LHS. 
That extends the lifetime of the pseudo's instance.  The question is
whether or not those actions either create a lost copy/swap problem or
not within the on-the-side SSA representation and whether or not there
could be implications if that happens.

>
>> The fact that passes don't directly manipulate the PHIs definitely helps
>> as well.  But I've still got some reading to do in this space to refresh
>> my memory of the issues.
> AFAIU Richards approach is more comparable to factored def-use chains than 
> to real SSA, which might indeed have no issues, though I then think the 
> problem moves into keeping _those_ consistent with the real instruction 
> stream as it changes.
To some degree, the change in model moves where we have to tackle these
issues.  Instead of tackling them in the out-of-ssa phase, we instead
have to think more about them in the analysis/optimization phases.  We
already do that to some degree in the gimple SSA representation (for
things like SSA_NAMEs associated with abnormal edges).

jeff

Re: [patch][rtl-optimization][i386][pr97777] Fix a reg-stack df maintenance bug triggered by zero-call-used-regs pass.

[Jeff Law via Gcc-patches]

On 11/30/20 1:50 PM, Qing Zhao wrote:
> Hi, Jeff,
>
> Sorry for the late reply due to thanksgiving long weekend. 
>
>> On Nov 25, 2020, at 1:37 PM, Jeff Law > > wrote:
>>
>>
>>
>> On 11/19/20 8:59 AM, Qing Zhao via Gcc-patches wrote:
>>> Hi, 
>>>
>>> PR9 - ICE: in df_refs_verify, at df-scan.c:3991 with -O
>>> -ffinite-math-only -fzero-call-used-regs=all
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9
>>> 
>>>
>>> Is a bug triggered by the new pass zero-call-used-regs, however,
>>> it’s an old bug in the pass “reg-stack”.
>>> This pass does not correctly maintain the df information after
>>> transformation. 
>>>
>>> Since the transformation is reg-stack pass is quite complicate,
>>> involving both instruction changes and control
>>> Flow changes, I called “df_insn_rescan_all” after the transformation
>>> is done.
>>>
>>> The patch has been tested with bootstrap with
>>> --enable-checking=yes,rtl,df,extra, no regression. 
>>>
>>> Okay for commit?
>>>
>>> Qing
>>>
>>> From c2573c6c8552b7b4c2eedb0684ce48b5c11436ec Mon Sep 17 00:00:00 2001
>>> From: qing zhao 
>>> Date: Thu, 19 Nov 2020 16:46:50 +0100
>>> Subject: [PATCH] rtl-optimization: Fix data flow maintenance bug in
>>> reg-stack.c [pr9]
>>>
>>> reg-stack pass does not maintain the data flow information correctly.
>>> call df_insn_rescan_all after the transformation is done.
>>>
>>>    gcc/
>>> PR rtl-optimization/9
>>> * reg-stack.c (rest_of_handle_stack_regs): call
>>> df_insn_rescan_all if reg_to_stack return true.
>>>
>>> gcc/testsuite/
>>> PR rtl-optimization/9
>>> * gcc.target/i386/pr9.c: New test.
>> I'd like to see more analysis here.
>>
>> ie, precisely what data is out of date and why?
>
> For the simple testing case, what happened is, for the insn #6:
>
> (gdb) call debug_rtx(insn)
> (insn 6 26 7 2 (set (reg:XF 8 st [84])
>         (reg:XF 9 st(1) [85])) "t.c":4:10 134 {*movxf_internal}
>      (expr_list:REG_EQUAL (const_double:XF 0.0 [0x0.0p+0])
>         (nil)))
>
> After the following statement in reg-stack.c:
>    3080           control_flow_insn_deleted |= subst_stack_regs (insn,
> ®stack);
>
> This insn # 6 becomes:
> (gdb) call debug_rtx(insn)
> (insn 6 26 7 2 (set (reg:XF 8 st)
>         (reg:XF 8 st)) "t.c":4:10 134 {*movxf_internal}
>      (expr_list:REG_EQUAL (const_double:XF 0.0 [0x0.0p+0])
>         (nil)))
>
> However, there is no any df maintenance routine (for example,
> df_insn_rescan, etc) is called for this changed insn.
So we are clearing the x87 registers with that option.  Hence the change
in reg-stack behavior.  I'm a bit surprised by this as I don't see
clearing the x87 registers as particularly helpful from a security
standpoint.  But I haven't followed that discussion closely.


>
> As I checked, the transformation for this pass “stack” is quite
> complicated. In addition to the above register replacement,
> New insns might be inserted, and control flow might be changed, but
> for most of the transformations applied in this pass,
> There is no corresponding df maintenance routine is added for deferred
> df rescanning.
But this has been the case essentially for ever with reg-stack.  So
what's unclear to me is why it's suddenly a problem now.

Jeff

Re: [PATCH/RFC v2] Add -fdiagnostics-path-format=html [v2]

[Jeff Law via Gcc-patches]

On 11/10/20 9:08 AM, David Malcolm via Gcc-patches wrote:
> Here's an updated version of the HTML output idea from:
>   https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556848.html
>
> I reworked the HTML path output to show stack frames as well as just
> runs of events, using drop-shadows to give a 3D look.  The idea is to try
> to highlight the stack of frames as if it were an actual stack of
> overlapping cards.
>
> Updated HTML for the example from the earlier patch can be seen here:
>   
> https://dmalcolm.fedorapeople.org/gcc/2020-11-05/html-examples/test.c.path-1.html
> As before, other examples can be seen in that directory, such as:
>   Signal handler issue:
> 
> https://dmalcolm.fedorapeople.org/gcc/2020-11-05/html-examples/signal-1.c.path-1.html
>   Leak due to longjmp past a "free":
> 
> https://dmalcolm.fedorapeople.org/gcc/2020-11-05/html-examples/setjmp-7.c.path-1.html
>
> Other changes in v2:
> * switched j and k in keyboard navigation so that j is "next event"
> and k is "previous event"
> * fixed event element IDs, fixing a bug where it assumed they were in
>   ascending order
> * moved HTML printing code out of path_summary and event_range
> * more selftest coverage
>
> As before, this approach merely emits the path information; it doesn't
> capture the associated diagnostic.  I'm working on an alternate approach
> for v3 of the patch that does that; doing that requires reworking
> pretty_printer.
>
> I'm not sure on exactly the correct approach here; for v3 I'm
> experimenting with an "html" option for -fdiagnostics-format= which
> when selected would supplement the existing text output, by additionally
> writing out an HTML file for each diagnostic group, with path
> information captured there.  Doing it per group means that the classic
> "warning"/"note" pairs would be grouped together in that output.
>
> I'm not sure what that ought to do with paths though; part of the point
> of doing it is to have less verbose output on stderr whilst capturing
> the pertinent information "on the side" in the HTML file.
>
> Thoughts?
>
> Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu, FWIW.
>
> gcc/ChangeLog:
>   * common.opt (diagnostic_path_format): Add DPF_HTML.
>   * diagnostic-format-json.cc: Include "selftest.h".
>   * diagnostic-show-locus.c (colorizer::m_context): Replace with...
>   (colorizer::m_pp): ...this new field.
>   (layout::m_context): Make const.
>   (layout::m_is_html): New field.
>   (layout::m_html_label_writer): New field.
>   (colorizer::colorizer): Update for use of pp rather than context.
>   (colorizer::begin_state): Likewise.
>   (colorizer::finish_state): Likewise.
>   (colorizer::get_color_by_name): Likewise.
>   (layout::layout): Make "context" param const.  Add "pp", "is_html"
>   and "label_writer" params, with defaults.  Use them to initialize
>   new fields.  Update for change to m_colorizer.
>   (layout::print_source_line): Add HTML support.
>   (layout::start_annotation_line): Likewise.
>   (layout::print_annotation_line): Likewise.
>   (line_label::line_label): Make context const.  Add
>   "original_range_idx" param and use it to initialize...
>   (line_label::m_original_range_idx): ...this new field.
>   (layout::print_any_labels): Pass original index of range to
>   line_label ctor.  Add HTML support.
>   (get_affected_range): Make context const.
>   (get_printed_columns): Likewise.
>   (line_corrections::line_corrections): Likewise.
>   (line_corrections::m_context): Likewise.
>   (layout::print_line): Don't print fix-it hints for HTML support.
>   (diagnostic_show_locus_as_html): New.
>   (selftest::assert_html_eq): New.
>   (ASSERT_HTML_EQ): New.
>   (selftest::test_one_liner_simple_caret): Verify the HTML output.
>   (selftest::test_diagnostic_show_locus_fixit_lines): Likewise.
>   (selftest::test_html): New.
>   (selftest::diagnostic_show_locus_c_tests): Call it.
>   * diagnostic.c (diagnostic_show_any_path): Pass the location to
>   the print_path callback.
>   * diagnostic.h (enum diagnostic_path_format): Add DPF_HTML.
>   (diagnostic_context::num_html_paths): New field.
>   (diagnostic_context::print_path): Add location_t param.
>   (class html_label_writer): New.
>   (diagnostic_show_locus_as_html): New decl.
>   * doc/invoke.texi (Diagnostic Message Formatting Options): Add
>   "html" to -fdiagnostics-path-format=.
>   (-fdiagnostics-path-format=): Add html.
>   * pretty-print.c (pp_write_text_as_html_to_stream): New.
>   * pretty-print.h (pp_write_text_as_html_to_stream): New decl.
>   * selftest-diagnostic.c (selftest::html_printer::html_printer):
>   New ctor.
>   (selftest::html_printer::get_html_output): New.
>   * selftest-diagnostic.h (class selftest::html_printer): New.
>   * tree-diagnostic-path.cc: Define GCC

Re: [PATCH] add -Wmismatched-new-delete to middle end (PR 90629)

[Jeff Law via Gcc-patches]

On 11/17/20 11:02 AM, Martin Sebor wrote:
>
>>
>> If you're interested
>> torsion.usersys.redhat.com:/opt/notnfs/law/WARNINGS contains all the
>> lines with "warning:" from all the Fedora test builds. Warning (pun
>> intended), it's big...  10G, so don't try to download it :-)  But it
>> is faster than find | xargs zgrep across all the build logs :-)
>
> There are quite a few (411 instances of -Wmismatched-new-delete to
> be exact) but without more context (at least the informational notes)
> they're hard to analyze.  I looked at just the first one and it points
> to this bug:
>
> ./gengetopt/builds/80/log.gz:gengetopt.cc:581:12: warning: 'free'
> called on pointer returned from a mismatched allocation function
> [-Wmismatched-new-delete]
>
> gengetopt_create_option (gengetopt_option *&n, const char * long_opt,
> char short_opt,
>   const char * desc,
>   int type, int flagstat, int required,
>   const char * default_value,
>   const char * group_value,
>   const char * mode_value,
>   const char * type_str,
>   const AcceptedValues *acceptedvalues,
>   int multiple,
>   int argoptional)
> {
>   if ((long_opt == NULL) ||
>   (long_opt[0] == 0) ||
>   (desc == NULL))
>     return FOUND_BUG;
>
>   n = new gengetopt_option; <<< allocate by new
>   if (n == NULL)
>     return NOT_ENOUGH_MEMORY;
>
>   // here we will set required anyway
>   n->required_set = true;
>
>   n->long_opt = strdup (long_opt);
>   if (n->long_opt == NULL)
>     {
>   free (n); <<< deallocate by free
>   return NOT_ENOUGH_MEMORY;
>     }
>
> Based on what others have said about what some static analyzers
> report I expect this to be a common bug (the "operator delete"
> message accounts for 336 instances out of the 411).
Yea, I suspect there's a lot of these lying around and probably will
continue to do so as long as folks aren't using -Werror.  Hence my
desire to have an opt-in mechanism in Fedora that turns on -Werror
within redhat-rpm-config for opted-in packages.

>
>>> diff --git a/gcc/builtins.c b/gcc/builtins.c
>>> index 5d60eab6ba2..1b8a5b82dac 100644
>>> --- a/gcc/builtins.c
>>> +++ b/gcc/builtins.c
>>> @@ -12589,30 +12594,336 @@ maybe_emit_sprintf_chk_warning (tree exp,
>>> enum built_in_function fcode)
>>>   access_write_only);
>>>   }
>>>   -/* Emit warning if a free is called with address of a variable.  */
>>> +/* Return the location of the assignment STMT if it has one, or
>>> another
>>> +   assignment on the chain that has one.  Used to improve the location
>>> +   of informational notes.  */
>>>   -static void
>>> +static location_t
>>> +find_assignment_location (tree var)
>>> +{
>>> +  gimple *stmt = SSA_NAME_DEF_STMT (var);
>>> +
>>> +  for (gimple *asgn = stmt; ; )
>>> +    {
>>> +  if (gimple_has_location (asgn))
>>> +    return gimple_location (asgn);
>>> +
>>> +  if (!is_gimple_assign (asgn))
>>> +    break;
>>> +
>>> +  tree rhs = gimple_assign_rhs1 (asgn);
>>> +  if (TREE_CODE (rhs) != SSA_NAME)
>>> +    break;
>>> +
>>> +  asgn = SSA_NAME_DEF_STMT (rhs);
>>> +    }
>>
>> What is this code for ^^^
>>
>>
>> Under what conditions does the assignment not have a location?
>> Perhaps if it's a default definition?
>
> I've seen all sorts of assignments with no location, including
> ASSERT_EXPRs, BIT_AND_EXPRs, as well as MIN/MAX_EXPs, clobber
> statements and others.  I didn't try to understand the pattern
> behind them.
I'd rather not include that hunk and instead xfail any tests affected by
the missing locations until such time as we fix them rather than just
papering over the problem.  Fixing locations helps diagnostics, our
ability to suppress them via pragmas, etc.    So it's in our best
interest to fix these issues.

>
>> All the nonsense walking up the use-def chain seems unnecessary and
>> probably misleading when we actually issue the diagnostic. Why are
>> you going through the trouble to do that?
>
> The "nonsense" is me doing my best to provide at least some context
> for warnings that might otherwise not have any and be harder to track
> down to the root cause.  A message like:
>
>   warning: ‘free’ called on pointer ‘’ with nonzero offset
>
> with nothing else for a function hundreds of lines long makes it
> harder to track down the cause of the problem than with a note
> pointing to at least a location of the closest assignment to
> the unknown pointer.
>
> That said, in this patch the function is only used for constants
> and AFAICS, doesn't get exercised by any tests so it can probably
> be removed with no adverse effect.  I do expect it to need to come
> back in some form because of the missing location problem.  (It
> comes from a bigger patch in progress where it's used more
> extensively.)
ACK.  So let's avoid it for now and try to tackle the mis

Re: V2 [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions

[Jeff Law via Gcc-patches]

On 11/17/20 6:20 AM, H.J. Lu via Gcc-patches wrote:
> On Mon, Nov 16, 2020 at 7:59 PM Hans-Peter Nilsson  wrote:
>> On Fri, 13 Nov 2020, H.J. Lu via Gcc-patches wrote:
>>> Done.  Here is the updated patch.
>> Hi.  I see a test-case for this kind of construct:
>>
>>  int foo __attribute__((__used__, __section__ (".bar"))) = 42;
>>
>> and IIUC that it's handled as I'd hope (setting "R" on the named
>> section, not another derived section), good.
>>
>> Could you also add a test-case that the same construct
>> *without* a specific initializer is handled the same way?
>> I.e.:
>>  int foo __attribute__((__used__, __section__ (".bar")));
>>
> Done.  The only changes are
>
> /* { dg-final { scan-assembler ".data.used_bar_sec,\"awR\"" } } */
> ...
> int __attribute__((used,section(".data.used_bar_sec"))) used_bar;
>
> and 2 additional tests for -fcommon.
>
> Thanks.
>
>
> 0001-Use-SHF_GNU_RETAIN-to-preserve-symbol-definitions.patch
>
> From d19f2e2ec7f0f47121a2a4c05ffe20af8972c1bb Mon Sep 17 00:00:00 2001
> From: "H.J. Lu" 
> Date: Mon, 3 Feb 2020 11:55:43 -0800
> Subject: [PATCH] Use SHF_GNU_RETAIN to preserve symbol definitions
>
> In assemly code, the section flag 'R' sets the SHF_GNU_RETAIN flag to
> indicate that the section must be preserved by the linker.
>
> Add SECTION_RETAIN to indicate a section should be retained by the linker
> and set SECTION_RETAIN on section for the preserved symbol if assembler
> supports SHF_GNU_RETAIN.  All retained symbols are placed in separate
> sections with
>
>   .section .data.rel.local.preserved_symbol,"awR"
> preserved_symbol:
> ...
>   .section .data.rel.local,"aw"
> not_preserved_symbol:
> ...
>
> to avoid
>
>   .section .data.rel.local,"awR"
> preserved_symbol:
> ...
> not_preserved_symbol:
> ...
>
> which places not_preserved_symbol definition in the SHF_GNU_RETAIN
> section.
>
> gcc/
>
> 2020-11-XX  H.J. Lu  
>
>   * configure.ac (HAVE_GAS_SHF_GNU_RETAIN): New.  Define 1 if
>   the assembler supports marking sections with SHF_GNU_RETAIN flag.
>   * output.h (SECTION_RETAIN): New.  Defined as 0x400.
>   (SECTION_MACH_DEP): Changed from 0x400 to 0x800.
>   (default_unique_section): Add a bool argument.
>   * varasm.c (get_section): Set SECTION_RETAIN for the preserved
>   symbol with HAVE_GAS_SHF_GNU_RETAIN.
>   (resolve_unique_section): Used named section for the preserved
>   symbol if assembler supports SHF_GNU_RETAIN.
>   (get_variable_section): Handle the preserved common symbol with
>   HAVE_GAS_SHF_GNU_RETAIN.
>   (default_elf_asm_named_section): Require the full declaration and
>   use the 'R' flag for SECTION_RETAIN.
>   * config.in: Regenerated.
>   * configure: Likewise.
>
> gcc/testsuite/
>
> 2020-11-XX  H.J. Lu  
>   Jozef Lawrynowicz  
>
>   * c-c++-common/attr-used.c: Check the 'R' flag.
>   * c-c++-common/attr-used-2.c: Likewise.
>   * c-c++-common/attr-used-3.c: New test.
>   * c-c++-common/attr-used-4.c: Likewise.
>   * gcc.c-torture/compile/attr-used-retain-1.c: Likewise.
>   * gcc.c-torture/compile/attr-used-retain-2.c: Likewise.
>   * gcc.c-torture/compile/attr-used-retain-3.c: Likewise.
>   * gcc.c-torture/compile/attr-used-retain-4.c: Likewise.
>   * lib/target-supports.exp
>   (check_effective_target_R_flag_in_section): New proc.
Can we try to avoid the #if stuff, particulary in varasm.c.  We worked
pretty hard to reduce the amount of conditionally compiled code through
the years and we should try to avoid adding new instances.

HAVE_GAS_SHF_GNU_RETAIN is going to be a compile-time constant, so it
should be just as efficient to do things like

if (HAVE_GAS_SHF_GNU_RETAIN)
   ... whatever ...

This has the advantage that the same code is presented to the
front-ends, so we're at lot less likely to stumble over set-but-not-used
warnings and the like that were so problematical a few years back.  In
fact, you use that style elsewhere in varasm.c :-)


I think you need to document the new effective target check in
doc/sourcebuild.texi

With those changes this should be fine.

jeff

Re: [PATCH] x86: Add -mneeded for GNU_PROPERTY_X86_ISA_1_V[234] marker

[Jeff Law via Gcc-patches]

On 11/16/20 6:44 PM, H.J. Lu wrote:
> On Mon, Nov 16, 2020 at 4:58 PM Jeff Law  wrote:
>>
>> On 11/9/20 11:57 AM, H.J. Lu via Gcc-patches wrote:
>>> GCC 11 supports -march=x86-64-v[234] to enable x86 micro-architecture ISA
>>> levels:
>>>
>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97250
>>>
>>> Binutils has been updated to support GNU_PROPERTY_X86_ISA_1_V[234] marker:
>>>
>>> https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13
>>>
>>> with
>>>
>>> commit b0ab06937385e0ae25cebf1991787d64f439bf12
>>> Author: H.J. Lu 
>>> Date:   Fri Oct 30 06:49:57 2020 -0700
>>>
>>> x86: Support GNU_PROPERTY_X86_ISA_1_BASELINE marker
>>>
>>> and
>>>
>>> commit 32930e4edbc06bc6f10c435dbcc63131715df678
>>> Author: H.J. Lu 
>>> Date:   Fri Oct 9 05:05:57 2020 -0700
>>>
>>> x86: Support GNU_PROPERTY_X86_ISA_1_V[234] marker
>>>
>>> in x86 ELF binaries.
>>>
>>> Add -mneeded to emit GNU_PROPERTY_X86_ISA_1_NEEDED property to indicate
>>> the micro-architecture ISA level required to execute the binary.
>>>
>>> gcc/
>>>
>>>   * config.gcc: Replace cet.o with gnu-property.o.  Replace
>>>   i386/t-cet with i386/t-gnu-property.
>>>   * config/i386/cet.c: Renamed to ...
>>>   * config/i386/gnu-property.c: This.
>>>   (emit_gnu_property): New function.
>>>   (file_end_indicate_exec_stack_and_cet): Renamed to ...
>>>   (file_end_indicate_exec_stack_and_gnu_property): This.  Call
>>>   emit_gnu_property to generate GNU_PROPERTY_X86_FEATURE_1_AND and
>>>   GNU_PROPERTY_X86_ISA_1_NEEDED properties.
>>>   * config/i386/i386.opt (mneeded): New.
>>>   * config/i386/linux-common.h (file_end_indicate_exec_stack_and_cet):
>>>   Renamed to ...
>>>   (file_end_indicate_exec_stack_and_gnu_property): This.
>>>   (TARGET_ASM_FILE_END): Updated.
>>>   * config/i386/t-cet: Renamed to ...
>>>   * config/i386/t-gnu-property: This.
>>>   (cet.o): Renamed to ...
>>>   (gnu-property.o): This.
>>>   * doc/invoke.texi: Document -mneeded.
>>>
>>> gcc/testsuite/
>>>
>>>   * gcc.target/i386/x86-needed-1.c: New test.
>>>   * gcc.target/i386/x86-needed-2.c: Likewise.
>>>   * gcc.target/i386/x86-needed-3.c: Likewise.
>> Would it make sense to have -mneeded on by default if we detect a
>> suitable assembler?  The goal being that on the distro level we'd have
>> the appropriate markup for everything in the distro without having to
>> worry about injecting the -mneeded flag into every build.
> It is OK to set the file level USED ISA bits.  But the file level NEEDED
> ISA bits should be set by developers.   Otherwise, function multiversioning
> with AVX512 will lead to output marked with ISA v4 needed which isn't
> true.
True.  Function multi-versioning does turn a lot of traditional thinking
in this space on its side.

OK for the trunk.

jeff

Re: [PATCH] handle conditionals in -Wstringop-overflow et al. (PR 92936)

[Jeff Law via Gcc-patches]

On 11/30/20 5:58 PM, Martin Sebor wrote:
>
> What I meant was that the recursion in compute_objsize has been
> there in various forms since at least GCC 8 (it's still in other
> parts of GCC today), and it hasn't been a source of reported
> problems.
Understood.  Could be due to a variety of factors.  Having the clamps is
still useful.

>
> I also never did understand how following a use-def chain of
> SSA_NAMEs could have any but linear complexity.  For everything
> except PHIs the traversal is strictly linear; for PHIs, setting
> and testing the visited bitmap breaks cycles, again guaranteeing
> linear complexity.  For reference, here are the numbers I put
> together last year (this was for get_range_strlen_dynamic, not
> compute_objsize):
> https://gcc.gnu.org/pipermail/gcc-patches/2019-July/525000.html
The worst of these cases tend to be when each block has thousands of
PHIs, each of which have thousands of arguments.   This kind of scenario
happens with computed gotos, setjmp/longjmp, EH and similar
mechansisms.  We've gone to great lengths to try and factor the gotos,
landing pads, etc to keep the complexity of the CFG (and indirectly the
complexity of the PHIs) to a minimum.   Bugzilla is riddled with all
kinds of these issues.  If you were to start wandering through them
you'd see the name Brad Lucier show up often ;-)  His codes were often
the motivating case for various clamps.

So the walk up the use-def chains isn't usually too bad, though in
extreme cases, even the linear walk gets expensive.

>
> Anyway, whether it's actually needed or not, the limit's there
> now (in compute_objsize), and the caching should only make
> reaching it that much less likely.
>
Thanks.

jeff

Re: [PATCH v2] rs6000, vector integer multiply/divide/modulo instructions

[Carl Love via Gcc-patches]

Segher, Pat:

I have updated the patch to address the comments below.

On Wed, 2020-11-25 at 20:30 -0600, Segher Boessenkool wrote:
> On Tue, Nov 24, 2020 at 08:34:51PM -0600, Pat Haugen wrote:
> > On 11/24/20 8:17 PM, Pat Haugen via Gcc-patches wrote:
> > > On 11/24/20 12:59 PM, Carl Love via Gcc-patches wrote:
> > > > +(define_insn "modu_"
> > > > +  [(set (match_operand:VIlong 0 "vsx_register_operand" "=v")
> > > > +   (umod:VIlong (match_operand:VIlong 1
> > > > "vsx_register_operand" "v")
> > > > +(match_operand:VIlong 2
> > > > "vsx_register_operand" "v")))]
> > > > +  "TARGET_POWER10"
> > > > +  "vmodu %0,%1,%2"
> > > > +  [(set_attr "type" "vecdiv")
> > > > +   (set_attr "size" "128")])
> > > 
> > > We should only be setting "size" "128" for instructions that
> > > operate on scalar 128-bit data items (i.e. 'vdivesq' etc). Since
> > > the above insns are either V2DI/V4SI (ala VIlong mode_iterator),
> > > they shouldn't be marked as size 128. If you want to set the size
> > > based on mode, (set_attr "size" "") should do the trick I
> > > believe.
> > 
> > Well, after you update "(define_mode_attr bits" in rs6000.md for
> > V2DI/V4SI.
> 
> So far,  was only used for scalars.  I agree that for vectors
> it
> makes most sense to do the element size (because the vector size
> always
> is 128 bits, and for scheduling the element size can matter).  But,
> the
> definitions of  and  now say
> 
> ;; What data size does this instruction work on?
> ;; This is used for insert, mul and others as necessary.
> (define_attr "size" "8,16,32,64,128" (const_string "32"))
> 
> and
> 
> ;; How many bits in this mode?
> (define_mode_attr bits [(QI "8") (HI "16") (SI "32") (DI "64")
>(SF "32") (DF "64")])
> so those need a bit of update as well then :-)

I set the size based on the vector element size, extendeing the
define_mode_attr bits definition.  Please take a look at the updated
patch.  Hopefully I have this all correct.  Thanks.

Note, I retested the updated patch on 

  powerpc64le-unknown-linux-gnu (Power 9 LE)
  powerpc64le-unknown-linux-gnu (Power 10 LE)

Thanks for the help.

 Carl 

---
rs6000, vector integer multiply/divide/modulo instructions

2020-12-01  Carl Love  

gcc/
* config/rs6000/altivec.h (vec_mulh, vec_div, vec_dive, vec_mod): New
defines.
* config/rs6000/altivec.md (VIlong): Move define to file vsx.md.
* config/rs6000/rs6000-builtin.def (DIVES_V4SI, DIVES_V2DI,
DIVEU_V4SI, DIVEU_V2DI, DIVS_V4SI, DIVS_V2DI, DIVU_V4SI,
DIVU_V2DI, MODS_V2DI, MODS_V4SI, MODU_V2DI, MODU_V4SI,
MULHS_V2DI, MULHS_V4SI, MULHU_V2DI, MULHU_V4SI, MULLD_V2DI):
Add builtin define.
(MULH, DIVE, MOD):  Add new BU_P10_OVERLOAD_2 definitions.
* config/rs6000/rs6000-call.c (VSX_BUILTIN_VEC_DIV,
P10_BUILTIN_VEC_VDIVE, P10_BUILTIN_VEC_VMOD, P10_BUILTIN_VEC_VMULH):
New overloaded definitions.
(builtin_function_type) [P10V_BUILTIN_DIVEU_V4SI,
P10V_BUILTIN_DIVEU_V2DI, P10V_BUILTIN_DIVU_V4SI,
P10V_BUILTIN_DIVU_V2DI, P10V_BUILTIN_MODU_V2DI,
P10V_BUILTIN_MODU_V4SI, P10V_BUILTIN_MULHU_V2DI,
P10V_BUILTIN_MULHU_V4SI, P10V_BUILTIN_MULLD_V2DI]: Add case
statement for builtins.
* config/rs6000/vsx.md (VIlong_char): Add define_mod_attribute.
(UNSPEC_VDIVES, UNSPEC_VDIVEU): Add enum for UNSPECs.
(vsx_mul_v2di, vsx_udiv_v2di): Add if TARGET_POWER10 statement.
(dives_, diveu_, div3, uvdiv3,
mods_, modu_, mulhs_, mulhu_, mulv2di3):
Add define_insn, mode is VIlong.
* doc/extend.texi (vec_mulh, vec_mul, vec_div, vec_dive, vec_mod): Add
builtin descriptions.

gcc/testsuite/
* gcc.target/powerpc/builtins-1-p10-runnable.c: New test file.
---
 gcc/config/rs6000/altivec.h   |   5 +
 gcc/config/rs6000/altivec.md  |   2 -
 gcc/config/rs6000/rs6000-builtin.def  |  22 +
 gcc/config/rs6000/rs6000-call.c   |  49 +++
 gcc/config/rs6000/rs6000.md   |   3 +-
 gcc/config/rs6000/vsx.md  | 213 +++---
 gcc/doc/extend.texi   | 120 ++
 .../powerpc/builtins-1-p10-runnable.c | 398 ++
 8 files changed, 759 insertions(+), 53 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/powerpc/builtins-1-p10-runnable.c

diff --git a/gcc/config/rs6000/altivec.h b/gcc/config/rs6000/altivec.h
index e1884f51bd8..12ccbd2fc2f 100644
--- a/gcc/config/rs6000/altivec.h
+++ b/gcc/config/rs6000/altivec.h
@@ -750,6 +750,11 @@ __altivec_scalar_pred(vec_any_nle,
 #define vec_strir_p(a) __builtin_vec_strir_p (a)
 #define vec_stril_p(a) __builtin_vec_stril_p (a)
 
+#define vec_mulh(a, b) __builtin_vec_mulh ((a), (b))
+#define vec_div(a, b) __builtin_vec_div ((a), (b))
+#define vec_dive(

Re: [PATCH] Add feature test macro for atomic::wait

[Thomas Rodgers via Gcc-patches]

Tested x86_64-pc-linux-gnu, committed to trunk.

Jonathan Wakely writes:

> On 30/11/20 10:17 -0800, Thomas Rodgers wrote:
>>From: Thomas Rodgers 
>>
>>Adds __cpp_lib_atomic_wait feature test macro which was overlooked in
>>the initial commit of this feature. Replaces uses of
>>_GLIBCXX_HAVE_ATOMIC_WAIT.
>>
>>libstdc++-v3/ChangeLog:
>>
>>  * include/bits/atomic_base.h: Replace usage of
>>  _GLIBCXX_HAVE_ATOMIC_WAIT with __cpp_lib_atomic_wait.
>>  * include/bits/atomic_timed_wait.h: Likewise.
>>  * include/bits/atomic_wait.h: Define __cpp_lib_atomic_wait
>>  feature test macro.
>>  * include/bits/semaphore_base: Replace usage of
>>  _GLIBCXX_HAVE_ATOMIC_WAIT with __cpp_lib_atomic_wait.
>>  * include/std/atomic: Likewise.
>>  * include/std/latch: Likewise.
>>  * include/std/semaphore: Likewise.
>>  * include/std/version: Define __cpp_lib_atomic wait
>>  feature test macro and replace usage of
>>  _GLIBCXX_HAVE_ATOMIC_WAIT.
>>  * testsuite/29_atomics/atomic/wait_notify/1.cc: New test.
>>  * testsuite/29_atomics/atomic/wait_notify/2.cc: Likewise.
>>
>>---
>> libstdc++-v3/include/bits/atomic_base.h   | 36 +--
>> libstdc++-v3/include/bits/atomic_timed_wait.h |  5 +--
>> libstdc++-v3/include/bits/atomic_wait.h   |  3 +-
>> libstdc++-v3/include/bits/semaphore_base.h|  4 +--
>> libstdc++-v3/include/std/atomic   | 16 -
>> libstdc++-v3/include/std/latch|  4 +--
>> libstdc++-v3/include/std/semaphore|  4 +--
>> libstdc++-v3/include/std/version  |  7 ++--
>> .../29_atomics/atomic/wait_notify/1.cc| 28 +++
>> .../29_atomics/atomic/wait_notify/2.cc| 29 +++
>> 10 files changed, 98 insertions(+), 38 deletions(-)
>> create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/1.cc
>> create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/2.cc
>>
>>diff --git a/libstdc++-v3/include/bits/atomic_base.h 
>>b/libstdc++-v3/include/bits/atomic_base.h
>>index d0d962d3047..ad4e24b4d20 100644
>>--- a/libstdc++-v3/include/bits/atomic_base.h
>>+++ b/libstdc++-v3/include/bits/atomic_base.h
>>@@ -230,7 +230,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>   return __v == __GCC_ATOMIC_TEST_AND_SET_TRUEVAL;
>> }
>>
>>-#ifdef _GLIBCXX_HAVE_ATOMIC_WAIT
>>+#ifdef __cpp_lib_atomic_wait
>
> I've not always been consistent about using #if or #ifdef for
> __cpp_lib macros, but let's not make that worse in a single patch. I
> think we should just use #if for __cpp_lib macros. That affects
> several places in the patch.
>
>> _GLIBCXX_ALWAYS_INLINE void
>> wait(bool __old,
>>  memory_order __m = memory_order_seq_cst) const noexcept
>>@@ -253,7 +253,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> { std::__atomic_notify(&_M_i, true); }
>>
>> // TODO add const volatile overload
>>-#endif // HAVE_ATOMIC_WAIT
>>+#endif // __cpp_lib_atomic_wait
>> #endif // C++20
>>
>> _GLIBCXX_ALWAYS_INLINE void
>>@@ -604,7 +604,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> __cmpexch_failure_order(__m));
>>   }
>>
>>-#if __cplusplus > 201703L && defined _GLIBCXX_HAVE_ATOMIC_WAIT
>>+#if __cpp_lib_atomic_wait
>>   _GLIBCXX_ALWAYS_INLINE void
>>   wait(__int_type __old,
>>memory_order __m = memory_order_seq_cst) const noexcept
>>@@ -627,7 +627,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>   { std::__atomic_notify(&_M_i, true); }
>>
>>   // TODO add const volatile overload
>>-#endif // C++20 && HAVE_ATOMIC_WAIT
>>+#endif // __cpp_lib_atomic_wait
>>
>>   _GLIBCXX_ALWAYS_INLINE __int_type
>>   fetch_add(__int_type __i,
>>@@ -898,7 +898,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>> int(__m1), int(__m2));
>>   }
>>
>>-#if __cplusplus > 201703L && defined _GLIBCXX_HAVE_ATOMIC_WAIT
>>+#if __cpp_lib_atomic_wait
>>   _GLIBCXX_ALWAYS_INLINE void
>>   wait(__pointer_type __old,
>> memory_order __m = memory_order_seq_cst) noexcept
>>@@ -921,7 +921,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>   { std::__atomic_notify(&_M_p, true); }
>>
>>   // TODO add const volatile overload
>>-#endif // C++20 && HAVE_ATOMIC_WAIT
>>+#endif // __cpp_lib_atomic_wait
>>
>>   _GLIBCXX_ALWAYS_INLINE __pointer_type
>>   fetch_add(ptrdiff_t __d,
>>@@ -1011,7 +1011,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>   int(__success), int(__failure));
>>   }
>>
>>-#if __cplusplus > 201703L && defined _GLIBCXX_HAVE_ATOMIC_WAIT
>>+#if __cpp_lib_atomic_wait
>> template
>>   _GLIBCXX_ALWAYS_INLINE void
>>   wait(const _Tp* __ptr, _Val<_Tp> __old,
>>@@ -1036,7 +1036,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>>   { std::__atomic_notify(__ptr, true); }
>>
>>   // TODO add const volatile overload
>>-#endif // C++20 && HAVE_ATOMIC_WAIT
>>+#endif // __cpp_lib_atomic_wait
>>
>> template
>>   _GLIBCXX_ALWAYS_INLINE _T

Re: [PATCH] expansion: Further improve double-word modulo, division and divmod [PR97459]

[Jeff Law via Gcc-patches]

On 12/1/20 2:00 PM, Jakub Jelinek wrote:
> Hi!
>
> The following patch implements what Thomas wrote about, in particular
> that we can handle also double-word divison by the constants for which
> the earlier patch optimized modulo (if it would be otherwise a library
> call) and that we can also easily handle such constants shifted to the left.
> Unfortunately, seems CSE isn't able to optimize away the two almost
> identical sequences (one to compute remainder, one to compute quotient),
> probably because of the ADD_OVERFLOW introduced jumps, so the patch also
> adjusts expand_DIVMOD.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2020-12-01  Jakub Jelinek  
>
>   PR rtl-optimization/97459
>   * optabs.h (expand_doubleword_divmod): Declare.
>   * optabs.c (expand_doubleword_divmod): New function.
>   (expand_binop): Use it.
>   * internal-fn.c (expand_DIVMOD): Likewise.
>
>   * gcc.target/i386/pr97282.c (foo): Use 123456 divisor instead of
>   10.
>   * gcc.dg/pr97459-1.c (TESTS): Add tests for 10, 12 and
>   6144.
>   * gcc.dg/pr97459-2.c (TESTS): Likewise.
>   * gcc.dg/pr97459-3.c: New test.
>   * gcc.dg/pr97459-4.c: New test.
>   * gcc.dg/pr97459-5.c: New test.
>   * gcc.dg/pr97459-6.c: New test.
OK
jeff

Re: [PATCH] cache compute_objsize results in strlen/sprintf (PR 97373)

[Jeff Law via Gcc-patches]

On 12/1/20 2:21 PM, Martin Sebor wrote:
> On 12/1/20 1:57 PM, Martin Sebor wrote:
>> On 11/23/20 2:04 PM, Jeff Law wrote:
>>>
>>>
>>> On 11/4/20 5:58 PM, Martin Sebor via Gcc-patches wrote:
 To determine the target of a pointer expression and the offset into
 it, the increasingly widely used compute_objsize function traverses
 the IL following the DEF statements of pointer variables, aggregating
 offsets from POINTER_PLUS assignments along the way.  It does that
 for many statements that involve pointers, including calls to
 built-in functions and (so far only) accesses to char arrays.  When
 a function has many such statements with pointers to the same objects
 but with different offsets, the traversal ends up visiting the same
 pointer assignments repeatedly and unnecessarily.

 To avoid this repeated traversal, the attached patch adds the ability
 to cache results obtained in prior calls to the function.  The cache
 is optional and only used when enabled.

 To exercise the cache I have enabled it for the strlen pass (which
 is probably the heaviest compute_objsize user).  That happens to
 resolve PR 97373 which tracks the pass' failure to detect sprintf
 overflowing allocated buffers at a non-constant offset.  I thought
 about making this a separate patch but the sprintf/strlen changes
 are completely mechanical so it didn't seem worth the effort.

 In the benchmarking I've done the cache isn't a huge win there but
 it does have a measurable difference in the project I'm wrapping up
 where most pointer assignments need to be examined.  The space used
 for the cache is negligible on average: fewer than 20 entries per
 Glibc function and about 6 for GCC.  The worst case in Glibc is
 6 thousand entries and 10k in GCC.  Since the entries are sizable
 (216 bytes each) the worst case memory consumption can be reduced
 by adding a level of indirection.  A further savings can be obtained
 by replacing some of the offset_int members of the entries with
 HOST_WIDE_INT.

 The efficiency benefits of the cache should increase further as more
 of the access checking code is integrated into the same pass.  This
 should eventually include the checking currently done in the built-in
 expanders.

 Tested on x86_64-linux, along with Glibc and Binutils/GDB.

 Martin

 PS The patch add the new pointer_query class (loosely modeled on
 range_query) to builtins.{h,c}.  This should be only temporary,
 until the access checking code is moved into a file (and ultimately
 a pass) of its own.

 gcc-97373.diff

 PR middle-end/97373 - missing warning on sprintf into allocated
 destination

 gcc/ChangeLog:

 PR middle-end/97373
 * builtins.c (compute_objsize): Rename...
 (compute_objsize_r): to this.  Change order and types of
 arguments.
 Use new argument.  Adjust calls to self.
 (access_ref::get_ref): New member function.
 (pointer_query::pointer_query): New member function.
 (pointer_query::get_ref): Same.
 (pointer_query::put_ref): Same.
 (handle_min_max_size): Change order and types of arguments.
 (maybe_emit_free_warning): Add a test.
 * builtins.h (class pointer_query): New class.
 (compute_objsize): Declare an overload.
 * gimple-ssa-sprintf.c (get_destination_size):
 (handle_printf_call):
 * tree-ssa-strlen.c (adjust_last_stmt): Add an argument and use
 it.
 (maybe_warn_overflow): Same.
 (handle_builtin_strcpy): Same.
 (maybe_diag_stxncpy_trunc): Same.
 (handle_builtin_memcpy): Change argument type.  Adjust calls.
 (handle_builtin_strcat): Same.
 (handle_builtin_memset): Same.
 (handle_store): Same.
 (strlen_check_and_optimize_call): Same.
 (check_and_optimize_stmt): Same.
 (strlen_dom_walker): Add new data members.
 (strlen_dom_walker::before_dom_children): Use new member.
 (printf_strlen_execute): Dump cache performance counters.
 * tree-ssa-strlen.h (maybe_diag_stxncpy_trunc): Add argument.
 (handle_printf_call): Change argument type.

 gcc/testsuite/ChangeLog:

 PR middle-end/97373
 * gcc.dg/warn-strnlen-no-nul.c:
 * g++.dg/warn/Wmismatched-new-delete-2.C: New test.
 * gcc.dg/tree-ssa/builtin-sprintf-warn-25.c: New test.
>>> I'm going to hesitatingly ACK this.
>>
>> Besides rebasing the changes on top the latest trunk I've also
>> adjusted them to avoid the "inefficient hacks" I mentioned in
>> the subsequent patch(*).  They were not only inefficient but
>> also would have caused the function to return incorrect results
>> in some cases.  After retesting with Binutils/GDB and Glibc
>> I committed the attached patch in r11-5622.
>>
>

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Michael Meissner via Gcc-patches]

Note this is just to keep the gcc-patches archive up to date.  I originally
posted this reply but the attached config.log file was too big.  It was also
sent directly to Jonathan, and he replied.  So I canceled the gcc-patches post,
and I'm sending out this one with a bzip2's config.log:

On Tue, Dec 01, 2020 at 09:10:30PM +, Jonathan Wakely wrote:
> On Tue, 1 Dec 2020 at 19:13, Michael Meissner via Libstdc++
>  wrote:
> >
> > On Tue, Dec 01, 2020 at 04:04:30PM +, Jonathan Wakely wrote:
> > > On 01/12/20 15:10 +, Jonathan Wakely wrote:
> > > >On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:
> > > >>Jonathan, could you send a fresh set of patches (or at least 
> > > >>replacements)?  I
> > > >>tried installing the patches on a master branch I checked out this 
> > > >>morning, and
> > > >>I got two rejects:
> > > >
> > > >I don't understand why those chunks failed, but I'll rebase and send a
> > > >new patch ASAP.
> > >
> > > Here's the rebased patch, with regenerated autoconf files and a fix
> > > for the  header. I'd changed it since sending
> > > the previous patch, and broke the "there's more than one long double"
> > > case (i.e. the _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT case).
> >
> > Unfortunately this patch DOES NOT work at all.
> >
> > If I build a compiler with the configure option:
> > --with-long-double-format=ieee
> >
> > And I compile this simple program:
> >
> > #include 
> >
> > int main(int argc, char *argv[], char *envp[])
> > {
> >   std::cout << "Hello World!\n";
> >   return 0;
> > }
> >
> > I get all of these errors:
> 
> It works fine for me (see below). I think your symptoms are due to
> using a glibc that doesn't support the new long double, and so
> libstdc++ support for it is also disabled. You need at least glibc
> 2.32 for the libstdc++ changes to be enabled.

I am using the Advance Toolchain which includes GLIBC 2.32, which has the
necessary support.  I will include the config.log as an attachment.

Note, I am also using the patches I submitted around November 19th.

In particular, there is the patch that maps long double built-in names if long
double is IEEE 128-bit:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559659.html

I used the patch that tries to fix some problems with gnu attributes:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559657.html

I used the patch that fixes up the gnu attributes use in libgcc:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559660.html

I used the patch that adds float128 <-> Decimal conversions:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559661.html

I used the patch that allows -mabi={ieee,ibm}longdouble to override the default
configuration for long double == 64 bits, without having to use the
-mlong-double-64 option as well:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559660.html

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797


libstdc++-v3-config.log.bz2
Description: BZip2 compressed data

Re: [PATCH] [tree-optimization] Optimize max/min pattern with comparison

[Jeff Law via Gcc-patches]

On 11/30/20 7:00 PM, Eugene Rozenfeld wrote:
> Thank you for the review Jeff.
>
> I don't need to look at the opcode to know the result. The pattern will be 
> matched only in these 4 cases:
>
> X <= MAX(X, Y) -> true
> X > MAX(X, Y) -> false
> X >= MIN(X, Y) -> true
> X < MIN(X, Y) -> false
>
> So, the result will be true for GE_EXPR and LE_EXPR and false otherwise.
>
> I added two test files: one for positive cases and one for negative cases. 
> The updated patch is attached.
Thanks.  Installed.

jeff

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Michael Meissner via Gcc-patches]

On Tue, Dec 01, 2020 at 10:36:10PM +, Jonathan Wakely wrote:
> You need to run autoconf-2.69's autoreconf in the libstdc++-v3 source
> tree to regenerate configure, Makefile.in etc. Without doing that
> you're just running the same configure script as is on current trunk,
> and that doesn't even try looking for IEEE128 support in glibc, and so
> the new code in libstdc++ doesn't get enabled.
> 
> I've attached a complete patch including those generated files, and
> I've also pushed the branch to refs/users/redi/heads/ieee128-squash in
> the gcc.gnu.org Git repo. That branch includes your patch for PR
> libgcc/97543 which is required for some of the libstdc++ changes to
> work properly.

Sorry, I should have realized about needing to do autoconf.  Any way the new
patch builds the iostream version of hello world.  And it is going through the
rest of the build:

   1) Build 3 compilers with different long double formats;
   2) Build non-bootstrap compilers with the compilers in step 1;
   3) Build bootstrap compilers with the compilers in step 2;
   4) Build spec for the 2 128-bit long double types.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.ibm.com, phone: +1 (978) 899-4797

[committed] Fix mcore multilib specification

[Jeff Law via Gcc-patches]

Kito's recent change to multilib handling seems to have exposed a latent
mcore bug.

The mcore 210 does not support little endian.  Yet we try to build a
mcore-210 little-endian multilibs.

I don't know why this wasn't failing before, but clearly it's not
supposed to work.  This patch adjusts the multilib set to not generate
that particular library configuration.  The net result is mcore's libgcc
builds again, as does newlib.

Committing to the trunk,
Jeff


commit db365b61c53136fd6ccc1a9d4f3fc5c020c28bc3
Author: Jeff Law 
Date:   Tue Dec 1 16:23:05 2020 -0700

Fix mcore multilib specification

gcc
* config/mcore/t-mcore (MULTILIB_EXCEPTIONS): Define.

diff --git a/gcc/config/mcore/t-mcore b/gcc/config/mcore/t-mcore
index 0c8763a2739..638a2e0872f 100644
--- a/gcc/config/mcore/t-mcore
+++ b/gcc/config/mcore/t-mcore
@@ -23,7 +23,7 @@
 # MULTILIB_DIRNAMES= align8 align4
 # MULTILIB_MATCHES = 
 # MULTILIB_EXTRA_OPTS  = 
-# MULTILIB_EXCEPTIONS  =
 
+MULTILIB_EXCEPTIONS  = mlittle-endian/m210
 MULTILIB_OPTIONS = mbig-endian/mlittle-endian m210/m340
 MULTILIB_DIRNAMES= big little m210 m340

[PATCH v4] generate EH info for asm statements (PR93981)

[J.W. Jagersma via Gcc-patches]

The following patch extends the generation of exception handling
information, so that it is possible to catch exceptions thrown from
asm statements, when -fnon-call-exceptions is enabled.  Parts of the
gcc code already suggested this should be possible, but it was never
fully implemented.  Both volatile and non-volatile asms, including
asm goto, are now considered potentially throwing.

A new '-' constraint modifier is introduced, that allows users to
specify which asm outputs must be clobbered in case an exception is
thrown.  This also applies to the jump path for asm goto.

Three new test cases are added.  The target-dependent test should pass
on platforms where throwing from a signal handler is allowed.  The only
platform I am aware of where that is the case is *-linux-gnu, so it is
set to XFAIL on all others.

gcc/
2020-12-01  Jan W. Jagersma  

PR inline-asm/93981
* cfgexpand.c (expand_asm_stmt): Expand throwing asms into jump
insns.  Emit move insns across edges.
* gimplify.c (gimplify_asm_expr): Assign '-' constrained
outputs via a temporary.  Warn for other constraint modifiers
if a copy must be made.
* stmt.c (parse_output_constraint): Accept '-' modifier.
(parse_input_constraint): Don't accept '-' modifier.
* tree-cfg.c (make_edges_bb): Make EH edges for GIMPLE_ASM.
* tree-eh.c (lower_eh_constructs_2): Add case for GIMPLE_ASM.
(tree_could_trap_p): Return true for case ASM_EXPR.
(stmt_could_throw_p): Likewise, for GIMPLE_ASM.
* rtlanal.c (may_trap_p_1): Likewise, for ASM_OPERANDS.
* doc/extend.texi: Document the effects of constraint modifiers
on output semantics for throwing/jumping asms.
* doc/md.texi: Document new '-' constraint modifier.

gcc/testsuite/
2020-12-01  Jan W. Jagersma  

PR inline-asm/93981
* g++.target/i386/pr93981.C: New test.
* g++.dg/eh/pr93981-1.C: New test.
* g++.dg/eh/pr93981-2.C: New test.
---
 gcc/cfgexpand.c |  12 +-
 gcc/doc/extend.texi |   9 ++
 gcc/doc/md.texi |  26 +++-
 gcc/gimplify.c  |  41 ++-
 gcc/rtlanal.c   |   4 +-
 gcc/stmt.c  |  16 +--
 gcc/testsuite/g++.dg/eh/pr93981-1.C |  18 +++
 gcc/testsuite/g++.dg/eh/pr93981-2.C |  29 +
 gcc/testsuite/g++.target/i386/pr93981.C | 151 
 gcc/tree-cfg.c  |   2 +
 gcc/tree-eh.c   |   7 +-
 11 files changed, 291 insertions(+), 24 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/eh/pr93981-1.C
 create mode 100644 gcc/testsuite/g++.dg/eh/pr93981-2.C
 create mode 100644 gcc/testsuite/g++.target/i386/pr93981.C

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 7e0bdd58e85..a32e3637601 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -3496,7 +3496,7 @@ expand_asm_stmt (gasm *stmt)
   if (noutputs == 0 && nclobbers == 0)
 {
   /* No output operands: put in a raw ASM_OPERANDS rtx.  */
-  if (nlabels > 0)
+  if (stmt_ends_bb_p (stmt))
emit_jump_insn (body);
   else
emit_insn (body);
@@ -3504,7 +3504,7 @@ expand_asm_stmt (gasm *stmt)
   else if (noutputs == 1 && nclobbers == 0)
 {
   ASM_OPERANDS_OUTPUT_CONSTRAINT (body) = constraints[0];
-  if (nlabels > 0)
+  if (stmt_ends_bb_p (stmt))
emit_jump_insn (gen_rtx_SET (output_rvec[0], body));
   else 
emit_insn (gen_rtx_SET (output_rvec[0], body));
@@ -3570,7 +3570,7 @@ expand_asm_stmt (gasm *stmt)
  XVECEXP (body, 0, i++) = gen_rtx_CLOBBER (VOIDmode, clobbered_reg);
}
 
-  if (nlabels > 0)
+  if (stmt_ends_bb_p (stmt))
emit_jump_insn (body);
   else
emit_insn (body);
@@ -3585,9 +3585,7 @@ expand_asm_stmt (gasm *stmt)
 emit_insn (after_md_seq);
   if (after_rtl_seq)
 {
-  if (nlabels == 0)
-   emit_insn (after_rtl_seq);
-  else
+  if (stmt_ends_bb_p (stmt))
{
  edge e;
  edge_iterator ei;
@@ -3604,6 +3602,8 @@ expand_asm_stmt (gasm *stmt)
  insert_insn_on_edge (copy, e);
}
}
+  else
+   emit_insn (after_rtl_seq);
 }
 
   free_temp_slots ();
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 23ede966bae..4e1da68a85e 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -10009,6 +10009,15 @@ ensures that modifying @var{a} does not affect the 
address referenced by
 @var{b}. Otherwise, the location of @var{b} 
 is undefined if @var{a} is modified before using @var{b}.
 
+If the @code{asm} throws an exception (which is possible when
+@option{-fnon-call-exceptions} are enabled) or jumps to a goto label, the
+operand's validity is determined by the constraint modifier used.  For example,
+the @samp{-} modifier may be used to specify that the output must be considered
+clobb

Re: [pushed] Darwin, D : Adjust the X spec to cater for duplicate use.

[Joseph Myers]

On Tue, 1 Dec 2020, Iain Sandoe wrote:

> Joseph; I don’t know if you have any advice on a ‘better’ long-term
> solution; in some ways I am surprised that the compiler built with
> duplicate specifications for a flag - perhaps the uses merged in some
> way.  Since the use of ‘X’ in D is an upstream decision and the use of

It's fine to have an option supported by multiple languages (here Driver 
counts as a language) as long as the syntax in each language (regarding 
any option arguments etc.) is compatible.  There are several options that 
are language-specific options for C-family languages and for Fortran, but 
not for other languages, for example.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] if-to-switch: consider only integral types

[Jeff Law via Gcc-patches]

On 12/1/20 12:35 PM, Martin Liška wrote:
> It fixes ICE seen in the PR which is about gswitch statements
> where an index type should be only an integral type.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
>     PR tree-optimization/98084
>     * gimple-if-to-switch.cc (find_conditions): Consider only
>     integral types.
>
> gcc/testsuite/ChangeLog:
>
>     PR tree-optimization/98084
>     * gcc.dg/tree-ssa/pr98084.c: New test.
OK
jeff

Re: [PATCH] expansion: FIx up infinite recusion due to double-word modulo optimization

[Jeff Law via Gcc-patches]

On 12/1/20 2:07 PM, Jakub Jelinek wrote:
> Hi!
>
> Jeff has reported that my earlier patch broke rl78-elf, e.g. with
> unsigned short foo (unsigned short x) { return x % 7; }
> when compiled with -O2 -mg14.  The problem is that rl78 is a BITS_PER_WORD
> == 8 target which doesn't have 8-bit modulo or divmod optab, but has instead
> 16-bit divmod, so my patch attempted to optimize it, then called
> expand_divmod to do 8-bit modulo and that in turn tried to do 16-bit modulo
> again.
>
> The following patch fixes it in two ways.
> One is to not perform the optimization when we have {u,s}divmod_optab
> handler for the double-word mode, in that case it is IMHO better to just
> do whatever we used to do before.  This alone should fix the infinite
> recursion.  But I'd be afraid some other target might have similar problem
> and might not have a divmod pattern, but only say a library call.
> So the patch also introduces a methods argument to expand_divmod such that
> normally we allow everything that was allowed before (using libcalls and
> widening), but when called from these expand_doubleword*mod routines we
> restrict it to no widening and no libcalls.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2020-12-01  Jakub Jelinek  
>
>   * expmed.h (expand_divmod): Only declare if GCC_OPTABS_H is defined.
>   Add enum optabs_method argument defaulted to OPTAB_LIB_WIDEN.
>   * expmed.c: Include expmed.h after optabs.h.
>   (expand_divmod): Add methods argument, if it is not OPTAB_{,LIB_}WIDEN,
>   don't choose a wider mode, and pass it to other calls instead of
>   hardcoded OPTAB_LIB_WIDEN.  Avoid emitting libcalls if not
>   OPTAB_LIB or OPTAB_LIB_WIDEN.
>   * optabs.c: Include expmed.h after optabs.h.
>   (expand_doubleword_mod, expand_doubleword_divmod): Pass OPTAB_DIRECT
>   as last argument to expand_divmod.
>   (expand_binop): Punt if {s,u}divmod_optab has handler for double-word
>   int_mode.
>   * expr.c: Include expmed.h after optabs.h.
>   * explow.c: Include expmed.h after optabs.h.
OK.

jeff

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Jonathan Wakely via Gcc-patches]

On Tue, 1 Dec 2020 at 22:25, Michael Meissner  wrote:
>
> On Tue, Dec 01, 2020 at 09:10:30PM +, Jonathan Wakely wrote:
> > On Tue, 1 Dec 2020 at 19:13, Michael Meissner via Libstdc++
> >  wrote:
> > >
> > > On Tue, Dec 01, 2020 at 04:04:30PM +, Jonathan Wakely wrote:
> > > > On 01/12/20 15:10 +, Jonathan Wakely wrote:
> > > > >On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:
> > > > >>Jonathan, could you send a fresh set of patches (or at least 
> > > > >>replacements)?  I
> > > > >>tried installing the patches on a master branch I checked out this 
> > > > >>morning, and
> > > > >>I got two rejects:
> > > > >
> > > > >I don't understand why those chunks failed, but I'll rebase and send a
> > > > >new patch ASAP.
> > > >
> > > > Here's the rebased patch, with regenerated autoconf files and a fix
> > > > for the  header. I'd changed it since sending
> > > > the previous patch, and broke the "there's more than one long double"
> > > > case (i.e. the _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT case).
> > >
> > > Unfortunately this patch DOES NOT work at all.
> > >
> > > If I build a compiler with the configure option:
> > > --with-long-double-format=ieee
> > >
> > > And I compile this simple program:
> > >
> > > #include 
> > >
> > > int main(int argc, char *argv[], char *envp[])
> > > {
> > >   std::cout << "Hello World!\n";
> > >   return 0;
> > > }
> > >
> > > I get all of these errors:
> >
> > It works fine for me (see below). I think your symptoms are due to
> > using a glibc that doesn't support the new long double, and so
> > libstdc++ support for it is also disabled. You need at least glibc
> > 2.32 for the libstdc++ changes to be enabled.
>
> I am using the Advance Toolchain which includes GLIBC 2.32, which has the
> necessary support.  I will include the config.log as an attachment.

I see the problem. The patch I sent doesn't include the regenerated
files, as is normal for patches posted to the mailing lists.

You need to run autoconf-2.69's autoreconf in the libstdc++-v3 source
tree to regenerate configure, Makefile.in etc. Without doing that
you're just running the same configure script as is on current trunk,
and that doesn't even try looking for IEEE128 support in glibc, and so
the new code in libstdc++ doesn't get enabled.

I've attached a complete patch including those generated files, and
I've also pushed the branch to refs/users/redi/heads/ieee128-squash in
the gcc.gnu.org Git repo. That branch includes your patch for PR
libgcc/97543 which is required for some of the libstdc++ changes to
work properly.


patch.txt.bz2
Description: application/bzip

Re: [PATCH v2] tree-ssa-threadbackward.c (profitable_jump_thread_path): Do not allow __builtin_constant_p () before IPA.

[Jeff Law via Gcc-patches]

On 11/23/20 7:36 AM, Ilya Leoshkevich wrote:
> On Fri, 2020-11-20 at 12:14 -0700, Jeff Law wrote:
>> On 6/30/20 12:46 PM, Ilya Leoshkevich wrote:
>>> v1: https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547236.html
>>>
>>> This is the implementation of Jakub's suggestion: allow
>>> __builtin_constant_p () after IPA, but fold it into 0.  Smoke test
>>> passed on s390x-redhat-linux, full regtest and bootstrap are
>>> running on
>>> x86_64-redhat-linux.
>>>
>>> ---
>>>
>>> Linux Kernel (specifically, drivers/leds/trigger/ledtrig-cpu.c)
>>> build
>>> with GCC 10 fails on s390 with "impossible constraint".
>>>
>>> The problem is that jump threading makes __builtin_constant_p ()
>>> lie
>>> when it splits a path containing a non-constant expression in a way
>>> that on each of the resulting paths this expression is constant.
>>>
>>> Fix by disallowing __builtin_constant_p () on threading paths
>>> before
>>> IPA and fold it into 0 after IPA.
>>>
>>> gcc/ChangeLog:
>>>
>>> 2020-06-30  Ilya Leoshkevich  
>>>
>>> * tree-ssa-threadbackward.c (thread_jumps::m_allow_bcp_p): New
>>> member.
>>> (thread_jumps::profitable_jump_thread_path): Do not allow
>>> __builtin_constant_p () on threading paths unless m_allow_bcp_p
>>> is set.
>>> (thread_jumps::find_jump_threads_backwards): Set m_allow_bcp_p.
>>> (pass_thread_jumps::execute): Allow __builtin_constant_p () on
>>> threading paths after IPA.
>>> (pass_early_thread_jumps::execute): Do not allow
>>> __builtin_constant_p () on threading paths before IPA.
>>> * tree-ssa-threadupdate.c (duplicate_thread_path): Fold
>>> __builtin_constant_p () on threading paths into 0.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> 2020-06-30  Ilya Leoshkevich  
>>>
>>> * gcc.target/s390/builtin-constant-p-threading.c: New test.
>> So I'm finally getting back to this.  Thanks for your patience.
>>
>> It's a nasty little problem, and I suspect there's actually some
>> deeper
>> issues here.  While I'd like to claim its a bad use of b_c_p, I don't
>> think I can reasonably make that argument.
>>
>> So what we have is a b_c_p at the start of an if-else chain. 
>> Subsequent
>> tests on the "true" arm of the the b_c_p test may throw us off the
>> constant path (because the constants are out of range).  Once all the
>> tests are passed (it's constant and the constant is in range) the
>> true
>> arm's terminal block has a special asm that requires a constant
>> argument.   In the case where we get to the terminal block on the
>> true
>> arm, the argument to the b_c_p is used as the constant argument to
>> the
>> special asm.
>>
>> At first glace jump threading seems to be doing the right thing. 
>> Except
>> that we end up with two paths to that terminal block with the special
>> asm, one for each of the two constant arguments to the b_c_p call. 
>> Naturally since that same value is used in the asm, we have to
>> introduce
>> a PHI to select between them at the head of the terminal block.   Now
>> the argument in the asm is no longer constant and boom we fail.
>>
>> I briefly pondered if we should only throttle when the argument to
>> the
>> b_c_p is not used elsewhere.  But I think that just hides the problem
>> and with a little work I could probably extend the testcase to still
>> fail in that scenario.
>>
>> I also briefly pondered if we should isolate the terminal block as
>> well
>> (essentially creating one for each unique PHI argument).  We'd likely
>> only need to do that when there's an ASM in the terminal block, but
>> that
>> likely just papers over the problem as well since the ASM could be in
>> a
>> successor of the terminal block.
>>
>> I haven't thought real deeply about it, but I wouldn't be surprised
>> if
>> there's other passes that can trigger similar problems.  Aggressive
>> cross-jumping would be the most obvious, but some of the
>> hosting/sinking
>> of operations past PHIs would seem potentially problematical as well.
>>
>> Jakub suggestion might be the best one in this space.   I don't have
>> anything better right now.  The deeper questions about other passes
>> setting up similar scenarios can probably be punted, I'd expect
>> threading to be far and above the most common way for this to happen
>> and
>> I'd be comfortable faulting in investigation of other cases if/when
>> they
>> happen.
>>
>> So I retract my initial objections.  Let's go with the V2 patch.
>>
>>
>> jeff
> Hi Jeff,
>
> Thanks for having another look!
>
> I did x86_64 builds of SPEC and vmlinux, and it seems that in practice
> v2 does not have any benefit over v1.
>
> What do you think about going with the v1, which is less complex?
No strong opinions.  I think whichever is less invasive in terms of code
quality is probably the way to go.  What we want to avoid is suppressing
threading unnecessarily as that often leads to false positives from
middle-end based warnings.  Suppressing threading can also lead to build
failures in the kernel due to the

Re: [PATCH] introduce --param max-object-size

[Jeff Law via Gcc-patches]

On 11/30/20 3:21 PM, Martin Sebor wrote:
> On 11/30/20 1:29 PM, Jeff Law wrote:
>>
>>
>> On 11/17/20 7:09 PM, Martin Sebor wrote:
>>> On 11/16/20 4:54 PM, Jeff Law wrote:

 On 11/16/20 2:04 AM, Richard Biener via Gcc-patches wrote:
> On Sun, Nov 15, 2020 at 1:46 AM Martin Sebor via Gcc-patches
>  wrote:
>> GCC considers PTRDIFF_MAX - 1 to be the size of the largest object
>> so that the difference between a pointer to the byte just past its
>> end and the first one is no more than PTRDIFF_MAX.  This is too
>> liberal in LP64 on most systems because the size of the address
>> space is constrained to much less than that, both by the width
>> of the address bus for physical memory and by the practical
>> limitations of disk sizes for swap files.
> Shouldn't this be a target hook like MAX_OFILE_ALIGNMENT then?

 I think one could argue either way.  Yes, the absolutes are a function
 of the underlying hardware and it can change over the lifetime of a
 processor family which likey differs from MAX_OFILE_ALIGNMENT.


 A PARAM gives the developer  a way to specify the limit which is more
 flexible.


 What I'm not really not sure of is whether is really matters in
 practice
 for end users.
>>>
>>> I'd like to do two things with this change: 1) make it easier
>>> (and encourage users) to detect as early as possible more bugs
>>> due to excessive sizes in various function calls (malloc, memcpy,
>>> etc.), and 2) verify that GCC code uses the limit consistently
>>> and correctly.
>>>
>>> I envision the first would appeal to security-minded distros
>>> and other organizations that use GCC as their system compiler.
>>> For those, a target hook would be more convenient than a --param.
>>> But I also expect individual projects wanting to impose stricter
>>> limits than distros select.  For those, a --param is the only
>>> choice (aside from individual -Wlarger-than- options(*)).
>>>
>>> With this in mind, I think providing both a target hook and
>>> a --param has the best chance of achieving these goals.
>>>
>>> The attached patch does that.
>>>
>>> Martin
>>>
>>> [*] To enforce more realistic object size limits than PTRDIFF_MAX,
>>> GCC users today have to set no fewer than five (or six if we count
>>> -Wstack-usage) options: -Walloca-larger-than,
>>> -Walloc-size-larger-than, -Wframe-larger-than, -Wlarger-than, and
>>> -Wvla-larger-than.  The limits are all independent of one another.
>>> I expect providing a single configurable baseline value for all
>>> these options to use and refine to be helpful to these users.
>>>
>>> gcc-max-objsize.diff
>>>
>> The more I think about this, the more I think it's not really useful in
>> practice.
>>
>> I don't see distros using this flag as there's likely no good values a
>> distro could use that would likely catch bogus code without needlessly
>> flagging valid code.
>
> Red Hat documents 128TB of maximum x86_64 per-process virtual address
> space:
>
>   https://access.redhat.com/articles/rhel-limits
>
> My understanding is that no x86_64 implementation exists that supports
> objects larger than 2^48 bytes.  AFAIK, other 64-bit architectures and
> operating system have similar limits.  The Red Hat page mentions limits
> for all our supported architectures.
And are there any real world cases where lowering from PTRDIFF_MAX to
one of these limits actually matters in our ability to detect bogus
code?   I strongly suspect the answer is no.

>
>>
>> I don't see individual projects using this code either -- for the most
>> part I would not expect a project developer to be able to accurately
>> predict the maximum size of allocations they potentially perform and
>> then bake that into their build system.  There are exceptions (kernel &
>> embedded systems come immediately to mind).
>
> They can refer to documentation like the RHEL link above to figure
> that out.  But even with 64-bit addresses, the size of the virtual
> address space is limited by the amount of physical memory and
> the size of the swap file (limited by the size of the disk), and
> for practical purposes, by the transfer rate of the disk.  So with
> some math, those who care about these things can easily come up
> with a more realistic limit for their application than PTRDIFF_MAX.
Yes, they can, but I strongly suspect they won't.

>
>>
>> And finally, I'm really not a fan of --params for end-user needs.  Those
>> feel much more like options that we as GCC developers use to help
>> ourselves rather than something we encourage others to use.
>
> I don't insist on it to be a parameter.  Whatever other knob will
> work as well.  I just thought this is what parameters were for(*).
>
> Will you approve the patch with the parameter changed to an option?
> Say -fmax-object-size, or would I be wasting my time?
Like the other thread (I believe around loop unrolling heuristics) a
-f= option is just as bad as a param IMHO.

I won

Re: [PATCH] if-to-switch: Support chain with 2 BBs.

[Jeff Law via Gcc-patches]

On 12/1/20 6:57 AM, Martin Liška wrote:
> Hello.
>
> The following patch is a small tweak than enables more opportunities.
> It fixes bug in PR88702 and I see 54 transformations to happen in SPEC
> 2006.
> Apart from that, I fixed a minor issues which I spotted during bootstrap.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> 0001-if-to-switch-Support-chain-with-2-BBs.patch
>
> From a27dca2d5ef87b493d1ab50da68d0b24dc9fdd93 Mon Sep 17 00:00:00 2001
> From: Martin Liska 
> Date: Tue, 1 Dec 2020 12:18:46 +0100
> Subject: [PATCH] if-to-switch: Support chain with 2 BBs.
>
> As seen in the test-case, even 2 BBs can handle interesting
> cases covered by a jump table or a bit-test.
>
> gcc/ChangeLog:
>
>   PR tree-optimization/88702
>   * gimple-if-to-switch.cc (pass_if_to_switch::execute):
>   Require at least 2 BBs.
>   * gimple-if-to-switch.cc (find_conditions): Require
>   equal precision for low and high of a range.
>
> gcc/testsuite/ChangeLog:
>
>   PR tree-optimization/88702
>   * gcc.dg/tree-ssa/if-to-switch-9.c: New test.
OK
jeff

Re: [PATCH] use TYPE_SIZE instead of DECL_SIZE for classes (PR 97595)

[Martin Sebor via Gcc-patches]

On 11/24/20 1:09 PM, Jason Merrill wrote:

On 11/23/20 7:06 PM, Martin Sebor wrote:

On 11/16/20 11:54 PM, Jason Merrill wrote:

On 11/16/20 9:41 PM, Martin Sebor wrote:

The result of DECL_SIZE_UNIT doesn't always reflect the size
of data members of virtual classes.  This can lead to objects
of such types appearing smaller than they are to warnings like
-Warray-bounds or -Wstringop-overflow, causing false positives.

To avoid these false positives, the attached replaces the use
of DECL_SIZE_UNIT in component_ref_size in the middle end with
TYPE_SIZE_UNIT.


Unfortunately, that's not enough; the offset between the intermediate 
base and the virtual base could be greater than the TYPE_SIZE of the 
intermediate base:


extern "C" int printf (const char *, ...);

struct A { char ar1[24]; };
struct B: virtual A { };
struct C { char ar2[42]; };
struct D: B, C { };

int main()
{
   D d;
   printf ("size %d, offset %d\n", sizeof (B), d.ar1 - (char*)(B*)&d);
}

Here base C is allocated between base B and its virtual base A, so 
the offset between them is 50, while the size of B is only 32.


The difference between TYPE_SIZE and DECL_SIZE could be a way to 
recognize the case of bases with virtual bases, and then either hunt 
down all the virtual bases or just use the bounds of the enclosing 
most-derived object.


An advanced analysis of classes with virtual bases is beyond what
I have cycles to tackle at this point (it seems it would also need
to be done in the C++ front end?)  It will have to wait until I have
more time or the next stage 1.

So for now, I've changed component_ref_size to fail when DECL_SIZE
isn't equal TYPE_SIZE.


OK.


+    /* DECL_SIZE may be less than TYPE_SIZE in C++ when referring
+   to the type of a virtual base class which doesn't reflect
+   the size of the virtual's members (see pr97595).  */


The problem isn't with the virtual base class itself (A), but with 
the intermediate base class subobject (B), for which DECL_SIZE 
doesn't include the size of the virtual base A, because the A base 
subobject is allocated separately.


I've also adjusted the comments above the _SIZE macros in tree.h
to more closely reflect what happens there.  My main goal isn't
to describe when they don't match with perfect accuracy, just to
point that they may be unequal and (roughly) when.


Sure, but why not be precise?  e.g.

May be less than TYPE_SIZE for a C++ FIELD_DECL representing a base 
class subobject with its own virtual base classes (which are laid out 
separately).


I have committed the patch with the adjusted comment in r11-5628.

Martin

[committed] Fix more minor testsuite fallout from improved switch optimization

[Jeff Law via Gcc-patches]

pr96480 regressed on nds32le-elf after the recent switch table
improvements.  Options for this test were tweaked as part of those
changes, but they're insufficient to keep it from regressing on
nds32le-elf.  This patch disables jump table optimization on that test
which resolves the regression.

Pushing to the trunk.

jeff
commit cebf2847271b65159e4e687e38a3a64e148084f9
Author: Jeff Law 
Date:   Tue Dec 1 15:06:48 2020 -0700

Fix more minor testsuite fallout from improved switch optimization

gcc/testsuite
* tree-ssa/pr96480.c: Disable jump table optimization

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr96480.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr96480.c
index cc04721c1df..fc2103dc172 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr96480.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr96480.c
@@ -1,6 +1,6 @@
 /* PR tree-optimization/96480 */
 /* { dg-do compile } */
-/* { dg-options "-O2 -fdump-tree-optimized -fno-bit-tests" } */
+/* { dg-options "-O2 -fdump-tree-optimized -fno-bit-tests -fno-jump-tables" } 
*/
 /* { dg-final { scan-tree-dump " = _\[0-9]* <= 3;" "optimized" } } */
 
 int v[4];

Re: [wwwdocs] Document libstdc++ header dependency changes

[Jeff Law via Gcc-patches]

On 12/1/20 2:58 PM, Gerald Pfeifer wrote:
> On Thu, 26 Nov 2020, Jonathan Wakely via Gcc-patches wrote:
>>> Also explain how to replace dynamic exception specifications.
>> And a small correction.
> Ah, I was going to point that out. :-)
>
> Let's see how many ports/packages the header cleanup is going to break 
> this time.  Updating the default version of GCC in FreeBSD has proven a 
> painful endeavour the last few times (though the GCC 10 update is mostly 
> delayed due to stricter behavior on the Fortran side).
I've already fixed ~100 in Fedora...  Those fixes are slowly trickling
to the appropriate upstreams.

Jeff

Re: [PATCH] gcc-11/changes: Document new configure flag --enable-s390-excess-float-precision

[Gerald Pfeifer]

On Thu, 26 Nov 2020, Marius Hillenbrand via Gcc-patches wrote:
> To document the new behavior around FLT_EVAL_METHOD and configure flag 
> --enable-s390-excess-float-precision on s390, I propose this update to 
> the Release Notes. Please commit to git-wwwdocs if you agree.

Thank you, Marius, and thank you Jeff for committing this.

I applied the follow up below since when refering to the project,
as opposed to just the C compiler, we use GCC (as opposed to gcc).

Gerald


commit aaf1c5103a16fba11e8c89766931be50df8a1ec9
Author: Gerald Pfeifer 
Date:   Tue Dec 1 23:03:04 2020 +0100

Refer to our project as GCC

diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index cd6e28c1..ed289744 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -345,11 +345,11 @@ a work-in-progress.
   The behavior when compiling with -fexcess-precision=standard
   (e.g., implied by -std=c99) on s390(x) targets can now be
   controlled at configure time with the flag
-  --enable-s390-excess-float-precision. When enabled, gcc will
+  --enable-s390-excess-float-precision. When enabled, GCC will
   maintain previous behavior and evaluate float expressions in double
   precision, which aligns with the definition of float_t as
-  double. With the flag disabled, gcc will always evaluate
-  float expressions in single precision. In native builds, gcc will by
+  double. With the flag disabled, GCC will always evaluate
+  float expressions in single precision. In native builds, GCC will by
   default match the definition of float_t in the installed
   glibc.
   

[committed] wwwdocs: Spell front end that way

[Gerald Pfeifer]

According to our coding conventions we use "front end" for the
noun.  I changed this in the GCC 11 release notes and on the way
noticed GCC 8 also has an instance.

Pushed.

Gerald
---
 htdocs/gcc-11/changes.html | 2 +-
 htdocs/gcc-8/changes.html  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html
index 20f29677..cd6e28c1 100644
--- a/htdocs/gcc-11/changes.html
+++ b/htdocs/gcc-11/changes.html
@@ -249,7 +249,7 @@ a work-in-progress.
   
https://gcc.gnu.org/onlinedocs/jit/topics/expressions.html#c.gcc_jit_global_set_initializer";>gcc_jit_global_set_initializer
   
-  9 entrypoints for https://gcc.gnu.org/onlinedocs/jit/topics/asm.html";>directly embedding 
asm statements into a compile, analogous to inline asm in the 
C frontend
+  9 entrypoints for https://gcc.gnu.org/onlinedocs/jit/topics/asm.html";>directly embedding 
asm statements into a compile, analogous to inline asm in the 
C front end
 
   
 
diff --git a/htdocs/gcc-8/changes.html b/htdocs/gcc-8/changes.html
index 83e57db1..638782e8 100644
--- a/htdocs/gcc-8/changes.html
+++ b/htdocs/gcc-8/changes.html
@@ -867,7 +867,7 @@ $ gcc templates-2.cc -fdiagnostics-show-template-tree 
-fno-elide-type
 stored in the heap are scanned precisely.
 
   Escape analysis is fully implemented and enabled by default in
-the Go frontend.  This significantly reduces the number of heap
+the Go front end.  This significantly reduces the number of heap
 allocations by allocating values on the stack instead.
 
 
-- 
2.29.2

Re: [PATCH] detect allocation/deallocation mismatches in user-defined functions (PR94527)

[Jeff Law via Gcc-patches]

On 12/1/20 10:14 AM, Martin Sebor wrote:
> On 11/30/20 3:53 PM, Jeff Law wrote:
>>
>>
>> On 11/13/20 2:45 PM, Martin Sebor via Gcc-patches wrote:
>>> Bug 94527 is request from the kernel developers for an attribute
>>> to indicate that a user-defined function deallocates an object
>>> allocated by an earlier call to an allocation function.  Their
>>> goal is to detect misuses of such functions and the pointers or
>>> objects returned from them.
>>>
>>> The recently submitted patches(*) enable the detection of a subset
>>> of such misuses for standard allocation functions like malloc and
>>> free, but those are just a small fraction of allocation/deallocation
>>> functions used in practice, and only rarely used in the kernel
>>> (mostly in utility programs). The attached patch extends attribute
>>> malloc to enable this detection also for user-defined functions.
>>>
>>> The design extends attribute malloc to accept one or two optional
>>> arguments: one naming a deallocation function that deallocates
>>> pointers returned from the malloc-like function, and another to
>>> denote the position of the pointer argument in the deallocation
>>> functions parameter list.  Any number of deallocators can be
>>> associated with any number of allocators.  This makes it possible
>>> to annotate, for example, all the POSIX  functions that
>>> open and close FILE streams and detect mismatches between any
>>> pairs that aren't suitable (in addition to calling free on
>>> a FILE* returned from fopen, for instance).
>>>
>>> An association with an allocator results in adding an internal
>>> "*dealloc" attribute to the deallocator so that the former can
>>> be quickly looked up based on a call to the latter.
>>>
>>> Tested on x86_64-linux + Glibc & Binutils/GDB (no instances
>>> of the new warnings).
>>>
>>> Martin
>>>
>>> [*] Prerequisite patch
>>> add -Wmismatched-new-delete to middle end (PR 90629)
>>> https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557987.html
>>>
>>> PS In pr94527 Jonathan notes that failing to properly match pairs
>>> of calls isn't limited to APIs that return pointers and applies
>>> to other kinds of "handles" including integers (e.g., the POSIX
>>> open/close APIs), and a detection of such mismatches would be
>>> helpful as well.  David submitted a prototype of this for
>>> the analyzer here:
>>> https://gcc.gnu.org/pipermail/gcc-patches/2020-October/44.html
>>> I chose not to implement nonpointer detection for some of the same
>>> reasons as mentioned in comment #8 on the bug (and also because
>>> there's no support for it in the machinery I use).  I also didn't
>>> use the same attribute as David, in part because I think it's better
>>> to provide separate attributes for pointer APIs and for others
>>> (integers), and in part also because the deallocated_by attribute
>>> design as is cannot accommodate my goal of supporting app standard
>>> functions (including the  freopen which "deallocates"
>>> the third argument).
>>>
>>> gcc-94527.diff
>>>
>>> PR middle-end/94527 - Add an __attribute__ that marks a function as
>>> freeing an object
>>>
>>> gcc/ChangeLog:
>>>
>>> PR middle-end/94527
>>> * builtins.c (gimple_call_alloc_p): Handle user-defined functions.
>>> (fndecl_alloc_p): New helper.
>>> (call_dealloc_argno): New helper.
>>> (gimple_call_dealloc_p): Call it.
>>> (call_dealloc_p): Same.
>>> (matching_alloc_calls_p): Handle user-defined functions.
>>> (maybe_emit_free_warning): Same.
>>> * doc/extend.texi (attribute malloc): Update.
>>> * doc/invoke.texi (-Wmismatched-dealloc): Document new option.
>>>
>>> gcc/c-family/ChangeLog:
>>>
>>> PR middle-end/94527
>>> * c-attribs.c (handle_dealloc_attribute): New function.
>>> (handle_malloc_attribute): Handle argument forms of attribute.
>>> * c.opt (-Wmismatched-dealloc): New option.
>>> (-Wmismatched-new-delete): Update description.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> PR middle-end/94527
>>> * g++.dg/warn/Wmismatched-dealloc-2.C: New test.
>>> * g++.dg/warn/Wmismatched-dealloc.C: New test.
>>> * gcc.dg/Wmismatched-dealloc.c: New test.
>>> * gcc.dg/attr-malloc.c: New test.
>> OK once prereq is wrapped up.
>
> Presumably you're referring to this patch:
>   https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557987.html
> Is there something I need to do to move it forward?  (I'm
> assuming you're still reviewing the rest of the patch so
> please let me know if you're waiting for me to remove
> the objectionable function first.)
Yes, that's the one.  I'm hoping to get to your reply today...

jeff

Re: [wwwdocs] Document libstdc++ header dependency changes

[Gerald Pfeifer]

On Thu, 26 Nov 2020, Jonathan Wakely via Gcc-patches wrote:
>> Also explain how to replace dynamic exception specifications.
> And a small correction.

Ah, I was going to point that out. :-)

Let's see how many ports/packages the header cleanup is going to break 
this time.  Updating the default version of GCC in FreeBSD has proven a 
painful endeavour the last few times (though the GCC 10 update is mostly 
delayed due to stricter behavior on the Fortran side).

Cheers,
Gerald

Re: [ Preprocessor ] [ Common ] Feature: Macros for identifying the wide and narrow execution string literal encoding

[Jeff Law via Gcc-patches]

On 11/23/20 1:40 PM, JeanHeyd Meneide wrote:
> Dear Jeff,
>
> On Mon, Nov 23, 2020 at 3:02 PM Jeff Law  wrote:
>> You use a getter function to retrieve the value of ret.to, which is
>> fine.  Is there a specific reason why you're not using a setter function
>> to save the value?
>  I did this because I have access to ret.to in the libcpp
> functions! Outside, the structure of that type is unknown and only a
> pointer, so it needs the getter function.
Thanks.  I've fixed up the ChangeLog entry and pushed the patch to the
trunk.

Jeff

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Jonathan Wakely via Gcc-patches]

On Tue, 1 Dec 2020 at 21:10, Jonathan Wakely  wrote:
>
> On Tue, 1 Dec 2020 at 19:13, Michael Meissner via Libstdc++
>  wrote:
> >
> > On Tue, Dec 01, 2020 at 04:04:30PM +, Jonathan Wakely wrote:
> > > On 01/12/20 15:10 +, Jonathan Wakely wrote:
> > > >On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:
> > > >>Jonathan, could you send a fresh set of patches (or at least 
> > > >>replacements)?  I
> > > >>tried installing the patches on a master branch I checked out this 
> > > >>morning, and
> > > >>I got two rejects:
> > > >
> > > >I don't understand why those chunks failed, but I'll rebase and send a
> > > >new patch ASAP.
> > >
> > > Here's the rebased patch, with regenerated autoconf files and a fix
> > > for the  header. I'd changed it since sending
> > > the previous patch, and broke the "there's more than one long double"
> > > case (i.e. the _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT case).
> >
> > Unfortunately this patch DOES NOT work at all.
> >
> > If I build a compiler with the configure option:
> > --with-long-double-format=ieee
> >
> > And I compile this simple program:
> >
> > #include 
> >
> > int main(int argc, char *argv[], char *envp[])
> > {
> >   std::cout << "Hello World!\n";
> >   return 0;
> > }
> >
> > I get all of these errors:
>
> It works fine for me (see below). I think your symptoms are due to
> using a glibc that doesn't support the new long double, and so
> libstdc++ support for it is also disabled. You need at least glibc
> 2.32 for the libstdc++ changes to be enabled.

I should improve the failure mode (maybe refuse to compile anything
using the C++ library headers if __LONG_DOUBLE_IEEE128__ is defined
and __ieee128 support was disabled due to the missing glibc
dependency) but that hasn't been a priority. Making the C++ library
support __ieee128 on a machine that doesn't even have libc support for
it isn't possible, so I didn't spend time on that use case. It doesn't
work, and it's not going to work.

Re: [PING] [PATCH] libstdc++: Pretty printers for std::_Bit_reference, std::_Bit_iterator and std::_Bit_const_iterator

[Jonathan Wakely via Gcc-patches]

On 27/11/20 16:33 +, Jonathan Wakely wrote:

On 25/11/20 15:05 +0100, Michael Weghorn via Libstdc++ wrote:

I'd like to ping for this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553870.html


Thanks, I'll take another look next week.


I've applied the patch now, thanks.

I adjusted it slightly, to add a test for const_iterator to the C++98
test, simple.cc, consistent with the C++11 one, simple11.cc

Tested powerpc64le-linux, committed to trunk.

Thanks again for the patch, and your patience.



Michael

On 11/10/2020 19.22, Michael Weghorn via Gcc-patches wrote:

On 22/09/2020 12.04, Jonathan Wakely wrote:

On 14/09/20 16:49 +0200, Michael Weghorn via Libstdc++ wrote:

Hi,

the attached patch implements pretty printers relevant for iteration
over std::vector, thus handling the TODO
added in commit 36d0dada6773d7fd7c5ace64c90e723930a3b81e
("Have std::vector printer's iterator return bool for vector",
2019-06-19):

   TODO add printer for vector's _Bit_iterator and
_Bit_const_iterator

Tested on x86_64-pc-linux-gnu (Debian testing).

I haven't filed any copyright assignment for GCC yet, but I'm happy to
do so when pointed to the right place.


Thanks for the patch! I'll send you the form to start the copyuright
assignment process.




Thanks! The copyright assignment is done now. Is there anything else to
do from my side at the moment?



commit 39836f8324d819459cb21198e95b993588c6a2b1
Author: Michael Weghorn 
Date:   Tue Dec 1 21:19:20 2020

libstdc++: Pretty printers for _Bit_reference and _Bit_iterator

'std::_Bit_iterator' and 'std::_Bit_const_iterator' are the iterators
used by 'std::vector'.
'std::_Bit_reference' is e.g. used in range-based for loops over
'std::vector'  like

std::vector vb {true, false, false};
for (auto b : vb) {
// b is of type std::_Bit_reference here
// ...
}

Like iterators of vectors for other types, the actual value is printed.

libstdc++-v3/ChangeLog:

* python/libstdcxx/v6/printers.py (StdBitIteratorPrinter)
(StdBitReferencePrinter): Add pretty-printers for
_Bit_reference, _Bit_iterator and _Bit_const_iterator.
* testsuite/libstdc++-prettyprinters/simple.cc: Test
std::_Bit_reference, std::_Bit_iterator and
std::_Bit_const_iterator.
* testsuite/libstdc++-prettyprinters/simple11.cc: Likewise.

diff --git a/libstdc++-v3/python/libstdcxx/v6/printers.py b/libstdc++-v3/python/libstdcxx/v6/printers.py
index c0f061f79c1..478e44eefdf 100644
--- a/libstdc++-v3/python/libstdcxx/v6/printers.py
+++ b/libstdc++-v3/python/libstdcxx/v6/printers.py
@@ -479,7 +479,27 @@ class StdVectorIteratorPrinter:
 return 'non-dereferenceable iterator for std::vector'
 return str(self.val['_M_current'].dereference())
 
-# TODO add printer for vector's _Bit_iterator and _Bit_const_iterator
+class StdBitIteratorPrinter:
+"Print std::vector's _Bit_iterator and _Bit_const_iterator"
+
+def __init__(self, typename, val):
+self.val = val
+
+def to_string(self):
+if not self.val['_M_p']:
+return 'non-dereferenceable iterator for std::vector'
+return bool(self.val['_M_p'].dereference() & (1 << self.val['_M_offset']))
+
+class StdBitReferencePrinter:
+"Print std::_Bit_reference"
+
+def __init__(self, typename, val):
+self.val = val
+
+def to_string(self):
+if not self.val['_M_p']:
+return 'invalid std::_Bit_reference'
+return bool(self.val['_M_p'].dereference() & (self.val['_M_mask']))
 
 class StdTuplePrinter:
 "Print a std::tuple"
@@ -1965,6 +1985,12 @@ def build_libstdcxx_dictionary ():
 StdDequeIteratorPrinter)
 libstdcxx_printer.add_version('__gnu_cxx::', '__normal_iterator',
   StdVectorIteratorPrinter)
+libstdcxx_printer.add_version('std::', '_Bit_iterator',
+  StdBitIteratorPrinter)
+libstdcxx_printer.add_version('std::', '_Bit_const_iterator',
+  StdBitIteratorPrinter)
+libstdcxx_printer.add_version('std::', '_Bit_reference',
+  StdBitReferencePrinter)
 libstdcxx_printer.add_version('__gnu_cxx::', '_Slist_iterator',
   StdSlistIteratorPrinter)
 libstdcxx_printer.add_container('std::', '_Fwd_list_iterator',
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc b/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc
index 4b44be594f5..9821d1805cf 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/simple.cc
@@ -127,6 +127,37 @@ main()
   vb.erase(vb.begin());
 // { dg-final { regexp-test vb {std::(__debug::)?vector of length 5, capa

[committed] Minor testsuite fixes after recent switch statement improvements

[Jeff Law via Gcc-patches]

Martin L's recent switch table improvements are compromising
gcc.dg/pr46309-2.c on a variety of targets.  They turn the series of if
statements into a switch, then convert that into a relatively simple
overflow test.  The net result is there's nothing interesting left for
tree-ssa-reassoc which is what the test is supposed to be verifying.

The right thing to do here is avoid the conversions which in turn leaves
the IL in the proper state for checking tree-ssa-reassoc's behavior.

I've pushed this to the trunk.

Jeff
commit 968666a011b904f70d12e52180d361faaedfd3a2
Author: Jeff Law 
Date:   Tue Dec 1 14:27:38 2020 -0700

Fix compromised tests after recent switch table improvements

gcc/testsuite
* gcc.dg/pr46309-2.c: Add -fno-bit-tests and -fno-jump-tables
to avoid compromising the test.

diff --git a/gcc/testsuite/gcc.dg/pr46309-2.c b/gcc/testsuite/gcc.dg/pr46309-2.c
index f56df42935c..2903fff225a 100644
--- a/gcc/testsuite/gcc.dg/pr46309-2.c
+++ b/gcc/testsuite/gcc.dg/pr46309-2.c
@@ -1,6 +1,6 @@
 /* PR tree-optimization/46309 */
 /* { dg-do compile } */
-/* { dg-options "-O2 -fno-ipa-icf -fdump-tree-reassoc-details" } */
+/* { dg-options "-O2 -fno-ipa-icf -fno-jump-tables -fno-bit-tests 
-fdump-tree-reassoc-details" } */
 
 int foo (void);
 

Re: [PATCH] cache compute_objsize results in strlen/sprintf (PR 97373)

[Martin Sebor via Gcc-patches]

On 12/1/20 1:57 PM, Martin Sebor wrote:

On 11/23/20 2:04 PM, Jeff Law wrote:



On 11/4/20 5:58 PM, Martin Sebor via Gcc-patches wrote:

To determine the target of a pointer expression and the offset into
it, the increasingly widely used compute_objsize function traverses
the IL following the DEF statements of pointer variables, aggregating
offsets from POINTER_PLUS assignments along the way.  It does that
for many statements that involve pointers, including calls to
built-in functions and (so far only) accesses to char arrays.  When
a function has many such statements with pointers to the same objects
but with different offsets, the traversal ends up visiting the same
pointer assignments repeatedly and unnecessarily.

To avoid this repeated traversal, the attached patch adds the ability
to cache results obtained in prior calls to the function.  The cache
is optional and only used when enabled.

To exercise the cache I have enabled it for the strlen pass (which
is probably the heaviest compute_objsize user).  That happens to
resolve PR 97373 which tracks the pass' failure to detect sprintf
overflowing allocated buffers at a non-constant offset.  I thought
about making this a separate patch but the sprintf/strlen changes
are completely mechanical so it didn't seem worth the effort.

In the benchmarking I've done the cache isn't a huge win there but
it does have a measurable difference in the project I'm wrapping up
where most pointer assignments need to be examined.  The space used
for the cache is negligible on average: fewer than 20 entries per
Glibc function and about 6 for GCC.  The worst case in Glibc is
6 thousand entries and 10k in GCC.  Since the entries are sizable
(216 bytes each) the worst case memory consumption can be reduced
by adding a level of indirection.  A further savings can be obtained
by replacing some of the offset_int members of the entries with
HOST_WIDE_INT.

The efficiency benefits of the cache should increase further as more
of the access checking code is integrated into the same pass.  This
should eventually include the checking currently done in the built-in
expanders.

Tested on x86_64-linux, along with Glibc and Binutils/GDB.

Martin

PS The patch add the new pointer_query class (loosely modeled on
range_query) to builtins.{h,c}.  This should be only temporary,
until the access checking code is moved into a file (and ultimately
a pass) of its own.

gcc-97373.diff

PR middle-end/97373 - missing warning on sprintf into allocated 
destination


gcc/ChangeLog:

PR middle-end/97373
* builtins.c (compute_objsize): Rename...
(compute_objsize_r): to this.  Change order and types of arguments.
Use new argument.  Adjust calls to self.
(access_ref::get_ref): New member function.
(pointer_query::pointer_query): New member function.
(pointer_query::get_ref): Same.
(pointer_query::put_ref): Same.
(handle_min_max_size): Change order and types of arguments.
(maybe_emit_free_warning): Add a test.
* builtins.h (class pointer_query): New class.
(compute_objsize): Declare an overload.
* gimple-ssa-sprintf.c (get_destination_size):
(handle_printf_call):
* tree-ssa-strlen.c (adjust_last_stmt): Add an argument and use it.
(maybe_warn_overflow): Same.
(handle_builtin_strcpy): Same.
(maybe_diag_stxncpy_trunc): Same.
(handle_builtin_memcpy): Change argument type.  Adjust calls.
(handle_builtin_strcat): Same.
(handle_builtin_memset): Same.
(handle_store): Same.
(strlen_check_and_optimize_call): Same.
(check_and_optimize_stmt): Same.
(strlen_dom_walker): Add new data members.
(strlen_dom_walker::before_dom_children): Use new member.
(printf_strlen_execute): Dump cache performance counters.
* tree-ssa-strlen.h (maybe_diag_stxncpy_trunc): Add argument.
(handle_printf_call): Change argument type.

gcc/testsuite/ChangeLog:

PR middle-end/97373
* gcc.dg/warn-strnlen-no-nul.c:
* g++.dg/warn/Wmismatched-new-delete-2.C: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-25.c: New test.

I'm going to hesitatingly ACK this.


Besides rebasing the changes on top the latest trunk I've also
adjusted them to avoid the "inefficient hacks" I mentioned in
the subsequent patch(*).  They were not only inefficient but
also would have caused the function to return incorrect results
in some cases.  After retesting with Binutils/GDB and Glibc
I committed the attached patch in r11-5622.

Martin

[*] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558775.html



The reason I saw hesitatingly is because I suspect that we're going to
see more cases where caching would be useful and I'd like to have a
general way to do that.  We've already got a ton of caching code in
Ranger and I fully expect more as we continue to write analysis code
that wants to walk backwards.  I don't want to see multiple
implementations of simple caching code.


I neglected to respond to this: if/when a general caching 

Re: [PATCH] c++: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093]

[Jakub Jelinek via Gcc-patches]

On Tue, Dec 01, 2020 at 04:05:22PM -0500, Jason Merrill wrote:
> > I see cp_parser_late_parsing_default_args calls push_defarg_context,
> > so perhaps it could check default_arg_context vector, except that
> > convert_default_arg calls that too around calling break_out_target_exprs
> > which in the patch is used to perform the late evaluation of the
> > std::source_location::current() calls.  So it might need to temporarily
> > pop_defarg_context before break_out_target_exprs and push it again?
> 
> How about forcing the constant evaluation in bot_manip?

That is probably a good idea anyway.

> Or simpler might be to always defer immediate evaluation of
> source_location::current() until genericize time.

Will try this too.

Though, I still wonder if it will be ok that we'll evaluate immediate
functions other than std::source_location::current() during the late
parsing of default arguments.

Testcase could be something like:
consteval bool foo (bool x) { if (x) throw 1; return false; }
consteval bool bar (bool x = foo (true)) { return true; }
struct S
{
  consteval static bool baz (bool x = foo (true)) { return true; }
};
constexpr bool a = bar (true);
constexpr bool b = S::baz (true);

We accept now bar, but reject baz.
I think the foo (true) expressions are in both cases in
immediate function context and therefore foo (true) calls are there
not immediate invocations (sure, if one calls bar () or S::baz () 
then it will be invalid anyway).

Jakub

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Jonathan Wakely via Gcc-patches]

On Tue, 1 Dec 2020 at 19:13, Michael Meissner via Libstdc++
 wrote:
>
> On Tue, Dec 01, 2020 at 04:04:30PM +, Jonathan Wakely wrote:
> > On 01/12/20 15:10 +, Jonathan Wakely wrote:
> > >On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:
> > >>Jonathan, could you send a fresh set of patches (or at least 
> > >>replacements)?  I
> > >>tried installing the patches on a master branch I checked out this 
> > >>morning, and
> > >>I got two rejects:
> > >
> > >I don't understand why those chunks failed, but I'll rebase and send a
> > >new patch ASAP.
> >
> > Here's the rebased patch, with regenerated autoconf files and a fix
> > for the  header. I'd changed it since sending
> > the previous patch, and broke the "there's more than one long double"
> > case (i.e. the _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT case).
>
> Unfortunately this patch DOES NOT work at all.
>
> If I build a compiler with the configure option:
> --with-long-double-format=ieee
>
> And I compile this simple program:
>
> #include 
>
> int main(int argc, char *argv[], char *envp[])
> {
>   std::cout << "Hello World!\n";
>   return 0;
> }
>
> I get all of these errors:

It works fine for me (see below). I think your symptoms are due to
using a glibc that doesn't support the new long double, and so
libstdc++ support for it is also disabled. You need at least glibc
2.32 for the libstdc++ changes to be enabled.

[test@ibm-p9b-30 build-ieee128]$ rpm -q glibc
glibc-2.32-2.fc33.ppc64le
[test@ibm-p9b-30 tmp]$ cat hello.C
#include 

int main(int argc, char *argv[], char *envp[])
{
  std::cout << "Hello World!\n";
  return 0;
}

[test@ibm-p9b-30 tmp]$ ~/gcc/ieee128/bin/g++ hello.C
-Wl,-rpath,$HOME/gcc/ieee128/lib64  -v
Using built-in specs.
COLLECT_GCC=/home/test/gcc/ieee128/bin/g++
COLLECT_LTO_WRAPPER=/home/test/gcc/ieee128/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/home/test/gcc/ieee128/
--enable-libstdcxx-debug --disable-bootstrap --disable-multilib
--disable-libvtv --with-system-zlib --without-isl
--with-long-double-format=ieee --enable-languages=c,c++ :
(reconfigured) ../gcc/configure --prefix=/home/test/gcc/ieee128/
--enable-libstdcxx-debug --disable-bootstrap --disable-multilib
--disable-libvtv --with-system-zlib --without-isl
--with-long-double-format=ieee --enable-languages=c,c++ :
(reconfigured) ../gcc/configure --prefix=/home/test/gcc/ieee128/
--enable-libstdcxx-debug --disable-bootstrap --disable-multilib
--disable-libvtv --with-system-zlib --without-isl
--with-long-double-format=ieee --enable-languages=c,c++,lto
--no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20201201 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-dumpdir' 'a-'
/home/test/gcc/ieee128/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.0/cc1plus
-quiet -v -D_GNU_SOURCE hello.C -quiet -dumpdir a- -dumpbase hello.C
-dumpbase-ext .C -version -o /tmp/cc1OWZTT.s
GNU C++17 (GCC) version 11.0.0 20201201 (experimental)
(powerpc64le-unknown-linux-gnu)
   compiled by GNU C version 10.2.1 20201016 (Red Hat 10.2.1-6),
GMP version 6.2.0, MPFR version 4.1.0, MPC version 1.1.0, isl version
none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/home/test/gcc/ieee128/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/../../../../powerpc64le-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/test/gcc/ieee128/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/../../../../include/c++/11.0.0
/home/test/gcc/ieee128/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/../../../../include/c++/11.0.0/powerpc64le-unknown-linux-gnu
/home/test/gcc/ieee128/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/../../../../include/c++/11.0.0/backward
/home/test/gcc/ieee128/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/include
/usr/local/include
/home/test/gcc/ieee128/include
/home/test/gcc/ieee128/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.0/include-fixed
/usr/include
End of search list.
GNU C++17 (GCC) version 11.0.0 20201201 (experimental)
(powerpc64le-unknown-linux-gnu)
   compiled by GNU C version 10.2.1 20201016 (Red Hat 10.2.1-6),
GMP version 6.2.0, MPFR version 4.1.0, MPC version 1.1.0, isl version
none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 868967e3eb6523a59f0ddd7cc415f672
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-dumpdir' 'a-'
as -v -a64 -mpowe

Re: [PATCH v2] C-family : Add attribute 'unavailable'.

[Iain Sandoe]

Hi Martin,

Martin Sebor  wrote:


On 11/29/20 6:56 PM, Iain Sandoe wrote:



Martin Sebor via Gcc-patches  wrote:

On 11/10/20 12:38 PM, Iain Sandoe wrote:

—— commit message.
If an interface is marked 'deprecated' then, presumably, at some point  
it

will be withdrawn and no longer available.  The 'unavailable' attribute
makes it possible to mark up interfaces to indicate this status.

Making an interface unavailable isn't the intent of deprecation in
standards like C, C++, or POSIX.  Rather, the intended next stage
after deprecation is to make the interface available for other uses,
either by the standards themselves, or by implementations, or by
programs (if its name is not in the reserved namespace).  So unless
you have other kinds of deprecation in mind this doesn't seem like
a fitting use case.

coming at things from the standards perspective .. perhaps.
.. however, in the first set of cases above, one never needs to indicate
  unavailability  since the entity never becomes unavailable, it changes
  meaning.
In practice, we don’t have markup of keywords etc. to indicate this (such
deprecation has been handled specifically in the FEs).
The practical (and actual) use of these attributes is in describing the  
lifecycle

of system APIs.
In that context, one could see it being used to describe APIs withdrawn  
in, say,
a Posix standard (as implemented by a given system or according to  
specific

compile-time flags).


Just for the sake of clarity, to make sure we are both talking about
the same thing, the term POSIX uses for "withdrawn" when referring
to APIs is removed.  Withdrawn is a term that ISO tends to apply to
whole standards.  For example, ISO 9945:2003 AKA SUSv3 is a withdrawn
revision of POSIX (likewise, C99 and C11 are withdrawn revisions of
C).

With that, the APIs that have been removed in recent POSIX versions
would not be appropriately described by the attribute, either on
paper, in the POSIX spec (if the hypothetical case when the attribute
was specified the C standard), or in implementations.  The APIs simply
don't exist and so are open to use by programs (unless they are in
the reserved namespace), or by implementations as extensions.
The latter typically means that the APIs are defined (i.e., can
continue to be linked to by legacy applications) but not declared
in the system's header so they can be defined by programs.  Declaring
removed APIs with the unavailable attribute would prevent that and so
would not be conforming.

An example from C (not yet POSIX) is the gets() function that was
removed in C11 (it's still SUSv4).  It's only declared in 
when targeting older versions of C and C++.  Because in more recent
versions of the standards gets is not a reserved name it's valid
for programs to declare symbols named gets (of any kind).  So
declaring gets in  with attribute unavailable would be
nonconforming.

My point here is not necessarily to object to the idea behind
the attribute but to draw attention to the fact that it's not
suitable for standard APIs.


I understand (and have no disagreement with) that this is not a facility
that could be used as an enforcement of standard’s compliance.



However, imagine that you are a system integrator, and you have a
system which supports the API of SUSv3 and some of the additions of
later systems; let’s say you want to help your users avoid use of APIs
which would be unavailable on a SUSv3 system

You could mark up your implementation’s headers such that when presented
with some compile flags, it made the toolchain emit an error if the user
attempted to use APIs that are not present in SUSv3.

This is not actually a completely inane goal - despite that SUSv3 is  
retired -

in reality (AFAICS) there is only one system that’s qualified to UNIX7.


It is used
quite extensively in some codebases where a single set of headers can  
be used

to permit code generation for multiple system versions.


This sounds like a different use case than the next stage after
deprecation.  I haven't come across it but I imagine its purpose
is to foster portability between variants or flavors (rather
than versions) of APSs?  Say one set of APIs for a feature-rich
desktop variant of an OS versus a subset of the same APIs for
an embedded, more limited variant of the same OS.
In the case of Darwin, the compilers are capable of targeting multiple  
versions
of the system (one doesn’t need a separate GCC or clang to target each  
version,
there is a -mmacosx-version-min= flag that allows the target version to  
be specified

on the command line).
Rather than install many versions of headers (and libraries) for all the  
system
versions, the designers elected to have one copy with markup that  
describes the

availability of APIs.
the lifecycle is typically:
introduced from version P.Q (ergo, unavailable before that)
perhaps deprecated at version R.S (ergo the user should be warned)
withdrawn at version X.Y (and unavailable thereafter).
The headers contain mac

[PATCH] expansion: FIx up infinite recusion due to double-word modulo optimization

[Jakub Jelinek via Gcc-patches]

Hi!

Jeff has reported that my earlier patch broke rl78-elf, e.g. with
unsigned short foo (unsigned short x) { return x % 7; }
when compiled with -O2 -mg14.  The problem is that rl78 is a BITS_PER_WORD
== 8 target which doesn't have 8-bit modulo or divmod optab, but has instead
16-bit divmod, so my patch attempted to optimize it, then called
expand_divmod to do 8-bit modulo and that in turn tried to do 16-bit modulo
again.

The following patch fixes it in two ways.
One is to not perform the optimization when we have {u,s}divmod_optab
handler for the double-word mode, in that case it is IMHO better to just
do whatever we used to do before.  This alone should fix the infinite
recursion.  But I'd be afraid some other target might have similar problem
and might not have a divmod pattern, but only say a library call.
So the patch also introduces a methods argument to expand_divmod such that
normally we allow everything that was allowed before (using libcalls and
widening), but when called from these expand_doubleword*mod routines we
restrict it to no widening and no libcalls.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2020-12-01  Jakub Jelinek  

* expmed.h (expand_divmod): Only declare if GCC_OPTABS_H is defined.
Add enum optabs_method argument defaulted to OPTAB_LIB_WIDEN.
* expmed.c: Include expmed.h after optabs.h.
(expand_divmod): Add methods argument, if it is not OPTAB_{,LIB_}WIDEN,
don't choose a wider mode, and pass it to other calls instead of
hardcoded OPTAB_LIB_WIDEN.  Avoid emitting libcalls if not
OPTAB_LIB or OPTAB_LIB_WIDEN.
* optabs.c: Include expmed.h after optabs.h.
(expand_doubleword_mod, expand_doubleword_divmod): Pass OPTAB_DIRECT
as last argument to expand_divmod.
(expand_binop): Punt if {s,u}divmod_optab has handler for double-word
int_mode.
* expr.c: Include expmed.h after optabs.h.
* explow.c: Include expmed.h after optabs.h.

--- gcc/expmed.h.jj 2020-01-12 11:54:36.56545 +0100
+++ gcc/expmed.h2020-12-01 19:25:55.117128688 +0100
@@ -716,8 +716,10 @@ extern rtx expand_variable_shift (enum t
  rtx, tree, rtx, int);
 extern rtx expand_shift (enum tree_code, machine_mode, rtx, poly_int64, rtx,
 int);
+#ifdef GCC_OPTABS_H
 extern rtx expand_divmod (int, enum tree_code, machine_mode, rtx, rtx,
- rtx, int);
+ rtx, int, enum optab_methods = OPTAB_LIB_WIDEN);
+#endif
 #endif
 
 extern void store_bit_field (rtx, poly_uint64, poly_uint64,
--- gcc/expmed.c.jj 2020-08-10 10:44:20.659560695 +0200
+++ gcc/expmed.c2020-12-01 19:30:40.993941266 +0100
@@ -31,8 +31,8 @@ along with GCC; see the file COPYING3.
 #include "predict.h"
 #include "memmodel.h"
 #include "tm_p.h"
-#include "expmed.h"
 #include "optabs.h"
+#include "expmed.h"
 #include "regs.h"
 #include "emit-rtl.h"
 #include "diagnostic-core.h"
@@ -4193,7 +4193,8 @@ expand_sdiv_pow2 (scalar_int_mode mode,
 
 rtx
 expand_divmod (int rem_flag, enum tree_code code, machine_mode mode,
-  rtx op0, rtx op1, rtx target, int unsignedp)
+  rtx op0, rtx op1, rtx target, int unsignedp,
+  enum optab_methods methods)
 {
   machine_mode compute_mode;
   rtx tquotient;
@@ -4299,17 +4300,22 @@ expand_divmod (int rem_flag, enum tree_c
   optab2 = (op1_is_pow2 ? optab1
: (unsignedp ? udivmod_optab : sdivmod_optab));
 
-  FOR_EACH_MODE_FROM (compute_mode, mode)
-if (optab_handler (optab1, compute_mode) != CODE_FOR_nothing
-   || optab_handler (optab2, compute_mode) != CODE_FOR_nothing)
-  break;
-
-  if (compute_mode == VOIDmode)
-FOR_EACH_MODE_FROM (compute_mode, mode)
-  if (optab_libfunc (optab1, compute_mode)
- || optab_libfunc (optab2, compute_mode))
+  if (methods == OPTAB_WIDEN || methods == OPTAB_LIB_WIDEN)
+{
+  FOR_EACH_MODE_FROM (compute_mode, mode)
+  if (optab_handler (optab1, compute_mode) != CODE_FOR_nothing
+ || optab_handler (optab2, compute_mode) != CODE_FOR_nothing)
break;
 
+  if (compute_mode == VOIDmode && methods == OPTAB_LIB_WIDEN)
+   FOR_EACH_MODE_FROM (compute_mode, mode)
+ if (optab_libfunc (optab1, compute_mode)
+ || optab_libfunc (optab2, compute_mode))
+   break;
+}
+  else
+compute_mode = mode;
+
   /* If we still couldn't find a mode, use MODE, but expand_binop will
  probably die.  */
   if (compute_mode == VOIDmode)
@@ -4412,8 +4418,7 @@ expand_divmod (int rem_flag, enum tree_c
remainder
  = expand_binop (int_mode, and_optab, op0,
  gen_int_mode (mask, int_mode),
- remainder, 1,
- OPTAB_LIB_WIDEN);
+ remainde

Re: [PATCH] c++: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093]

[Jason Merrill via Gcc-patches]

On 12/1/20 3:59 AM, Jakub Jelinek wrote:

Hi!

While std::source_location::current () is static consteval source_location
current() noexcept; in the standard, it also says with LWG3396:
"Any call to current that appears as a default member initializer
([class.mem]), or as a subexpression thereof, should correspond to the
location of the constructor definition or aggregate initialization that uses
the default member initializer.  Any call to current that appears as a
default argument ([dcl.fct.default]), or as a subexpression thereof, should
correspond to the location of the invocation of the function that uses the
default argument ([expr.call])."
so it must work as compiler magic rather than normal immediate functions,
in particular we need to defer its evaluation when parsing default arguments
or nsdmis.





The problem is that with your/JeanHeyd's testcase above, the default
argument parsing is deferred until the whole class is parsed and then
cp_parser_late_parsing_default_args performs that deferred parsing.
Except at this point nothing creates the sk_function_params scope.

So, I think we need some way for the build_over_call code to know if
it is called from within cp_parser_late_parsing_default_args and whether
for an immediate function or not, and take that into account too.

I see cp_parser_late_parsing_default_args calls push_defarg_context,
so perhaps it could check default_arg_context vector, except that
convert_default_arg calls that too around calling break_out_target_exprs
which in the patch is used to perform the late evaluation of the
std::source_location::current() calls.  So it might need to temporarily
pop_defarg_context before break_out_target_exprs and push it again?


How about forcing the constant evaluation in bot_manip?

Or simpler might be to always defer immediate evaluation of 
source_location::current() until genericize time.



And guess we need some tests if it works as expected also in templates;


Please.


2020-12-01  Jakub Jelinek  

LWG3396 Clarify point of reference for source_location::current()
PR c++/80780
PR c++/93093
* cp-tree.h (source_location_current_p): Declare.
* tree.c (source_location_current_p): New function.
(bot_manip): Resolve deferred calls to immediate function
std::source_location::current ().
* call.c (build_over_call): Don't evaluate calls to immediate
function std::source_location::current () in default arguments
or when parsing nsdmi.

* g++.dg/cpp2a/srcloc15.C: New test.
* g++.dg/cpp2a/srcloc16.C: New test.

--- gcc/cp/cp-tree.h.jj 2020-11-26 16:22:24.252407018 +0100
+++ gcc/cp/cp-tree.h2020-11-30 19:45:36.784286305 +0100
@@ -7413,6 +7413,7 @@ extern tree bind_template_template_parm
  extern tree array_type_nelts_total(tree);
  extern tree array_type_nelts_top  (tree);
  extern bool array_of_unknown_bound_p  (const_tree);
+extern bool source_location_current_p  (tree);
  extern tree break_out_target_exprs(tree, bool = false);
  extern tree build_ctor_subob_ref  (tree, tree, tree);
  extern tree replace_placeholders  (tree, tree, bool * = NULL);
--- gcc/cp/tree.c.jj2020-11-26 16:22:24.264406884 +0100
+++ gcc/cp/tree.c   2020-11-30 19:53:58.034686074 +0100
@@ -2968,6 +2968,37 @@ array_type_nelts_total (tree type)
return sz;
  }
  
+/* Return true if FNDECL is std::source_location::current () method.  */

+
+bool
+source_location_current_p (tree fndecl)
+{
+  gcc_checking_assert (TREE_CODE (fndecl) == FUNCTION_DECL
+  && DECL_IMMEDIATE_FUNCTION_P (fndecl));
+  if (DECL_NAME (fndecl) == NULL_TREE
+  || TREE_CODE (TREE_TYPE (fndecl)) != FUNCTION_TYPE
+  || TREE_CODE (TREE_TYPE (TREE_TYPE (fndecl))) != RECORD_TYPE
+  || DECL_CONTEXT (fndecl) != TREE_TYPE (TREE_TYPE (fndecl)))
+return false;
+
+  if (strcmp (IDENTIFIER_POINTER (DECL_NAME (fndecl)), "current") != 0)


You can use id_equal for comparing identifiers to strings.


+return false;
+
+  tree source_location = DECL_CONTEXT (fndecl);
+  if (TYPE_NAME (source_location) == NULL_TREE
+  || TREE_CODE (TYPE_NAME (source_location)) != TYPE_DECL
+  || DECL_NAME (TYPE_NAME (source_location)) == NULL_TREE
+  || strcmp (IDENTIFIER_POINTER (DECL_NAME (TYPE_NAME (source_location))),
+"source_location") != 0)


TYPE_IDENTIFIER would make this shorter.


+return false;
+
+  tree decl
+= lookup_qualified_name (std_node,
+DECL_NAME (TYPE_NAME (source_location)),
+LOOK_want::TYPE, tf_none);
+  return TYPE_NAME (source_location) == decl;


Why not TYPE_CONTEXT (source_location) == std_node?  I don't think we 
need to do name lookup here.



+}
+
  struct bot_data
  {
splay_tree target_remap;
@@ -3064,6 +3095,38 @@ bot_manip (tree* tp, int* walk_subtrees,
set_flags_from_callee (*tp

[PATCH] expansion: Further improve double-word modulo, division and divmod [PR97459]

[Jakub Jelinek via Gcc-patches]

Hi!

The following patch implements what Thomas wrote about, in particular
that we can handle also double-word divison by the constants for which
the earlier patch optimized modulo (if it would be otherwise a library
call) and that we can also easily handle such constants shifted to the left.
Unfortunately, seems CSE isn't able to optimize away the two almost
identical sequences (one to compute remainder, one to compute quotient),
probably because of the ADD_OVERFLOW introduced jumps, so the patch also
adjusts expand_DIVMOD.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2020-12-01  Jakub Jelinek  

PR rtl-optimization/97459
* optabs.h (expand_doubleword_divmod): Declare.
* optabs.c (expand_doubleword_divmod): New function.
(expand_binop): Use it.
* internal-fn.c (expand_DIVMOD): Likewise.

* gcc.target/i386/pr97282.c (foo): Use 123456 divisor instead of
10.
* gcc.dg/pr97459-1.c (TESTS): Add tests for 10, 12 and
6144.
* gcc.dg/pr97459-2.c (TESTS): Likewise.
* gcc.dg/pr97459-3.c: New test.
* gcc.dg/pr97459-4.c: New test.
* gcc.dg/pr97459-5.c: New test.
* gcc.dg/pr97459-6.c: New test.

--- gcc/optabs.h.jj 2020-12-01 13:19:12.831127718 +0100
+++ gcc/optabs.h2020-12-01 17:40:08.783137431 +0100
@@ -183,6 +183,8 @@ extern bool force_expand_binop (machine_
enum optab_methods);
 extern rtx expand_vector_broadcast (machine_mode, rtx);
 
+extern rtx expand_doubleword_divmod (machine_mode, rtx, rtx, rtx *, bool);
+
 /* Generate code for a simple binary or unary operation.  "Simple" in
this case means "can be unambiguously described by a (mode, code)
pair and mapped to a single optab."  */
--- gcc/optabs.c.jj 2020-12-01 16:25:01.56773 +0100
+++ gcc/optabs.c2020-12-01 18:11:12.878230572 +0100
@@ -1118,6 +1118,99 @@ expand_doubleword_mod (machine_mode mode
 }
   return NULL_RTX;
 }
+
+/* Similarly to the above function, but compute both quotient and remainder.
+   Quotient can be computed from the remainder as:
+   rem = op0 % op1;  // Handled using expand_doubleword_mod
+   quot = (op0 - rem) * inv; // inv is multiplicative inverse of op1 modulo
+// 2 * BITS_PER_WORD
+
+   We can also handle cases where op1 is a multiple of power of two constant
+   and constant handled by expand_doubleword_mod.
+   op11 = 1 << __builtin_ctz (op1);
+   op12 = op1 / op11;
+   rem1 = op0 % op12;  // Handled using expand_doubleword_mod
+   quot1 = (op0 - rem1) * inv; // inv is multiplicative inverse of op12 modulo
+  // 2 * BITS_PER_WORD
+   rem = (quot1 % op11) * op12 + rem1;
+   quot = quot1 / op11;  */
+
+rtx
+expand_doubleword_divmod (machine_mode mode, rtx op0, rtx op1, rtx *rem,
+ bool unsignedp)
+{
+  *rem = NULL_RTX;
+
+  /* Negative dividend should have been optimized into positive,
+ similarly modulo by 1 and modulo by power of two is optimized
+ differently too.  */
+  if (INTVAL (op1) <= 1 || pow2p_hwi (INTVAL (op1)))
+return NULL_RTX;
+
+  rtx op11 = const1_rtx;
+  rtx op12 = op1;
+  if ((INTVAL (op1) & 1) == 0)
+{
+  int bit = ctz_hwi (INTVAL (op1));
+  op11 = GEN_INT (HOST_WIDE_INT_1 << bit);
+  op12 = GEN_INT (INTVAL (op1) >> bit);
+}
+
+  rtx rem1 = expand_doubleword_mod (mode, op0, op12, unsignedp);
+  if (rem1 == NULL_RTX)
+return NULL_RTX;
+
+  int prec = 2 * BITS_PER_WORD;
+  wide_int a = wide_int::from (INTVAL (op12), prec + 1, UNSIGNED);
+  wide_int b = wi::shifted_mask (prec, 1, false, prec + 1);
+  wide_int m = wide_int::from (wi::mod_inv (a, b), prec, UNSIGNED);
+  rtx inv = immed_wide_int_const (m, mode);
+
+  rtx_insn *last = get_last_insn ();
+  rtx quot1 = expand_simple_binop (mode, MINUS, op0, rem1,
+  NULL_RTX, unsignedp, OPTAB_DIRECT);
+  if (quot1 == NULL_RTX)
+return NULL_RTX;
+
+  quot1 = expand_simple_binop (mode, MULT, quot1, inv,
+  NULL_RTX, unsignedp, OPTAB_DIRECT);
+  if (quot1 == NULL_RTX)
+return NULL_RTX;
+
+  if (op11 != const1_rtx)
+{
+  rtx rem2 = expand_divmod (1, TRUNC_MOD_EXPR, mode, quot1, op11,
+   NULL_RTX, unsignedp);
+  if (rem2 == NULL_RTX)
+   return NULL_RTX;
+
+  rem2 = expand_simple_binop (mode, MULT, rem2, op12, NULL_RTX,
+ unsignedp, OPTAB_DIRECT);
+  if (rem2 == NULL_RTX)
+   return NULL_RTX;
+
+  rem2 = expand_simple_binop (mode, PLUS, rem2, rem1, NULL_RTX,
+ unsignedp, OPTAB_DIRECT);
+  if (rem2 == NULL_RTX)
+   return NULL_RTX;
+
+  rtx quot2 = expand_divmod (0, TRUNC_DIV_EXPR, mode, quot1, op11,
+NULL_RTX, unsignedp);
+  if (quot2 == NULL_RTX)
+   return NULL_RTX;
+
+  rem1 = rem2;
+  quot1 = quot2;
+}

Re: [PATCH] cache compute_objsize results in strlen/sprintf (PR 97373)

[Martin Sebor via Gcc-patches]

On 11/23/20 2:04 PM, Jeff Law wrote:



On 11/4/20 5:58 PM, Martin Sebor via Gcc-patches wrote:

To determine the target of a pointer expression and the offset into
it, the increasingly widely used compute_objsize function traverses
the IL following the DEF statements of pointer variables, aggregating
offsets from POINTER_PLUS assignments along the way.  It does that
for many statements that involve pointers, including calls to
built-in functions and (so far only) accesses to char arrays.  When
a function has many such statements with pointers to the same objects
but with different offsets, the traversal ends up visiting the same
pointer assignments repeatedly and unnecessarily.

To avoid this repeated traversal, the attached patch adds the ability
to cache results obtained in prior calls to the function.  The cache
is optional and only used when enabled.

To exercise the cache I have enabled it for the strlen pass (which
is probably the heaviest compute_objsize user).  That happens to
resolve PR 97373 which tracks the pass' failure to detect sprintf
overflowing allocated buffers at a non-constant offset.  I thought
about making this a separate patch but the sprintf/strlen changes
are completely mechanical so it didn't seem worth the effort.

In the benchmarking I've done the cache isn't a huge win there but
it does have a measurable difference in the project I'm wrapping up
where most pointer assignments need to be examined.  The space used
for the cache is negligible on average: fewer than 20 entries per
Glibc function and about 6 for GCC.  The worst case in Glibc is
6 thousand entries and 10k in GCC.  Since the entries are sizable
(216 bytes each) the worst case memory consumption can be reduced
by adding a level of indirection.  A further savings can be obtained
by replacing some of the offset_int members of the entries with
HOST_WIDE_INT.

The efficiency benefits of the cache should increase further as more
of the access checking code is integrated into the same pass.  This
should eventually include the checking currently done in the built-in
expanders.

Tested on x86_64-linux, along with Glibc and Binutils/GDB.

Martin

PS The patch add the new pointer_query class (loosely modeled on
range_query) to builtins.{h,c}.  This should be only temporary,
until the access checking code is moved into a file (and ultimately
a pass) of its own.

gcc-97373.diff

PR middle-end/97373 - missing warning on sprintf into allocated destination

gcc/ChangeLog:

PR middle-end/97373
* builtins.c (compute_objsize): Rename...
(compute_objsize_r): to this.  Change order and types of arguments.
Use new argument.  Adjust calls to self.
(access_ref::get_ref): New member function.
(pointer_query::pointer_query): New member function.
(pointer_query::get_ref): Same.
(pointer_query::put_ref): Same.
(handle_min_max_size): Change order and types of arguments.
(maybe_emit_free_warning): Add a test.
* builtins.h (class pointer_query): New class.
(compute_objsize): Declare an overload.
* gimple-ssa-sprintf.c (get_destination_size):
(handle_printf_call):
* tree-ssa-strlen.c (adjust_last_stmt): Add an argument and use it.
(maybe_warn_overflow): Same.
(handle_builtin_strcpy): Same.
(maybe_diag_stxncpy_trunc): Same.
(handle_builtin_memcpy): Change argument type.  Adjust calls.
(handle_builtin_strcat): Same.
(handle_builtin_memset): Same.
(handle_store): Same.
(strlen_check_and_optimize_call): Same.
(check_and_optimize_stmt): Same.
(strlen_dom_walker): Add new data members.
(strlen_dom_walker::before_dom_children): Use new member.
(printf_strlen_execute): Dump cache performance counters.
* tree-ssa-strlen.h (maybe_diag_stxncpy_trunc): Add argument.
(handle_printf_call): Change argument type.

gcc/testsuite/ChangeLog:

PR middle-end/97373
* gcc.dg/warn-strnlen-no-nul.c:
* g++.dg/warn/Wmismatched-new-delete-2.C: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-25.c: New test.

I'm going to hesitatingly ACK this.


Besides rebasing the changes on top the latest trunk I've also
adjusted them to avoid the "inefficient hacks" I mentioned in
the subsequent patch(*).  They were not only inefficient but
also would have caused the function to return incorrect results
in some cases.  After retesting with Binutils/GDB and Glibc
I committed the attached patch in r11-5622.

Martin

[*] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558775.html



The reason I saw hesitatingly is because I suspect that we're going to
see more cases where caching would be useful and I'd like to have a
general way to do that.  We've already got a ton of caching code in
Ranger and I fully expect more as we continue to write analysis code
that wants to walk backwards.  I don't want to see multiple
implementat

[committed] openmp: Avoid ICE on depend clause on depobj OpenMP construct [PR98072]

[Jakub Jelinek via Gcc-patches]

Hi!

Since r11-5430 we ICE on the following testcase.  When parsing the depobj
directive we don't really use cp_parser_omp_all_clauses routine which ATM
disables generation of location wrappers and the newly added assertion
that there are no location wrappers thus triggers.

Fixed by adding the location wrappers suppression sentinel.

Longer term, we should handle location wrappers inside of OpenMP clauses.

Bootstrapped/regtested on x86_64-linux and i686-linux, committed to trunk,
queued for backporting.

2020-12-01  Jakub Jelinek  

PR c++/98072
* parser.c (cp_parser_omp_depobj): Suppress location wrappers when
parsing depend clause.

* c-c++-common/gomp/depobj-2.c: New test.

--- gcc/cp/parser.c.jj  2020-11-26 16:22:24.258406951 +0100
+++ gcc/cp/parser.c 2020-12-01 10:37:02.611703012 +0100
@@ -38784,6 +38784,8 @@ cp_parser_omp_depobj (cp_parser *parser,
   cp_lexer_consume_token (parser->lexer);
   if (!strcmp ("depend", p))
{
+ /* Don't create location wrapper nodes within the depend clause.  */
+ auto_suppress_location_wrappers sentinel;
  clause = cp_parser_omp_clause_depend (parser, NULL_TREE, c_loc);
  if (clause)
clause = finish_omp_clauses (clause, C_ORT_OMP);
--- gcc/testsuite/c-c++-common/gomp/depobj-2.c.jj   2020-12-01 
10:37:50.873159687 +0100
+++ gcc/testsuite/c-c++-common/gomp/depobj-2.c  2020-12-01 10:38:14.018899116 
+0100
@@ -0,0 +1,11 @@
+/* PR c++/98072 */
+
+typedef struct __attribute__((__aligned__ (sizeof (void * omp_depend_t {
+  char __omp_depend_t__[2 * sizeof (void *)];
+} omp_depend_t;
+
+void
+foo (int *x, omp_depend_t *y, int z)
+{
+  #pragma omp depobj (*y) depend (in: x[z])
+}


Jakub

Re: [PATCH] Objective-C++ : Allow prefix attrs on linkage specs.

[Jason Merrill via Gcc-patches]

On 11/28/20 4:53 AM, Iain Sandoe wrote:

(resending - this didn’t seem to reach gcc-patches@)

Jason Merrill  wrote:


On Mon, Nov 23, 2020 at 8:52 AM Iain Sandoe  wrote:
Jason Merrill  wrote:



(NOTE: likewise,   ^~~ starting indent is below ‘int’ for a fixed spacing
font)

===

I’m inclined to think that the second is more useful,
but have patches for both,
which (or something else) do you prefer?

I agree that the second is preferable, thanks.  But let's not 
underline all of "int" there, just the caret is sufficient.  I'd also 
drop the mention of Obj-C++.


t.C:2:1: warning: attributes are not permitted in this position 
[-Wattributes]

    2 | __attribute__(())
  | ^
t.C:3:11: note: attributes may be inserted here
    3 | extern "C" int foo (void);
  |   ^

(the caret _is_ below the space)

(cool, I got to find out how to make a diagnostic point to the space 
between two tokens)


OK?
thanks
Iain


OK, thanks.


[PATCH] C++ : Adjust warning for misplaced attributes.

This removes the reference to Objective-C++ for the warning that
attributes may not be placed before linkage specifications.  It also
adds a note that they may be placed after that.

gcc/cp/ChangeLog:

 * parser.c (cp_parser_declaration): Add a not about where
 attributes may be placed.
---
gcc/cp/parser.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 7a83bf4a2a7..fe1dffc391f 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -13567,9 +13567,12 @@ cp_parser_declaration (cp_parser* parser, tree 
prefix_attrs)

   /* We might have already been here.  */
   if (!c_dialect_objc ())
     {
+  location_t where = get_finish (t2->location);
   warning_at (token1->location, OPT_Wattributes, "attributes are"
-  " only permitted in this position for Objective-C++,"
-  " ignored");
+  " not permitted in this position");
+  where = linemap_position_for_loc_and_offset (line_table,
+   where, 1);
+  inform (where, "attributes may be inserted here");
   attributes = NULL_TREE;
     }
   token1 = t1;

[SPARC] Make -fzero-call-used-regs work

[Eric Botcazou]

This contains both a generic fixlet for targets implementing the leaf register 
optimization (SPARC and Xtensa) and the implementation of the target hook 
TARGET_ZERO_CALL_USED_REGS, which is needed to make this work on the SPARC.

Tested on SPARC/Solaris and SPARC64/Linux, applied on the mainline.


2020-12-01  Eric Botcazou  

* function.c (gen_call_used_regs_seq): In a function subject to the
leaf register optimization, skip registers that are not present.
* config/sparc/sparc.c (TARGET_ZERO_CALL_USED_REGS): Define to...
(sparc_zero_call_used_regs): ...this.  New function.

-- 
Eric Botcazoudiff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 02138c5d478..ec0921b7ef5 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -708,6 +708,7 @@ static HOST_WIDE_INT sparc_constant_alignment (const_tree, HOST_WIDE_INT);
 static bool sparc_vectorize_vec_perm_const (machine_mode, rtx, rtx, rtx,
 	const vec_perm_indices &);
 static bool sparc_can_follow_jump (const rtx_insn *, const rtx_insn *);
+static HARD_REG_SET sparc_zero_call_used_regs (HARD_REG_SET);
 
 #ifdef SUBTARGET_ATTRIBUTE_TABLE
 /* Table of valid machine attributes.  */
@@ -959,6 +960,9 @@ char sparc_hard_reg_printed[8];
 #undef TARGET_CAN_FOLLOW_JUMP
 #define TARGET_CAN_FOLLOW_JUMP sparc_can_follow_jump
 
+#undef TARGET_ZERO_CALL_USED_REGS
+#define TARGET_ZERO_CALL_USED_REGS sparc_zero_call_used_regs
+
 struct gcc_target targetm = TARGET_INITIALIZER;
 
 /* Return the memory reference contained in X if any, zero otherwise.  */
@@ -13810,4 +13814,50 @@ sparc_constant_alignment (const_tree exp, HOST_WIDE_INT align)
   return align;
 }
 
+/* Implement TARGET_ZERO_CALL_USED_REGS.
+
+   Generate a sequence of instructions that zero registers specified by
+   NEED_ZEROED_HARDREGS.  Return the ZEROED_HARDREGS that are actually
+   zeroed.  */
+
+static HARD_REG_SET
+sparc_zero_call_used_regs (HARD_REG_SET need_zeroed_hardregs)
+{
+  for (unsigned int regno = 0; regno < FIRST_PSEUDO_REGISTER; regno++)
+if (TEST_HARD_REG_BIT (need_zeroed_hardregs, regno))
+  {
+	/* Do not touch the CC registers or the FP registers if no VIS.  */
+	if (regno >= SPARC_FCC_REG
+	|| (regno >= SPARC_FIRST_FP_REG && !TARGET_VIS))
+	  CLEAR_HARD_REG_BIT (need_zeroed_hardregs, regno);
+
+	/* Do not access the odd upper FP registers individually.  */
+	else if (regno >= SPARC_FIRST_V9_FP_REG && (regno & 1))
+	  ;
+
+	/* Use the most natural mode for the registers, which is not given by
+	   regno_reg_rtx/reg_raw_mode for the FP registers on the SPARC.  */
+	else
+	  {
+	machine_mode mode;
+	rtx reg;
+
+	if (regno < SPARC_FIRST_FP_REG)
+	  {
+		reg = regno_reg_rtx[regno];
+		mode = GET_MODE (reg);
+	  }
+	else
+	  {
+		mode = regno < SPARC_FIRST_V9_FP_REG ? SFmode : DFmode;
+		reg = gen_raw_REG (mode, regno);
+	  }
+
+	emit_move_insn (reg, CONST0_RTX (mode));
+	  }
+  }
+
+  return need_zeroed_hardregs;
+}
+
 #include "gt-sparc.h"
diff --git a/gcc/function.c b/gcc/function.c
index 004fa389207..59fd72b0e82 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -5880,6 +5880,10 @@ gen_call_used_regs_seq (rtx_insn *ret, unsigned int zero_regs_type)
 	continue;
   if (only_arg && !FUNCTION_ARG_REGNO_P (regno))
 	continue;
+#ifdef LEAF_REG_REMAP
+  if (crtl->uses_only_leaf_regs && LEAF_REG_REMAP (regno) < 0)
+	continue;
+#endif
 
   /* Now this is a register that we might want to zero.  */
   SET_HARD_REG_BIT (selected_hardregs, regno);

[pushed] Darwin, D : Adjust the X spec to cater for duplicate use.

[Iain Sandoe]

Hi

For Darwin, the '-X' flag is an obsolete spelling for a command to tell
the linker to 'strip local symbols'.  This has been the default action
for a long time - but, as per the usual GCC approach, although the
flag is retired, we have not removed it; rather, we just delete it
in the driver self-spec.

The D language adds this flag as a front end option (to emit json)
which means that deleting it in the driver disables that function
in D.

This patch works around the duplication by removing the unused flag
in the link_spec instead of the driver self-spec.

this workaround tested on x86_64-darwin (where gdc tests now pass)
applied to master
thanks
Iain



Joseph; I don’t know if you have any advice on a ‘better’ long-term
solution; in some ways I am surprised that the compiler built with
duplicate specifications for a flag - perhaps the uses merged in some
way.  Since the use of ‘X’ in D is an upstream decision and the use of
‘X’ in Darwin is a historical fact (albeit luckily obsolete) it seems the
only recourse is eventually to delete one useage?



gcc/ChangeLog:

* config/darwin.h: Remove unused 'X' specs in the link spec
rather than driver self-specs.
---
 gcc/config/darwin.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
index 5a766319cb0..da40a08443e 100644
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@ -135,7 +135,7 @@ extern GTY(()) int darwin_ms_struct;
 "%{shared:-Zdynamiclib} %

Re: [PATCH][pushed] if-to-switch: Fix test-suite patterns.

[Martin Liška]

On 12/1/20 8:57 PM, Jakub Jelinek wrote:

Would be better to use \[^\n\r]\* instead of .*, with .* you can match parts
even from completely different parts of the dump file.


Thank you Jakub! I've just pushed a patch with that.

Martin

Re: [PATCH][pushed] if-to-switch: Fix test-suite patterns.

[Jakub Jelinek via Gcc-patches]

On Tue, Dec 01, 2020 at 08:52:45PM +0100, Martin Liška wrote:
> -/* { dg-final { scan-tree-dump "Condition chain with 3 BBs transformed into 
> a switch statement." "iftoswitch" } } */
> +/* { dg-final { scan-tree-dump "Condition chain with .* BBs transformed into 
> a switch statement." "iftoswitch" } } */

Would be better to use \[^\n\r]\* instead of .*, with .* you can match parts
even from completely different parts of the dump file.

Jakub

[PATCH][pushed] if-to-switch: Fix test-suite patterns.

[Martin Liška]

On ppc64le some conditions in BBs are not merged so we merge
a different number of BBs.

Pushed as obvious. Tested on x86_64-linux-gnu and ppc64le-linux-gnu.

gcc/testsuite/ChangeLog:

PR testsuite/98085
* g++.dg/tree-ssa/if-to-switch-1.C: Do not expect precise number
of BBs.
* gcc.dg/tree-ssa/if-to-switch-1.c: Likewise.
* gcc.dg/tree-ssa/if-to-switch-2.c: Likewise. Find better name
for the function.
* gcc.dg/tree-ssa/if-to-switch-3.c: Likewise. Find better name
for the function.
* gcc.dg/tree-ssa/if-to-switch-5.c: Likewise.
---
 gcc/testsuite/g++.dg/tree-ssa/if-to-switch-1.C | 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-1.c | 2 +-
 gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-2.c | 4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-3.c | 4 ++--
 gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-5.c | 2 +-
 5 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/gcc/testsuite/g++.dg/tree-ssa/if-to-switch-1.C 
b/gcc/testsuite/g++.dg/tree-ssa/if-to-switch-1.C
index 88505e8869f..96c4d577064 100644
--- a/gcc/testsuite/g++.dg/tree-ssa/if-to-switch-1.C
+++ b/gcc/testsuite/g++.dg/tree-ssa/if-to-switch-1.C
@@ -22,4 +22,4 @@ void tree_node() {
   int g = 0;
 }
 
-/* { dg-final { scan-tree-dump "Condition chain with 3 BBs transformed into a switch statement." "iftoswitch" } } */

+/* { dg-final { scan-tree-dump "Condition chain with .* BBs transformed into a switch 
statement." "iftoswitch" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-1.c 
b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-1.c
index 92df4e93bfa..52f92ae145d 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-1.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-1.c
@@ -32,4 +32,4 @@ int main(int argc, char **argv)
   return 0;
 }
 
-/* { dg-final { scan-tree-dump "Condition chain with 5 BBs transformed into a switch statement." "iftoswitch" } } */

+/* { dg-final { scan-tree-dump "Condition chain with .* BBs transformed into a switch 
statement." "iftoswitch" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-2.c 
b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-2.c
index 36e62ae5be1..c229614a3d8 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-2.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-2.c
@@ -1,11 +1,11 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fdump-tree-iftoswitch-optimized" } */
 
-int IsHTMLWhitespaceNoRange(int aChar)

+int isMyRandomCharacter(int aChar)
 {
   return aChar == 0x0001 || aChar == 0x000A ||
  aChar == 0x000C || aChar == 0x000E ||
  aChar == 0x0020;
 }
 
-/* { dg-final { scan-tree-dump "Condition chain with 3 BBs transformed into a switch statement." "iftoswitch" } } */

+/* { dg-final { scan-tree-dump "Condition chain with .* BBs transformed into a switch 
statement." "iftoswitch" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-3.c 
b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-3.c
index 9a4ce160238..4c7253ce212 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-3.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-3.c
@@ -1,11 +1,11 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -fdump-tree-iftoswitch-optimized" } */
 
-int IsHTMLWhitespace(int aChar)

+int IsMySuperRandomChar(int aChar)
 {
   return aChar == 0x0009 || aChar == 0x000A ||
  aChar == 0x000C || aChar == 0x000D ||
  aChar == 0x0020 || aChar == 0x0030;
 }
 
-/* { dg-final { scan-tree-dump "Condition chain with 3 BBs transformed into a switch statement." "iftoswitch" } } */

+/* { dg-final { scan-tree-dump "Condition chain with .* BBs transformed into a switch 
statement." "iftoswitch" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-5.c 
b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-5.c
index 7734a58500b..43b0f31b2ff 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-5.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-5.c
@@ -9,4 +9,4 @@ int crud (unsigned char c)
   || (int) c == 39) != 0);
 }
 
-/* { dg-final { scan-tree-dump "Condition chain with 5 BBs transformed into a switch statement." "iftoswitch" } } */

+/* { dg-final { scan-tree-dump "Condition chain with .* BBs transformed into a switch 
statement." "iftoswitch" } } */
--
2.29.2

Re: How to traverse all the local variables that declared in the current routine?

[Qing Zhao via Gcc-patches]

Hi, Richard, 

Could you please comment on the following approach:

Instead of adding the zero-initializer quite late at the pass “pass_expand”, we 
can add it as early as during gimplification. 
However, we will mark these new added zero-initializers as “artificial”. And 
passing this “artificial” information to 
“pass_early_warn_uninitialized” and “pass_late_warn_uninitialized”, in these 
two uninitialized variable analysis passes, 
(i.e., in tree-sea-uninit.c) We will update the checking on 
“ssa_undefined_value_p”  to consider “artificial” zero-initializers. 
(i.e, if the def_stmt is marked with “artificial”, then it’s a undefined 
value). 

With such approach, we should be able to address all those conflicts. 

Do you see any obvious issue with this approach?

Thanks a lot for your help.

Qing


> On Nov 25, 2020, at 3:11 AM, Richard Biener  
> wrote:
>> 
>> 
>> I am planing to add a new phase immediately after 
>> “pass_late_warn_uninitialized” to initialize all auto-variables that are
>> not explicitly initialized in the declaration, the basic idea is following:
>> 
>> ** The proposal:
>> 
>> A. add a new GCC option: (same name and meaning as CLANG)
>> -ftrivial-auto-var-init=[pattern|zero], similar pattern init as CLANG;
>> 
>> B. add a new attribute for variable:
>> __attribute((uninitialized)
>> the marked variable is uninitialized intentionaly for performance purpose.
>> 
>> C. The implementation needs to keep the current static warning on 
>> uninitialized
>> variables untouched in order to avoid "forking the language".
>> 
>> 
>> ** The implementation:
>> 
>> There are two major requirements for the implementation:
>> 
>> 1. all auto-variables that do not have an explicit initializer should be 
>> initialized to
>> zero by this option.  (Same behavior as CLANG)
>> 
>> 2. keep the current static warning on uninitialized variables untouched.
>> 
>> In order to satisfy 1, we should check whether an auto-variable has 
>> initializer
>> or not;
>> In order to satisfy 2, we should add this new transformation after
>> "pass_late_warn_uninitialized".
>> 
>> So, we should be able to check whether an auto-variable has initializer or 
>> not after “pass_late_warn_uninitialized”,
>> If Not, then insert an initialization for it.
>> 
>> For this purpose, I guess that “FOR_EACH_LOCAL_DECL” might be better?
>> 
>> 
>> I think both as long as they are source-level auto-variables. Then which one 
>> is better?
>> 
>> 
>> Another issue is, in order to check whether an auto-variable has 
>> initializer, I plan to add a new bit in “decl_common” as:
>> /* In a VAR_DECL, this is DECL_IS_INITIALIZED.  */
>> unsigned decl_is_initialized :1;
>> 
>> /* IN VAR_DECL, set when the decl is initialized at the declaration.  */
>> #define DECL_IS_INITIALIZED(NODE) \
>> (DECL_COMMON_CHECK (NODE)->decl_common.decl_is_initialized)
>> 
>> set this bit when setting DECL_INITIAL for the variables in FE. then keep it
>> even though DECL_INITIAL might be NULLed.
>> 
>> 
>> For locals it would be more reliable to set this flag-Wmaybe-uninitialized.
>> 
>> 
>> You mean I can set the flag “DECL_IS_INITIALIZED (decl)”  inside the routine 
>> “gimpley_decl_expr” (gimplify.c) as following:
>> 
>>  if (VAR_P (decl) && !DECL_EXTERNAL (decl))
>>{
>>  tree init = DECL_INITIAL (decl);
>> ...
>>  if (init && init != error_mark_node)
>>{
>>  if (!TREE_STATIC (decl))
>>{
>>  DECL_IS_INITIALIZED(decl) = 1;
>>}
>> 
>> Is this enough for all Frontends? Are there other places that I need to 
>> maintain this bit?
>> 
>> 
>> 
>> Do you have any comment and suggestions?
>> 
>> 
>> As said above - do you want to cover registers as well as locals?
>> 
>> 
>> All the locals from the source-code point of view should be covered.   (From 
>> my study so far,  looks like that Clang adds that phase in FE).
>> If GCC adds this phase in FE, then the following design requirement
>> 
>> C. The implementation needs to keep the current static warning on 
>> uninitialized
>> variables untouched in order to avoid "forking the language”.
>> 
>> cannot be satisfied.  Since gcc’s uninitialized variables analysis is 
>> applied quite late.
>> 
>> So, we have to add this new phase after “pass_late_warn_uninitialized”.
>> 
>> I'd do
>> the actual zeroing during RTL expansion instead since otherwise you
>> have to figure youself whether a local is actually used (see 
>> expand_stack_vars)
>> 
>> 
>> Adding  this new transformation during RTL expansion is okay.  I will check 
>> on this in more details to see how to add it to RTL expansion phase.
>> 
>> 
>> Note that optimization will already made have use of "uninitialized" state
>> of locals so depending on what the actual goal is here "late" may be too 
>> late.
>> 
>> 
>> This is a really good point…
>> 
>> In order to avoid optimization  to use the “uninitialized” state of locals, 
>> we should add the zeroing phase as early as possible (adding it in FE might 
>> be best
>> for this 

C++ Module keywords

[Nathan Sidwell]

This adds the module keywords.  These are special internal tokens
generated by the preprocessor's module-control-line token peeking
logic.  Spelling them with a space means that they turn back into
regular tokens in preprocessor output (but do skew the column
numbering :()

gcc/c-family/
* c-common.c (module, import, export): New internal tokens (with
trailing space).
* c-common.h (RID__MODULE, RID__IMPORT & RID__EXPORT): Enumerate
them.
(D_CXX_MODULES, D_CXX_MODULES_FLAGS): Enable them.
* c-cppbuiltins.c (c_cpp_builtins): Feature macro.
gcc/cp/
* lex.c (init_reswords): Maybe enable module keywords.

pushing to trunk

--
Nathan Sidwell
diff --git i/gcc/c-family/c-common.c w/gcc/c-family/c-common.c
index 5d1e4ef289c..cae883b5309 100644
--- i/gcc/c-family/c-common.c
+++ w/gcc/c-family/c-common.c
@@ -540,6 +540,12 @@ const struct c_common_resword c_common_reswords[] =
   { "concept",		RID_CONCEPT,	D_CXX_CONCEPTS_FLAGS | D_CXXWARN },
   { "requires", 	RID_REQUIRES,	D_CXX_CONCEPTS_FLAGS | D_CXXWARN },
 
+  /* Modules-related keywords, these are internal unspellable tokens,
+ created by the preprocessor.  */
+  { "module ",		RID__MODULE,	D_CXX_MODULES_FLAGS | D_CXXWARN },
+  { "import ",		RID__IMPORT,	D_CXX_MODULES_FLAGS | D_CXXWARN },
+  { "export ",		RID__EXPORT,	D_CXX_MODULES_FLAGS | D_CXXWARN },
+
   /* Coroutines-related keywords */
   { "co_await",		RID_CO_AWAIT,	D_CXX_COROUTINES_FLAGS | D_CXXWARN },
   { "co_yield",		RID_CO_YIELD,	D_CXX_COROUTINES_FLAGS | D_CXXWARN },
diff --git i/gcc/c-family/c-common.h w/gcc/c-family/c-common.h
index f413e8773f5..8c17067e63c 100644
--- i/gcc/c-family/c-common.h
+++ w/gcc/c-family/c-common.h
@@ -195,6 +195,9 @@ enum rid
   /* C++ concepts */
   RID_CONCEPT, RID_REQUIRES,
 
+  /* C++ modules.  */
+  RID__MODULE, RID__IMPORT, RID__EXPORT, /* Internal tokens.  */
+
   /* C++ coroutines */
   RID_CO_AWAIT, RID_CO_YIELD, RID_CO_RETURN,
 
@@ -449,9 +452,11 @@ extern machine_mode c_default_pointer_mode;
 #define D_CXX_CHAR8_T	0X1000	/* In C++, only with -fchar8_t.  */
 #define D_CXX20		0x2000  /* In C++, C++20 only.  */
 #define D_CXX_COROUTINES 0x4000  /* In C++, only with coroutines.  */
+#define D_CXX_MODULES	0x8000  /* In C++, only with modules.  */
 
 #define D_CXX_CONCEPTS_FLAGS D_CXXONLY | D_CXX_CONCEPTS
 #define D_CXX_CHAR8_T_FLAGS D_CXXONLY | D_CXX_CHAR8_T
+#define D_CXX_MODULES_FLAGS (D_CXXONLY | D_CXX_MODULES)
 #define D_CXX_COROUTINES_FLAGS (D_CXXONLY | D_CXX_COROUTINES)
 
 /* The reserved keyword table.  */
diff --git i/gcc/c-family/c-cppbuiltin.c w/gcc/c-family/c-cppbuiltin.c
index d35b087bdcc..41914f64874 100644
--- i/gcc/c-family/c-cppbuiltin.c
+++ w/gcc/c-family/c-cppbuiltin.c
@@ -1025,6 +1025,10 @@ c_cpp_builtins (cpp_reader *pfile)
   else
 cpp_define (pfile, "__cpp_concepts=201507L");
 }
+  if (flag_modules)
+	/* The std-defined value is 201907L, but I don't think we can
+	   claim victory yet.  201810 is the p1103 date. */
+	cpp_define (pfile, "__cpp_modules=201810L");
   if (flag_coroutines)
 	cpp_define (pfile, "__cpp_impl_coroutine=201902L"); /* n4861, DIS */
   if (flag_tm)
diff --git i/gcc/cp/lex.c w/gcc/cp/lex.c
index 8a69bc4f170..21e33d69c08 100644
--- i/gcc/cp/lex.c
+++ w/gcc/cp/lex.c
@@ -235,6 +235,8 @@ init_reswords (void)
 mask |= D_CXX_CONCEPTS;
   if (!flag_coroutines)
 mask |= D_CXX_COROUTINES;
+  if (!flag_modules)
+mask |= D_CXX_MODULES;
   if (!flag_tm)
 mask |= D_TRANSMEM;
   if (!flag_char8_t)

C++ Module parameters & timers

[Nathan Sidwell]

Here is the new parameter and instrumentation timers for modules.

gcc/
* params.opt (lazy-modules): New.
* timevar.def (TV_MODULE_IMPORT, TV_MODULE_EXPORT)
(TV_MODULE_MAPPER): New.


pushing to trunk
--
Nathan Sidwell
diff --git c/gcc/params.opt w/gcc/params.opt
index 7bac39a9d58..0366584f94e 100644
--- c/gcc/params.opt
+++ w/gcc/params.opt
@@ -349,6 +349,10 @@ Maximal stack frame growth due to inlining (in percent).
 Common Joined UInteger Var(param_large_unit_insns) Optimization Init(1) Param
 The size of translation unit to be considered large.
 
+-param=lazy-modules=
+C++ Joined UInteger Var(param_lazy_modules) Init(32768) Param
+Maximum number of concurrently open C++ module files when lazy loading.
+
 -param=lim-expensive=
 Common Joined UInteger Var(param_lim_expensive) Init(20) Param Optimization
 The minimum cost of an expensive expression in the loop invariant motion.
diff --git c/gcc/timevar.def w/gcc/timevar.def
index 08c21c04009..f2bd58f0f58 100644
--- c/gcc/timevar.def
+++ w/gcc/timevar.def
@@ -145,6 +145,9 @@ DEFTIMEVAR (TV_CONSTEXPR	 , "constant expression evaluation")
 DEFTIMEVAR (TV_CONSTRAINT_NORM	 , "constraint normalization")
 DEFTIMEVAR (TV_CONSTRAINT_SAT	 , "constraint satisfaction")
 DEFTIMEVAR (TV_CONSTRAINT_SUB	 , "constraint subsumption")
+DEFTIMEVAR (TV_MODULE_IMPORT	 , "module import")
+DEFTIMEVAR (TV_MODULE_EXPORT	 , "module export")
+DEFTIMEVAR (TV_MODULE_MAPPER , "module mapper")
 DEFTIMEVAR (TV_FLATTEN_INLINING  , "flatten inlining")
 DEFTIMEVAR (TV_EARLY_INLINING, "early inlining heuristics")
 DEFTIMEVAR (TV_INLINE_PARAMETERS , "inline parameters")

[PATCH] if-to-switch: consider only integral types

[Martin Liška]

It fixes ICE seen in the PR which is about gswitch statements
where an index type should be only an integral type.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

gcc/ChangeLog:

PR tree-optimization/98084
* gimple-if-to-switch.cc (find_conditions): Consider only
integral types.

gcc/testsuite/ChangeLog:

PR tree-optimization/98084
* gcc.dg/tree-ssa/pr98084.c: New test.
---
 gcc/gimple-if-to-switch.cc  |  1 +
 gcc/testsuite/gcc.dg/tree-ssa/pr98084.c | 26 +
 2 files changed, 27 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr98084.c

diff --git a/gcc/gimple-if-to-switch.cc b/gcc/gimple-if-to-switch.cc
index d132064fb9b..0aa1b0e4e7e 100644
--- a/gcc/gimple-if-to-switch.cc
+++ b/gcc/gimple-if-to-switch.cc
@@ -429,6 +429,7 @@ find_conditions (basic_block bb,
 
   for (unsigned i = 0; i < info.m_ranges.length (); ++i)

if (info.m_ranges[i].exp == NULL_TREE
+   || !INTEGRAL_TYPE_P (TREE_TYPE (info.m_ranges[i].exp))
|| info.m_ranges[i].low == NULL_TREE
|| info.m_ranges[i].high == NULL_TREE)
  return;
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr98084.c 
b/gcc/testsuite/gcc.dg/tree-ssa/pr98084.c
new file mode 100644
index 000..637962481d1
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr98084.c
@@ -0,0 +1,26 @@
+/* PR tree-optimization/98084 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+enum {
+  JSON_VARIANT_STRING,
+  JSON_VARIANT_UNSIGNED,
+  JSON_VARIANT_REAL,
+  JSON_VARIANT_ARRAY,
+  _JSON_VARIANT_TYPE_INVALID,
+  _JSON_VARIANT_MAGIC_ZERO_UNSIGNED,
+  _JSON_VARIANT_MAGIC_ZERO_REAL,
+  _JSON_VARIANT_MAGIC_EMPTY_STRING,
+  _JSON_VARIANT_MAGIC_EMPTY_ARRAY
+} json_variant_type(int *v) {
+  if (!v)
+return _JSON_VARIANT_TYPE_INVALID;
+  if (v == (int *)_JSON_VARIANT_MAGIC_ZERO_UNSIGNED)
+return JSON_VARIANT_UNSIGNED;
+  if (v == (int *)_JSON_VARIANT_MAGIC_ZERO_REAL)
+return JSON_VARIANT_REAL;
+  if (v == (int *)_JSON_VARIANT_MAGIC_EMPTY_STRING)
+return JSON_VARIANT_STRING;
+  if (v == (int *)_JSON_VARIANT_MAGIC_EMPTY_ARRAY)
+return JSON_VARIANT_ARRAY;
+}
--
2.29.2

[PATCH] Remove misleading debug line entries

[Bernd Edlinger]

Hi!


This removes gimple_debug stmts without block info after a
NULL INLINE_ENTRY.

The line numbers from these stmts are from the inline function,
but since the inline function is completely optimized away,
there will be no DW_TAG_inlined_subroutine so the debugger has
no callstack available at this point, and therefore those
line table entries are not helpful to the user.

2020-11-20  Bernd Edlinger  

* cfgexpand.c (expand_gimple_basic_block): Remove debug_begin_stmts
following a removed debug_inline_entry.


Bootstrapped and reg-tested on x86_64-pc-linux-gnu.
Is it OK for trunk?


Thanks
Bernd.
From 464867ca9b4cc6270fb6d41dc5346dc55395efb0 Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Fri, 13 Nov 2020 16:26:28 +0100
Subject: [PATCH] Remove misleading debug line entries

This removes gimple_debug stmts without block info after a
NULL INLINE_ENTRY.

The line numbers from these stmts are from the inline function,
but since the inline function is completely optimized away,
there will be no DW_TAG_inlined_subroutine so the debugger has
no callstack available at this point, and therefore those
line table entries are not helpful to the user.

2020-11-20  Bernd Edlinger  

	* cfgexpand.c (expand_gimple_basic_block): Remove debug_begin_stmts
	following a removed debug_inline_entry.
---
 gcc/cfgexpand.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 1df6f4b..6bd38ac 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -5785,6 +5785,7 @@ expand_gimple_basic_block (basic_block bb, bool disable_tail_calls)
 	  tree value = NULL_TREE;
 	  rtx val = NULL_RTX;
 	  machine_mode mode;
+	  bool skip_inline_loc = false;
 
 	  if (!gimple_debug_nonbind_marker_p (stmt))
 		{
@@ -5837,7 +5838,10 @@ expand_gimple_basic_block (basic_block bb, bool disable_tail_calls)
 		  if (block)
 		val = GEN_RTX_DEBUG_MARKER_INLINE_ENTRY_PAT ();
 		  else
-		goto delink_debug_stmt;
+		{
+		  skip_inline_loc = true;
+		  goto delink_debug_stmt;
+		}
 		}
 	  else
 		gcc_unreachable ();
@@ -5877,6 +5881,8 @@ expand_gimple_basic_block (basic_block bb, bool disable_tail_calls)
 	  stmt = gsi_stmt (nsi);
 	  if (!is_gimple_debug (stmt))
 		break;
+	  if (skip_inline_loc && !gimple_block (stmt))
+		goto delink_debug_stmt;
 	}
 
 	  set_curr_insn_location (sloc);
-- 
1.9.1

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Michael Meissner via Gcc-patches]

On Tue, Dec 01, 2020 at 04:04:30PM +, Jonathan Wakely wrote:
> On 01/12/20 15:10 +, Jonathan Wakely wrote:
> >On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:
> >>Jonathan, could you send a fresh set of patches (or at least replacements)? 
> >> I
> >>tried installing the patches on a master branch I checked out this morning, 
> >>and
> >>I got two rejects:
> >
> >I don't understand why those chunks failed, but I'll rebase and send a
> >new patch ASAP.
> 
> Here's the rebased patch, with regenerated autoconf files and a fix
> for the  header. I'd changed it since sending
> the previous patch, and broke the "there's more than one long double"
> case (i.e. the _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT case).

Unfortunately this patch DOES NOT work at all.

If I build a compiler with the configure option:
--with-long-double-format=ieee

And I compile this simple program:

#include 

int main(int argc, char *argv[], char *envp[])
{
  std::cout << "Hello World!\n";
  return 0;
}

I get all of these errors:

/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::ostreambuf_iterator > 
std::num_put > 
>::_M_insert_int(std::ostreambuf_iterator >, 
std::ios_base&, char, long) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::money_get > 
>::_M_extract(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, std::string&) 
const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::ostreambuf_iterator > 
std::money_put > 
>::_M_insert(std::ostreambuf_iterator >, 
std::ios_base&, char, std::string const&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, unsigned long 
long&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, long long&) 
const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::money_get > 
>::_M_extract(std::istreambuf_iterator 
>, std::istreambuf_iterator >, 
std::ios_base&, std::_Ios_Iostate&, std::string&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, unsigned int&) 
const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator >, std::ios_base&, std::_Ios_Iostate&, unsigned 
long&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > 
std::num_get > 
>::_M_extract_int(std::istreambuf_iterator >, std::istreambuf_iterator 
>, std::ios_base&, std::_Ios_Iostate&, unsigned int&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::istreambuf_iterator > 
std::money_get > 
>::_M_extract(std::istreambuf_iterator >, 
std::istreambuf_iterator >, std::ios_base&, 
std::_Ios_Iostate&, std::string&) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::ostreambuf_iterator > std::num_put > 
>::_M_insert_float(std::ostreambuf_iterator >, std::ios_base&, wchar_t, char, long double) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/work029-kf/lib/../lib64/libstdc++.so: 
undefined reference to `std::ostreambuf_iterator > 
std::num_put > 
>::_M_insert_int(std::ostreambuf_iterator >, std::ios_base&, char, unsigned long) const'
/home3/meissner/fsf-install-ppc64le/binutils-gdb/bin/ld: 
/home/meissner/fsf-install-ppc64le/wor

C++ Module options

[Nathan Sidwell]

This adds the C++ module options, and wires them into lang-specs.  The
options are not connected to any machinery.  The options! They do
nothing!

Since posting the earlier patch, I added 
-flang-info-include-translate-not, to warn about header files that are 
being treated textually.


gcc/c-family/
* c-opts.c (c_common_init_options): Ask for module dependencies.
(c_common_handle_option): Handle -Mmodules -Mno-modules.
* c-pch.c (c_common_valid_pch): ... does not play with C++
modules.
* c.opt (Mmodules, Mno-modules): New preprocessor dependency
options.
(fmodules-ts, fmodule-header, fmodule-implicit-inline)
(fmodule-only, fmodule-mapper, fmodule-lazy)
(fmodule-version-ignore, Winvalid-imported-macros)
(flang-info-include-translate, flang-info-include-translate-not):
New options
gcc/cp/
* lang-spec.h: Add module-related options.

pushing to trunk

nathan

--
Nathan Sidwell
diff --git c/gcc/c-family/c-opts.c w/gcc/c-family/c-opts.c
index 77844d7daf1..59cabd12407 100644
--- c/gcc/c-family/c-opts.c
+++ w/gcc/c-family/c-opts.c
@@ -234,6 +234,7 @@ c_common_init_options (unsigned int decoded_options_count,
   cpp_opts = cpp_get_options (parse_in);
   cpp_opts->dollars_in_ident = DOLLARS_IN_IDENTIFIERS;
   cpp_opts->objc = c_dialect_objc ();
+  cpp_opts->deps.modules = true;
 
   /* Reset to avoid warnings on internal definitions.  We set it just
  before passing on command-line options to cpplib.  */
@@ -367,6 +368,18 @@ c_common_handle_option (size_t scode, const char *arg, HOST_WIDE_INT value,
   cpp_opts->deps.phony_targets = true;
   break;
 
+case OPT_Mmodules:
+  /* Do not set deps_seen, so the user can unconditionally turn
+	 this on or off.  */
+  cpp_opts->deps.modules = true;
+  break;
+
+case OPT_Mno_modules:
+  /* Do not set deps_seen, so the user can unconditionally turn
+	 this on or off.  */
+  cpp_opts->deps.modules = false;
+  break;
+
 case OPT_MQ:
 case OPT_MT:
   deps_seen = true;
diff --git c/gcc/c-family/c-pch.c w/gcc/c-family/c-pch.c
index 9c0bd0b631d..fdeb860c0e6 100644
--- c/gcc/c-family/c-pch.c
+++ w/gcc/c-family/c-pch.c
@@ -206,6 +206,10 @@ c_common_valid_pch (cpp_reader *pfile, const char *name, int fd)
   /* Perform a quick test of whether this is a valid
  precompiled header for the current language.  */
 
+  /* C++ modules and PCH don't play together.  */
+  if (flag_modules)
+return 2;
+
   sizeread = read (fd, ident, IDENT_LENGTH + 16);
   if (sizeread == -1)
 fatal_error (input_location, "cannot read %s: %m", name);
diff --git c/gcc/c-family/c.opt w/gcc/c-family/c.opt
index 0532cb70ffc..059f6c38a40 100644
--- c/gcc/c-family/c.opt
+++ w/gcc/c-family/c.opt
@@ -236,6 +236,14 @@ MMD
 C ObjC C++ ObjC++ NoDriverArg Separate MissingArgError(missing filename after %qs)
 Like -MD but ignore system header files.
 
+Mmodules
+C++
+Generate C++ Module dependency information.
+
+Mno-modules
+C++
+; undocumented
+
 MP
 C ObjC C++ ObjC++
 Generate phony targets for all headers.
@@ -1683,6 +1691,57 @@ flax-vector-conversions
 C ObjC C++ ObjC++ Var(flag_lax_vector_conversions)
 Allow implicit conversions between vectors with differing numbers of subparts and/or differing element types.
 
+fmodules-ts
+C++ ObjC++ Var(flag_modules) Integer Init(0)
+Enable C++ modules-ts (experimental).
+
+fno-modules
+C++ ObjC++ Undocumented RejectNegative Var(flag_modules,0) Integer
+;; undocumented
+
+fmodule-header
+C++ ObjC RejectNegative Var(flag_header_unit,0) Integer
+Enable C++ header module (experimental).
+
+fmodule-header=
+C++ ObjC++ Joined RejectNegative Undocumented
+
+fmodule-implicit-inline
+C++ ObjC++ Var(flag_module_implicit_inline,0) Integer
+Member functions defined within their class are inline in module purview.
+
+fmodule-only
+C++ ObjC RejectNegative Var(flag_module_only) Integer
+Only emit Compiled Module Interface.
+
+fmodule-mapper=
+C++ ObjC++ Joined RejectNegative MissingArgError(missing mapper)
+Mapper for module to CMI files.
+
+fmodule-lazy
+C++ ObjC++ Var(flag_module_lazy) Init(1)
+Enable lazy module importing.
+
+fmodule-version-ignore
+C++ ObjC Var(flag_module_version_ignore) Integer
+; undocumented, Very dangerous, but occasionally useful
+
+Winvalid-imported-macros
+C++ ObjC++ Var(warn_imported_macros)
+Warn about macros that have conflicting header units definitions.
+
+flang-info-include-translate
+C++ Var(note_include_translate_yes)
+Note #include directives translated to import declarations.
+
+flang-info-include-translate-not
+C++ Var(note_include_translate_no)
+Note #include directives not translated to import declarations, and not known to be textual.
+
+flang-info-include-translate=
+C++ Joined RejectNegative MissingArgError(missing header name)
+Note a #include translation of a specific header.
+
 fmax-include-depth=
 C ObjC C++ ObjC++ Joined RejectNegative UInteger
 fmax-include-depth= Set

Re: [PATCH] Avoid atomic for guard acquire when that is expensive

[Bernd Edlinger]

On 11/24/20 11:10 PM, Jason Merrill wrote:
> On 11/22/20 3:05 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> this avoids the need to use -fno-threadsafe-statics on
>> arm-none-eabi or working around that problem by supplying
>> a dummy __sync_synchronize function which might
>> just lead to silent code failure of the worst kind
>> (non-reproducable, racy) at runtime, as was pointed out
>> on previous discussions here.
>>
>> When the atomic access involves a call to __sync_synchronize
>> it is better to call __cxa_guard_acquire unconditionally,
>> since it handles the atomics too, or is a non-threaded
>> implementation when there is no gthread support for this target.
>>
>> This fixes also a bug for the ARM EABI big-endian target,
>> that is, previously the wrong bit was checked.
> 
> Instead of a new target macro, can't you follow 
> fold_builtin_atomic_always_lock_free/can_atomic_load_p?
> 

Yes, thanks, that should work too.
Would you like this better?


Thanks
Bernd.
From 863b023786f7e8321979bcdb33c027d37d5e155b Mon Sep 17 00:00:00 2001
From: Bernd Edlinger 
Date: Tue, 1 Dec 2020 18:54:48 +0100
Subject: [PATCH] Avoid atomic for guard acquire when that is expensive

When the atomic access involves a call to __sync_synchronize
it is better to call __cxa_guard_acquire unconditionally,
since it handles the atomics too, or is a non-threaded
implementation when there is no gthread support for this target.

This fixes also a bug for the ARM EABI big-endian target,
that is, previously the wrong bit was checked.

2020-11-22  Bernd Edlinger  

	* decl2.c: (is_atomic_expensive_p): New helper function.
	(build_atomic_load_byte): Rename to...
	(build_atomic_load_type): ... and add new parameter type.
	(get_guard_cond): Skip the atomic here if that is expensive.
	Use the correct type for the atomic load on certain targets.
---
 gcc/cp/decl2.c | 33 +
 1 file changed, 29 insertions(+), 4 deletions(-)

diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c
index 1bc7b7e..5001e8f 100644
--- a/gcc/cp/decl2.c
+++ b/gcc/cp/decl2.c
@@ -48,6 +48,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "intl.h"
 #include "c-family/c-ada-spec.h"
 #include "asan.h"
+#include "optabs-query.h"
 
 /* Id for dumping the raw trees.  */
 int raw_dump_id;
@@ -3297,18 +3298,34 @@ get_guard (tree decl)
   return guard;
 }
 
+/* Returns true if accessing the GUARD atomic is expensive,
+   i.e. involves a call to __sync_synchronize or similar.
+   In this case let __cxa_guard_acquire handle the atomics.  */
+
+static bool
+is_atomic_expensive_p (machine_mode mode)
+{
+  if (!flag_inline_atomics)
+return false;
+
+  if (!can_compare_and_swap_p (mode, false) || !can_atomic_load_p (mode))
+return false;
+
+  return true;
+}
+
 /* Return an atomic load of src with the appropriate memory model.  */
 
 static tree
-build_atomic_load_byte (tree src, HOST_WIDE_INT model)
+build_atomic_load_type (tree src, HOST_WIDE_INT model, tree type)
 {
-  tree ptr_type = build_pointer_type (char_type_node);
+  tree ptr_type = build_pointer_type (type);
   tree mem_model = build_int_cst (integer_type_node, model);
   tree t, addr, val;
   unsigned int size;
   int fncode;
 
-  size = tree_to_uhwi (TYPE_SIZE_UNIT (char_type_node));
+  size = tree_to_uhwi (TYPE_SIZE_UNIT (type));
 
   fncode = BUILT_IN_ATOMIC_LOAD_N + exact_log2 (size) + 1;
   t = builtin_decl_implicit ((enum built_in_function) fncode);
@@ -3351,7 +3368,15 @@ get_guard_cond (tree guard, bool thread_safe)
   if (!thread_safe)
 guard = get_guard_bits (guard);
   else
-guard = build_atomic_load_byte (guard, MEMMODEL_ACQUIRE);
+{
+  tree type = targetm.cxx.guard_mask_bit ()
+		  ? TREE_TYPE (guard) : char_type_node;
+
+  if (is_atomic_expensive_p (TYPE_MODE (type)))
+	guard = integer_zero_node;
+  else
+	guard = build_atomic_load_type (guard, MEMMODEL_ACQUIRE, type);
+}
 
   /* Mask off all but the low bit.  */
   if (targetm.cxx.guard_mask_bit ())
-- 
1.9.1

[PATCH] c++: Fix tsubst ICE with invalid code [PR97993, PR97187]

[Marek Polacek via Gcc-patches]

I had a strong sense of deja vu when looking into this, and no wonder,
since this is almost identical to c++/95728.

Since r11-423 tsubst_copy_and_build/TREE_LIST uses tsubst_tree_list
instead of open coding it.  While the latter could return an error
node wrapped in a TREE_LIST, the former can return a naked error node.

That broke in tsubst_copy_and_build/NEW_EXPR, because we were accessing
TREE_VALUE of an error node.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?

gcc/cp/ChangeLog:

PR c++/97187
PR c++/97993
* pt.c (tsubst_copy_and_build) : Return error_mark_node
if init is erroneous.

gcc/testsuite/ChangeLog:

PR c++/97187
PR c++/97993
* g++.dg/eh/crash2.C: New test.
* g++.dg/template/crash132.C: New test.
---
 gcc/cp/pt.c  |  2 ++
 gcc/testsuite/g++.dg/eh/crash2.C | 20 
 gcc/testsuite/g++.dg/template/crash132.C |  6 ++
 3 files changed, 28 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/eh/crash2.C
 create mode 100644 gcc/testsuite/g++.dg/template/crash132.C

diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 4fb0bc82c31..72d6cc3ad98 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -19829,6 +19829,8 @@ tsubst_copy_and_build (tree t,
   parameter packs are of length zero.  */
if (init == NULL_TREE && TREE_OPERAND (t, 3) == NULL_TREE)
  init_vec = NULL;
+   else if (init == error_mark_node)
+ RETURN (error_mark_node);
else
  {
init_vec = make_tree_vector ();
diff --git a/gcc/testsuite/g++.dg/eh/crash2.C b/gcc/testsuite/g++.dg/eh/crash2.C
new file mode 100644
index 000..fff8e142fd6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/eh/crash2.C
@@ -0,0 +1,20 @@
+// PR c++/97187
+// { dg-do compile { target c++14 } }
+// { dg-options "-fno-exceptions" }
+
+auto yp = [] { return 0; };
+
+template 
+DI
+zl ()
+{
+  auto au = [] () -> DI { return *new auto (true ? yp : throw); }; // { 
dg-error "exception handling disabled" }
+
+  return au ();
+}
+
+auto
+vd ()
+{
+  return zl  ();
+}
diff --git a/gcc/testsuite/g++.dg/template/crash132.C 
b/gcc/testsuite/g++.dg/template/crash132.C
new file mode 100644
index 000..f6f4863e937
--- /dev/null
+++ b/gcc/testsuite/g++.dg/template/crash132.C
@@ -0,0 +1,6 @@
+// PR c++/97993
+// { dg-do compile { target c++14 } }
+
+template  T a;
+template  auto foo ();
+struct S decltype (foo ); // { dg-error "" }

base-commit: b46314c78061a5156bac44a317c87d32b00d4295
-- 
2.28.0

[PATCH] c++: Fix ICE with inline variable in template [PR97975]

[Marek Polacek via Gcc-patches]

In this test, we have

  static inline const int c = b;

in a class template, and we call store_init_value as usual.  There, the
value is

  IMPLICIT_CONV_EXPR(b)

which is is_nondependent_static_init_expression but isn't
is_nondependent_constant_expression (they only differ in STRICT).
We call fold_non_dependent_expr, but that just returns the expression
because it only instantiates is_nondependent_constant_expression
expressions.  Since we're not checking the initializer of a constexpr
variable, we go on to call maybe_constant_init, whereupon we crash
because it tries to evaluate all is_nondependent_static_init_expression
expressions, which our value is, but it still contains a template code.

I think the fix is to call fold_non_dependent_init instead of
maybe_constant_init, and only call fold_non_dependent_expr on the
"this is a constexpr variable" path so as to avoid instantiating twice
in a row.  Outside a template this should also avoid evaluating the
value twice.

Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10?

gcc/cp/ChangeLog:

PR c++/97975
* constexpr.c (fold_non_dependent_init): Add a tree parameter.
Use it.
* cp-tree.h (fold_non_dependent_init): Add a tree parameter with
a default value.
* typeck2.c (store_init_value): Call fold_non_dependent_expr
only when checking the initializer for constexpr variables.
Call fold_non_dependent_init instead of maybe_constant_init.

gcc/testsuite/ChangeLog:

PR c++/97975
* g++.dg/cpp1z/inline-var8.C: New test.
---
 gcc/cp/constexpr.c   |  7 ---
 gcc/cp/cp-tree.h |  2 +-
 gcc/cp/typeck2.c |  7 +--
 gcc/testsuite/g++.dg/cpp1z/inline-var8.C | 17 +
 4 files changed, 27 insertions(+), 6 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp1z/inline-var8.C

diff --git a/gcc/cp/constexpr.c b/gcc/cp/constexpr.c
index 054ee524c7a..9a1a1db1267 100644
--- a/gcc/cp/constexpr.c
+++ b/gcc/cp/constexpr.c
@@ -7271,7 +7271,8 @@ maybe_fold_non_dependent_expr (tree expr,
 tree
 fold_non_dependent_init (tree t,
 tsubst_flags_t complain /*=tf_warning_or_error*/,
-bool manifestly_const_eval /*=false*/)
+bool manifestly_const_eval /*=false*/,
+tree object /* = NULL_TREE */)
 {
   if (t == NULL_TREE)
 return NULL_TREE;
@@ -7279,7 +7280,7 @@ fold_non_dependent_init (tree t,
   if (processing_template_decl)
 {
   t = fold_non_dependent_expr_template (t, complain,
-   manifestly_const_eval, NULL_TREE);
+   manifestly_const_eval, object);
   /* maybe_constant_init does this stripping, so do it here too.  */
   if (TREE_CODE (t) == TARGET_EXPR)
{
@@ -7290,7 +7291,7 @@ fold_non_dependent_init (tree t,
   return t;
 }
 
-  return maybe_constant_init (t, NULL_TREE, manifestly_const_eval);
+  return maybe_constant_init (t, object, manifestly_const_eval);
 }
 
 /* Like maybe_constant_value, but returns a CONSTRUCTOR directly, rather
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 021de76e142..41516deeafa 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -7953,7 +7953,7 @@ extern tree maybe_fold_non_dependent_expr (tree,
 tsubst_flags_t = 
tf_warning_or_error);
 extern tree fold_non_dependent_init(tree,
 tsubst_flags_t = 
tf_warning_or_error,
-bool = false);
+bool = false, tree = 
NULL_TREE);
 extern tree fold_simple(tree);
 extern bool reduced_constant_expression_p   (tree);
 extern bool is_instantiation_of_constexpr   (tree);
diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 721987e8502..575c609a365 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -744,11 +744,13 @@ store_init_value (tree decl, tree init, vec** cleanups, int flags)
 {
   bool const_init;
   tree oldval = value;
-  value = fold_non_dependent_expr (value, tf_warning_or_error, true, decl);
   if (DECL_DECLARED_CONSTEXPR_P (decl)
  || (DECL_IN_AGGR_P (decl)
  && DECL_INITIALIZED_IN_CLASS_P (decl)))
{
+ value = fold_non_dependent_expr (value, tf_warning_or_error,
+  /*manifestly_const_eval=*/true,
+  decl);
  /* Diagnose a non-constant initializer for constexpr variable or
 non-inline in-class-initialized static data member.  */
  if (!require_constant_expression (value))
@@ -762,7 +764,8 @@ store_init_value (tree decl, tree init, vec** 
cleanups, int flags)
value = cxx_constant_init (value, decl)

Re: [PATCH] detect allocation/deallocation mismatches in user-defined functions (PR94527)

[Martin Sebor via Gcc-patches]

On 11/30/20 3:53 PM, Jeff Law wrote:



On 11/13/20 2:45 PM, Martin Sebor via Gcc-patches wrote:

Bug 94527 is request from the kernel developers for an attribute
to indicate that a user-defined function deallocates an object
allocated by an earlier call to an allocation function.  Their
goal is to detect misuses of such functions and the pointers or
objects returned from them.

The recently submitted patches(*) enable the detection of a subset
of such misuses for standard allocation functions like malloc and
free, but those are just a small fraction of allocation/deallocation
functions used in practice, and only rarely used in the kernel
(mostly in utility programs). The attached patch extends attribute
malloc to enable this detection also for user-defined functions.

The design extends attribute malloc to accept one or two optional
arguments: one naming a deallocation function that deallocates
pointers returned from the malloc-like function, and another to
denote the position of the pointer argument in the deallocation
functions parameter list.  Any number of deallocators can be
associated with any number of allocators.  This makes it possible
to annotate, for example, all the POSIX  functions that
open and close FILE streams and detect mismatches between any
pairs that aren't suitable (in addition to calling free on
a FILE* returned from fopen, for instance).

An association with an allocator results in adding an internal
"*dealloc" attribute to the deallocator so that the former can
be quickly looked up based on a call to the latter.

Tested on x86_64-linux + Glibc & Binutils/GDB (no instances
of the new warnings).

Martin

[*] Prerequisite patch
add -Wmismatched-new-delete to middle end (PR 90629)
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557987.html

PS In pr94527 Jonathan notes that failing to properly match pairs
of calls isn't limited to APIs that return pointers and applies
to other kinds of "handles" including integers (e.g., the POSIX
open/close APIs), and a detection of such mismatches would be
helpful as well.  David submitted a prototype of this for
the analyzer here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/44.html
I chose not to implement nonpointer detection for some of the same
reasons as mentioned in comment #8 on the bug (and also because
there's no support for it in the machinery I use).  I also didn't
use the same attribute as David, in part because I think it's better
to provide separate attributes for pointer APIs and for others
(integers), and in part also because the deallocated_by attribute
design as is cannot accommodate my goal of supporting app standard
functions (including the  freopen which "deallocates"
the third argument).

gcc-94527.diff

PR middle-end/94527 - Add an __attribute__ that marks a function as freeing an 
object

gcc/ChangeLog:

PR middle-end/94527
* builtins.c (gimple_call_alloc_p): Handle user-defined functions.
(fndecl_alloc_p): New helper.
(call_dealloc_argno): New helper.
(gimple_call_dealloc_p): Call it.
(call_dealloc_p): Same.
(matching_alloc_calls_p): Handle user-defined functions.
(maybe_emit_free_warning): Same.
* doc/extend.texi (attribute malloc): Update.
* doc/invoke.texi (-Wmismatched-dealloc): Document new option.

gcc/c-family/ChangeLog:

PR middle-end/94527
* c-attribs.c (handle_dealloc_attribute): New function.
(handle_malloc_attribute): Handle argument forms of attribute.
* c.opt (-Wmismatched-dealloc): New option.
(-Wmismatched-new-delete): Update description.

gcc/testsuite/ChangeLog:

PR middle-end/94527
* g++.dg/warn/Wmismatched-dealloc-2.C: New test.
* g++.dg/warn/Wmismatched-dealloc.C: New test.
* gcc.dg/Wmismatched-dealloc.c: New test.
* gcc.dg/attr-malloc.c: New test.

OK once prereq is wrapped up.


Presumably you're referring to this patch:
  https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557987.html
Is there something I need to do to move it forward?  (I'm
assuming you're still reviewing the rest of the patch so
please let me know if you're waiting for me to remove
the objectionable function first.)



I realize the dealloc attribute is currently internal only to make
lookups quick.  Any thoughts on whether or not we might want to make it
a user visible attribute at some point?


I see no problem with exposing both attributes.

Martin

Re: [PATCH v3 1/2] generate EH info for volatile asm statements (PR93981)

[J.W. Jagersma via Gcc-patches]

On 2020-11-30 17:47, J.W. Jagersma wrote:
> On 2020-11-23 09:20, Richard Biener wrote:
>> On Sun, Nov 22, 2020 at 5:38 PM J.W. Jagersma  wrote:
>>>
>>> On 2020-11-21 12:27, J.W. Jagersma wrote:
 ...
 Another idea I had is to introduce a new operand modifier, eg. '-', which
 would signify that the output *must* be considered clobbered on exception,
 and it would be an error if a copy is not possible.  Then the meaning of 
 '+'
 can be extended to say that the output must be valid regardless of whether 
 an
 exception occured or not.  Modifier '=' would mean the same as '+' with the
 additional implication that it is okay to eliminate earlier assignments, so
 that its value on the EH edge would be undefined.
>>>
>>> I've been working on implementing this, but I ran into an issue:
>>>
>>> First of all, in the first version of this patch I had to make sure that
>>> debug stmts were inserted across the fallthrough edge, so that they don't
>>> appear at the end a basic block.  I was surprised to find that this is no
>>> longer necessary.
>>>
>>> Next I discovered that the following test case fails (returns -1):
>>>
>>> int f ()
>>> {
>>>   int i = 0;
>>>   try { asm ("mov %0, 1; ud2" : "+r" (i)); }
>>>   catch (...) { }
>>>   return i - 1;
>>> }
>>>
>>> And this does succeed with a memory operand.
>>>
>>> It seems that something changed in the past few months, and now asm register
>>> outputs are already being assigned via a temporary variable, somewhere.  
>>> Does
>>> anyone know where that might be?
>>
>> It's likely out-of SSA / RTL expansion inserting a bogus copy or doing
>> coalescing on the EH edge.  Semantics of throwing asm stmts need to be
>> honored there.
>>
>> Richard.
> 
> Quick update.  I have a mostly working implementation now, the only case where
> it fails is when an asm clobbers all callee-saved registers.  In this one case
> the output is not available on the exception edge.  However this same case 
> does
> work correctly with an 'asm goto' that throws.
> 
> The problem I think is in lra_process_new_insns (lra.c:1878) where the 
> condition
> to insert new insns across edges is "JUMP_P (insn)", but this should happen 
> for
> throwing asms as well.  I figured "insn == BB_END (BLOCK_FOR_INSN (insn))" 
> would
> make sense but that causes all sorts of trouble (segfaults during bootstrap).
> 
> Would appreciate any advice on what to do here.

Just realized I can make it work by simply expanding throwing asms as jump
insns with no label.  I'm not sure about the specific semantic differences
between regular and jump insns, but this doesn't seem to have any negative
effects so far.

I will submit v4 after I finish running regression tests and writing docs and
changelogs.  Or if this is not an acceptable workaround, please let me know.

[PATCH] diagnostics: ignore -fmax-errors for ICE

[Martin Liška]

Right now I see:

./xgcc -B. ~/Programming/testcases/json.i -c -O2 -fmax-errors=1
/home/marxin/Programming/testcases/json.i: In function ‘json_variant_type’:
/home/marxin/Programming/testcases/json.i:22:1: error: non-integral type switch 
statement
   22 | }
  | ^
int *
switch (v_2(D))  [INV], case 0B:  [INV], case 5B:  [INV], case 6B: 
 [INV], case 7B:  [INV], case 8B:  [INV]>
compilation terminated due to -fmax-errors=1.

with the patch I get:

./xgcc -B. ~/Programming/testcases/json.i -c -O2 -fmax-errors=1 -c
/home/marxin/Programming/testcases/json.i: In function ‘json_variant_type’:
/home/marxin/Programming/testcases/json.i:22:1: error: non-integral type switch 
statement
   22 | }
  | ^
int *
switch (v_2(D))  [INV], case 0B:  [INV], case 5B:  [INV], case 6B: 
 [INV], case 7B:  [INV], case 8B:  [INV]>
during GIMPLE pass: iftoswitch
/home/marxin/Programming/testcases/json.i:22:1: internal compiler error: 
verify_gimple failed
0xe4478c verify_gimple_in_cfg(function*, bool)
/home/marxin/Programming/gcc/gcc/tree-cfg.c:5467
0xd201cf execute_function_todo
/home/marxin/Programming/gcc/gcc/passes.c:2042
0xd2101c do_per_function
/home/marxin/Programming/gcc/gcc/passes.c:1687
0xd2101c execute_todo
/home/marxin/Programming/gcc/gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

gcc/ChangeLog:

* diagnostic.c (diagnostic_report_diagnostic): ICE causes to
terminate compiler immediately, so I guess it should be printed
always.
---
 gcc/diagnostic.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/diagnostic.c b/gcc/diagnostic.c
index fe509d88e6d..da20cdb2703 100644
--- a/gcc/diagnostic.c
+++ b/gcc/diagnostic.c
@@ -1172,7 +1172,7 @@ diagnostic_report_diagnostic (diagnostic_context *context,
return false;
 }
 
-  if (diagnostic->kind != DK_NOTE)

+  if (diagnostic->kind != DK_NOTE && diagnostic->kind != DK_ICE)
 diagnostic_check_max_errors (context);
 
   context->lock++;

--
2.29.2

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Jonathan Wakely via Gcc-patches]

On 01/12/20 15:10 +, Jonathan Wakely wrote:

On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:

Jonathan, could you send a fresh set of patches (or at least replacements)?  I
tried installing the patches on a master branch I checked out this morning, and
I got two rejects:


I don't understand why those chunks failed, but I'll rebase and send a
new patch ASAP.


Here's the rebased patch, with regenerated autoconf files and a fix
for the  header. I'd changed it since sending
the previous patch, and broke the "there's more than one long double"
case (i.e. the _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT case).



commit 8739b6c0223fa38592b93e706c6e532fe027e3da
Author: Jonathan Wakely 
Date:   Mon Nov 12 10:47:41 2018

libstdc++: Add C++ runtime support for new 128-bit long double format

This adds support for the new __ieee128 long double format on
powerpc64le targets.

Most of the complexity comes from wanting a single libstdc++.so library
that contains the symbols needed by code compiled with both
-mabi=ibmlongdouble and -mabi=ieeelongdouble (and not forgetting
-mlong-double-64 as well!)

In a few places this just requires an extra overload, for example
std::from_chars has to be overloaded for both forms of long double.
That can be done in a single translation unit that defines overloads
for 'long double' and also '__ieee128', so that user code including
 will be able to link to a definition for either type of long
double. Those are the easy cases.

The difficult parts are (as for the std::string ABI transition) the I/O
and locale facets. In order to be able to write either form of long
double to an ostream such as std::cout we need the locale to contain a
std::num_put facet that can handle both forms. The same approach is
taken as was already done for supporting 64-bit long double and 128-bit
long double: adding extra overloads of do_put to the facet class. On
targets where the new long double code is enabled, the facets that are
registered in the locale at program startup have additional overloads so
that they can work with any long double type. Where this fails to work
is if user code installs its own facet, which will probably not have the
additional overloads and so will only be able to output one or the other
type. In practice the number of users expecting to be able to use their
own locale facets in code using a mix of -mabi=ibmlongdouble and
-mabi=ieeelongdouble is probably close to zero.

libstdc++-v3/ChangeLog:

* Makefile.in: Regenerate.
* config.h.in: Regenerate.
* config/abi/pre/gnu.ver: Make patterns less greedy.
* config/os/gnu-linux/ldbl-ieee128-extra.ver: New file with patterns
for IEEE128 long double symbols.
* configure: Regenerate.
* configure.ac: Enable alternative 128-bit long double format on
powerpc64*-*-linux*.
* doc/Makefile.in: Regenerate.
* fragment.am: Regenerate.
* include/Makefile.am: Set _GLIBCXX_LONG_DOUBLE_ALT128_COMPAT.
* include/Makefile.in: Regenerate.
* include/bits/c++config: Define inline namespace for new long
double symbols. Don't define _GLIBCXX_USE_FLOAT128 when it's the
same type as long double.
* include/bits/locale_classes.h [_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT]
(locale::_Impl::_M_init_extra_ldbl128): Declare new member function.
* include/bits/locale_facets.h (_GLIBCXX_NUM_FACETS): Simplify by
only counting narrow character facets.
(_GLIBCXX_NUM_CXX11_FACETS): Likewise.
(_GLIBCXX_NUM_LBDL_ALT128_FACETS): New.
[_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT] (num_get::__do_get): Define
vtable placeholder for __ibm128 long double type.
[_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__]
(num_get::__do_get): Declare vtable placeholder for __ibm128 long
double type.
[_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__]
(num_put::__do_put): Likewise.
* include/bits/locale_facets.tcc
[_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__]
(num_get::__do_get, num_put::__do_put): Define.
* include/bits/locale_facets_nonio.h
[_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__]
(money_get::__do_get): Declare vtable placeholder for __ibm128 long
double type.
[_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__]
(money_put::__do_put): Likewise.
* include/bits/locale_facets_nonio.tcc
[_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT && __LONG_DOUBLE_IEEE128__]
(money_get::__do_get, money_put::__do_put): Define.
* include/ext

Re: Add pretty-printing support for __is_nothrow_{assignable, constructible}. [PR98054]

[Jason Merrill via Gcc-patches]

On 11/30/20 8:50 AM, Marek Polacek wrote:

On Mon, Nov 30, 2020 at 01:19:32PM +0200, Ville Voutilainen via Gcc-patches 
wrote:

OK for trunk if full testsuite passes? Should we consider having some sort
of test that catches such omissions?


IMHO this doesn't require a test.


2020-11-30  Ville Voutilainen  

 gcc/

>>

 PR c++/98054
 * cp/cxx-pretty-print.c (pp_cxx_trait_expression):
 Add support for __is_nothrow_{assignable,constructible}.


No "cp/" please.


And change the gcc/ above to gcc/cp/.  OK with that change.


diff --git a/gcc/cp/cxx-pretty-print.c b/gcc/cp/cxx-pretty-print.c
index 058b9c2f4fc..1cdf0772a6b 100644
--- a/gcc/cp/cxx-pretty-print.c
+++ b/gcc/cp/cxx-pretty-print.c
@@ -2666,6 +2666,12 @@ pp_cxx_trait_expression (cxx_pretty_printer *pp, tree t)
  case CPTK_IS_CONSTRUCTIBLE:
pp_cxx_ws_string (pp, "__is_constructible");
break;
+case CPTK_IS_NOTHROW_ASSIGNABLE:
+  pp_cxx_ws_string (pp, "__is_nothrow_assignable");
+  break;
+case CPTK_IS_NOTHROW_CONSTRUCTIBLE:
+  pp_cxx_ws_string (pp, "__is_nothrow_constructible");
+  break;
  
  default:

gcc_unreachable ();


Looks fine, thanks.

Marek

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Jonathan Wakely via Gcc-patches]

On 30/11/20 16:30 -0500, Michael Meissner via Libstdc++ wrote:

Jonathan, could you send a fresh set of patches (or at least replacements)?  I
tried installing the patches on a master branch I checked out this morning, and
I got two rejects:


I don't understand why those chunks failed, but I'll rebase and send a
new patch ASAP.

Re: [PATCH] libstdc++: Add C++ runtime support for new 128-bit long double format

[Jonathan Wakely via Gcc-patches]

On 30/11/20 17:29 -0600, Segher Boessenkool wrote:

Hi!

Thank you for all this.

On Wed, Nov 11, 2020 at 09:50:01PM +, Jonathan Wakely wrote:

This adds support for the new __ieee128 long double format on
powerpc64le targets.



* testsuite/27_numerics/complex/abi_tag.cc: Add u9___ieee128 to
regex matching expected symbols.


One less underscore.


Thanks. There was also a misnamed test in the changelog which I've
also fixed.


libstdc++-v3/ChangeLog:

* Makefile.in:
* config.h.in:


(etc.)  Something missing here?


It's just an empty changelog template added by my prepare-commit-msg.
The complete changelog was present above it already. I've removed the
duplication, thanks.

Updated patch coming shortly ...

Re: [PATCH] c++: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093]

[Jakub Jelinek via Gcc-patches]

On Tue, Dec 01, 2020 at 01:03:52PM +, Jonathan Wakely wrote:
> Most of them pass now, but this case fails:
> 
> using namespace std;
> 
> struct S {
>   const char* func;
>   unsigned line = 0;
>   source_location loc = source_location::current();
> 
>   S(int l, source_location loc = source_location::current())
>   : func(__FUNCTION__), line(l), loc(loc) // values of loc will be from 
> call-site
>   {}
> 
>   S(void*)
>   : func(__FUNCTION__), line(__LINE__) // values of loc should be hereabouts
>   {}
> };
> 
> int main()
> {
>   S s0(__LINE__);
>// ...
> }

Ah, I see what is going on here.

using namespace std;

struct S {
  const char *func;
  unsigned line = 0;
  source_location loc = source_location::current ();

  S (int l, source_location);

  S (void *)
  : func(__FUNCTION__), line(__LINE__) // values of loc should be hereabouts
  {}
};

S::S (int l, source_location loc = source_location::current ())
: func(__FUNCTION__), line(l), loc(loc) // values of loc will be from call-site
{}

int
main ()
{
  S s0(__LINE__);
///...
}

would work fine.

We have (since this patch, but before that it was already mostly like that
too):
  && DECL_IMMEDIATE_FUNCTION_P (fndecl)
  && cp_unevaluated_operand == 0
  && (current_function_decl == NULL_TREE
  || !DECL_IMMEDIATE_FUNCTION_P (current_function_decl))
  && (current_binding_level->kind != sk_function_parms
  || (!current_binding_level->immediate_fn_ctx_p
  && !source_location_current_p (fndecl)))
  && (!parsing_nsdmi () || !source_location_current_p (fndecl)))
as the condition whether to evaluate an immediate function right away or
not.
The intent is do not evaluate it in default arguments of immediate functions
(will be done at constant expression evaluation time instead), and (newly)
for std::source_location::current () not evaluated in nsdmis and in default
arguments.

The problem is that with your/JeanHeyd's testcase above, the default
argument parsing is deferred until the whole class is parsed and then
cp_parser_late_parsing_default_args performs that deferred parsing.
Except at this point nothing creates the sk_function_params scope.

So, I think we need some way for the build_over_call code to know if
it is called from within cp_parser_late_parsing_default_args and whether
for an immediate function or not, and take that into account too.

I see cp_parser_late_parsing_default_args calls push_defarg_context,
so perhaps it could check default_arg_context vector, except that
convert_default_arg calls that too around calling break_out_target_exprs
which in the patch is used to perform the late evaluation of the
std::source_location::current() calls.  So it might need to temporarily
pop_defarg_context before break_out_target_exprs and push it again?

Jason, any thoughts on that?

And guess we need some tests if it works as expected also in templates;
I bet we create scope for the default params in that case, but I could be
wrong.

Thanks

Jakub

Re: [PATCH] Add feature test macro for atomic::wait

[Jonathan Wakely via Gcc-patches]

On 30/11/20 10:17 -0800, Thomas Rodgers wrote:

From: Thomas Rodgers 

Adds __cpp_lib_atomic_wait feature test macro which was overlooked in
the initial commit of this feature. Replaces uses of
_GLIBCXX_HAVE_ATOMIC_WAIT.

libstdc++-v3/ChangeLog:

* include/bits/atomic_base.h: Replace usage of
_GLIBCXX_HAVE_ATOMIC_WAIT with __cpp_lib_atomic_wait.
* include/bits/atomic_timed_wait.h: Likewise.
* include/bits/atomic_wait.h: Define __cpp_lib_atomic_wait
feature test macro.
* include/bits/semaphore_base: Replace usage of
_GLIBCXX_HAVE_ATOMIC_WAIT with __cpp_lib_atomic_wait.
* include/std/atomic: Likewise.
* include/std/latch: Likewise.
* include/std/semaphore: Likewise.
* include/std/version: Define __cpp_lib_atomic wait
feature test macro and replace usage of
_GLIBCXX_HAVE_ATOMIC_WAIT.
* testsuite/29_atomics/atomic/wait_notify/1.cc: New test.
* testsuite/29_atomics/atomic/wait_notify/2.cc: Likewise.

---
libstdc++-v3/include/bits/atomic_base.h   | 36 +--
libstdc++-v3/include/bits/atomic_timed_wait.h |  5 +--
libstdc++-v3/include/bits/atomic_wait.h   |  3 +-
libstdc++-v3/include/bits/semaphore_base.h|  4 +--
libstdc++-v3/include/std/atomic   | 16 -
libstdc++-v3/include/std/latch|  4 +--
libstdc++-v3/include/std/semaphore|  4 +--
libstdc++-v3/include/std/version  |  7 ++--
.../29_atomics/atomic/wait_notify/1.cc| 28 +++
.../29_atomics/atomic/wait_notify/2.cc| 29 +++
10 files changed, 98 insertions(+), 38 deletions(-)
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/1.cc
create mode 100644 libstdc++-v3/testsuite/29_atomics/atomic/wait_notify/2.cc

diff --git a/libstdc++-v3/include/bits/atomic_base.h 
b/libstdc++-v3/include/bits/atomic_base.h
index d0d962d3047..ad4e24b4d20 100644
--- a/libstdc++-v3/include/bits/atomic_base.h
+++ b/libstdc++-v3/include/bits/atomic_base.h
@@ -230,7 +230,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  return __v == __GCC_ATOMIC_TEST_AND_SET_TRUEVAL;
}

-#ifdef _GLIBCXX_HAVE_ATOMIC_WAIT
+#ifdef __cpp_lib_atomic_wait


I've not always been consistent about using #if or #ifdef for
__cpp_lib macros, but let's not make that worse in a single patch. I
think we should just use #if for __cpp_lib macros. That affects
several places in the patch.


_GLIBCXX_ALWAYS_INLINE void
wait(bool __old,
memory_order __m = memory_order_seq_cst) const noexcept
@@ -253,7 +253,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{ std::__atomic_notify(&_M_i, true); }

// TODO add const volatile overload
-#endif // HAVE_ATOMIC_WAIT
+#endif // __cpp_lib_atomic_wait
#endif // C++20

_GLIBCXX_ALWAYS_INLINE void
@@ -604,7 +604,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __cmpexch_failure_order(__m));
  }

-#if __cplusplus > 201703L && defined _GLIBCXX_HAVE_ATOMIC_WAIT
+#if __cpp_lib_atomic_wait
  _GLIBCXX_ALWAYS_INLINE void
  wait(__int_type __old,
  memory_order __m = memory_order_seq_cst) const noexcept
@@ -627,7 +627,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  { std::__atomic_notify(&_M_i, true); }

  // TODO add const volatile overload
-#endif // C++20 && HAVE_ATOMIC_WAIT
+#endif // __cpp_lib_atomic_wait

  _GLIBCXX_ALWAYS_INLINE __int_type
  fetch_add(__int_type __i,
@@ -898,7 +898,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   int(__m1), int(__m2));
  }

-#if __cplusplus > 201703L && defined _GLIBCXX_HAVE_ATOMIC_WAIT
+#if __cpp_lib_atomic_wait
  _GLIBCXX_ALWAYS_INLINE void
  wait(__pointer_type __old,
   memory_order __m = memory_order_seq_cst) noexcept
@@ -921,7 +921,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  { std::__atomic_notify(&_M_p, true); }

  // TODO add const volatile overload
-#endif // C++20 && HAVE_ATOMIC_WAIT
+#endif // __cpp_lib_atomic_wait

  _GLIBCXX_ALWAYS_INLINE __pointer_type
  fetch_add(ptrdiff_t __d,
@@ -1011,7 +1011,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 int(__success), int(__failure));
  }

-#if __cplusplus > 201703L && defined _GLIBCXX_HAVE_ATOMIC_WAIT
+#if __cpp_lib_atomic_wait
template
  _GLIBCXX_ALWAYS_INLINE void
  wait(const _Tp* __ptr, _Val<_Tp> __old,
@@ -1036,7 +1036,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
  { std::__atomic_notify(__ptr, true); }

  // TODO add const volatile overload
-#endif // C++20 && HAVE_ATOMIC_WAIT
+#endif // __cpp_lib_atomic_wait

template
  _GLIBCXX_ALWAYS_INLINE _Tp
@@ -1291,7 +1291,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   __cmpexch_failure_order(__order));
  }

-#ifdef _GLIBCXX_HAVE_ATOMIC_WAIT
+#ifdef __cpp_lib_atomic_wait
  _GLIBCXX_ALWAYS_INLINE void
  wait(_Fp __old, memory_order __m = memory_order_seq_cst) const noexcept

[committed] libstdc++: Simplify detection of built-in functions

[Jonathan Wakely via Gcc-patches]

This fixes a regression affecting the Intel compiler. Because that
compiler defines __GNUC__ to match whatever version of GCC it finds on
the host system, it might claim to be a brand new GCC despite not
actually supporting all the built-ins that the latest GCC supports. This
means the config checks for __GNUC__ don't work. Most recently this
broke when r11-3569-g73ae6eb572515ad627b575a7fbdfdd47a4368e1c switched
us from using __is_same_as to __is_same when __GNUC__ >= 11.

Because __has_builtin is supported by all of GCC, Clang, and Intel we can
use that to reliably detect whether a given built-in is supported,
instead of hardcoding anything based on __GNUC__. The big caveat is
that for versions of Clang <= 9.0.0 and for (as far as I can tell) all
released versions of Intel icc, __has_builtin only evaluates to true for
built-ins with a name starting "__builtin_". For __is_aggregate,
__is_same, and __has_unique_object_representations it's necessary to use
__is_identifier to check if it's a valid identifeir token instead.

The solution used in this patch is to define _GLIBCXX_HAS_BUILTIN and
use that instead of using __has_builtin directly. For compilers that
define __is_identifier as well as __has_builtin we use both, so that if
__has_builtin evaluates to false we try again using !__is_identifier.

libstdc++-v3/ChangeLog:

* include/bits/c++config (_GLIBCXX_HAS_BUILTIN): Define macro to
work around different implementations of __has_builtin.
(_GLIBCXX_HAVE_BUILTIN_HAS_UNIQ_OBJ_REP)
(_GLIBCXX_HAVE_BUILTIN_IS_AGGREGATE)
(_GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED)
(_GLIBCXX_HAVE_BUILTIN_IS_SAME, _GLIBCXX_HAVE_BUILTIN_LAUNDER):
Define using _GLIBCXX_HAS_BUILTIN.

Tested powerpc64le-linux. Committed to trunk.

commit 6aa12274007bccbae2691a9d336c37fe167bb535
Author: Jonathan Wakely 
Date:   Tue Dec 1 14:14:18 2020

libstdc++: Simplify detection of built-in functions

This fixes a regression affecting the Intel compiler. Because that
compiler defines __GNUC__ to match whatever version of GCC it finds on
the host system, it might claim to be a brand new GCC despite not
actually supporting all the built-ins that the latest GCC supports. This
means the config checks for __GNUC__ don't work. Most recently this
broke when r11-3569-g73ae6eb572515ad627b575a7fbdfdd47a4368e1c switched
us from using __is_same_as to __is_same when __GNUC__ >= 11.

Because __has_builtin is supported by all of GCC, Clang, and Intel we can
use that to reliably detect whether a given built-in is supported,
instead of hardcoding anything based on __GNUC__. The big caveat is
that for versions of Clang <= 9.0.0 and for (as far as I can tell) all
released versions of Intel icc, __has_builtin only evaluates to true for
built-ins with a name starting "__builtin_". For __is_aggregate,
__is_same, and __has_unique_object_representations it's necessary to use
__is_identifier to check if it's a valid identifeir token instead.

The solution used in this patch is to define _GLIBCXX_HAS_BUILTIN and
use that instead of using __has_builtin directly. For compilers that
define __is_identifier as well as __has_builtin we use both, so that if
__has_builtin evaluates to false we try again using !__is_identifier.

libstdc++-v3/ChangeLog:

* include/bits/c++config (_GLIBCXX_HAS_BUILTIN): Define macro to
work around different implementations of __has_builtin.
(_GLIBCXX_HAVE_BUILTIN_HAS_UNIQ_OBJ_REP)
(_GLIBCXX_HAVE_BUILTIN_IS_AGGREGATE)
(_GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED)
(_GLIBCXX_HAVE_BUILTIN_IS_SAME, _GLIBCXX_HAVE_BUILTIN_LAUNDER):
Define using _GLIBCXX_HAS_BUILTIN.

diff --git a/libstdc++-v3/include/bits/c++config 
b/libstdc++-v3/include/bits/c++config
index 2e6c880ad95..27302ed392e 100644
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -653,35 +653,36 @@ namespace std
 #define _GLIBCXX_USE_FLOAT128
 #endif
 
-#if __GNUC__ >= 7
-// Assume these are available if the compiler claims to be a recent GCC:
+#ifdef __has_builtin
+# ifdef __is_identifier
+// Intel and older Clang require !__is_identifier for some built-ins:
+#  define _GLIBCXX_HAS_BUILTIN(B) __has_builtin(B) || ! __is_identifier(B)
+# else
+#  define _GLIBCXX_HAS_BUILTIN(B) __has_builtin(B)
+# endif
+#endif
+
+#if _GLIBCXX_HAS_BUILTIN(__has_unique_object_representations)
 # define _GLIBCXX_HAVE_BUILTIN_HAS_UNIQ_OBJ_REP 1
+#endif
+
+#if _GLIBCXX_HAS_BUILTIN(__is_aggregate)
 # define _GLIBCXX_HAVE_BUILTIN_IS_AGGREGATE 1
+#endif
+
+#if _GLIBCXX_HAS_BUILTIN(__builtin_is_constant_evaluated)
+#  define _GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED 1
+#endif
+
+#if _GLIBCXX_HAS_BUILTIN(__is_same)
+#  define _GLIBCXX_HAVE_BUILTIN_IS_SAME 1
+#endif
+
+#if _GLIBCXX_HAS_BUILTIN(__builtin_launder)
 # define _GLIBCXX_HAVE_BUILTIN_LA

[PATCH] if-to-switch: Support chain with 2 BBs.

[Martin Liška]

Hello.

The following patch is a small tweak than enables more opportunities.
It fixes bug in PR88702 and I see 54 transformations to happen in SPEC 2006.
Apart from that, I fixed a minor issues which I spotted during bootstrap.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin
>From a27dca2d5ef87b493d1ab50da68d0b24dc9fdd93 Mon Sep 17 00:00:00 2001
From: Martin Liska 
Date: Tue, 1 Dec 2020 12:18:46 +0100
Subject: [PATCH] if-to-switch: Support chain with 2 BBs.

As seen in the test-case, even 2 BBs can handle interesting
cases covered by a jump table or a bit-test.

gcc/ChangeLog:

	PR tree-optimization/88702
	* gimple-if-to-switch.cc (pass_if_to_switch::execute):
	Require at least 2 BBs.
	* gimple-if-to-switch.cc (find_conditions): Require
	equal precision for low and high of a range.

gcc/testsuite/ChangeLog:

	PR tree-optimization/88702
	* gcc.dg/tree-ssa/if-to-switch-9.c: New test.
---
 gcc/gimple-if-to-switch.cc |  6 --
 gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-9.c | 11 +++
 2 files changed, 15 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-9.c

diff --git a/gcc/gimple-if-to-switch.cc b/gcc/gimple-if-to-switch.cc
index d132064fb9b..19ec6318229 100644
--- a/gcc/gimple-if-to-switch.cc
+++ b/gcc/gimple-if-to-switch.cc
@@ -430,7 +430,9 @@ find_conditions (basic_block bb,
   for (unsigned i = 0; i < info.m_ranges.length (); ++i)
 	if (info.m_ranges[i].exp == NULL_TREE
 	|| info.m_ranges[i].low == NULL_TREE
-	|| info.m_ranges[i].high == NULL_TREE)
+	|| info.m_ranges[i].high == NULL_TREE
+	|| (TYPE_PRECISION (TREE_TYPE (info.m_ranges[i].low))
+		!= TYPE_PRECISION (TREE_TYPE (info.m_ranges[i].high
 	  return;
 
   for (unsigned i = 1; i < info.m_ranges.length (); ++i)
@@ -525,7 +527,7 @@ pass_if_to_switch::execute (function *fun)
 	}
 
 	  chain->m_entries.reverse ();
-	  if (chain->m_entries.length () >= 3
+	  if (chain->m_entries.length () >= 2
 	  && chain->check_non_overlapping_cases ()
 	  && chain->is_beneficial ())
 	{
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-9.c b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-9.c
new file mode 100644
index 000..d0e9df75f55
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/if-to-switch-9.c
@@ -0,0 +1,11 @@
+/* PR tree-optimization/88702 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-iftoswitch-optimized" } */
+
+int IsHTMLWhitespace(int aChar) { 
+  return aChar == 0x0009 || aChar == 0x000A ||  
+ aChar == 0x000C || aChar == 0x000D ||  
+ aChar == 0x0020; 
+}
+
+/* { dg-final { scan-tree-dump "Condition chain with 2 BBs transformed into a switch statement." "iftoswitch" } } */
-- 
2.29.2

[PATCH] arm: Improve documentation for effective target 'arm_softfloat'

[Andrea Corallo via Gcc-patches]

Hi all,

I'd like to submit the following patch to better specify the meaning
of the 'arm_softfloat' effective target.

As I've recently discovered we can have cases where '-mfloat-abi=hard'
is used and the compiler correctly defines '__SOFTFP__'.

Effectively 'arm_softfloat' is checking if the target requires floating
point emulation but not what ABI is used, so I think would be nice to
specify that in the documentation.

Okay for trunk?

Thanks

  Andrea
  
>From 67e74689e4332d33c3f27119dc21a7722bb6125b Mon Sep 17 00:00:00 2001
From: Andrea Corallo 
Date: Tue, 1 Dec 2020 11:21:33 +0100
Subject: [PATCH] arm: Improve documentation for effective target
 'arm_softfloat'

gcc/ChangeLog

2020-12-01  Andrea Corallo  

* doc/sourcebuild.texi (arm_softfloat): Improve documentation.

gcc/testsuite/ChangeLog

2020-12-01  Andrea Corallo  

* lib/target-supports.exp (check_effective_target_arm_softfloat):
Improve documentation.
---
 gcc/doc/sourcebuild.texi  | 3 +--
 gcc/testsuite/lib/target-supports.exp | 4 ++--
 2 files changed, 3 insertions(+), 4 deletions(-)

diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 852eaa2e676..72b83748318 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1799,8 +1799,7 @@ variant of the ABI for the ARM Architecture (as selected 
with
 @code{-mfloat-abi=hard}).
 
 @item arm_softfloat
-ARM target uses the soft-float ABI with no floating-point instructions
-used whatsoever (as selected with @code{-mfloat-abi=soft}).
+ARM target uses emulated floating point operations.
 
 @item arm_hard_vfp_ok
 ARM target supports @code{-mfpu=vfp -mfloat-abi=hard}.
diff --git a/gcc/testsuite/lib/target-supports.exp 
b/gcc/testsuite/lib/target-supports.exp
index ff6bc5f4b92..24ff9fa0476 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -5658,8 +5658,8 @@ proc check_effective_target_arm_hf_eabi { } {
 }]
 }
 
-# Return 1 if this is an ARM target that uses the soft float ABI
-# with no floating-point instructions at all (e.g. -mfloat-abi=soft).
+# Return 1 if this is an ARM target uses emulated floating point
+# operations.
 
 proc check_effective_target_arm_softfloat { } {
 return [check_no_compiler_messages arm_softfloat object {
-- 
2.20.1

Re: [committed] Fix hppa64-hpux11 build to remove source paths from embedded path.

[John David Anglin]

On 2020-12-01 4:29 a.m., Iain Sandoe wrote:
> It seems that you didn’t apply (or generate?) the gcc/configure change from 
> the libtool one.
>
> Happy to do that before applying mine - but thought you might want to check 
> first,
> thanks
Yes please.  It should have been regenerated.

Thanks,
Dave

-- 
John David Anglin  dave.ang...@bell.net

Re: [PATCH] c++: Implement LWG3396 Clarify point of reference for source_location::current() [PR80780, PR93093]

[Jonathan Wakely via Gcc-patches]

On 01/12/20 09:59 +0100, Jakub Jelinek wrote:

Hi!

While std::source_location::current () is static consteval source_location
current() noexcept; in the standard, it also says with LWG3396:
"Any call to current that appears as a default member initializer
([class.mem]), or as a subexpression thereof, should correspond to the
location of the constructor definition or aggregate initialization that uses
the default member initializer.  Any call to current that appears as a
default argument ([dcl.fct.default]), or as a subexpression thereof, should
correspond to the location of the invocation of the function that uses the
default argument ([expr.call])."
so it must work as compiler magic rather than normal immediate functions,
in particular we need to defer its evaluation when parsing default arguments
or nsdmis.

The following patch implements that.


Nice.


Bootstrapped/regtested on x86_64-linux and i686-linux.

Jon, does it fix all the library testcases you and JeanHeyd had?


Most of them pass now, but this case fails:

using namespace std;

struct S {
  const char* func;
  unsigned line = 0;
  source_location loc = source_location::current();

  S(int l, source_location loc = source_location::current())
  : func(__FUNCTION__), line(l), loc(loc) // values of loc will be from 
call-site
  {}

  S(void*)
  : func(__FUNCTION__), line(__LINE__) // values of loc should be hereabouts
  {}
};

int main()
{
  S s0(__LINE__);
  assert( s0.loc.line() == s0.line );
  assert( !__builtin_strcmp(s0.loc.file_name(), __FILE__) );
  assert( !__builtin_strcmp(s0.loc.function_name(), __FUNCTION__) );
}

The location is the constructor parameter list, but it should be in
main() where the default argument is evaluated.

JeanHeyd's test also verify that the function_name() for the NSDMI
cases is "s::s" but that fails because __FUNCTION__ is only "s".

I mentioned in PR 80780 that a __builtin__PRETTY_FUNCTION would have
been nice, because __FUNCTION__ isn't very useful for C++, because of
overloading and namespace/class scopes. There are an unlimited number
of functions that have __FUNCTION__ == "s", e.g. "ns::s(int)" and
"ns::s()" and "another_scope::s::s(T...)" etc.

Since __builtin_source_location() can do whatever it wants (without
needing to add __builtin__PRETTY_FUNCTION) it might be nice to use the
__PRETTY_FUNCTION__ string. JeanHeyd's tests would still need changes,
because the name would be "s::s(void*)" not "s::s" but that still
seems better for users.

Re: [PATCH] dwarf: Add -gdwarf{32,64} options

[Jakub Jelinek via Gcc-patches]

On Tue, Dec 01, 2020 at 01:03:07PM +0100, Richard Biener wrote:
> > So yes, we can either do a sorry, error, or could just avoid 64-bit
> > relocations (depending on endianity instead of emitting
> > .quad expression_that_needs_relocation
> > emit
> > .long expression_that_needs_relocation, 0
> > or
> > .long 0, expression_that_needs_relocation
> > So, which way do we want to go?
> 
> 64bit relocs are not required here?  That is, can one with
> dwarf64 choose 32bit forms for select offsets (like could
> dwz exploit this?)?

I guess it depends on whether for 32-bit target and -gdwarf64, when
calling dw2_assemble_integer with non-CONST_INT argument we only
need positive values or might need negative ones too.
Because positive ones can be easily emulated through that
.long expression, 0
or
.long 0, expression
depending on endianity, but I'm afraid there is no way to emit
0 or -1 depending on the sign of expression, when it needs relocations.
Looking through dw2_asm_output_delta calls, at least the vast majority
of the calls seem to guarantee being positive, not 100% sure about
one case in .debug_line views, but I'd hope it is ok too.
In most cases, the deltas are between two labels where the first one
in the arguments is later in the same section than the other one,
or where the second argument is the start of a section or another section
base.

This patch implements that, dunno if we need also configure tests for that
or not, maybe some 32-bit targets use 64-bit ELF and can handle such
relocations.

2020-12-01  Jakub Jelinek  

* dwarf2asm.c (dw2_assemble_integer): Handle size twice as large
as DWARF2_ADDR_SIZE if x is not a scalar int by emitting it as
two halves, one with x and the other with const0_rtx, ordered
depending on endianity.

--- gcc/dwarf2asm.c.jj  2020-01-12 11:54:36.558411221 +0100
+++ gcc/dwarf2asm.c 2020-12-01 13:42:38.347298352 +0100
@@ -46,6 +46,52 @@ along with GCC; see the file COPYING3.
 void
 dw2_assemble_integer (int size, rtx x)
 {
+  if (size == 2 * DWARF2_ADDR_SIZE && !CONST_SCALAR_INT_P (x))
+{
+  /* On 32-bit targets with -gdwarf64, DImode values with
+relocations usually result in assembler errors.  Assume
+all such values are positive and emit the relocation only
+in the least significant half.  */
+  const char *op = integer_asm_op (DWARF2_ADDR_SIZE, FALSE);
+  if (BYTES_BIG_ENDIAN)
+   {
+ if (op)
+   {
+ fputs (op, asm_out_file);
+ fprint_whex (asm_out_file, 0);
+ fputs (", ", asm_out_file);
+ output_addr_const (asm_out_file, x);
+   }
+ else
+   {
+ assemble_integer (const0_rtx, DWARF2_ADDR_SIZE,
+   BITS_PER_UNIT, 1);
+ putc ('\n', asm_out_file);
+ assemble_integer (x, DWARF2_ADDR_SIZE,
+   BITS_PER_UNIT, 1);
+   }
+   }
+  else
+   {
+ if (op)
+   {
+ fputs (op, asm_out_file);
+ output_addr_const (asm_out_file, x);
+ fputs (", ", asm_out_file);
+ fprint_whex (asm_out_file, 0);
+   }
+ else
+   {
+ assemble_integer (x, DWARF2_ADDR_SIZE,
+   BITS_PER_UNIT, 1);
+ putc ('\n', asm_out_file);
+ assemble_integer (const0_rtx, DWARF2_ADDR_SIZE,
+   BITS_PER_UNIT, 1);
+   }
+   }
+  return;
+}
+
   const char *op = integer_asm_op (size, FALSE);
 
   if (op)


Jakub

Re: [PATCH] dwarf: Add -gdwarf{32,64} options

[Richard Biener]

On Tue, 1 Dec 2020, Jakub Jelinek wrote:

> On Tue, Dec 01, 2020 at 11:49:43AM +0100, Richard Biener wrote:
> > On Tue, 1 Dec 2020, Jakub Jelinek wrote:
> > 
> > > Hi!
> > > 
> > > The following patch makes the choice between 32-bit and 64-bit DWARF 
> > > formats
> > > selectable by command line switch, rather than being hardcoded through
> > > DWARF_OFFSET_SIZE macro.
> > > 
> > > The options themselves don't turn on debug info themselves, so one needs
> > > to use -g -gdwarf64 or similar.
> > > 
> > > Ok for trunk if it passes bootstrap/regtest?
> > 
> > OK.  Note there's
> > 
> > /* Various DIE's use offsets relative to the beginning of the
> >.debug_info section to refer to each other.  */
> > 
> > typedef long int dw_offset;
> > 
> > which on L32 hosts means we might not support dwarf64 generation
> > for CUs that do not fit in 31bits?  Should we change that to
> > int64_t?  Or should we sorry() for -gdwarf64 on 32bit hosts?
> > 
> > There's also
> > 
> >   unsigned long die_abbrev;
> > 
> > and other uses of '[unsigned] long' in dwarf2out.c.
> 
> One thing is 32-bit hosts vs. 64-bit targets, and we maybe should indeed use
> HOST_WIDE_INT for dw_offset; not sure about die_abbrev, if the .debug_abbrev
> section is over 4GiB in one TU, then that would be already massive amounts of 
> debug
> info (.debug_info is typically 10-100x times larger than .debug_abbrev).
> Even the HOST_WIDE_INT dw_offset might not be immediately necessary, if a
> 32-bit host needs to emit 4GiB of .debug_info for one TU, then I'm pretty
> sure we need at least 4 times that much of compile memory if not much more,
> our in memory DIE representation isn't exactly compact.
> The advantage of DWARF 64-bit is not (at least for the time being) a single
> TU exceeding the limits, but when linking a shared library with tons of TUs
> where we exceed those limits then (for some large libraries we are already
> close to those limits or over them now).
> 
> Another thing is 32-bit targets.  For them the limitations of the object
> file format (e.g. 32-bit ELF) will not allow > 2GiB debug info anyway,
> and as I've just tested, e.g. on x86_64 with -m32 -gdwarf64 will not work
> even on tiny testcases:
> as: pr64716.o: unsupported relocation type: 0x1
> pr64716.s: Assembler messages:
> pr64716.s:6013: Error: cannot represent relocation type BFD_RELOC_64
> as: pr64716.o: unsupported relocation type: 0x1
> pr64716.s:6015: Error: cannot represent relocation type BFD_RELOC_64
> as: pr64716.o: unsupported relocation type: 0x1
> pr64716.s:6017: Error: cannot represent relocation type BFD_RELOC_64
> So yes, we can either do a sorry, error, or could just avoid 64-bit
> relocations (depending on endianity instead of emitting
> .quad expression_that_needs_relocation
> emit
> .long expression_that_needs_relocation, 0
> or
> .long 0, expression_that_needs_relocation
> So, which way do we want to go?

64bit relocs are not required here?  That is, can one with
dwarf64 choose 32bit forms for select offsets (like could
dwz exploit this?)?

If so the above might be OK, otherwise I guess a sorry()
would be more to the point.

> > Do dwarf32 and dwarf64 objects inter-operate just fine (as long as
> > the linker can resolve all relocations w/o truncating)?
> 
> I think it should, but whether all debug info consumers and other tools
> will be able to cope with it remains to be seen.  If they have bugs, those
> should be fixed.  By adding the -gdwarf{32,64} switches we allow them to try
> that.
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)