[Bug c++/91505] [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91505

--- Comment #4 from Andrew Pinski  ---
>This should fix it:

Except it is wrong.
builtin_decl_explicit should be only used with BUILT_IN_NORMAL class.

[Bug target/91481] POWER9 "DARN" RNG intrinsic produces repeated output

[noloader at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91481

--- Comment #3 from Jeffrey Walton  ---
Lloyd's finding can be confirmed on GCC135. For example,

gcc135:~$ /opt/at12.0/bin/gcc -O3 -mcpu=power9 -m64 darn.c -o darn
gcc135:~$ ./darn
9FBE0B8B6E861BD6
9FBE0B8B6E861BD6
9FBE0B8B6E861BD6
9FBE0B8B6E861BD6
...

I can't find a header with a declaration, though:

gcc135:~$ grep -IR builtin_darn /opt/at12.0/ 2>/dev/null
gcc135:~$ grep -IR builtin_darn /lib 2>/dev/null
gcc135:~$

Does someone know where the header is located?

[PATCH] Add MD Function type check for builtin_md vectorize

[Xiong Hu Luo]

The DECL_MD_FUNCTION_CODE added in r274404(PR 91421) by rsandifo requires that
DECL to be a BUILTIN_IN_MD class built-in, asserts will happen when lto
as the patch r274411(PR 91287) outputs some math function symbol to the object,
this patch will check function type before do builtin_md vectorize.

gcc/ChangeLog

2019-08-21  Xiong Hu Luo  

* tree-vect-stmts.c (vectorizable_call): Check callee built-in type.
* gcc/tree.h (DECL_MD_FUNCTION_P): New function.
---
 gcc/tree-vect-stmts.c |  2 +-
 gcc/tree.h| 12 
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 1e2dfe5d22d..ef947f20d63 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -3376,7 +3376,7 @@ vectorizable_call (stmt_vec_info stmt_info, 
gimple_stmt_iterator *gsi,
   if (cfn != CFN_LAST)
fndecl = targetm.vectorize.builtin_vectorized_function
  (cfn, vectype_out, vectype_in);
-  else if (callee)
+  else if (callee && DECL_MD_FUNCTION_P (callee))
fndecl = targetm.vectorize.builtin_md_vectorized_function
  (callee, vectype_out, vectype_in);
 }
diff --git a/gcc/tree.h b/gcc/tree.h
index b910c5cb475..8cce89e5cf3 100644
--- a/gcc/tree.h
+++ b/gcc/tree.h
@@ -3905,6 +3905,18 @@ DECL_MD_FUNCTION_CODE (const_tree decl)
   return fndecl.function_code;
 }
 
+/* Return true if decl is a FUNCTION_DECL with built-in class BUILT_IN_MD.
+   Otherwise return false.  */
+inline bool
+DECL_MD_FUNCTION_P (const_tree decl)
+{
+  const tree_function_decl  = FUNCTION_DECL_CHECK (decl)->function_decl;
+  if (fndecl.built_in_class == BUILT_IN_MD)
+return true;
+  else
+return false;
+}
+
 /* Return the frontend-specific built-in function that DECL represents,
given that it is known to be a FUNCTION_DECL with built-in class
BUILT_IN_FRONTEND.  */
-- 
2.22.0.428.g6d5b264208

[Bug middle-end/90676] default GIMPLE dumps lack information

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90676

--- Comment #11 from Martin Sebor  ---
Author: msebor
Date: Wed Aug 21 02:18:41 2019
New Revision: 274764

URL: https://gcc.gnu.org/viewcvs?rev=274764=gcc=rev
Log:
PR testsuite/91458

gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/ssa-dse-1.C: Use the same search pattern
unconditionally (correcting r272199, PR middle-end/90676).
* gcc.dg/tree-prof/stringop-2.c: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/ssa-dse-1.C
trunk/gcc/testsuite/gcc.dg/tree-prof/stringop-2.c

[Bug testsuite/91458] FAIL: g++.dg/tree-ssa/pr19807.C -std=gnu++98 scan-tree-dump-times optimized "\\\\[\\\\(void .\\\\) \\\\+ 8B\\\\]" 3

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91458

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Wed Aug 21 02:18:41 2019
New Revision: 274764

URL: https://gcc.gnu.org/viewcvs?rev=274764=gcc=rev
Log:
PR testsuite/91458

gcc/testsuite/ChangeLog:
* g++.dg/tree-ssa/ssa-dse-1.C: Use the same search pattern
unconditionally (correcting r272199, PR middle-end/90676).
* gcc.dg/tree-prof/stringop-2.c: Same.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/tree-ssa/ssa-dse-1.C
trunk/gcc/testsuite/gcc.dg/tree-prof/stringop-2.c

Re: [PATCH] fold more string comparison with known result (PR 90879)

[Martin Sebor]

Jeff,

Please let me know if you agree/disagree and what I need to
do to advance this work:

  https://gcc.gnu.org/ml/gcc-patches/2019-08/msg00643.html

Thanks
Martin

On 8/14/19 1:59 PM, Martin Sebor wrote:

On 8/13/19 4:46 PM, Jeff Law wrote:

On 8/13/19 3:43 PM, Martin Sebor wrote:

On 8/13/19 2:07 PM, Jeff Law wrote:

On 8/9/19 10:51 AM, Martin Sebor wrote:


PR tree-optimization/90879 - fold zero-equality of strcmp between a
longer string and a smaller array

gcc/c-family/ChangeLog:

 PR tree-optimization/90879
 * c.opt (-Wstring-compare): New option.

gcc/testsuite/ChangeLog:

 PR tree-optimization/90879
 * gcc.dg/Wstring-compare-2.c: New test.
 * gcc.dg/Wstring-compare.c: New test.
 * gcc.dg/strcmpopt_3.c: Scan the optmized dump instead of strlen.
 * gcc.dg/strcmpopt_6.c: New test.
 * gcc.dg/strlenopt-65.c: Remove uinnecessary declarations, add
 test cases.
 * gcc.dg/strlenopt-66.c: Run it.
 * gcc.dg/strlenopt-68.c: New test.

gcc/ChangeLog:

 PR tree-optimization/90879
 * builtins.c (check_access): Avoid using maxbound when null.
 * calls.c (maybe_warn_nonstring_arg): Adjust to get_range_strlen
change.
 * doc/invoke.texi (-Wstring-compare): Document new warning 
option.

 * gimple-fold.c (get_range_strlen_tree): Make setting maxbound
 conditional.
 (get_range_strlen): Overwrite initial maxbound when non-null.
 * gimple-ssa-sprintf.c (get_string_length): Adjust to
get_range_strlen
 change.
 * tree-ssa-strlen.c (maybe_diag_stxncpy_trunc): Same.
 (used_only_for_zero_equality): New function.
 (handle_builtin_memcmp): Call it.
 (determine_min_objsize): Return an integer instead of tree.
 (get_len_or_size, strxcmp_eqz_result): New functions.
 (maybe_warn_pointless_strcmp): New function.
 (handle_builtin_string_cmp): Call it.  Fold zero-equality of 
strcmp

 between a longer string and a smaller array.




diff --git a/gcc/tree-ssa-strlen.c b/gcc/tree-ssa-strlen.c
index 4af47855e7c..31e012b741b 100644
--- a/gcc/tree-ssa-strlen.c
+++ b/gcc/tree-ssa-strlen.c



@@ -3079,196 +3042,388 @@ determine_min_objsize (tree dest)
       type = TYPE_MAIN_VARIANT (type);
   -  /* We cannot determine the size of the array if it's a flexible
array,
- which is declared at the end of a structure.  */
-  if (TREE_CODE (type) == ARRAY_TYPE
-  && !array_at_struct_end_p (dest))
+  /* The size of a flexible array cannot be determined.  Otherwise,
+ for arrays with more than one element, return the size of its
+ type.  GCC itself misuses arrays of both zero and one elements
+ as flexible array members so they are excluded as well.  */
+  if (TREE_CODE (type) != ARRAY_TYPE
+  || !array_at_struct_end_p (dest))
   {
-  tree size_t = TYPE_SIZE_UNIT (type);
-  if (size_t && TREE_CODE (size_t) == INTEGER_CST
-  && !integer_zerop (size_t))
-    return size_t;
+  tree type_size = TYPE_SIZE_UNIT (type);
+  if (type_size && TREE_CODE (type_size) == INTEGER_CST
+  && !integer_onep (type_size)
+  && !integer_zerop (type_size))
+    return tree_to_uhwi (type_size);

So I nearly commented on this when looking at the original patch.  Can
we really depend on the size when we've got an array at the end of a
struct with a declared size other than 0/1?   While 0/1 are by far the
most common way to declare them, couldn't someone have used other 
sizes?

   I think we pondered doing that at one time to cut down on the noise
from Coverity for RTL and TREE operand accessors.

Your code makes us safer, so I'm not saying you've done anything wrong,
just trying to decide if we need to tighten this up even further.


This patch issues a warning in these cases, i.e., when it sees
a call like, say, strcmp("foobar", A) with an A that's smaller
than the string, because it seems they are likely (rare) bugs.
I haven't seen the warning in any of the projects I tested it
with (Binutils/GDB, GCC, Glibc, the Linux kernel, and LLVM).

The warning uses strcmp to detect these mistakes (or misuses)
but I'd like to add similar warnings for other string functions
as well and have code out there that does this on purpose use
true flexible array members (or the zero-length extension)
instead.  That makes the intent clear.

It's a judgment call whether to also fold (or do something else
like insert a trap) in addition to issuing a warning.  In this
case (reading) I don't think it matters as much as it does for
writes.  Either way, it would be nice to set a policy and
document it in the manual so users know what to expect and
so we don't have to revisit this question for each patch that
touches on this subject.

The GCC manual documents zero length arrays at the end of an aggregate
as a GNU extension for variable length objects.  The manual also
documents that it could be done with single element arrays, but that
doing so does contribute to the base size of the aggregate, but
otherwise it's handled 

C++ PATCH for c++/79817 - attribute deprecated on namespace

[Marek Polacek]

This PR complains that we are not handling the attribute deprecated on
namespaces.  This has gotten more important now because of ranges-v3 which
renamed its "view" namespace to "views", following the PascalCase to snake_case
change, and "view" is now deprecated.

Unfortunately we can't just call cp_warn_deprecated_use_scopes in
cp_parser_nested_name_specifier_opt and call it a day because we shouldn't warn
for code like

  namespace [[deprecated]] N {
void fn();
  }
  void N::fn(); // here
  void N::fn() { } // and here

and in cp_parser_nested_name_specifier_opt we simply don't know if we're
dealing with a function decl.  Calling cp_warn_deprecated_use_scopes from
cp_parser_type_specifier resulted int duplicated diagnostics so that one
is out too.  So I did the following which doesn't seem too bad.

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

2019-08-20  Marek Polacek  

PR c++/79817 - attribute deprecated on namespace.
* cp-tree.h (cp_warn_deprecated_use_scopes): Declare.
* decl.c (grokdeclarator): Call cp_warn_deprecated_use_scopes.
(type_is_deprecated): Likewise.
* decl2.c (cp_warn_deprecated_use_scopes): New function.
* name-lookup.c (handle_namespace_attrs): Handle attribute deprecated.
* parser.c (cp_parser_namespace_alias_definition): Call
cp_warn_deprecated_use_scopes.
(cp_parser_using_declaration): Likewise.
(cp_parser_using_directive): Likewise.
* semantics.c (finish_id_expression_1): Likewise.

* g++.dg/cpp0x/attributes-namespace1.C: New test.
* g++.dg/cpp0x/attributes-namespace2.C: New test.
* g++.dg/cpp0x/attributes-namespace3.C: New test.
* g++.dg/cpp0x/attributes-namespace4.C: New test.
* g++.dg/cpp0x/attributes-namespace5.C: New test.
* g++.dg/cpp1z/namespace-attribs.C: Adjust.
* g++.dg/cpp1z/namespace-attribs2.C: Adjust.

diff --git gcc/cp/cp-tree.h gcc/cp/cp-tree.h
index 05f91861b42..42f180d1dd3 100644
--- gcc/cp/cp-tree.h
+++ gcc/cp/cp-tree.h
@@ -6264,6 +6264,7 @@ extern bool is_list_ctor  (tree);
 extern void validate_conversion_obstack(void);
 extern void mark_versions_used (tree);
 extern bool cp_warn_deprecated_use (tree, tsubst_flags_t = 
tf_warning_or_error);
+extern void cp_warn_deprecated_use_scopes  (tree);
 extern tree get_function_version_dispatcher(tree);
 
 /* in class.c */
diff --git gcc/cp/decl.c gcc/cp/decl.c
index 08b7baa40e0..46ad0271f7b 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -10791,6 +10791,7 @@ grokdeclarator (const cp_declarator *declarator,
   cp_warn_deprecated_use (type);
   if (type && TREE_CODE (type) == TYPE_DECL)
 {
+  cp_warn_deprecated_use_scopes (DECL_CONTEXT (type));
   typedef_decl = type;
   type = TREE_TYPE (typedef_decl);
   if (DECL_ARTIFICIAL (typedef_decl))
@@ -13230,7 +13231,10 @@ type_is_deprecated (tree type)
   if (TREE_DEPRECATED (TYPE_NAME (type)))
return type;
   else
-   return NULL_TREE;
+   {
+ cp_warn_deprecated_use_scopes (DECL_CONTEXT (TYPE_NAME (type)));
+ return NULL_TREE;
+   }
 }
 
   /* Do warn about using typedefs to a deprecated class.  */
diff --git gcc/cp/decl2.c gcc/cp/decl2.c
index a32108f9d16..d6f407d7aef 100644
--- gcc/cp/decl2.c
+++ gcc/cp/decl2.c
@@ -5407,6 +5407,23 @@ cp_warn_deprecated_use (tree decl, tsubst_flags_t 
complain)
   return warned;
 }
 
+/* Like above, but takes into account outer scopes.  */
+
+void
+cp_warn_deprecated_use_scopes (tree ns)
+{
+  while (ns
+&& ns != error_mark_node
+&& ns != global_namespace)
+{
+  cp_warn_deprecated_use (ns);
+  if (TYPE_P (ns))
+   ns = CP_TYPE_CONTEXT (ns);
+  else
+   ns = CP_DECL_CONTEXT (ns);
+}
+}
+
 /* Mark DECL (either a _DECL or a BASELINK) as "used" in the program.
If DECL is a specialization or implicitly declared class member,
generate the actual definition.  Return false if something goes
diff --git gcc/cp/name-lookup.c gcc/cp/name-lookup.c
index 5f5ff81f405..a8ab4db4d0d 100644
--- gcc/cp/name-lookup.c
+++ gcc/cp/name-lookup.c
@@ -4905,6 +4905,24 @@ handle_namespace_attrs (tree ns, tree attributes)
DECL_ATTRIBUTES (ns) = tree_cons (name, args,
  DECL_ATTRIBUTES (ns));
}
+  else if (is_attribute_p ("deprecated", name))
+   {
+ if (!DECL_NAME (ns))
+   {
+ warning (OPT_Wattributes, "ignoring %qD attribute on anonymous "
+  "namespace", name);
+ continue;
+   }
+ if (args && TREE_CODE (TREE_VALUE (args)) != STRING_CST)
+   {
+ error ("deprecated message is not a string");
+ continue;
+   }
+ TREE_DEPRECATED (ns) = 1;
+ if (args)
+   DECL_ATTRIBUTES (ns) = tree_cons (name, args,
+   

[Bug c++/91505] [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91505

--- Comment #3 from Marek Polacek  ---
This should fix it:
diff --git a/gcc/attribs.c b/gcc/attribs.c
index b89be5834de..90055a612b9 100644
--- a/gcc/attribs.c
+++ b/gcc/attribs.c
@@ -1525,7 +1525,15 @@ duplicate_one_attribute (tree *attrs, tree attr, const
char *name)
 void
 copy_attributes_to_builtin (tree decl)
 {
-  tree b = builtin_decl_explicit (DECL_FUNCTION_CODE (decl));
+  int fcode;
+  if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_NORMAL)
+fcode = DECL_FUNCTION_CODE (decl);
+  else if (DECL_BUILT_IN_CLASS (decl) == BUILT_IN_MD)
+fcode = DECL_MD_FUNCTION_CODE (decl);
+  else
+fcode = DECL_FE_FUNCTION_CODE (decl);
+
+  tree b = builtin_decl_explicit (static_cast(fcode));
   if (b)
 duplicate_one_attribute (_ATTRIBUTES (b),
 DECL_ATTRIBUTES (decl), "omp declare simd");

Patch RFA: [C family frontend]: avoid weird constant values in libgo/sysinfo.go

[Ian Lance Taylor]

On Mon, Aug 12, 2019 at 8:21 PM Xiangdong JI  wrote:
>
> The .go files generated during building gccgo seem to have a few constants 
> with weird values, for example:
>
> // sysinfo.go (on x86-64, latest gcc-9 trunk)
>
> const ___FLT128_MAX__ = 1.1
> const ___FLT32X_DENORM_MIN__ = 1.1
>
> as a comparison, gollvm generates expected values.
> Could it be caused by incorrect building setting?

Per later discussion, this problem is fixed by this patch.
Bootstrapped and ran full testsuite on x86_64-pc-linux-gnu.

OK for mainline?

Ian


2019-08-20  Ian Lance Taylor  

* c-cppbuiltin.c (builtin_define_with_hex_fp_value): Always expand
when using -fgo-dump-spec.
Index: c-family/c-cppbuiltin.c
===
--- c-family/c-cppbuiltin.c (revision 274749)
+++ c-family/c-cppbuiltin.c (working copy)
@@ -1643,6 +1643,7 @@ builtin_define_with_hex_fp_value (const
   /* This is very expensive, so if possible expand them lazily.  */
   if (lazy_hex_fp_value_count < LAZY_HEX_FP_VALUES_CNT
   && flag_dump_macros == 0
+  && flag_dump_go_spec == NULL
   && !cpp_get_options (parse_in)->traditional)
 {
   if (lazy_hex_fp_value_count == 0)

Go patch committed: Implement shifts by signed amounts

[Ian Lance Taylor]

This Go patch implements shift by signed types.  This is a new
language feature in Go 1.13
(https://tip.golang.org/doc/go1.13#language).  Bootstrapped and ran Go
testsuite on x86_64-pc-linux-gnu.  Committed to mainline.

Unfortunately this is another case where GMail spam detection
incomprehensibly rejects the actual patch.  So if you want to see it,
please see https://gcc.gnu.org/viewcvs/gcc?view=revision=274755
.

Ian

2019-08-20  Ian Lance Taylor  

* go.test/test/fixedbugs/bug073.go: Update for language changes.

Re: Implement C++20 p1424 - 'constexpr' feature macro concerns.

[Jonathan Wakely]

On 16/08/19 22:39 -0400, Ed Smith-Rowland via libstdc++ wrote:
The latest draft and I guess the above paper changed the macro names 
for the C++20 constexpr lib featues.


__cpp_lib_constexpr_algorithms ->__cpp_lib_constexpr.


The __cpp_lib_constexpr macro is (now?) for a different feature.

The proposed resolution for https://cplusplus.github.io/LWG/issue3256
is to keep the __cpp_lib_constexpr_algorithms name to indicate support
for what is currently described by __cpp_lib_constexpr_swap_algorithms
(and see https://cplusplus.github.io/LWG/issue3257 for another issue
in this area).

[Bug c++/91476] [9/10 Regression] const reference variables sharing the same name in two anonymous namespaces cause a multiple definition error

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91476

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||jason at gcc dot gnu.org

--- Comment #2 from Jonathan Wakely  ---
Started to fail with r268252:

PR c++/89001 - mangling of reference temporaries

It used to be the case that the mangled name of a reference temporary
didn't
need to be standardized, because all access would be through the reference.
But now constant expressions can look through references and so different
translation units need to agree on the address of a temporary in the
initializer of a reference with vague linkage.

* cp-tree.h (struct saved_scope): Add ref_temp_count.
(current_ref_temp_count): New macro.
* mangle.c (mangle_ref_init_variable): Use it.
* typeck2.c (store_init_value): Clear it.
* call.c (make_temporary_var_for_ref_to_temp): Copy public and
comdat.

[Bug c++/91505] [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91505

--- Comment #2 from Marek Polacek  ---
Started with r274404.

[Bug libstdc++/91495] std::transform_reduce with unary op is implemented in the parallel case but not the basic case

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91495

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jonathan Wakely  ---
Fixed for 9.3

Re: [PATCH V2 2/8] bpf: new GCC port

[Jeff Law]

On 8/20/19 3:14 PM, Jose E. Marchesi wrote:
> 
> Hi Jeff.
> 
> > This patch adds a port for the Linux kernel eBPF architecture to GCC.
> > 
> > ChangeLog:
> > 
> >   * configure.ac: Support for bpf-*-* targets.
> >   * configure: Regenerate.
> > 
> > contrib/ChangeLog:
> > 
> >   * config-list.mk (LIST): Disable go in bpf-*-* targets.
> > 
> > gcc/ChangeLog:
> > 
> >   * config.gcc: Support for bpf-*-* targets.
> >   * common/config/bpf/bpf-common.c: New file.
> >   * config/bpf/t-bpf: Likewise.
> >   * config/bpf/predicates.md: Likewise.
> >   * config/bpf/constraints.md: Likewise.
> >   * config/bpf/bpf.opt: Likewise.
> >   * config/bpf/bpf.md: Likewise.
> >   * config/bpf/bpf.h: Likewise.
> >   * config/bpf/bpf.c: Likewise.
> >   * config/bpf/bpf-protos.h: Likewise.
> >   * config/bpf/bpf-opts.h: Likewise.
> >   * config/bpf/bpf-helpers.h: Likewise.
> >   * config/bpf/bpf-helpers.def: Likewise.
> So I think various folks have already mentioned the configure rebuild
> issues, formatting and other stuff.  I'm going to try to keep them all
> in mind so that I don't duplicate anything.  If I do duplicate someone's
> comment, apologies in advance.
> 
> At a high level I realize there's lots of things not supported due to
> the restricted environment it'll ultimately be used in.  However, you
> might want to consider extensions that would allow larger portions of
> the gcc testsuite to run and some kind of user mode simulator so that
> you can reasonably test the target.  Not a requirement, but could be
> useful (from experience :-)
> 
> I agree to both regards.
> 
> I have been thinking about Segher's suggestion on providing options to
> lift some of the limitations, for compiler testing.  Unfortunately, many
> of the restrictions are deeply rooted in the design of the
> architecture... or the other way around.  Finding sane ways to implement
> these extensions will be fun :)
Hell, it's a virtual architecture.  I'd just make up new instructions
for the missing functionality, make them dependent on an flag.  I think
the PRU is in a similar position and uses that approach.  PTX might have
as well.


> 
> As for the simulator, I have one, along with an initial GDB port... but
> it doesn't work very well due to a particularly nasty bug in CGEN.  I
> have a patch that seems to fix it but, as everything that touches cgen's
> ifield handling code, it is difficult to be 100% sure about that, and I
> also need to adapt some of the other existing cgen-based ports...  so it
> will take a while before I have something that can run the GCC
> testsuite.
ACK.

> Curious about the motivation on the loop unrolling stuff.  In general we
> discourage targets from mucking around with the default
> flags/optimizations, but it is sometimes the right thing to do.
> 
> The kernel verifier doesn't allow backward jumps.
Oh yea, I should have remembered that.  I think it came up in a
systemtap and/or ebpf+systemtap discussion at some point.

> 
> This may change at some point.  There is much discussion among the
> kernel hackers in whether it is possible to allow bounded loops in a
> safe way.  In that case, some of the restrictions may be lifted.
ACK.  It's an interesting problem.  Would it help if we could annotate
loops with bound information?  Not sure how to preserve that from gimple
down to assembly, but it's worth pondering.

> Does this get called often?  If so the linear search could end up being
> expensive from a compile-time standpoint.
> 
> It gets called per function call to a symbol with the form
> __builtin_bpf_helper_*...  you think it is worth of a hash?
Hard to tell.  Maybe leave it for now and revisit post integration and
real world feedback.

> Is the stack limit likely to change?  Would a param work better here
> which would allow us to accommodate such a change without having to
> re-release GCC?
> 
> It will probably be increased at some point.  Using a param sounds like
> a good idea.  However...
> 
> The stack limit is associated with kernel version.  I guess we can just
> set the appropriate defaults in bpf_option_override if we make it
> variable, in case the user didn't specify a --param for it, so no
> problem.
> 
> Also, if we allow the user to specify a stack frame bigger than 0x7fff,
> bpf_expand_prologue will break.  Probably in that case we want to detect
> this, warn and truncate to the -mkernel's default, also in
> bpf_option_override.
> 
> Does that sound reasonable?
It does.  I think PARAMS have the ability to enforce a min/max and
specify a default.  So set a default to 512 since that's what works
everywhere and if the kernel bumps up, folks can just use the param to
allow more stack space.

> 
> > diff --git a/gcc/config/bpf/bpf.h b/gcc/config/bpf/bpf.h
> > +
> > +/ Debugging Info /
> > +

[PATCH] Do not try to process deleted headers with Doxygen

[Jonathan Wakely]

* doc/doxygen/user.cfg.in (INPUT): Remove profile mode headers.

Committed to trunk.

commit 47af321610e47dfcf0179b71c50b0937ab0c19d9
Author: redi 
Date:   Tue Aug 20 21:35:55 2019 +

Do not try to process deleted headers with Doxygen

* doc/doxygen/user.cfg.in (INPUT): Remove profile mode headers.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@274758 
138bc75d-0d04-0410-961f-82ee72b054a4

diff --git a/libstdc++-v3/doc/doxygen/user.cfg.in 
b/libstdc++-v3/doc/doxygen/user.cfg.in
index 4ac5a0e39b2..dc493998a1a 100644
--- a/libstdc++-v3/doc/doxygen/user.cfg.in
+++ b/libstdc++-v3/doc/doxygen/user.cfg.in
@@ -886,17 +886,6 @@ INPUT  = 
@srcdir@/doc/doxygen/doxygroups.cc \
  include/debug/unordered_map \
  include/debug/unordered_set \
  include/debug/vector \
- include/profile \
- include/profile/impl \
- include/profile/bitset \
- include/profile/deque \
- include/profile/forward_list \
- include/profile/list \
- include/profile/map \
- include/profile/set \
- include/profile/unordered_map \
- include/profile/unordered_set \
- include/profile/vector \
  include/ext/algorithm \
  include/ext/cmath \
  include/ext/functional \

[PATCH] Fix markdown in Doxygen comments for std::reduce

[Jonathan Wakely]

* include/std/numeric (reduce): Fix Doxygen markup.

Committed to trunk.

commit eb08c33dadf6f53fa202aaddea5c68a01b83987a
Author: Jonathan Wakely 
Date:   Tue Aug 20 22:27:19 2019 +0100

Fix markdown in Doxygen comments for std::reduce

* include/std/numeric (reduce): Fix Doxygen markup.

diff --git a/libstdc++-v3/include/std/numeric b/libstdc++-v3/include/std/numeric
index 2f9462183dd..239276946b5 100644
--- a/libstdc++-v3/include/std/numeric
+++ b/libstdc++-v3/include/std/numeric
@@ -288,7 +288,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*  @return  The final sum.
*
*  Reduce the values in the range `[first,last)` using addition.
-   *  Equivalent to calling std::reduce(first, last, init, std::plus<>())`.
+   *  Equivalent to calling `std::reduce(first, last, init, std::plus<>())`.
*/
   template
 inline _Tp
@@ -304,7 +304,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
*
*  Reduce the values in the range `[first,last)` using addition, with
*  an initial value of `T{}`, where `T` is the iterator's value type.
-   *  Equivalent to calling std::reduce(first, last, T{}, std::plus<>())`.
+   *  Equivalent to calling `std::reduce(first, last, T{}, std::plus<>())`.
*/
   template
 inline typename iterator_traits<_InputIterator>::value_type

Re: What to do with argument mismatches in Fortran (was: [patch, fortran] Fix PR 91443)

[N.M. Maclaren]

On Aug 20 2019, Steve Kargl wrote:

On Tue, Aug 20, 2019 at 09:56:27PM +0200, Thomas Koenig wrote:

I wrote:

> Committed as r274551.

Well, this revision appears to have woken quite a few bugs from their
slumber.  While argument mismatch was always illegal, it seems to have
been a common idiom at one time.  And, like almost all bad habits of
the past, SPEC also has this (see PR 91473, where you can see thatt a
rather large number of SPEC tests now require -std=legacy).


Yes and no.  In de jure standard Fortran, it always has been illegal,
but the de facto standards were not always the same.  This caused a LOT
of debate in the early 1970s :-)  It was also an essential facility, for
various reasons, none of which have applied since Fortran 90.


So, what to do?  Is -std=legacy the right option, or should we add
something different (like -faccept-argument-mismatch), which we
could then set by -std=legacy?  And is there anything special
we should be doing after we have diagnoses the problem, if the
user simply wants to run the code?


Perhaps, something along the lines of -fallow-invalid-boz
I recently introduced.  Issue an error be default, but 
have -fallow-argument-mismatch downgrades the error to a

warning.  The only way to disable the warning is with -w.

Personally, if gfortran can detect an error in code, I think
it should report the error to the user.


I agree.


Regards,
Nick Maclaren,

Re: What to do with argument mismatches in Fortran (was: [patch, fortran] Fix PR 91443)

[N.M. Maclaren]

On Aug 20 2019, Steve Kargl wrote:

On Tue, Aug 20, 2019 at 09:56:27PM +0200, Thomas Koenig wrote:

I wrote:

> Committed as r274551.

Well, this revision appears to have woken quite a few bugs from their
slumber.  While argument mismatch was always illegal, it seems to have
been a common idiom at one time.  And, like almost all bad habits of
the past, SPEC also has this (see PR 91473, where you can see thatt a
rather large number of SPEC tests now require -std=legacy).


Yes and no.  In de jure standard Fortran, it always has been illegal,
but the de facto standards were not always the same.  This caused a LOT
of debate in the early 1970s :-)  It was also an essential facility, for
various reasons, none of which have applied since Fortran 90.


So, what to do?  Is -std=legacy the right option, or should we add
something different (like -faccept-argument-mismatch), which we
could then set by -std=legacy?  And is there anything special
we should be doing after we have diagnoses the problem, if the
user simply wants to run the code?


Perhaps, something along the lines of -fallow-invalid-boz
I recently introduced.  Issue an error be default, but 
have -fallow-argument-mismatch downgrades the error to a

warning.  The only way to disable the warning is with -w.

Personally, if gfortran can detect an error in code, I think
it should report the error to the user.


I agree.


Regards,
Nick Maclaren,

[Bug libstdc++/91371] std::bind and bind_front don't work with function with call convention

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91371

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Tue Aug 20 21:21:15 2019
New Revision: 274756

URL: https://gcc.gnu.org/viewcvs?rev=274756=gcc=rev
Log:
PR libstdc++/91371 make std::is_function handle other calling conventions

The x86 attributes such as ms_abi, stdcall, fastcall etc. alter the
function type, which means that functions with one of those attributes
do not match any of the partial specializations of std::is_function.

Rather than duplicating the list for every calling convention, use a
much simpler definition of std::is_function.

Also redefine __is_referenceable to not rely on partial specializations
for each type of referenceable function.

PR libstdc++/91371
* include/std/type_traits (is_function): Simplify definition. Remove
partial specializations for function types.
(__is_referenceable): Simplify definition.
* testsuite/20_util/bind/91371.cc: New test.
* testsuite/20_util/is_function/91371.cc: New test.
* testsuite/20_util/is_function/value.cc: Check more pointer types.
* testsuite/20_util/is_member_function_pointer/91371.cc: New test.
* testsuite/20_util/is_object/91371.cc: New test.

Added:
trunk/libstdc++-v3/testsuite/20_util/bind/91371.cc
trunk/libstdc++-v3/testsuite/20_util/is_function/91371.cc
trunk/libstdc++-v3/testsuite/20_util/is_member_function_pointer/91371.cc
trunk/libstdc++-v3/testsuite/20_util/is_object/91371.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/type_traits
trunk/libstdc++-v3/testsuite/20_util/is_function/value.cc

Re: [PATCH V2 2/8] bpf: new GCC port

[Jose E. Marchesi]

Hi Jeff.

> This patch adds a port for the Linux kernel eBPF architecture to GCC.
> 
> ChangeLog:
> 
>   * configure.ac: Support for bpf-*-* targets.
>   * configure: Regenerate.
> 
> contrib/ChangeLog:
> 
>   * config-list.mk (LIST): Disable go in bpf-*-* targets.
> 
> gcc/ChangeLog:
> 
>   * config.gcc: Support for bpf-*-* targets.
>   * common/config/bpf/bpf-common.c: New file.
>   * config/bpf/t-bpf: Likewise.
>   * config/bpf/predicates.md: Likewise.
>   * config/bpf/constraints.md: Likewise.
>   * config/bpf/bpf.opt: Likewise.
>   * config/bpf/bpf.md: Likewise.
>   * config/bpf/bpf.h: Likewise.
>   * config/bpf/bpf.c: Likewise.
>   * config/bpf/bpf-protos.h: Likewise.
>   * config/bpf/bpf-opts.h: Likewise.
>   * config/bpf/bpf-helpers.h: Likewise.
>   * config/bpf/bpf-helpers.def: Likewise.
So I think various folks have already mentioned the configure rebuild
issues, formatting and other stuff.  I'm going to try to keep them all
in mind so that I don't duplicate anything.  If I do duplicate someone's
comment, apologies in advance.

At a high level I realize there's lots of things not supported due to
the restricted environment it'll ultimately be used in.  However, you
might want to consider extensions that would allow larger portions of
the gcc testsuite to run and some kind of user mode simulator so that
you can reasonably test the target.  Not a requirement, but could be
useful (from experience :-)

I agree to both regards.

I have been thinking about Segher's suggestion on providing options to
lift some of the limitations, for compiler testing.  Unfortunately, many
of the restrictions are deeply rooted in the design of the
architecture... or the other way around.  Finding sane ways to implement
these extensions will be fun :)

As for the simulator, I have one, along with an initial GDB port... but
it doesn't work very well due to a particularly nasty bug in CGEN.  I
have a patch that seems to fix it but, as everything that touches cgen's
ifield handling code, it is difficult to be 100% sure about that, and I
also need to adapt some of the other existing cgen-based ports...  so it
will take a while before I have something that can run the GCC
testsuite.

> diff --git a/gcc/common/config/bpf/bpf-common.c 
b/gcc/common/config/bpf/bpf-common.c
> new file mode 100644
> index 000..a68feb62897
> --- /dev/null
> +++ b/gcc/common/config/bpf/bpf-common.c
[ snip ]
> +/* Implement TARGET_OPTION_OPTIMIZATION_TABLE.  */
> +static const struct default_options bpf_option_optimization_table[] =
> +  {
> +/* Enable -funroll-all-loops by default.  */
> +{ OPT_LEVELS_ALL, OPT_funroll_all_loops, NULL, 1 },
> +/* Disable -fomit-frame-pointer by default.  */
> +{ OPT_LEVELS_ALL, OPT_fomit_frame_pointer, NULL, 0 },
> +{ OPT_LEVELS_NONE, 0, NULL, 0 }
> +  };
Curious about the motivation on the loop unrolling stuff.  In general we
discourage targets from mucking around with the default
flags/optimizations, but it is sometimes the right thing to do.

The kernel verifier doesn't allow backward jumps.

This may change at some point.  There is much discussion among the
kernel hackers in whether it is possible to allow bounded loops in a
safe way.  In that case, some of the restrictions may be lifted.

For now, only loops that can be peeled/massaged and then fully unrolled
are supported.

Rather than -fomit-frame-pointer, I think you can use the
FRAME_POINTER_REQUIRED hook if you always want a frame pointer.

Oh so specifying -fomit-frame-pointer there is redundant... good to
know.  Will remove it.

> diff --git a/gcc/config/bpf/bpf-helpers.h b/gcc/config/bpf/bpf-helpers.h
> new file mode 100644
> index 000..2fe96be7637
> --- /dev/null
> +++ b/gcc/config/bpf/bpf-helpers.h
I can't remember, is this an installed header that consumers are
expected to use?  If so you might want to be careful with polluting user
code with BPF #defines such as BPF_ANY, BPF_NOEXIST, BPF_EXIST, etc.
The #defines for mapping to the builtins are probably OK though.

Yes, it is a header file for consumers.  Unfortunately, the whole
purpose of the header is to provide an interface that is compatible with
the kernel's bpf_helpers.h (which at the moment is llvm-specific).  The
API is given :(

This is a point I plan to raise with the eBPF developers in a few weeks,
at the Linux Plumbers conference in Lisbon.

> diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
> new file mode 100644
> index 000..4a42259a9c3
> --- /dev/null
> +++ b/gcc/config/bpf/bpf.c
> @@ -0,0 +1,1136 @@
[ ... ]
> +
> +/* Return the builtin code corresponding to the kernel helper builtin
> +   __builtin_NAME, or 0 if the 

[Bug tree-optimization/91491] [9 Regression] glib2.0 build not working when built with -O2 on x86_64-linux-gnu

[smcv at debian dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91491

--- Comment #5 from Simon McVittie  ---
> I suppose you did things like running under valgrind or compiling with
-fsanitize=address.

I wasn't able to reproduce the bug earlier on, in a build with
-fsanitize=address, but this was probably because I was focusing on GLib and
not Clutter. valgrind reveals that the (already compiled) Clutter test (not the
part we were recompiling) wasn't fully initializing a struct on the stack.

> The most obvious thing I expect from -fno-tree-pre
> is stack layout changes which then smells like some bogus stack smashing
> going on.

Enabling or disabling the optimization resulted in the uninitialized part of
the struct (apparently reliably) containing a zero or nonzero value. If it's
nonzero, the rest of the test is effectively skipped, so it has no opportunity
to hang.

It's entirely possible that the test in question has never worked correctly -
when I initialize the struct to all-zeroes (which appears to have been the
intention), it reliably hangs.

So I think this can be closed as not your bug. Sorry for the noise.

[Bug libstdc++/91495] std::transform_reduce with unary op is implemented in the parallel case but not the basic case

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91495

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Tue Aug 20 21:03:11 2019
New Revision: 274754

URL: https://gcc.gnu.org/viewcvs?rev=274754=gcc=rev
Log:
Implement new serial algorithms from Parallelism TS (P0024R2)

These new (non-parallel) algorithms were added to C++17 along with the
parallel algorithms, but were missing from libstdc++.

Backported for PR libstdc++/91495, replacing the use of
std::__size_to_integer which is not present on the branch.

Backport from mainline
2019-06-19  Jonathan Wakely  

* include/std/numeric (reduce(Iter, Iter, T, BinOp)): Fix value
category used in invocable check.
(reduce(Iter, Iter, T)): Pass initial value as rvalue.
* testsuite/26_numerics/reduce/2.cc: New test.

Backport from mainline
2019-06-18  Jonathan Wakely  

* include/bits/algorithmfwd.h: Change title of doc group.
* include/bits/stl_algo.h (for_each_n): Add new C++17 algorithm from
P0024R2.
* include/bits/stl_numeric.h: Define doc group and add algos to it.
* include/std/numeric (__is_random_access_iter): New internal trait.
(reduce, transform_reduce, exclusive_scan, inclusive_scan)
(transform_exclusive_scan, transform_inclusive_scan): Likewise.
* testsuite/25_algorithms/for_each/for_each_n.cc: New test.
* testsuite/26_numerics/exclusive_scan/1.cc: New test.
* testsuite/26_numerics/inclusive_scan/1.cc: New test.
* testsuite/26_numerics/reduce/1.cc: New test.
* testsuite/26_numerics/transform_exclusive_scan/1.cc: New test.
* testsuite/26_numerics/transform_inclusive_scan/1.cc: New test.
* testsuite/26_numerics/transform_reduce/1.cc: New test.
* testsuite/util/testsuite_iterators.h (test_container::size()): New
member function.

Added:
   
branches/gcc-9-branch/libstdc++-v3/testsuite/25_algorithms/for_each/for_each_n.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/exclusive_scan/
   
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/exclusive_scan/1.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/inclusive_scan/
   
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/inclusive_scan/1.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/reduce/
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/reduce/1.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/reduce/2.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/transform_exclusive_scan/
   
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/transform_exclusive_scan/1.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/transform_inclusive_scan/
   
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/transform_inclusive_scan/1.cc
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/transform_reduce/
   
branches/gcc-9-branch/libstdc++-v3/testsuite/26_numerics/transform_reduce/1.cc
Modified:
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/include/bits/algorithmfwd.h
branches/gcc-9-branch/libstdc++-v3/include/bits/stl_algo.h
branches/gcc-9-branch/libstdc++-v3/include/bits/stl_numeric.h
branches/gcc-9-branch/libstdc++-v3/include/std/numeric
branches/gcc-9-branch/libstdc++-v3/testsuite/util/testsuite_iterators.h

[Bug fortran/91426] Different colors for errors with multiple locations

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91426

David Malcolm  changed:

   What|Removed |Added

  Attachment #46732|0   |1
is obsolete||

--- Comment #6 from David Malcolm  ---
Created attachment 46736
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46736=edit
Updated version of patch

This version of the patch hopefully covers all of the various
diagnostic-emitting functions in gcc/fortran/error.c

Caveats:
- not yet bootstrapped/regrtested
- patch is against an very old tree (r267518)

[patch, fortran] Fix PR 91390 - treatment of extra parameter in a subroutine call

[Thomas König]

Hello world,

here is the next installment of checking for mismatched calls,
this time for mismatching CALLs.

The solution is to build a separate namespace with procedure
arguments determined from the actual arguments the first time a
procedure is seen, and then compare it against that on subsequent
calls.

This has uncovered quite a few examples of non-conforming code
in our testsuite, so no separate test case needed, IMHO.

So, OK for trunk?  (The -std=legacy question can be settled
later).

2019-08-20  Thomas Koenig  

PR fortran/91390
* frontend-passes.c (check_externals_procedure): New
function. If a procedure is not in the translation unit, create
an "interface" for it, including its formal arguments.
(check_externals_code): Use check_externals_procedure for common
code with check_externals_expr.
(check_externals_expr): Vice versa.
* gfortran.h (gfc_get_formal_from_actual-arglist): New prototype.
(gfc_compare_actual_formal): New prototype.
* interface.c (compare_actual_formal): Rename to
(gfc_compare_actual_forma): New function, make global.
(gfc_get_formal_from_actual_arglist): Make global, and move here from
* trans-types.c (get_formal_from_actual_arglist): Remove here.
(gfc_get_function_type): Use gfc_get_formal_from_actual_arglist.

2019-08-20  Thomas Koenig  

PR fortran/91390
* gfortran.dg/bessel_3.f90: Add type mismatch errors.
* gfortran.dg/coarray_7.f90: Rename subroutines to avoid
additional errors.
* gfortran.dg/g77/20010519-1.f: Add -std=legacy. Remove
warnings for ASSIGN. Add warnings for type mismatch.
* gfortran.dg/goacc/acc_on_device-1.f95: Add -std=legacy.
Add cath-all warning.
* gfortran.dg/internal_pack_9.f90: Rename subroutine to
avoid type error.
* gfortran.dg/internal_pack_9.f90: Add -std=legacy. Add
warnings for type mismatch.
* gfortran.dg/pr39937.f: Add -std=legacy and type warnings. Move
here from
* gfortran.fortran-torture/compile/pr39937.f: Move to gfortran.dg.
Index: fortran/frontend-passes.c
===
--- fortran/frontend-passes.c	(Revision 274623)
+++ fortran/frontend-passes.c	(Arbeitskopie)
@@ -5369,25 +5369,22 @@ gfc_code_walker (gfc_code **c, walk_code_fn_t code
We do this by looping over the code (and expressions). The first call
we happen to find is assumed to be canonical.  */
 
-/* Callback for external functions.  */
 
+/* Common tests for argument checking for both functions and subroutines.  */
+
 static int
-check_externals_expr (gfc_expr **ep, int *walk_subtrees ATTRIBUTE_UNUSED,
-		  void *data ATTRIBUTE_UNUSED)
+check_externals_procedure (gfc_symbol *sym, locus *loc, gfc_actual_arglist *actual)
 {
-  gfc_expr *e = *ep;
-  gfc_symbol *sym, *def_sym;
   gfc_gsymbol *gsym;
+  gfc_symbol *def_sym = NULL;
 
-  if (e->expr_type != EXPR_FUNCTION)
+ if (sym == NULL || sym->attr.is_bind_c)
 return 0;
 
-  sym = e->value.function.esym;
-
-  if (sym == NULL || sym->attr.is_bind_c)
+  if (sym->attr.proc != PROC_EXTERNAL && sym->attr.proc != PROC_UNKNOWN)
 return 0;
 
-  if (sym->attr.proc != PROC_EXTERNAL && sym->attr.proc != PROC_UNKNOWN)
+  if (sym->attr.if_source == IFSRC_IFBODY || sym->attr.if_source == IFSRC_DECL)
 return 0;
 
   gsym = gfc_find_gsymbol (gfc_gsym_root, sym->name);
@@ -5394,15 +5391,39 @@ static int
   if (gsym == NULL)
 return 0;
 
-  gfc_find_symbol (sym->name, gsym->ns, 0, _sym);
+  if (gsym->ns)
+gfc_find_symbol (sym->name, gsym->ns, 0, _sym);
 
-  if (sym && def_sym)
-gfc_procedure_use (def_sym, >value.function.actual, >where);
+  if (def_sym)
+{
+  gfc_procedure_use (def_sym, , loc);
+  return 0;
+}
 
+  /* First time we have seen this procedure called. Let's create an
+ "interface" from the call and put it into a new namespace.  */
+  gfc_namespace *save_ns;
+  gfc_symbol *new_sym;
+
+  gsym->where = *loc;
+  save_ns = gfc_current_ns;
+  gsym->ns = gfc_get_namespace (gfc_current_ns, 0);
+  gsym->ns->proc_name = sym;
+
+  gfc_get_symbol (sym->name, gsym->ns, _sym);
+  gcc_assert (new_sym);
+  new_sym->attr = sym->attr;
+  new_sym->attr.if_source = IFSRC_DECL;
+  gfc_current_ns = gsym->ns;
+
+  gfc_get_formal_from_actual_arglist (new_sym, actual);
+  gfc_current_ns = save_ns;
+
   return 0;
+
 }
 
-/* Callback for external code.  */
+/* Callback for calls of external routines.  */
 
 static int
 check_externals_code (gfc_code **c, int *walk_subtrees ATTRIBUTE_UNUSED,
@@ -5409,32 +5430,43 @@ check_externals_code (gfc_code **c, int *walk_subt
 		  void *data ATTRIBUTE_UNUSED)
 {
   gfc_code *co = *c;
-  gfc_symbol *sym, *def_sym;
-  gfc_gsymbol *gsym;
+  gfc_symbol *sym;
+  locus *loc;
+  gfc_actual_arglist *actual;
 
   if (co->op != EXEC_CALL)
 return 0;
 
   sym = co->resolved_sym;
-  if 

Re: What to do with argument mismatches in Fortran (was: [patch, fortran] Fix PR 91443)

[Steve Kargl]

On Tue, Aug 20, 2019 at 09:56:27PM +0200, Thomas Koenig wrote:
> I wrote:
> 
> > Committed as r274551.
> 
> Well, this revision appears to have woken quite a few bugs from their
> slumber.  While argument mismatch was always illegal, it seems to have
> been a common idiom at one time.  And, like almost all bad habits of
> the past, SPEC also has this (see PR 91473, where you can see thatt a
> rather large number of SPEC tests now require -std=legacy).
> 
> So, what to do?  Is -std=legacy the right option, or should we add
> something different (like -faccept-argument-mismatch), which we
> could then set by -std=legacy?  And is there anything special
> we should be doing after we have diagnoses the problem, if the
> user simply wants to run the code?

Perhaps, something along the lines of -fallow-invalid-boz
I recently introduced.  Issue an error be default, but 
have -fallow-argument-mismatch downgrades the error to a
warning.  The only way to disable the warning is with -w.

Personally, if gfortran can detect an error in code, I think
it should report the error to the user.

-- 
Steve

Re: What to do with argument mismatches in Fortran (was: [patch, fortran] Fix PR 91443)

[Steve Kargl]

On Tue, Aug 20, 2019 at 09:56:27PM +0200, Thomas Koenig wrote:
> I wrote:
> 
> > Committed as r274551.
> 
> Well, this revision appears to have woken quite a few bugs from their
> slumber.  While argument mismatch was always illegal, it seems to have
> been a common idiom at one time.  And, like almost all bad habits of
> the past, SPEC also has this (see PR 91473, where you can see thatt a
> rather large number of SPEC tests now require -std=legacy).
> 
> So, what to do?  Is -std=legacy the right option, or should we add
> something different (like -faccept-argument-mismatch), which we
> could then set by -std=legacy?  And is there anything special
> we should be doing after we have diagnoses the problem, if the
> user simply wants to run the code?

Perhaps, something along the lines of -fallow-invalid-boz
I recently introduced.  Issue an error be default, but 
have -fallow-argument-mismatch downgrades the error to a
warning.  The only way to disable the warning is with -w.

Personally, if gfortran can detect an error in code, I think
it should report the error to the user.

-- 
Steve

[Bug c++/91505] [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91505

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-08-20
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

Re: [PATCH 2/8] bpf: new GCC port

[Hans-Peter Nilsson]

On Tue, 20 Aug 2019, Jose E. Marchesi wrote:
> > On Thu, Aug 15, 2019 at 12:22:46AM +0200, Jose E. Marchesi wrote:
> > > --- a/configure
> > > +++ b/configure
> Yeah by mistake I used a Debian patched autoconf 2.96.  Will regenerate
> using vanilla autoconf for subsequent versions of the patch.

It's nice that this is identified and hopefully resolved, but
since nobody mentioned it I'll just point out that
it's preferable to *not at all* include generated files like
configure in patches.  See
.

brgds, H-P

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497

--- Comment #8 from Steve Kargl  ---
On Tue, Aug 20, 2019 at 07:50:06PM +, manfred99 at gmx dot ch wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
> 
> --- Comment #7 from Manfred Schwarb  ---
> Hopefully this rings some bells: The warnings happen
> only for parameters:

Yeah. I know.  See the diff I posted.

What to do with argument mismatches in Fortran (was: [patch, fortran] Fix PR 91443)

[Thomas Koenig]

I wrote:


Committed as r274551.


Well, this revision appears to have woken quite a few bugs from their
slumber.  While argument mismatch was always illegal, it seems to have
been a common idiom at one time.  And, like almost all bad habits of
the past, SPEC also has this (see PR 91473, where you can see thatt a
rather large number of SPEC tests now require -std=legacy).

So, what to do?  Is -std=legacy the right option, or should we add
something different (like -faccept-argument-mismatch), which we
could then set by -std=legacy?  And is there anything special
we should be doing after we have diagnoses the problem, if the
user simply wants to run the code?

What to do with argument mismatches in Fortran (was: [patch, fortran] Fix PR 91443)

[Thomas Koenig]

I wrote:


Committed as r274551.


Well, this revision appears to have woken quite a few bugs from their
slumber.  While argument mismatch was always illegal, it seems to have
been a common idiom at one time.  And, like almost all bad habits of
the past, SPEC also has this (see PR 91473, where you can see thatt a
rather large number of SPEC tests now require -std=legacy).

So, what to do?  Is -std=legacy the right option, or should we add
something different (like -faccept-argument-mismatch), which we
could then set by -std=legacy?  And is there anything special
we should be doing after we have diagnoses the problem, if the
user simply wants to run the code?

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[manfred99 at gmx dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497

--- Comment #7 from Manfred Schwarb  ---
Hopefully this rings some bells: The warnings happen
only for parameters:

  real b
  double precision a,c,d
  PARAMETER(a=3.1415927d0)

  DATA c /3.1415927d0/
  d=3.1415927d0

  b=REAL(a)
  b=REAL(a, kind=4)
  b=REAL(c)
  b=REAL(d)
  end


a.f:8:13:

8 |   b=REAL(a)
  | 1
Warning: Change of value in conversion from 'REAL(8)' to 'REAL(4)' at (1)
[-Wconversion]
a.f:9:13:

9 |   b=REAL(a, kind=4)
  | 1
Warning: Change of value in conversion from 'REAL(8)' to 'REAL(4)' at (1)
[-Wconversion]


Thanks for your efforts!

[Bug lto/91478] FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors)

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478

--- Comment #5 from John David Anglin  ---
Previously, we had in pr41893-1.o.debug.temp.o:
 w gnu_lto_v1
 w gnu_lto_v1
 w gnu_lto_v1
 w gnu_lto_v1
 W pr41893_1.c.ebbf0839

Now we have:
 w
 w
 w
 W pr41893_1.c.ebbf0839

The gnu_lto_v1 symbol was resolved by libgcc.a hack.

Re: Expansion of narrowing math built-ins into power instructions

[Segher Boessenkool]

On Tue, Aug 20, 2019 at 03:43:43PM +0100, Richard Sandiford wrote:
> Segher Boessenkool  writes:
> > On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote:
> >> Segher Boessenkool  writes:
> >> >>   [(set (match_operand:SI 0 "register_operand" "=d")
> >> >> (truncate:SI
> >> >>  (lshiftrt:DI
> >> >
> >> > (this is optimised to a subreg, in many cases, for example).
> >> 
> >> Right.  MIPS avoids that one thanks to TARGET_TRULY_NOOP_TRUNCATION.
> >
> > Trying 10 -> 18:
> >10: r200:TI=zero_extend(r204:DI)*zero_extend(r205:DI)
> >   REG_DEAD r205:DI
> >   REG_DEAD r204:DI
> >18: $2:DI=r200:TI#0
> >   REG_DEAD r200:TI
> > Failed to match this instruction:
> > (set (reg/i:DI 2 $2)
> > (subreg:DI (mult:TI (zero_extend:TI (reg:DI 204))
> > (zero_extend:TI (reg:DI 205))) 0))
> >
> > I'm afraid not.
> 
> That's TI->DI though, whereas the pattern above is DI->SI.  The modes
> matter :-)  There'd also need to be a shift to match a highpart pattern.

It's the same for 32-bit:

mips-linux-gcc -Wall -W -O2 -S mulh.c -mips32 -mabi=32
(I hope these options are reasonable?  I don't know MIPS well at all).

Trying 12 -> 20:
   12: r200:DI=zero_extend(r204:SI)*zero_extend(r205:SI)
  REG_DEAD r205:SI
  REG_DEAD r204:SI
   20: $2:SI=r200:DI#0
  REG_DEAD r200:DI
Failed to match this instruction:
(set (reg/i:SI 2 $2)
(subreg:SI (mult:DI (zero_extend:DI (reg:SI 204))
(zero_extend:DI (reg:SI 205))) 0))

The point is that this is the form that this insn is simplified to.  If
that form is not recognised by your backend, various optimisation
opportunities are missed.

> I wouldn't say it knows nothing about rounding.  It doesn't know
> what the runtime rounding mode is, but that isn't the same thing.
> (Just like not knowing what (mem:SI (sp)) contains isn't the same
> thing as not knowing anything about stack memory.)

Does it even know if the rounding mode is one of the IEEE FP rounding
modes?


Segher

[Bug c++/91505] New: [10 Regression] ICE in DECL_FUNCTION_CODE, at tree.h:3896

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91505

Bug ID: 91505
   Summary: [10 Regression] ICE in DECL_FUNCTION_CODE, at
tree.h:3896
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

g++-10.0.0-alpha20190818 snapshot (r274625) ICEs when compiling
gcc/testsuite/gcc.target/i386/crc32-4.c w/ -msse4 or -mavx*:

% x86_64-unknown-linux-gnu-g++-10.0.0-alpha20190818 -mavx2 -c
gcc/testsuite/gcc.target/i386/crc32-4.c
gcc/testsuite/gcc.target/i386/crc32-4.c:6:29: internal compiler error: in
DECL_FUNCTION_CODE, at tree.h:3896
6 | unsigned long long y);
  | ^
0x685466 DECL_FUNCTION_CODE(tree_node const*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/tree.h:3896
0x685466 copy_attributes_to_builtin(tree_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/attribs.c:1528
0x918ed9 duplicate_decls(tree_node*, tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/decl.c:2570
0x9890b7 do_pushdecl
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/name-lookup.c:3029
0x9890b7 pushdecl(tree_node*, bool)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/name-lookup.c:3157
0x9261b6 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/decl.c:5292
0x9c6ac9 cp_parser_init_declarator
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/parser.c:20391
0x9a9831 cp_parser_simple_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/parser.c:13555
0x9cd9e2 cp_parser_declaration
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/parser.c:13252
0x9ce079 cp_parser_translation_unit
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/parser.c:4709
0x9ce079 c_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/cp/parser.c:41805
0xad6c4c c_common_parse_file()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/c-family/c-opts.c:1164

[Bug tree-optimization/91504] New: Inlining misses some logical operation folding

[rth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91504

Bug ID: 91504
   Summary: Inlining misses some logical operation folding
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rth at gcc dot gnu.org
  Target Milestone: ---

In the following test case,

static inline unsigned deposit32(unsigned value, int start, int length,
 unsigned fieldval)
{
unsigned mask = (~0U >> (32 - length)) << start;
return (value & ~mask) | ((fieldval << start) & mask);
}

unsigned foo(unsigned value)
{
   return deposit32(value, 10, 1, 1);
}

unsigned bar(unsigned value)
{
int start = 10;
int length = 1;
unsigned fieldval = 1;
unsigned mask = (~0U >> (32 - length)) << start;
return (value & ~mask) | ((fieldval << start) & mask);
}

One would expect FOO and BAR to compile to the same code, since
the latter is the trivial inlining of the former, but that does
not happen.

gcc -O2 -S z.c gives

foo:
mvn w1, w0
and w1, w1, 1024
eor w0, w1, w0
ret

bar:
orr w0, w0, 1024
ret

The problem appears independent of target, as it isvisible on
both x86 and aarch64 targets.

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497

--- Comment #6 from Steve Kargl  ---
On Tue, Aug 20, 2019 at 06:58:27PM +, tkoenig at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497
> 
> --- Comment #5 from Thomas Koenig  ---
> (In reply to Steve Kargl from comment #4)
> 
> > This diff will silence warnings for explicit conversion
> > using REAL() and INT() for the -Wconversion option.  It
> > does not silence warnings for -Wconversion-extra.
> 
> This approcach looks very good.  It might make sense to also extend it
> to -Wconversion-extra.
> 
> Do you plan to commit?  If you do, this patch is OK (we can discuss
> -Wconversion-extra later).
> 

I wasn't going to commit until others had a chance to 
weigh in.  In particular, I wasn't sure what to do
with -Wconversion-extra as I haven't looked at the
manual to see what "extra" implies.

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497

--- Comment #5 from Thomas Koenig  ---
(In reply to Steve Kargl from comment #4)

> This diff will silence warnings for explicit conversion
> using REAL() and INT() for the -Wconversion option.  It
> does not silence warnings for -Wconversion-extra.

This approcach looks very good.  It might make sense to also extend it
to -Wconversion-extra.

Do you plan to commit?  If you do, this patch is OK (we can discuss
-Wconversion-extra later).

Re: [PATCH V2 2/8] bpf: new GCC port

[Jeff Law]

On 8/16/19 6:59 PM, Jose E. Marchesi wrote:
> This patch adds a port for the Linux kernel eBPF architecture to GCC.
> 
> ChangeLog:
> 
>   * configure.ac: Support for bpf-*-* targets.
>   * configure: Regenerate.
> 
> contrib/ChangeLog:
> 
>   * config-list.mk (LIST): Disable go in bpf-*-* targets.
> 
> gcc/ChangeLog:
> 
>   * config.gcc: Support for bpf-*-* targets.
>   * common/config/bpf/bpf-common.c: New file.
>   * config/bpf/t-bpf: Likewise.
>   * config/bpf/predicates.md: Likewise.
>   * config/bpf/constraints.md: Likewise.
>   * config/bpf/bpf.opt: Likewise.
>   * config/bpf/bpf.md: Likewise.
>   * config/bpf/bpf.h: Likewise.
>   * config/bpf/bpf.c: Likewise.
>   * config/bpf/bpf-protos.h: Likewise.
>   * config/bpf/bpf-opts.h: Likewise.
>   * config/bpf/bpf-helpers.h: Likewise.
>   * config/bpf/bpf-helpers.def: Likewise.
So I think various folks have already mentioned the configure rebuild
issues, formatting and other stuff.  I'm going to try to keep them all
in mind so that I don't duplicate anything.  If I do duplicate someone's
comment, apologies in advance.

At a high level I realize there's lots of things not supported due to
the restricted environment it'll ultimately be used in.  However, you
might want to consider extensions that would allow larger portions of
the gcc testsuite to run and some kind of user mode simulator so that
you can reasonably test the target.  Not a requirement, but could be
useful (from experience :-)


> ---

> diff --git a/contrib/config-list.mk b/contrib/config-list.mk
> index 69c826e649a..aa9fdb64eaf 100644
> --- a/contrib/config-list.mk
> +++ b/contrib/config-list.mk
> @@ -123,7 +123,7 @@ $(LIST): make-log-dir
>   TGT=`echo $@ | awk 'BEGIN { FS = "OPT" }; { print $$1 }'` &&
> \
>   TGT=`$(GCC_SRC_DIR)/config.sub $$TGT` &&
> \
>   case $$TGT in   
> \
> - *-*-darwin* | *-*-cygwin* | *-*-mingw* | *-*-aix*)  
> \
> + *-*-darwin* | *-*-cygwin* | *-*-mingw* | *-*-aix* | 
> bpf-*-* )   \
>   ADDITIONAL_LANGUAGES="";
> \
>   ;;  
> \
>   *)  
> \
So I've got no problem disabling Go for BFD, but I don't see bpf added
to LIST, which it should be.


> diff --git a/gcc/common/config/bpf/bpf-common.c 
> b/gcc/common/config/bpf/bpf-common.c
> new file mode 100644
> index 000..a68feb62897
> --- /dev/null
> +++ b/gcc/common/config/bpf/bpf-common.c
[ snip ]
> +/* Implement TARGET_OPTION_OPTIMIZATION_TABLE.  */
> +static const struct default_options bpf_option_optimization_table[] =
> +  {
> +/* Enable -funroll-all-loops by default.  */
> +{ OPT_LEVELS_ALL, OPT_funroll_all_loops, NULL, 1 },
> +/* Disable -fomit-frame-pointer by default.  */
> +{ OPT_LEVELS_ALL, OPT_fomit_frame_pointer, NULL, 0 },
> +{ OPT_LEVELS_NONE, 0, NULL, 0 }
> +  };
Curious about the motivation on the loop unrolling stuff.  In general we
discourage targets from mucking around with the default
flags/optimizations, but it is sometimes the right thing to do.

Rather than -fomit-frame-pointer, I think you can use the
FRAME_POINTER_REQUIRED hook if you always want a frame pointer.


> +
> +#undef TARGET_OPTION_OPTIMIZATION_TABLE
> +#define TARGET_OPTION_OPTIMIZATION_TABLE bpf_option_optimization_table
> +
> +/* Implement TARGET_OPTION_DEFAULT_PARAMS.  */
> +
> +static void
> +bpf_option_default_params (void)
> +{
> +  /* XXX large-stack-frame = 512 bytes */
> +  /* XXX max-unrolled-insns */
> +  /* XXX max-unroll-times */
> +}
> +
> +#undef TARGET_OPTION_DEFAULT_PARAMS
> +#define TARGET_OPTION_DEFAULT_PARAMS bpf_option_default_params
I'd generally discourage twiddling the params like this, at least the
ones for the unroller.



> diff --git a/gcc/config/bpf/bpf-helpers.h b/gcc/config/bpf/bpf-helpers.h
> new file mode 100644
> index 000..2fe96be7637
> --- /dev/null
> +++ b/gcc/config/bpf/bpf-helpers.h
I can't remember, is this an installed header that consumers are
expected to use?  If so you might want to be careful with polluting user
code with BPF #defines such as BPF_ANY, BPF_NOEXIST, BPF_EXIST, etc.
The #defines for mapping to the builtins are probably OK though.




> diff --git a/gcc/config/bpf/bpf.c b/gcc/config/bpf/bpf.c
> new file mode 100644
> index 000..4a42259a9c3
> --- /dev/null
> +++ b/gcc/config/bpf/bpf.c
> @@ -0,0 +1,1136 @@
[ ... ]
> +
> +/* Return the builtin code corresponding to the kernel helper builtin
> +   __builtin_NAME, or 0 if the name doesn't correspond to a kernel
> +   helper builtin.  */
> +
> +static inline int
> +bpf_helper_code (const char *name)
> +{
> +  int i;

[Bug ada/91417] [10 regression] acats c761003 fails for powerpc targets

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91417

Iain Sandoe  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #1 from Iain Sandoe  ---
somewhere between 274397 and 274624 this was fixed.

[Bug fortran/91426] Different colors for errors with multiple locations

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91426

--- Comment #5 from Thomas Koenig  ---
(In reply to David Malcolm from comment #4)

> The patch I've just attached ought to do this (though it's just a crude
> prototype - it only works for the gfc_error_opt case).
> 
> With that caveat, how does the output look?

Looks _very_ good to me.

[Bug tree-optimization/91491] [9 Regression] glib2.0 build not working when built with -O2 on x86_64-linux-gnu

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91491

--- Comment #4 from Andrew Pinski  ---
(In reply to Richard Biener from comment #3)
> Eh, "interesting".  Thanks for the clarifications.
> 
> I suppose you did things like running under valgrind or compiling with
> -fsanitize=address.  The most obvious thing I expect from -fno-tree-pre
> is stack layout changes which then smells like some bogus stack smashing
> going on.  Can you try building gtestutils.c with
> -O2 -fno-optimize-sibling-calls?

That or there is some other undefined behavior.  Try also -fno-strict-aliasing.

[SVE] PR88839

[Prathamesh Kulkarni]

Hi,
The attached patch is a fix for PR88839 ported from sve-acle-branch.
OK to commit to trunk ?

Thanks,
Prathamesh
2019-08-21  Prathamesh Kulkarni  
Richard Sandiford  

PR target/88839
* config/aarch64/aarch64.c (aarch64_evpc_sel): New function.
(aarch64_expand_vec_perm_const_1): Call aarch64_evpc_sel.

testsuite/
* gcc.target/aarch64/sve/sel_1.c: New test.
* gcc.target/aarch64/sve/sel_2.c: Likewise.
* gcc.target/aarch64/sve/sel_3.c: Likewise.
* gcc.target/aarch64/sve/sel_4.c: Likewise.
* gcc.target/aarch64/sve/sel_5.c: Likewise.
* gcc.target/aarch64/sve/sel_6.c: Likewise.

diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index ec60e972f5f..f8d5270b982 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -16632,6 +16632,50 @@ aarch64_evpc_sve_tbl (struct expand_vec_perm_d *d)
   return true;
 }
 
+/* Try to implement D using SVE SEL instruction.  */
+
+static bool
+aarch64_evpc_sel (struct expand_vec_perm_d *d)
+{
+  machine_mode vmode = d->vmode;
+  int nunits = GET_MODE_UNIT_SIZE (vmode);
+
+  if (d->vec_flags != VEC_SVE_DATA
+  || nunits > 8)
+return false;
+
+  int n_patterns = d->perm.encoding ().npatterns ();
+  poly_int64 vec_len = d->perm.length ();
+
+  for (int i = 0; i < n_patterns; ++i)
+if (!known_eq (d->perm[i], i)
+   && !known_eq (d->perm[i], vec_len + i))
+  return false;
+
+  for (int i = n_patterns; i < n_patterns * 2; i++)
+if (!d->perm.series_p (i, n_patterns, i, n_patterns)
+   && !d->perm.series_p (i, n_patterns, vec_len + i, n_patterns))
+  return false;
+
+  if (d->testing_p)
+return true;
+
+  machine_mode pred_mode = aarch64_sve_pred_mode (nunits).require ();
+
+  rtx_vector_builder builder (pred_mode, n_patterns, 2);
+  for (int i = 0; i < n_patterns * 2; i++)
+{
+  rtx elem = known_eq (d->perm[i], i) ? CONST1_RTX (BImode)
+ : CONST0_RTX (BImode);
+  builder.quick_push (elem);
+}
+
+  rtx const_vec = builder.build ();
+  rtx pred = force_reg (pred_mode, const_vec);
+  emit_insn (gen_vcond_mask (vmode, vmode, d->target, d->op1, d->op0, pred));
+  return true;
+}
+
 static bool
 aarch64_expand_vec_perm_const_1 (struct expand_vec_perm_d *d)
 {
@@ -16664,6 +16708,8 @@ aarch64_expand_vec_perm_const_1 (struct 
expand_vec_perm_d *d)
return true;
   else if (aarch64_evpc_trn (d))
return true;
+  else if (aarch64_evpc_sel (d))
+   return true;
   if (d->vec_flags == VEC_SVE_DATA)
return aarch64_evpc_sve_tbl (d);
   else if (d->vec_flags == VEC_ADVSIMD)
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/sel_1.c 
b/gcc/testsuite/gcc.target/aarch64/sve/sel_1.c
new file mode 100644
index 000..e651e5b93b6
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/sve/sel_1.c
@@ -0,0 +1,27 @@
+/* { dg-do assemble { target aarch64_asm_sve_ok } } */
+/* { dg-options "-O2 -msve-vector-bits=256 --save-temps" } */
+
+#include 
+
+typedef int8_t vnx16qi __attribute__((vector_size (32)));
+
+/* Predicate vector: 1 0 1 0 ... */
+
+#define MASK_32{ 0, 33, 2, 35, 4, 37, 6, 39, 8, 41,
\
+ 10, 43, 12, 45, 14, 47, 16, 49, 18, 51,   
\
+ 20, 53, 22, 55, 24, 57, 26, 59, 28, 61, 30, 63 }
+
+#define INDEX_32 vnx16qi
+
+#define PERMUTE(type, nunits)  \
+type permute_##type (type x, type y)   \
+{  \
+  return __builtin_shuffle (x, y, (INDEX_##nunits) MASK_##nunits); \
+}
+
+PERMUTE(vnx16qi, 32)
+
+/* { dg-final { scan-assembler-not {\ttbl\t} } } */
+
+/* { dg-final { scan-assembler-times {\tsel\tz[0-9]+\.b, p[0-9]+, z[0-9]+\.b, 
z[0-9]+\.b\n} 1 } } */
+/* { dg-final { scan-assembler-times {\tptrue\tp[0-9]+\.h, vl16\n} 1 } } */
diff --git a/gcc/testsuite/gcc.target/aarch64/sve/sel_2.c 
b/gcc/testsuite/gcc.target/aarch64/sve/sel_2.c
new file mode 100644
index 000..05391474a92
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/sve/sel_2.c
@@ -0,0 +1,41 @@
+/* { dg-do assemble { target aarch64_asm_sve_ok } } */
+/* { dg-options "-O2 -msve-vector-bits=256 --save-temps" } */
+
+#include 
+
+typedef int8_t vnx16qi __attribute__((vector_size (32)));
+typedef int16_t vnx8hi __attribute__((vector_size (32)));
+typedef int32_t vnx4si __attribute__((vector_size (32)));
+
+typedef _Float16 vnx8hf __attribute__((vector_size (32)));
+typedef float vnx4sf __attribute__((vector_size (32)));
+
+/* Predicate vector: 1 0 0 0 ... */
+
+#define MASK_32{ 0, 33, 34, 35, 4, 37, 38, 39, 8, 41, 42, 43, 
12,  \
+ 45, 46, 47, 16, 49, 50, 51, 20, 53, 54, 55, 24,   
\
+ 57, 58, 59, 28, 61, 62, 63 } 
+
+/* Predicate vector: 1 0 1 0 ... */
+

[Bug target/91502] suboptimal atomic_fetch_sub and atomic_fetch_add

[nruslan_devel at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91502

--- Comment #1 from Ruslan Nikolaev  ---
btw, the same problem for

#include 

int func(_Atomic(long) *a)
{
return (atomic_fetch_sub(a, 1) <= 0);
}

In the previous case clang/llvm was just like gcc, i.e., unable to optimize; in
this case clang/llvm was able to produce better code, but gcc still cannot.

[Bug rtl-optimization/91503] New: ICE ira-build.i:17:1: error: shared rtx

[skpgkp2 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91503

Bug ID: 91503
   Summary: ICE ira-build.i:17:1: error: shared rtx
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skpgkp2 at gmail dot com
CC: crazylht at gmail dot com, hjl.tools at gmail dot com
  Target Milestone: ---

ICE when compile with gcc option "-O3  -mtune-ctrl=^inter_unit_moves_to_vec
-msse4.1"

$cat ira-build.i
typedef struct a *b;
struct a {
  b c}
;
d
  ;
e( f,  g) {
  int h, i;
  b j;
  i = g + 1;
  for (j = f; j ;
   j = j->c) 
h = e( 1);
if (h > i)
  i = h;
  return i;
}
static k() {
  d = e();
}
l() {
  k();
}


$gcc -S  -O3  -mtune-ctrl="^inter_unit_moves_to_vec"  ira-build.i  -msse4.1 -w
ira-build.i: In function \u2018l\u2019:
ira-build.i:23:1: error: invalid rtl sharing found in the insn
   23 | }
  | ^
(insn 57 56 15 4 (set (subreg:V4SI (reg:SI 96) 0)
(vec_merge:V4SI (vec_duplicate:V4SI (mem/c:SI (plus:DI (reg/f:DI 19
frame)
(const_int -4 [0xfffc])) [0  S4 A32]))
(const_vector:V4SI [
(const_int 0 [0]) repeated x4
])
(const_int 1 [0x1]))) "ira-build.i":13:9 -1
 (nil))
ira-build.i:23:1: error: shared rtx
(mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -4 [0xfffc])) [0  S4 A32])
during RTL pass: stv
ira-build.i:23:1: internal compiler error: internal consistency failure
0xa21114 verify_rtx_sharing
/local/gccwork/gcc_trunk/gcc/gcc/emit-rtl.c:2927
0xa20feb verify_rtx_sharing
/local/gccwork/gcc_trunk/gcc/gcc/emit-rtl.c:2942
0xa20feb verify_rtx_sharing
/local/gccwork/gcc_trunk/gcc/gcc/emit-rtl.c:2942
0xa20feb verify_rtx_sharing
/local/gccwork/gcc_trunk/gcc/gcc/emit-rtl.c:2942
0xa2143f verify_insn_sharing
/local/gccwork/gcc_trunk/gcc/gcc/emit-rtl.c:3013
0xa24d67 verify_rtl_sharing()
/local/gccwork/gcc_trunk/gcc/gcc/emit-rtl.c:3036
0xcb2ae9 execute_function_todo
/local/gccwork/gcc_trunk/gcc/gcc/passes.c:2004
0xcb382e execute_todo
/local/gccwork/gcc_trunk/gcc/gcc/passes.c:2037
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[asolokha at gmx dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91498

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #9 from Arseny Solokha  ---
(In reply to H.J. Lu from comment #7)
> Our SPEC CPU 2017 failed with
> 
>  39 util.c:205:1: error: invalid rtl sharing found in the insn
>  40   205 | }
>  41   | ^
>  42 (insn 29 28 3 2 (set (subreg:V2DI (reg:DI 91) 0)
>  43 (vec_concat:V2DI (mem/c:DI (plus:DI (reg/f:DI 19 frame)
>  44 (const_int -8 [0xfff8])) [0  S8 A64])
>  45 (const_int 0 [0]))) "util.c":134:1 -1
>  46  (nil))
>  47 util.c:205:1: error: shared rtx
>  48 (mem/c:DI (plus:DI (reg/f:DI 19 frame)
>  49 (const_int -8 [0xfff8])) [0  S8 A64])
>  50 during RTL pass: stv
> 
> We have an invalid shared rtx.

And the testcase is as simple as:

int
ff (int jn)
{
  return jn > 0 ? jn : 0;
}

% x86_64-unknown-linux-gnu-gcc-10.0.0-alpha20190818 -march=nano-3000 -Os -c
f9272pqv.c
f9272pqv.c: In function 'ff':
f9272pqv.c:5:1: error: invalid rtl sharing found in the insn
5 | }
  | ^
(insn 18 17 3 2 (set (subreg:V4SI (reg:SI 87) 0)
(vec_merge:V4SI (vec_duplicate:V4SI (mem/c:SI (plus:DI (reg/f:DI 19
frame)
(const_int -4 [0xfffc])) [0  S4 A32]))
(const_vector:V4SI [
(const_int 0 [0]) repeated x4
])
(const_int 1 [0x1]))) "f9272pqv.c":3:1 -1
 (nil))
f9272pqv.c:5:1: error: shared rtx
(mem/c:SI (plus:DI (reg/f:DI 19 frame)
(const_int -4 [0xfffc])) [0  S4 A32])
during RTL pass: stv
f9272pqv.c:5:1: internal compiler error: internal consistency failure
0x9f3eca verify_rtx_sharing
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/emit-rtl.c:2927
0x9f3dba verify_rtx_sharing
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/emit-rtl.c:2942
0x9f3dba verify_rtx_sharing
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/emit-rtl.c:2942
0x9f3dba verify_rtx_sharing
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/emit-rtl.c:2942
0x9f4178 verify_insn_sharing
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/emit-rtl.c:3013
0x9f79ed verify_rtl_sharing()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/emit-rtl.c:3036
0xc7a8f3 execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/passes.c:2004
0xc7b536 execute_todo
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20190818/work/gcc-10-20190818/gcc/passes.c:2037

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497

--- Comment #4 from Steve Kargl  ---
On Tue, Aug 20, 2019 at 03:28:29PM +, kargl at gcc dot gnu.org wrote:
> 
> --- Comment #1 from kargl at gcc dot gnu.org ---
> Unfortunately, -Wconversion has a problem with false positives.
> You can, of course, avoid the problem by not using the option.
> 

This diff will silence warnings for explicit conversion
using REAL() and INT() for the -Wconversion option.  It
does not silence warnings for -Wconversion-extra.

Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c  (revision 274676)
+++ gcc/fortran/simplify.c  (working copy)
@@ -3572,6 +3572,7 @@ static gfc_expr *
 simplify_intconv (gfc_expr *e, int kind, const char *name)
 {
   gfc_expr *result = NULL;
+  int tmp;

   /* Convert BOZ to integer, and return without range checking.  */
   if (e->ts.type == BT_BOZ)
@@ -3585,7 +3586,12 @@ simplify_intconv (gfc_expr *e, int kind, const char *n
   if (e->expr_type != EXPR_CONSTANT)
 return NULL;

+  /* For explicit conversion, turn off -Wconversion warning.  Leave the 
+ warning if -Wconversion-extra is used.  */
+  tmp = warn_conversion;
+  warn_conversion = 0;
   result = gfc_convert_constant (e, BT_INTEGER, kind);
+  warn_conversion = tmp;
   if (result == _bad_expr)
 return _bad_expr;

@@ -6467,7 +6473,7 @@ gfc_expr *
 gfc_simplify_real (gfc_expr *e, gfc_expr *k)
 {
   gfc_expr *result = NULL;
-  int kind;
+  int kind, tmp;

   /* Convert BOZ to real, and return without range checking.  */
   if (e->ts.type == BT_BOZ)
@@ -6495,7 +6501,12 @@ gfc_simplify_real (gfc_expr *e, gfc_expr *k)
   if (e->expr_type != EXPR_CONSTANT)
 return NULL;

+  /* For explicit conversion, turn off -Wconversion warning.  Leave the 
+ warning if -Wconversion-extra is used.  */
+  tmp = warn_conversion;
+  warn_conversion = 0;
   result = gfc_convert_constant (e, BT_REAL, kind);
+  warn_conversion = tmp;
   if (result == _bad_expr)
 return _bad_expr;

[PATCH], Fix V1TI in Altivec regs on old systems

[Michael Meissner]

This is a little corner case that I noticed in my rewrite of the RELOAD_REG
stuff for the future machine.

I was testing what registers were allowed in what registers for various systems
(power5 through power9 for big endian on both 32 & 64-bit systems, and
power8/power9 for little endian systems).  I was using the debug flag
-mdebug=reg which dumps out the reg_addr information (among other things).  I
noticed on power5 that the V1TImode mode is allowed in Altivec registers, even
though power5 doesn't have Altivec registers.

While it doesn't seem to effect anything (I couldn't create a test case that
failed), it is a small nit that should be fixed.  The test for TARGET_VADDUQM
matches a test earlier in the function where VSX registers are checked.

I have done a bootstrap on a little endian power8 and there were no regressions
in the bootstrap or make check.  I also verified via -mdebug=reg that V1TI mode
is marked as being valid in the Altivec registers with -mcpu=power5.  Can I
check this into the trunk?

2019-08-20  Michael Meissner  

* config/rs6000/rs6000.c (rs6000_hard_regno_mode_ok_uncached):
Don't allow V1TImode in Altivec registers on pre-altivec systems.

Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 274635)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -1874,7 +1874,7 @@ rs6000_hard_regno_mode_ok_uncached (int
   /* AltiVec only in AldyVec registers.  */
   if (ALTIVEC_REGNO_P (regno))
 return (VECTOR_MEM_ALTIVEC_OR_VSX_P (mode)
-   || mode == V1TImode);
+   || (TARGET_VADDUQM && mode == V1TImode));
 
   /* We cannot put non-VSX TImode or PTImode anywhere except general register
  and it must be able to fit within the register set.  */


-- 
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

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154

--- Comment #35 from Rainer Orth  ---
Between 20190819 (r274678) and 20190820 (r274749), a new failure was
introduced:

+FAIL: gcc.target/i386/minmax-6.c scan-assembler-not rsp

Seen on both i386-pc-solaris2.11 with -m64 and x86_64-pc-linux-gnu (oldest
report
for r274708).

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91498

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #8 from Rainer Orth  ---
The new testcase FAILs on both i386-pc-solaris2.11 and x86_64-pc-linux-gnu with
-m32:

+FAIL: gcc.target/i386/minmax-7.c scan-assembler pminsd

[Bug lto/91478] FAIL: gcc.dg/debug/pr41893-1.c -gdwarf-2 -g1 (test for excess errors)

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91478

--- Comment #4 from John David Anglin  ---
See PR lto/83452:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83452

Re: [PATCH 1/8] Document signaling for min, max and ltgt operations

[Segher Boessenkool]

On Tue, Aug 20, 2019 at 06:13:00PM +0200, Ilya Leoshkevich wrote:
> > Am 20.08.2019 um 17:50 schrieb Segher Boessenkool 
> > :
> > There is currently no way to say (in trees or gimple or rtl) whether
> > comparisons are signaling ("ordered", generate a trap on an unordered
> > result).  I am working on this, but :-)
> 
> Isn't there?  This whole series is based on the following assumption:
> LT, LE, GT, GE are definitely signaling; LTGT is most likely signaling
> as well; the rest are not signaling.  This is based on gccint 11.6.3:
> Unary and Binary Expressions.

There is currently no way to implement, say, iseqsig.  And whether an
operation is signaling should be determined by the language frontend,
not separately by each backend!

(There should be a signaling and a non-signaling version of every float
comparison that can be unordered).


Segher

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497

--- Comment #3 from Steve Kargl  ---
On Tue, Aug 20, 2019 at 04:12:47PM +, manfred99 at gmx dot ch wrote:
> 
> --- Comment #2 from Manfred Schwarb  ---
> Of course. But not being able to silence such warnings renders
> this option rather useless, IMO.

Yep.  At the top of my Makefile.inc file, which all of my
Makefiles pull in to set defaults, I have

.ifdef EBUG
CFLAGS+= -g -O
FFLAGS+= -g -pipe -O -fmax-errors=1 -Werror -Wall -fcheck=all
FFLAGS+= -ffpe-trap=invalid
.else
CFLAGS = -O2 -pipe -Wall -march=native -mtune=native
FFLAGS += -O2 -pipe -march=native -mtune=native
FFLAGS += -funroll-loops --param max-unroll-times=4
FFLAGS += -ftree-vectorize -Wall
.endif

# gfortran is too noisy
FFLAGS += -Wno-maybe-uninitialized -Wno-conversion -Wno-integer-division

These options produce too many false positives.

> I would have expected that explicit castings would have been
> special-cased in some way... 
> 
> And the manual talks explicitely about implicit conversion:
>  -Wconversion
>Warn about implicit conversions ...

Improvements to the documentation are encouraged.

[Bug c/91502] New: suboptimal atomic_fetch_sub and atomic_fetch_add

[nruslan_devel at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91502

Bug ID: 91502
   Summary: suboptimal atomic_fetch_sub and atomic_fetch_add
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nruslan_devel at yahoo dot com
  Target Milestone: ---

I have not specified the gcc version; it seems like it applies to any version.

I have noticed that if I write code:

#include 

int func(_Atomic(int) *a)
{
return (atomic_fetch_sub(a, 1) - 1 == 0);
}

gcc generates optimized code (gcc -O2):
func:
.LFB0:
.cfi_startproc
xorl%eax, %eax
lock subl   $1, (%rdi)
sete%al
ret

But when I change the condition to <= 0, it does not work. Correct me if I am
wrong, but, I think, it should still be able to use sub:

#include 

int func(_Atomic(int) *a)
{
return (atomic_fetch_sub(a, 1) - 1 <= 0);

}

func:
.LFB0:
.cfi_startproc
movl$-1, %eax
lock xaddl  %eax, (%rdi)
cmpl$1, %eax
setle   %al
movzbl  %al, %eax
ret

Seems like the same problem exists for atomic_fetch_add as well.

[Bug target/90606] Replace mfence with faster xchg for std::memory_order_seq_cst.

[nruslan_devel at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90606

Ruslan Nikolaev  changed:

   What|Removed |Added

 CC||nruslan_devel at yahoo dot com

--- Comment #1 from Ruslan Nikolaev  ---
Yes, mfence is twice as slower on my machine as well. Btw, clang generates xchg
for the same code.

[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|9.2 |9.3

Re: For which gcc release is going to be foreseen the support for the Coroutines TS extension?

[Florian Weimer]

* Richard Biener:

> On August 20, 2019 5:19:33 PM GMT+02:00, Nathan Sidwell  
> wrote:
>>On 7/26/19 6:03 AM, Iain Sandoe wrote:
>>> Hello Sebastian,
>>> 
 On 26 Jul 2019, at 10:19, Florian Weimer  wrote:
>>
 C++ coroutines are stackless.  I don't think any new low-level
>>run-time
 support will be needed.
>>> 
>>> correct, C++20 coroutines and threading mechanisms are orthogonal
>>> facilities; one can use (IS C++20) coroutines on top of a threaded
>>system
>>> or in a single-threaded environment.
>>> 
>>> Two places I see them as being a go-to facility in embedded systems
>>are:
>>>   * co-operative multi-tasking UIs on single-threaded platforms.
>>>   * async I/O completion by continuations, rather than callbacks.
>>
>>There are cases where the overhead of threads is too expensive.  For 
>>instance hiding (cache-missing) load latencies by doing other work
>>while 
>>waiting -- a context switch at that point is far too expensive.
>
> But are coroutines so much lower latency (and a context switch does
> not involve cache misses on its own?). For doing useful work in this
> context CPU designers invented SMT...

I think the idea is that you don't have to worry about synchronizing
multiple threads to reap the benefits from hardware parallelism.  For
hiding memory access latency, that could be important because the
synchronization overhead could easily eat up any potential benefits.

Thanks,
Florian

Re: [PATCH 1/8] Document signaling for min, max and ltgt operations

[Ilya Leoshkevich]

> Am 20.08.2019 um 17:50 schrieb Segher Boessenkool 
> :
> 
> On Tue, Aug 20, 2019 at 11:18:38AM +0200, Ilya Leoshkevich wrote:
>> Currently it's not clear whether or not min, max and ltgt should raise
>> floating point exceptions when dealing with qNaNs.
>> 
>> Right now a lot of code assumes that LTGT is signaling: in particular,
>> it's generated for ((x < y) || (x > y)), which is signaling. The
>> behavior of MIN/MAX is (intentionally?) left unspecified, according to
>> commit 64dd117734d0 ("Unconditionally use MAX_EXPR/MIN_EXPR for MAX/MIN
>> intrinsics").
> 
> Btw, this is not the difference between LTGT and NE, which is exactly
> the same difference as that between LT and UNLT: if NaNs are allowed,
> the first is false for unordered, while the second is true.  If NaNs
> are not allowed, only one of the two is generated.
> 
> (0UNORD)
> LTUNLT
> EQUNEQ
> LEUNLE
> GTUNGT
> LTGT  NE
> GEUNGE
> (ORD  1)

This matches my understanding (modulo signaling). cThis also doesn't
contradict the proposed manual update, right?

> There is currently no way to say (in trees or gimple or rtl) whether
> comparisons are signaling ("ordered", generate a trap on an unordered
> result).  I am working on this, but :-)

Isn't there?  This whole series is based on the following assumption:
LT, LE, GT, GE are definitely signaling; LTGT is most likely signaling
as well; the rest are not signaling.  This is based on gccint 11.6.3:
Unary and Binary Expressions.

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[manfred99 at gmx dot ch]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497

Manfred Schwarb  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org

--- Comment #2 from Manfred Schwarb  ---
Of course. But not being able to silence such warnings renders
this option rather useless, IMO.
I would have expected that explicit castings would have been
special-cased in some way... 

And the manual talks explicitely about implicit conversion:
 -Wconversion
   Warn about implicit conversions ...

Re: Expansion of narrowing math built-ins into power instructions

[Joseph Myers]

On Tue, 20 Aug 2019, Segher Boessenkool wrote:

> plus minus neg mult div mod smin smax abs sqrt fma  I think?  And let's
> hope we never ever have to do saturating versions of FP :-)

There are six operations with narrowing versions in TS 18661-1 (plus minus 
mult div sqrt fma).

neg and abs are operations that do no rounding, raise no exceptions and 
preserve signaling NaNs (affecting their sign bit appropriately).

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

Re: [PATCH V2 2/8] bpf: new GCC port

[Richard Sandiford]

jose.march...@oracle.com (Jose E. Marchesi) writes:
> Hi Richard!
>
> Many thanks for the deep review.  I'm addressing some of your questions
> below.
>
> > [...]
> > +/* Override options and do some other initialization.  */
> > +
> > +static void
> > +bpf_option_override (void)
> > +{
> > +  /* Set the default target kernel if no -mkernel was specified.  */
> > +  if (!global_options_set.x_bpf_kernel)
> > +bpf_kernel = LINUX_LATEST;
> 
> LINUX_LATEST is the default in the .opt file, so when is this needed?
>
> It is an idiom I got from sparc.c:
>
>   /* Set the default CPU if no -mcpu option was specified.  */
>   if (!global_options_set.x_sparc_cpu_and_features)
> {
>   ...
> }
>
> Maybe the code in sparc.c predates the Init() directive in sparc.opt
> file?

Might be wrong, but it looks like the SPARC code is overriding the .opt
default with the configure-time one.  I don't think it's needed when
the default is fixed.

> > [...]
> > +/* Return a RTX indicating whether a function argument is passed in a
> > +   register and if so, which register.  */
> > +
> > +static rtx
> > +bpf_function_arg (cumulative_args_t ca, enum machine_mode mode 
> ATTRIBUTE_UNUSED,
> > +  const_tree type ATTRIBUTE_UNUSED, bool named 
> ATTRIBUTE_UNUSED)
> > +{
> > +  CUMULATIVE_ARGS *cum = get_cumulative_args (ca);
> > +
> > +  if (*cum < 5)
> > +return gen_rtx_REG (mode, *cum + 1);
> > +  else
> > +/* An error have been emitted for this in
> > +   bpf_function_arg_advance.  */
> > +return NULL_RTX;
>
> This hook is called first, so "will be" rather than "has been".
>
> (BTW, I just submitted a series of patches to change this interface,
> but it should be a trivial change for whichever of us gets to make it.)
>
> I see your interface change was approved yesterday, so I will just adapt
> in my next rebase :)

Thanks!

Richard

Re: [PATCH 1/8] Document signaling for min, max and ltgt operations

[Ilya Leoshkevich]

> Am 20.08.2019 um 17:32 schrieb Segher Boessenkool 
> :
> 
> On Tue, Aug 20, 2019 at 05:19:46PM +0200, Ilya Leoshkevich wrote:
>>> Am 20.08.2019 um 17:04 schrieb Segher Boessenkool 
>>> :
>>> The < and > operators separately already can cause exceptions, unless
>>> you use -fno-trapping-math, in which case you cannot have LTGT at all.
>> 
>> Hmm, I've just tried compiling:
>> 
>>int foo(float a, float b) { return ((a < b) || (a > b)); }
>> 
>> with -ftrapping-math and -fno-trapping-math with gcc 8.0.1, and got LTGT
>> on tree and rtl levels in both cases:
>> 
>>232t.optimized: _1 = a_2(D) <> b_3(D);
>>312r.final:(if_then_else:SI (ltgt (reg:CCS 33 %cc)
> 
> Hrm, it seems to need -ffinite-math-only, even?  Or just -ffast-math
> of course.  (That'll teach me to post without testing for another year
> or two, sorry!)

Ah, that's correct, and I have even added s390 tests for this: with
-ffinite-math-only the generated code is more "straightforward".  I
should update the commit message, but this isn't affecting the manual
update itself, right?

Re: [ARM/FDPIC v5 04/21] [ARM] FDPIC: Add support for FDPIC for arm architecture

[Christophe Lyon]

On 16/07/2019 13:58, Richard Sandiford wrote:

Christophe Lyon  writes:

The FDPIC register is hard-coded to r9, as defined in the ABI.

We have to disable tailcall optimizations if we don't know if the
target function is in the same module. If not, we have to set r9 to
the value associated with the target module.

When generating a symbol address, we have to take into account whether
it is a pointer to data or to a function, because different
relocations are needed.

2019-XX-XX  Christophe Lyon  
Mickaël Guêné 

* config/arm/arm-c.c (__FDPIC__): Define new pre-processor macro
in FDPIC mode.
* config/arm/arm-protos.h (arm_load_function_descriptor): Declare
new function.
* config/arm/arm.c (arm_option_override): Define pic register to
FDPIC_REGNUM.
(arm_function_ok_for_sibcall): Disable sibcall optimization if we
have no decl or go through PLT.
(arm_load_pic_register): Handle TARGET_FDPIC.
(arm_is_segment_info_known): New function.
(arm_pic_static_addr): Add support for FDPIC.
(arm_load_function_descriptor): New function.
(arm_assemble_integer): Add support for FDPIC.
* config/arm/arm.h (PIC_OFFSET_TABLE_REG_CALL_CLOBBERED):
Define. (FDPIC_REGNUM): New define.
* config/arm/arm.md (call): Add support for FDPIC.
(call_value): Likewise.
(*restore_pic_register_after_call): New pattern.
(untyped_call): Disable if FDPIC.
(untyped_return): Likewise.
* config/arm/unspecs.md (UNSPEC_PIC_RESTORE): New.

Change-Id: I8fb1a6b85ace672184013568c5d28fbda2f7fda4

diff --git a/gcc/config/arm/arm-c.c b/gcc/config/arm/arm-c.c
index 6e256ee..34695fa 100644
--- a/gcc/config/arm/arm-c.c
+++ b/gcc/config/arm/arm-c.c
@@ -203,6 +203,8 @@ arm_cpu_builtins (struct cpp_reader* pfile)
builtin_define ("__ARM_EABI__");
  }
  
+  def_or_undef_macro (pfile, "__FDPIC__", TARGET_FDPIC);

+
def_or_undef_macro (pfile, "__ARM_ARCH_EXT_IDIV__", TARGET_IDIV);
def_or_undef_macro (pfile, "__ARM_FEATURE_IDIV", TARGET_IDIV);
  
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h

index 485bc68..272968a 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -139,6 +139,7 @@ extern int arm_max_const_double_inline_cost (void);
  extern int arm_const_double_inline_cost (rtx);
  extern bool arm_const_double_by_parts (rtx);
  extern bool arm_const_double_by_immediates (rtx);
+extern rtx arm_load_function_descriptor (rtx funcdesc);
  extern void arm_emit_call_insn (rtx, rtx, bool);
  bool detect_cmse_nonsecure_call (tree);
  extern const char *output_call (rtx *);
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 45abcd8..d9397b5 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -3485,6 +3485,15 @@ arm_option_override (void)
if (flag_pic && TARGET_VXWORKS_RTP)
  arm_pic_register = 9;
  
+  /* If in FDPIC mode then force arm_pic_register to be r9.  */

+  if (TARGET_FDPIC)
+{
+  arm_pic_register = FDPIC_REGNUM;
+  if (! TARGET_ARM && ! TARGET_THUMB2)
+   sorry ("FDPIC mode is supported on architecture versions that "
+  "support ARM or Thumb-2 only.");
+}
+
if (arm_pic_register_string != NULL)
  {
int pic_register = decode_reg_name (arm_pic_register_string);


Isn't this equivalent to rejecting Thumb-1?  I think that would be
clearer in both the condition and the error message.

How does this interact with arm_pic_data_is_text_relative?  Are both
values supported?


@@ -7295,6 +7304,21 @@ arm_function_ok_for_sibcall (tree decl, tree exp)
if (cfun->machine->sibcall_blocked)
  return false;
  
+  if (TARGET_FDPIC)

+{
+  /* In FDPIC, never tailcall something for which we have no decl:
+the target function could be in a different module, requiring
+a different FDPIC register value.  */
+  if (decl == NULL)
+   return false;
+
+  /* Don't tailcall if we go through the PLT since the FDPIC
+register is then corrupted and we don't restore it after
+static function calls.  */
+  if (!targetm.binds_local_p (decl))
+   return false;
+}
+
/* Never tailcall something if we are generating code for Thumb-1.  */
if (TARGET_THUMB1)
  return false;
@@ -7711,7 +7735,9 @@ arm_load_pic_register (unsigned long saved_regs 
ATTRIBUTE_UNUSED, rtx pic_reg)
  {
rtx l1, labelno, pic_tmp, pic_rtx;
  
-  if (crtl->uses_pic_offset_table == 0 || TARGET_SINGLE_PIC_BASE)

+  if (crtl->uses_pic_offset_table == 0
+  || TARGET_SINGLE_PIC_BASE
+  || TARGET_FDPIC)
  return;
  
gcc_assert (flag_pic);

@@ -7780,28 +7806,142 @@ arm_load_pic_register (unsigned long saved_regs 
ATTRIBUTE_UNUSED, rtx pic_reg)
emit_use (pic_reg);
  }
  
+/* Try to determine whether an object, referenced via ORIG, will be

+   placed in the text or data segment.  This is used in FDPIC mode, to
+   

Re: For which gcc release is going to be foreseen the support for the Coroutines TS extension?

[Richard Biener]

On August 20, 2019 5:19:33 PM GMT+02:00, Nathan Sidwell  wrote:
>On 7/26/19 6:03 AM, Iain Sandoe wrote:
>> Hello Sebastian,
>> 
>>> On 26 Jul 2019, at 10:19, Florian Weimer  wrote:
>
>>> C++ coroutines are stackless.  I don't think any new low-level
>run-time
>>> support will be needed.
>> 
>> correct, C++20 coroutines and threading mechanisms are orthogonal
>> facilities; one can use (IS C++20) coroutines on top of a threaded
>system
>> or in a single-threaded environment.
>> 
>> Two places I see them as being a go-to facility in embedded systems
>are:
>>   * co-operative multi-tasking UIs on single-threaded platforms.
>>   * async I/O completion by continuations, rather than callbacks.
>
>There are cases where the overhead of threads is too expensive.  For 
>instance hiding (cache-missing) load latencies by doing other work
>while 
>waiting -- a context switch at that point is far too expensive.

But are coroutines so much lower latency (and a context switch does not involve 
cache misses on its own?). For doing useful work in this context CPU designers 
invented SMT... 

Richard. 

>nathan

Re: [PATCH 1/8] Document signaling for min, max and ltgt operations

[Segher Boessenkool]

On Tue, Aug 20, 2019 at 11:18:38AM +0200, Ilya Leoshkevich wrote:
> Currently it's not clear whether or not min, max and ltgt should raise
> floating point exceptions when dealing with qNaNs.
> 
> Right now a lot of code assumes that LTGT is signaling: in particular,
> it's generated for ((x < y) || (x > y)), which is signaling. The
> behavior of MIN/MAX is (intentionally?) left unspecified, according to
> commit 64dd117734d0 ("Unconditionally use MAX_EXPR/MIN_EXPR for MAX/MIN
> intrinsics").

Btw, this is not the difference between LTGT and NE, which is exactly
the same difference as that between LT and UNLT: if NaNs are allowed,
the first is false for unordered, while the second is true.  If NaNs
are not allowed, only one of the two is generated.

(0UNORD)
LTUNLT
EQUNEQ
LEUNLE
GTUNGT
LTGT  NE
GEUNGE
(ORD  1)

There is currently no way to say (in trees or gimple or rtl) whether
comparisons are signaling ("ordered", generate a trap on an unordered
result).  I am working on this, but :-)


Segher

[Bug libstdc++/91480] Nonconforming definitions of standard library feature-test macros

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91480

--- Comment #3 from Jonathan Wakely  ---
(In reply to frankhb1989 from comment #0)
> Also, in , `__cpp_lib_allocator_traits_is_always_equal` is
> wrongly spelled as `__cpp_lib_allocator_is_always_equal`.

This is incorrect. We *also* define __cpp_lib_allocator_traits_is_always_equal,
in the appropriate places. So we have an extra, non-standard macro. We don't
spell the standard one wrong.

The allocator_is_always_equal spelling was present in
http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4440.html#recs.cpp17 and
in
http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0096r0.html#detail.cpp17
but gone in
http://open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0096r1.html#recs.cpp17

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91498

--- Comment #7 from H.J. Lu  ---
Our SPEC CPU 2017 failed with

 39 util.c:205:1: error: invalid rtl sharing found in the insn
 40   205 | }
 41   | ^
 42 (insn 29 28 3 2 (set (subreg:V2DI (reg:DI 91) 0)
 43 (vec_concat:V2DI (mem/c:DI (plus:DI (reg/f:DI 19 frame)
 44 (const_int -8 [0xfff8])) [0  S8 A64])
 45 (const_int 0 [0]))) "util.c":134:1 -1
 46  (nil))
 47 util.c:205:1: error: shared rtx
 48 (mem/c:DI (plus:DI (reg/f:DI 19 frame)
 49 (const_int -8 [0xfff8])) [0  S8 A64])
 50 during RTL pass: stv

We have an invalid shared rtx.

Re: Fwd: [PATCHv5] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)

[Bernd Edlinger]

Ah, yes that was unexpected...
Sorry for the breakage.

So this needs to be known_eq (STACK_POINTER_OFFSET, 0)
instead of STACK_POINTER_OFFSET == 0 obviously.

Should be fixed by this patch, which I am going to commit
as "obvious" in a moment unless someone objects.


Thanks
Bernd.


On 8/20/19 4:39 PM, John David Anglin wrote:
> On 2019-08-15 3:47 p.m., Bernd Edlinger wrote:
>> 2019-08-15  Bernd Edlinger  
>>
>>  PR middle-end/89544
>>  * function.c (assign_parm_find_stack_rtl): Use larger alignment
>>  when possible.
> This patch breaks build on hppa-unknown-linux-gnu:
> https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot=hppa=1%3A20190820-1=1566307455=0
> 
> hppa-linux-gnu-g++-9 -std=gnu++98 -fno-PIE -c   -g -DIN_GCC 
> -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall 
> -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
> -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
> -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. 
> -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include 
> -I../../src/gcc/../libcpp/include  -I../../src/gcc/../libdecnumber 
> -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I../../src/gcc/../libbacktrace   -o function.o -MT function.o -MMD -MP -MF 
> ./.deps/function.TPo ../../src/gcc/function.c
> hppa-linux-gnu-g++-9 -std=gnu++98 -fno-PIE -c   -g -DIN_GCC 
> -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall 
> -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
> -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
> -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. 
> -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include 
> -I../../src/gcc/../libcpp/include  -I../../src/gcc/../libdecnumber 
> -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I../../src/gcc/../libbacktrace   -o function-tests.o -MT function-tests.o 
> -MMD -MP -MF ./.deps/function-tests.TPo ../../src/gcc/function-tests.c
> hppa-linux-gnu-g++-9 -std=gnu++98 -fno-PIE -c   -g -DIN_GCC 
> -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall 
> -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format 
> -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long 
> -Wno-variadic-macros -Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. 
> -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include 
> -I../../src/gcc/../libcpp/include  -I../../src/gcc/../libdecnumber 
> -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I../../src/gcc/../libbacktrace   -o fwprop.o -MT fwprop.o -MMD -MP -MF 
> ./.deps/fwprop.TPo ../../src/gcc/fwprop.c
> ../../src/gcc/function.c: In function 'void assign_parm_find_stack_rtl(tree, 
> assign_parm_data_one*)':
> ../../src/gcc/function.c:2690:28: error: no match for 'operator==' (operand 
> types are 'poly_int<1, long long int>' and 'int')
>  2690 |&& STACK_POINTER_OFFSET == 0)
>   |^~ ~
>   |   |
>   |   int
> In file included from ../../src/gcc/coretypes.h:415,
>  from ../../src/gcc/function.c:36:
> ../../src/gcc/wide-int.h:3287:19: note: candidate: 'template T2> typename wi::binary_traits::predicate_result operator==(const 
> T1&, const T2&)'
>  3287 | BINARY_PREDICATE (operator ==, eq_p)
>   |   ^~~~
> ../../src/gcc/wide-int.h:3264:3: note: in definition of macro 
> 'BINARY_PREDICATE'
>  3264 |   OP (const T1 , const T2 ) \
>   |   ^~
> ../../src/gcc/wide-int.h:3287:19: note:   template argument 
> deduction/substitution failed:
>  3287 | BINARY_PREDICATE (operator ==, eq_p)
>   |   ^~~~
> ../../src/gcc/wide-int.h:3264:3: note: in definition of macro 
> 'BINARY_PREDICATE'
>  3264 |   OP (const T1 , const T2 ) \
>   |   ^~
> ../../src/gcc/wide-int.h: In substitution of 'template 
> typename wi::binary_traits::predicate_result operator==(const T1&, 
> const T2&) [with T1 = poly_int<1, long long int>; T2 = int]':
> ../../src/gcc/function.c:2690:31:   required from here
> ../../src/gcc/wide-int.h:3287:19: error: incomplete type 
> 'wi::int_traits >' used in nested name specifier
>  3287 | BINARY_PREDICATE (operator ==, eq_p)
>   |   ^~~~
> ../../src/gcc/wide-int.h:3264:3: note: in definition of macro 
> 'BINARY_PREDICATE'
>  3264 |   OP (const T1 , const T2 ) \
>   |   ^~
> make[5]: *** [Makefile:1118: function.o] Error 1
> make[5]: *** Waiting for unfinished jobs
> 
> We have the following define for STACK_POINTER_OFFSET:
> 
> #define STACK_POINTER_OFFSET \
>   (TARGET_64BIT ? -(crtl->outgoing_args_size + 48) : poly_int64 (-32))
>  
> Dave
> 
2019-08-20  Bernd Edlinger  

	* function.c (assign_parm_find_stack_rtl): Use known_eq instead of ==.

Index: gcc/function.c
===
--- 

Re: [PATCH 1/8] Document signaling for min, max and ltgt operations

[Segher Boessenkool]

On Tue, Aug 20, 2019 at 05:19:46PM +0200, Ilya Leoshkevich wrote:
> > Am 20.08.2019 um 17:04 schrieb Segher Boessenkool 
> > :
> > The < and > operators separately already can cause exceptions, unless
> > you use -fno-trapping-math, in which case you cannot have LTGT at all.
> 
> Hmm, I've just tried compiling:
> 
> int foo(float a, float b) { return ((a < b) || (a > b)); }
> 
> with -ftrapping-math and -fno-trapping-math with gcc 8.0.1, and got LTGT
> on tree and rtl levels in both cases:
> 
> 232t.optimized: _1 = a_2(D) <> b_3(D);
> 312r.final:(if_then_else:SI (ltgt (reg:CCS 33 %cc)

Hrm, it seems to need -ffinite-math-only, even?  Or just -ffast-math
of course.  (That'll teach me to post without testing for another year
or two, sorry!)


Segher

[Bug fortran/91497] -Wconversion warns when doing explicit type conversion

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91497

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P5
 CC||kargl at gcc dot gnu.org
   Severity|normal  |enhancement

--- Comment #1 from kargl at gcc dot gnu.org ---
Unfortunately, -Wconversion has a problem with false positives.
You can, of course, avoid the problem by not using the option.

[Bug pch/90306] ICE when using precompiled headers with -MD and -fpch-deps

[gcc at scarsita dot it]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90306

Luca Bonissi  changed:

   What|Removed |Added

 CC||gcc at scarsita dot it

--- Comment #4 from Luca Bonissi  ---
Similar behavior when compiling openjdk 1.8 with gcc 9.1 or 9.2 (tried on
x86_64, armv5te, armv7hl, aarch64):

CACHE_COMPRESS=1  CCACHE_SLOPPINESS=time_macros /usr/bin/ccache /usr/bin/g++
-DLINUX -D_GNU_SOURCE -DAMD64 -DPRODUCT -I. -I/root/tmp/jdk-build
/openjdk-boot/hotspot/src/share/vm/prims
-I/root/tmp/jdk-build/openjdk-boot/hotspot/src/share/vm
-I/root/tmp/jdk-build/openjdk-boot/hotspot/sr
c/share/vm/precompiled
-I/root/tmp/jdk-build/openjdk-boot/hotspot/src/cpu/x86/vm
-I/root/tmp/jdk-build/openjdk-boot/hotspot/src/os_cpu/linux_x
86/vm -I/root/tmp/jdk-build/openjdk-boot/hotspot/src/os/linux/vm
-I/root/tmp/jdk-build/openjdk-boot/hotspot/src/os/posix/vm -I../generated -DH
OTSPOT_RELEASE_VERSION="\"25.222-b10\"" -DHOTSPOT_BUILD_TARGET="\"product\""
-DHOTSPOT_BUILD_USER="\"root\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHO
TSPOT_VM_DISTRO="\"OpenJDK\"" -DDERIVATIVE_ID="\"IcedTea 3.13.0\""
-DDISTRIBUTION_ID="\"Custom build (Tue Aug 20 15:45:08 CEST 2019)\""  -DTAR
GET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64
-DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPI
LER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT
-fcheck-new -fvisibility=hidden -m64  -pipe -fno-strict-aliasing
 -g -fno-omit-frame-pointer -O3  -DVM_LITTLE_ENDIAN -D_LP64=1  -Wpointer-arith
-Wsign-compare -Wundef -Wunused-function -Wunused-value -Wretur
n-type   -fstack-protector -g -O2 -fno-delete-null-pointer-checks
-fno-lifetime-dse -std=gnu++98  -c -MMD -MP -MF ../generated/dependencies/ac
cessFlags.o.d -fpch-deps -o accessFlags.o
/root/tmp/jdk-build/openjdk-boot/hotspot/src/share/vm/utilities/accessFlags.cpp
/root/tmp/jdk-build/openjdk-boot/hotspot/src/share/vm/precompiled/precompiled.hpp:1:
internal compiler error: Segmentation fault
1 | /*
  |
0xb83cef crash_signal
../../gcc-9.2.0/gcc/toplev.c:326
0x13c23fd apply_vpath
../../gcc-9.2.0/libcpp/mkdeps.c:127
0x13c285d deps_add_dep(deps*, char const*)
../../gcc-9.2.0/libcpp/mkdeps.c:258
0x13c2e8d deps_restore(deps*, _IO_FILE*, char const*)
../../gcc-9.2.0/libcpp/mkdeps.c:432
0x13c3f3c cpp_read_state(cpp_reader*, char const*, _IO_FILE*, save_macro_data*)
../../gcc-9.2.0/libcpp/pch.c:859
0x78eacb c_common_read_pch(cpp_reader*, char const*, int, char const*)
../../gcc-9.2.0/gcc/c-family/c-pch.c:365
0x13b469f should_stack_file
../../gcc-9.2.0/libcpp/files.c:814
0x13b469f _cpp_stack_file
../../gcc-9.2.0/libcpp/files.c:900
0x13abc4b do_include_common
../../gcc-9.2.0/libcpp/directives.c:846
0x13ac760 _cpp_handle_directive
../../gcc-9.2.0/libcpp/directives.c:541
0x13bae54 _cpp_lex_token
../../gcc-9.2.0/libcpp/lex.c:2609
0x13c1c37 cpp_get_token_1
../../gcc-9.2.0/libcpp/macro.c:2703
0x787c7e c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc-9.2.0/gcc/c-family/c-lex.c:405
0x69ba3e cp_lexer_get_preprocessor_token
../../gcc-9.2.0/gcc/cp/parser.c:790
0x6d3437 cp_parser_initial_pragma
../../gcc-9.2.0/gcc/cp/parser.c:40747
0x6d3437 cp_lexer_new_main
../../gcc-9.2.0/gcc/cp/parser.c:644
0x6d3437 cp_parser_new
../../gcc-9.2.0/gcc/cp/parser.c:3936
0x6d3437 c_parse_file()
../../gcc-9.2.0/gcc/cp/parser.c:41188
0x78e1db c_common_parse_file()
../../gcc-9.2.0/gcc/c-family/c-opts.c:1160

Always reproducible with ccache >= 3.3.2; all works fine with ccache <= 3.2.9
or without ccache.

Re: [PATCH 1/8] Document signaling for min, max and ltgt operations

[Ilya Leoshkevich]

> Am 20.08.2019 um 17:04 schrieb Segher Boessenkool 
> :
> 
> On Tue, Aug 20, 2019 at 11:18:38AM +0200, Ilya Leoshkevich wrote:
>> Currently it's not clear whether or not min, max and ltgt should raise
>> floating point exceptions when dealing with qNaNs.
>> 
>> Right now a lot of code assumes that LTGT is signaling: in particular,
>> it's generated for ((x < y) || (x > y)), which is signaling. The
>> behavior of MIN/MAX is (intentionally?) left unspecified, according to
>> commit 64dd117734d0 ("Unconditionally use MAX_EXPR/MIN_EXPR for MAX/MIN
>> intrinsics").
> 
> The < and > operators separately already can cause exceptions, unless
> you use -fno-trapping-math, in which case you cannot have LTGT at all.

Hmm, I've just tried compiling:

int foo(float a, float b) { return ((a < b) || (a > b)); }

with -ftrapping-math and -fno-trapping-math with gcc 8.0.1, and got LTGT
on tree and rtl levels in both cases:

232t.optimized: _1 = a_2(D) <> b_3(D);
312r.final:(if_then_else:SI (ltgt (reg:CCS 33 %cc)

Re: For which gcc release is going to be foreseen the support for the Coroutines TS extension?

[Nathan Sidwell]

On 7/26/19 6:03 AM, Iain Sandoe wrote:

Hello Sebastian,


On 26 Jul 2019, at 10:19, Florian Weimer  wrote:



C++ coroutines are stackless.  I don't think any new low-level run-time
support will be needed.


correct, C++20 coroutines and threading mechanisms are orthogonal
facilities; one can use (IS C++20) coroutines on top of a threaded system
or in a single-threaded environment.

Two places I see them as being a go-to facility in embedded systems are:
  * co-operative multi-tasking UIs on single-threaded platforms.
  * async I/O completion by continuations, rather than callbacks.


There are cases where the overhead of threads is too expensive.  For 
instance hiding (cache-missing) load latencies by doing other work while 
waiting -- a context switch at that point is far too expensive.


nathan

--
Nathan Sidwell

[Bug c++/89179] compiler error: in ggc_set_mark, at ggc-page.c:1532

[sje at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89179

--- Comment #17 from Steve Ellcey  ---
The bug I was seeing on aarch64 turns out to be PR 91404.  It has now been
fixed.  I don't know if that patch will also fix the original bug seen on
Darwin or not.

[Bug target/91498] [10 Regression] STV change in r274481 causes 300.twolf regression on Haswell

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91498

--- Comment #6 from H.J. Lu  ---
(In reply to Uroš Bizjak from comment #5)
> (In reply to Uroš Bizjak from comment #4)
> > Following patch
> 
> HJ, can you please put the patch through some benchmarks? (I have no access
> to SPEC).

Sure. We will measure it.  Thanks.

Re: [PATCH V2 2/8] bpf: new GCC port

[Segher Boessenkool]

On Tue, Aug 20, 2019 at 04:20:03PM +0200, Jose E. Marchesi wrote:
> > +  (PLUS ADDR_BASE CONST_INT)
> > +  (PLUS CONST_INT ADDR_BASE)
> 
> The second one isn't canonical rtl, so you shouldn't (need to) handle it.
> Please raise a bug if you find a case where it's being generated. :-)
> 
> Oooh, didn't know that, that's actually very handy :)
> 
> Do you know if this is documented anywhere?  I don't recall seeing this
> in the internals manual, but maybe I missed it.

@node Insn Canonicalizations
...
@itemize @bullet
@item
For commutative and comparison operators, a constant is always made the
second operand.  If a machine only supports a constant as the second
operand, only patterns that match a constant in the second operand need
be supplied.

The whole section is worth reading :-)


Segher

Re: Expansion of narrowing math built-ins into power instructions

[Richard Sandiford]

Richard Sandiford  writes:
>> And yes, it is icky.  But it is sound, as far as I can see.
>
> I really disagree that it's sound, but no point me saying why again :-)
>
> (It could certainly be made to work with sufficient hacks of course,
> like pretty much anything could, but I don't think that's the same thing.)

For an example, we have:

  /* Maybe simplify x + 0 to x.  The two expressions are equivalent
 when x is NaN, infinite, or finite and nonzero.  They aren't
 when x is -0 and the rounding mode is not towards -infinity,
 since (-0) + 0 is then 0.  */
  if (!HONOR_SIGNED_ZEROS (mode) && trueop1 == CONST0_RTX (mode))
return op0;

I think it's plausible that people will care about accurate rounding
but not signed zeroes.  In that mode we could have:

(set (reg:DF r3) (plus:DF (reg:DF r1) (reg:DF r2)))
(set (reg:DF r4) (const_double:DF 0.0))
(set (reg:SF r5) (float_narrow:SF (plus:DF (reg:DF r3) (reg:DF r4

Then combine through normal structural simplification could (with the
rule above) fold all this down to:

(set (reg:SF r5) (float_narrow:SF (plus:DF (reg:DF r1) (reg:DF r2

where the truncation is now fused with r1+r2 instead of r3+r4.  We would
have to have to add specific checks to avoid this happening, it wouldn't
fall out naturally from structural PoV.

Thanks,
Richard

[Bug c++/91493] g++ 9.2.1 crashes compiling clickhouse

[rafaeldtinoco at ubuntu dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91493

--- Comment #2 from Rafael David Tinoco  ---
Related:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91500

Possibly a duplicate.

Re: [PATCH 1/8] Document signaling for min, max and ltgt operations

[Segher Boessenkool]

On Tue, Aug 20, 2019 at 11:18:38AM +0200, Ilya Leoshkevich wrote:
> Currently it's not clear whether or not min, max and ltgt should raise
> floating point exceptions when dealing with qNaNs.
> 
> Right now a lot of code assumes that LTGT is signaling: in particular,
> it's generated for ((x < y) || (x > y)), which is signaling. The
> behavior of MIN/MAX is (intentionally?) left unspecified, according to
> commit 64dd117734d0 ("Unconditionally use MAX_EXPR/MIN_EXPR for MAX/MIN
> intrinsics").

The < and > operators separately already can cause exceptions, unless
you use -fno-trapping-math, in which case you cannot have LTGT at all.


Segher

[Bug tree-optimization/21485] [7/8/9/10 Regression] missed load PRE, PRE makes i?87/8/9/10 suck

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485

--- Comment #67 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #49)
> PR 37242 is also needed from what I remember reading the IR.

That's fixed now.

Re: [PATCH V2 2/8] bpf: new GCC port

[Jose E. Marchesi]

> > +/*** Order of Allocation of Registers.  */
> > +
> > +/* We generally want to put call-clobbered registers ahead of
> > +   call-saved ones.  (IRA expects this.)  */
> > +#define REG_ALLOC_ORDER\
> > +  {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}
> 
> Do you gain much by defining this?  I would have expected better
> code without, given the architecture is so regular.

It does exactly the same as not defining REG_ALLOC_ORDER, just a tiny
bit less efficient.

Yeah I just removed the definition from the port.

[Bug libgomp/91473] Test case libgomp.fortran/appendix-a/a.28.5.f90 is invalid

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91473

--- Comment #8 from seurer at gcc dot gnu.org ---
So for 481.wrf in cpu2006 add this to the config:

FPORTABILITY = -std=legacy

Add the same for 178.galgel, 187.facerec, and 191.fma3d in cpu2000.

For 200.sixtrack and 301.apsi in cpu2000 for some reason I had to use

PORTABILITY = -std=legacy

Re: [PATCH V2 2/8] bpf: new GCC port

[Jose E. Marchesi]

> [...]
> +;; Division
> +(define_insn "div3"
> +  [(set (match_operand:AM 0 "register_operand" "=r,r")
> +(div:AM (match_operand:AM 1 "register_operand" " 0,0")
> +(match_operand:AM 2 "reg_or_imm_operand" "r,I")))]
> +  ""
> +  "div\t%0,%2"
> +  [(set_attr "type" "")])
> +
> +(define_insn "udiv3"
> +  [(set (match_operand:AM 0 "register_operand" "=r,r")
> +(div:AM (match_operand:AM 1 "register_operand" " 0,0")
> +(match_operand:AM 2 "reg_or_imm_operand" "r,I")))]
> +  ""
> +  "div\t%0,%2"
> +  [(set_attr "type" "")])

div and udiv are two different operations.  I don't see how we can
use the same eBPF instruction for both.  The rtl for udiv should also
use the udiv rtx code.

> +;;; Modulus
> +(define_insn "mod3"
> +  [(set (match_operand:AM 0 "register_operand" "=r,r")
> +(mod:AM (match_operand:AM 1 "register_operand" " 0,0")
> +(match_operand:AM 2 "reg_or_imm_operand" "r,I")))]
> +  ""
> +  "mod\t%0,%2"
> +  [(set_attr "type" "")])
> +
> +(define_insn "umod3"
> +  [(set (match_operand:AM 0 "register_operand" "=r,r")
> +(mod:AM (match_operand:AM 1 "register_operand" " 0,0")
> +(match_operand:AM 2 "reg_or_imm_operand" "r,I")))]
> +  ""
> +  "mod\t%0,%2"
> +  [(set_attr "type" "")])

Same here, with umod for the rtx code.

Oh dear the signed division...  during development I just made both
signed and unsigned flavors to use the same instructions, then forgot to
change it.

Why did I do that?  Because eBPF does not provide instructions for doing
_signed_ division, nor signed remainder: both `div' and `mod' perform
unsigned arithmetic.

clang/llvm ICEs whenever it finds signed division in a C program:

   $ clang -target bpf foo.c
   Error: Unsupport signed division for DAG: t17: i64 = sdiv t15, t16Please 
convert to unsigned div/mod.
   fatal error: error in backend: Cannot select: t17: i64 = sdiv t15, t16

For GCC I much prefer for the compiler to generate funcalls instead, to
__divdi3/__divsi3/__moddi3/__modsi3 or the like, even if nothing is
providing implementations for these functions (yet.)

So I just defined the u{div,mod}MODE3 patterns in bpf.md (yes this time
using the right rtl opcode :P) and removed the insns for signed
operations.

Thanks for noticing this!

Re: Expansion of narrowing math built-ins into power instructions

[Richard Sandiford]

Segher Boessenkool  writes:
> On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote:
>> Segher Boessenkool  writes:
>> >>   [(set (match_operand:SI 0 "register_operand" "=d")
>> >> (truncate:SI
>> >>  (lshiftrt:DI
>> >
>> > (this is optimised to a subreg, in many cases, for example).
>> 
>> Right.  MIPS avoids that one thanks to TARGET_TRULY_NOOP_TRUNCATION.
>
> Trying 10 -> 18:
>10: r200:TI=zero_extend(r204:DI)*zero_extend(r205:DI)
>   REG_DEAD r205:DI
>   REG_DEAD r204:DI
>18: $2:DI=r200:TI#0
>   REG_DEAD r200:TI
> Failed to match this instruction:
> (set (reg/i:DI 2 $2)
> (subreg:DI (mult:TI (zero_extend:TI (reg:DI 204))
> (zero_extend:TI (reg:DI 205))) 0))
>
> I'm afraid not.

That's TI->DI though, whereas the pattern above is DI->SI.  The modes
matter :-)  There'd also need to be a shift to match a highpart pattern.

>> >> float_narrow is different in that the plus (or whatever operation
>> >> it's quoting) has to be kept in-place rather than folded away,
>> >> otherwise the rtx itself is malformed and could trigger an ICE,
>> >> just like the zero_extend of a const_int that I mentioned.
>> >
>> > Yes, it will not pass recog.  Structurally it is just hunky-dory though.
>> 
>> So maybe that's the main point of difference.  We're introducing
>> float_narrow to modify another rtx operation rather than to operate
>> on an rtx value.
>
> I wouldn't say it "operates" on anything.  A float_narrow rtx means the
> thing inside it does single-rounding to SP float.  And it is just
> notation: RTL itself knows *nothing* about float rounding, and because
> of the way this is structured, nothing can change anything about the
> float_narrow.

I wouldn't say it knows nothing about rounding.  It doesn't know
what the runtime rounding mode is, but that isn't the same thing.
(Just like not knowing what (mem:SI (sp)) contains isn't the same
thing as not knowing anything about stack memory.)

Besides, how much depends on target-independent code not knowing what
the rounding mode is?  Do you think float_narrow would still make
sense even if more information was available at compile time
(e.g. if a plus could be annotated with a specific rounding mode)?
Or is not knowing the rounding mode a fundamental part of float_narrow
being OK for you?

> And yes, it is icky.  But it is sound, as far as I can see.

I really disagree that it's sound, but no point me saying why again :-)

(It could certainly be made to work with sufficient hacks of course,
like pretty much anything could, but I don't think that's the same thing.)

Thanks,
Richard

Re: [PATCH V2 2/8] bpf: new GCC port

[Segher Boessenkool]

On Mon, Aug 19, 2019 at 08:57:22PM +0100, Richard Sandiford wrote:
> > +/*** Order of Allocation of Registers.  */
> > +
> > +/* We generally want to put call-clobbered registers ahead of
> > +   call-saved ones.  (IRA expects this.)  */
> > +#define REG_ALLOC_ORDER\
> > +  {0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11}
> 
> Do you gain much by defining this?  I would have expected better
> code without, given the architecture is so regular.

It does exactly the same as not defining REG_ALLOC_ORDER, just a tiny
bit less efficient.

> > +#define REG_CLASS_CONTENTS \
> > +{  \
> > +   0x, /* NO_REGS */   \
> > +   0x07ff, /* GR_REGS */   \
> > +   0x07ff, /* ALL_REGS */  \
> > +}
> > +
> > +/* A C expression whose value is a register class containing hard
> > +   register REGNO.  In general there is more that one such class;
> > +   choose a class which is "minimal", meaning that no smaller class
> > +   also contains the register.  */
> > +#define REGNO_REG_CLASS(REGNO) ((REGNO) < 11 ? GR_REGS : ALL_REGS)
> 
> Did you mean to include register 11 in ALL_REGS in REG_CLASS_CONTENTS?
> If not, then there doesn't seem to be any distinction between ALL_REGS
> and GR_REGS, and it'd be better to make one the alias of the other
> (and make REGNO_REG_CLASS return NO_REGS for 11).

ALL_REGS is required to contain all (hard) registers, too.  I wonder what
will go wrong this way...  Well nothing too obvious, apparently!  :-)

> > +(define_insn "*mulsi3_extended"
> > +  [(set (match_operand:DI 0 "register_operand" "=r,r")
> > +(sign_extend:DI
> > + (mult:SI (match_operand:SI 1 "register_operand" "0,0")
> > +  (match_operand:SI 2 "reg_or_imm_operand" "r,I"]
> > +  ""
> > +  "mul32\t%0,%2"
> > +  [(set_attr "type" "alu32")])
> 
> There's a named pattern for this: mulsidi3.  You might get better
> code by using that name instead.

mulsidi3 is something else (it extends the operands before the mult).

> > +(define_expand "extendsidi2"
> > +  [(set (match_operand:DI 0 "register_operand" "=r")
> > +   (sign_extend:DI (match_operand:SI 1 "register_operand" "r")))]
> 
> define_expands shouldn't have constraints.  (Same for the rest of the file.)
> 
> > [...]
> > +(define_expand "mov"
> > +  [(set (match_operand:AMM 0 "general_operand" "")
> > +(match_operand:AMM 1 "general_operand" ""))]

Not empty constraints, either...  That is, you do not need to write them,
and internally it will be the same thing.


Segher

[Bug c++/91501] New: Stack Optimization bug on function and lambda return

[baptiste.cartier at ertosgener dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91501

Bug ID: 91501
   Summary: Stack Optimization bug on function and lambda return
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baptiste.cartier at ertosgener dot com
  Target Milestone: ---

Created attachment 46735
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46735=edit
Preprocessed test file

When calling a function or a lambda to create function arguments, the stack is
not reused properly.

This bug was discovered using the 8-2019-q3-update of ARM GCC, but it appears
it also exists in GCC.

Discussion about this bug can be found here (for the ARM version of GCC) :
https://community.arm.com/developer/tools-software/tools/f/arm-compilers-forum/13366/arm-gcc-lambda-optimization/159463#159463

Link to online compiler test case : https://godbolt.org/z/hx2cEU

Attached is the preprocessed test case.

The problem with the following example code is :

wrapper2LAMBDA uses 32 bytes more of stack than wrapper1LAMBDA (ie the size of
the structure), but it should not, the stack should be reused for further
structures.


struct TestStruct
{
uint32_t field1;
uint32_t field2;
uint32_t field3;
uint32_t field4;

uint32_t field11;
uint32_t field21;
uint32_t field31;
uint32_t field41;
} ;

struct TestStruct initStructure(uint32_t f1, uint32_t f2, uint32_t f3,
uint32_t f4,uint32_t f11, uint32_t f21, uint32_t f31, uint32_t f41)
{
struct TestStruct myStruct;
myStruct.field1 = f1;
myStruct.field2 = f2;
myStruct.field3 = f3;
myStruct.field4 = f4;

myStruct.field11 = f11;
myStruct.field21 = f21;
myStruct.field31 = f31;
myStruct.field41 = f41;

return myStruct;
}

#define MACROLAMBDA(f1,f2,f3,f4,f5,f6,f7,f8) \
[&]() -> struct TestStruct { struct TestStruct ${}; \
$.field1 = f1; \
$.field2 = f2; \
$.field3 = f3; \
$.field4 = f4; \
$.field11 = f5; \
$.field21 = f6; \
$.field31 = f7; \
$.field41 = f8; \
return $; \
}()

void __attribute__((noinline)) doStuff(struct TestStruct myStruct)
{
printf("f1 = %d, f2 = %d, f3 = %d, f4 = %d, f1 = %d, f2 = %d, f3 = %d,
f4 = %d", myStruct.field1, myStruct.field2, myStruct.field3,
myStruct.field4,myStruct.field11, myStruct.field21, myStruct.field31,
myStruct.field41);
}

void __attribute__((noinline)) wrapper2LAMBDA(void)
{
doStuff(MACROLAMBDA(1,2,3,4,5,6,7,8));
doStuff(MACROLAMBDA(11,22,33,44,55,66,77,88));
}

void __attribute__((noinline)) wrapper1LAMBDA(void)
{
doStuff(MACROLAMBDA(1,2,3,4,5,6,7,8));
}

---

The assembly generated for both functions are :

--
_Z14wrapper2LAMBDAv:
movabs  rax, 8589934593
sub rsp, 72
mov QWORD PTR [rsp], rax
movabs  rax, 17179869187
mov QWORD PTR [rsp+8], rax
movabs  rax, 25769803781
mov QWORD PTR [rsp+16], rax
movabs  rax, 34359738375
mov QWORD PTR [rsp+24], rax
pushQWORD PTR [rsp+24]
pushQWORD PTR [rsp+24]
pushQWORD PTR [rsp+24]
pushQWORD PTR [rsp+24]
call_Z7doStuff10TestStruct
movabs  rax, 94489280523
mov QWORD PTR [rsp+64], rax
movabs  rax, 188978561057
mov QWORD PTR [rsp+72], rax
movabs  rax, 283467841591
mov QWORD PTR [rsp+80], rax
movabs  rax, 377957122125
mov QWORD PTR [rsp+88], rax
add rsp, 32
pushQWORD PTR [rsp+56]
pushQWORD PTR [rsp+56]
pushQWORD PTR [rsp+56]
pushQWORD PTR [rsp+56]
call_Z7doStuff10TestStruct
add rsp, 104
ret
_Z14wrapper1LAMBDAv:
movabs  rax, 8589934593
sub rsp, 40
mov QWORD PTR [rsp], rax
movabs  rax, 17179869187
mov QWORD PTR [rsp+8], rax
movabs  rax, 25769803781
mov QWORD PTR [rsp+16], rax
movabs  rax, 34359738375
mov QWORD PTR [rsp+24], rax
pushQWORD PTR [rsp+24]
pushQWORD PTR [rsp+24]
pushQWORD PTR [rsp+24]
pushQWORD PTR [rsp+24]
call_Z7doStuff10TestStruct
add rsp, 72
ret
--

"sub rsp, 72 " for wrapper2LAMBDA and "sub rsp, 40" for wrapper1LAMBDA
is what makes me believe stack is not reused, or that there is some dead stack.

The same behavior happen with ARM ASM

"subsp, sp, #80" for wrapper2LAMBDA and "subsp, sp, #52" for
wrapper1LAMBDA.

This also happens 

Re: [PATCHv5] Fix not 8-byte aligned ldrd/strd on ARMv5 (PR 89544)

[John David Anglin]

On 2019-08-15 3:47 p.m., Bernd Edlinger wrote:
> 2019-08-15  Bernd Edlinger  
>
>   PR middle-end/89544
>   * function.c (assign_parm_find_stack_rtl): Use larger alignment
>   when possible.
This patch breaks build on hppa-unknown-linux-gnu:
https://buildd.debian.org/status/fetch.php?pkg=gcc-snapshot=hppa=1%3A20190820-1=1566307455=0

hppa-linux-gnu-g++-9 -std=gnu++98 -fno-PIE -c   -g -DIN_GCC -fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. 
-I../../src/gcc/../include -I../../src/gcc/../libcpp/include  
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd 
-I../libdecnumber -I../../src/gcc/../libbacktrace   -o function.o -MT 
function.o -MMD -MP -MF ./.deps/function.TPo ../../src/gcc/function.c
hppa-linux-gnu-g++-9 -std=gnu++98 -fno-PIE -c   -g -DIN_GCC -fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. 
-I../../src/gcc/../include -I../../src/gcc/../libcpp/include  
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd 
-I../libdecnumber -I../../src/gcc/../libbacktrace   -o function-tests.o -MT 
function-tests.o -MMD -MP -MF ./.deps/function-tests.TPo 
../../src/gcc/function-tests.c
hppa-linux-gnu-g++-9 -std=gnu++98 -fno-PIE -c   -g -DIN_GCC -fno-exceptions 
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual 
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings 
-fno-common  -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. 
-I../../src/gcc/../include -I../../src/gcc/../libcpp/include  
-I../../src/gcc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd 
-I../libdecnumber -I../../src/gcc/../libbacktrace   -o fwprop.o -MT fwprop.o 
-MMD -MP -MF ./.deps/fwprop.TPo ../../src/gcc/fwprop.c
../../src/gcc/function.c: In function 'void assign_parm_find_stack_rtl(tree, 
assign_parm_data_one*)':
../../src/gcc/function.c:2690:28: error: no match for 'operator==' (operand 
types are 'poly_int<1, long long int>' and 'int')
 2690 |&& STACK_POINTER_OFFSET == 0)
  |^~ ~
  |   |
  |   int
In file included from ../../src/gcc/coretypes.h:415,
 from ../../src/gcc/function.c:36:
../../src/gcc/wide-int.h:3287:19: note: candidate: 'template typename wi::binary_traits::predicate_result operator==(const T1&, 
const T2&)'
 3287 | BINARY_PREDICATE (operator ==, eq_p)
  |   ^~~~
../../src/gcc/wide-int.h:3264:3: note: in definition of macro 'BINARY_PREDICATE'
 3264 |   OP (const T1 , const T2 ) \
  |   ^~
../../src/gcc/wide-int.h:3287:19: note:   template argument 
deduction/substitution failed:
 3287 | BINARY_PREDICATE (operator ==, eq_p)
  |   ^~~~
../../src/gcc/wide-int.h:3264:3: note: in definition of macro 'BINARY_PREDICATE'
 3264 |   OP (const T1 , const T2 ) \
  |   ^~
../../src/gcc/wide-int.h: In substitution of 'template 
typename wi::binary_traits::predicate_result operator==(const T1&, 
const T2&) [with T1 = poly_int<1, long long int>; T2 = int]':
../../src/gcc/function.c:2690:31:   required from here
../../src/gcc/wide-int.h:3287:19: error: incomplete type 
'wi::int_traits >' used in nested name specifier
 3287 | BINARY_PREDICATE (operator ==, eq_p)
  |   ^~~~
../../src/gcc/wide-int.h:3264:3: note: in definition of macro 'BINARY_PREDICATE'
 3264 |   OP (const T1 , const T2 ) \
  |   ^~
make[5]: *** [Makefile:1118: function.o] Error 1
make[5]: *** Waiting for unfinished jobs

We have the following define for STACK_POINTER_OFFSET:

#define STACK_POINTER_OFFSET \
  (TARGET_64BIT ? -(crtl->outgoing_args_size + 48) : poly_int64 (-32))
 
Dave

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

Re: [PATCH V2 2/8] bpf: new GCC port

[Jose E. Marchesi]

Hi Richard!

Many thanks for the deep review.  I'm addressing some of your questions
below.

> [...]
> +/* Override options and do some other initialization.  */
> +
> +static void
> +bpf_option_override (void)
> +{
> +  /* Set the default target kernel if no -mkernel was specified.  */
> +  if (!global_options_set.x_bpf_kernel)
> +bpf_kernel = LINUX_LATEST;

LINUX_LATEST is the default in the .opt file, so when is this needed?

It is an idiom I got from sparc.c:

  /* Set the default CPU if no -mcpu option was specified.  */
  if (!global_options_set.x_sparc_cpu_and_features)
{
  ...
}

Maybe the code in sparc.c predates the Init() directive in sparc.opt
file?

> +/* Determine whether the port is prepared to handle insns involving
> +   scalar mode MODE.  For a scalar mode to be considered supported,
> +   all the basic arithmetic and comparisons must work.  */
> +
> +static bool
> +bpf_scalar_mode_supported_p (scalar_mode mode)
> +{
> +  switch (mode)
> +{
> +case E_QImode:
> +case E_HImode:
> +case E_SImode:
> +case E_DImode:
> +case E_TImode:
> +  return true;
> +
> +default:
> +  return false;
> +}
> +
> +  return false;
> +}

Are you overriding this just to exclude floating-point modes?
If so, what specifically doesn't work?

Would be worth a comment.

Reminiscence of not having support for TImodes at some stage.  I'm
removing the target hook.

> [...]
> +/* Return true if a value of mode MODE1 is accessible in mode MODE2
> +   without copying.  */
> +
> +static bool
> +bpf_modes_tieable_p (enum machine_mode mode1,
> +  enum machine_mode mode2)
> +{
> +  return (mode1 == mode2
> +   || GET_MODE_CLASS (mode1) == GET_MODE_CLASS (mode2));
> +}

The second part makes the first part redundant.  But why do you
need to restrict it based on classes?  It seems like eBPF is an
example of an architecture where any modes are tieable, so using
the default would be better if possible.

If the restriction is needed, it would be worth having a comment
explaining which case you're excluding and why.

Hm yes, you are right.  TARGET_HARD_REGNO_MODE_OK (R,MODE1) ==
TARGET_HARD_REGNO_MODE_OK (R,MODE2) for all supported modes...  I'm
removing the target hook.

> [...]
> +case PLUS:
> +  {
> + /* The valid patterns here are:
> +
> +(PLUS ADDR_BASE CONST_INT)
> +(PLUS CONST_INT ADDR_BASE)

The second one isn't canonical rtl, so you shouldn't (need to) handle it.
Please raise a bug if you find a case where it's being generated. :-)

Oooh, didn't know that, that's actually very handy :)

Do you know if this is documented anywhere?  I don't recall seeing this
in the internals manual, but maybe I missed it.

> [...]
> +/* Split an out-of-range address displacement into hi and lo parts.
> +   The hi part will have to be loaded into a register separately, but
> +   the low part will be folded into the memory operand.  */
> +
> +static bool
> +bpf_legitimize_address_displacement (rtx *off1, rtx *off2,
> +  poly_int64 poly_offset, machine_mode)
> +{
> +  HOST_WIDE_INT orig_offset = poly_offset;
> +
> +  /* Our case is very easy: the REG part of an indirect address is
> + 64-bit wide, so it can hold any address.  This always leads to
> + REG+0 */
> +
> +  *off1 = GEN_INT (orig_offset);
> +  *off2 = GEN_INT (0);
> +  return true;
> +}
> +
> +#undef TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT
> +#define TARGET_LEGITIMIZE_ADDRESS_DISPLACEMENT 
bpf_legitimize_address_displacement

But then do you need to define the hook at all?  I think this is what
LRA does by default.  The hook is only really there to get better spill
code (via common anchor points) on targets with limited offset ranges.

Hm I think I wrote this hook to fix some invalid addresses being
generated at some point... but I don't recall the details.  It looks
like this hook is no longer necessary with the current implementation of
addresses (legitimize etc) so I'm removing it.

> [...]
> +/* Return true if memory address ADDR in address space AS can have
> +   different meanings depending on the machine mode of the memory
> +   reference it is used for or if the address is valid for some modes
> +   but not others.  */
> +
> +static bool
> +bpf_mode_dependent_address_p (const_rtx addr ATTRIBUTE_UNUSED,
> +  addr_space_t as ATTRIBUTE_UNUSED)
> +{
> +  return true;
> +}
> +
> +#undef TARGET_MODE_DEPENDENT_ADDRESS_P
> +#define TARGET_MODE_DEPENDENT_ADDRESS_P bpf_mode_dependent_address_p

[Bug ada/91492] [10 regression] Ada documentation issue starting with r274637

[pmderodat at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91492

pmderodat at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from pmderodat at gcc dot gnu.org ---
Great, thanks! Sorry for the inconvenience…

Re: Expansion of narrowing math built-ins into power instructions

[Segher Boessenkool]

On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote:
> Segher Boessenkool  writes:
> >>   [(set (match_operand:SI 0 "register_operand" "=d")
> >> (truncate:SI
> >>  (lshiftrt:DI
> >
> > (this is optimised to a subreg, in many cases, for example).
> 
> Right.  MIPS avoids that one thanks to TARGET_TRULY_NOOP_TRUNCATION.

Trying 10 -> 18:
   10: r200:TI=zero_extend(r204:DI)*zero_extend(r205:DI)
  REG_DEAD r205:DI
  REG_DEAD r204:DI
   18: $2:DI=r200:TI#0
  REG_DEAD r200:TI
Failed to match this instruction:
(set (reg/i:DI 2 $2)
(subreg:DI (mult:TI (zero_extend:TI (reg:DI 204))
(zero_extend:TI (reg:DI 205))) 0))

I'm afraid not.

This was
mips64-linux-gcc -Wall -W -O2 -S mulh.c -mips64 -mabi=64 -fdump-rtl-combine-all
on
===
typedef unsigned long S;
typedef unsigned __int128 D;

S mulh(S a, S b) { return (D)a*b >> (8*sizeof(S)); }
===

> >> float_narrow is different in that the plus (or whatever operation
> >> it's quoting) has to be kept in-place rather than folded away,
> >> otherwise the rtx itself is malformed and could trigger an ICE,
> >> just like the zero_extend of a const_int that I mentioned.
> >
> > Yes, it will not pass recog.  Structurally it is just hunky-dory though.
> 
> So maybe that's the main point of difference.  We're introducing
> float_narrow to modify another rtx operation rather than to operate
> on an rtx value.

I wouldn't say it "operates" on anything.  A float_narrow rtx means the
thing inside it does single-rounding to SP float.  And it is just
notation: RTL itself knows *nothing* about float rounding, and because
of the way this is structured, nothing can change anything about the
float_narrow.

And yes, it is icky.  But it is sound, as far as I can see.

> >> Whatever the number is, we'll still be listing them individually for
> >> built-in enumerations, internal_fn, and (I assume) optabs.  But maybe
> >> after a certain point it does become too unwieldly for rtx codes.
> >> We have to keep it within 16 bits at least...
> >
> > My main concern is all the (simplification) code that parses RTL.  All of
> > that will have to handle all variant versions as well.
> 
> True, but we'd have to err on the side of caution whatever happens.

Yes.

> Not all existing PLUS simplifications necessarily apply as-is.

Yes.  Everything will have to be checked.  But not everything will
have to be modified, if we pick the defaults carefully.  I hope.  :-)


Segher

[Bug rtl-optimization/91154] [10 Regression] 456.hmmer regression on Haswell caused by r272922

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #34 from Rainer Orth  ---
Some of the new testcases FAIL on 32-bit x86:

+FAIL: gcc.target/i386/minmax-4.c scan-assembler-times pmaxsd 1
+FAIL: gcc.target/i386/minmax-4.c scan-assembler-times pmaxud 1
+FAIL: gcc.target/i386/minmax-4.c scan-assembler-times pminsd 1
+FAIL: gcc.target/i386/minmax-4.c scan-assembler-times pminud 1
+FAIL: gcc.target/i386/minmax-5.c scan-assembler-times vpmaxsd 1
+FAIL: gcc.target/i386/minmax-5.c scan-assembler-times vpmaxud 1
+FAIL: gcc.target/i386/minmax-5.c scan-assembler-times vpminsd 1
+FAIL: gcc.target/i386/minmax-5.c scan-assembler-times vpminud 1
+FAIL: gcc.target/i386/minmax-6.c scan-assembler pmaxsd

This group is only seen on i386-pc-solaris2.11 while ...

+FAIL: gcc.target/i386/pr91154.c scan-assembler-not cmov
+FAIL: gcc.target/i386/pr91154.c scan-assembler-times paddd 2
+FAIL: gcc.target/i386/pr91154.c scan-assembler-times pmaxsd 2

... for this one there are also couple of gcc-testresults reports on
x86_64-pc-linux-gnu.

[Bug lto/91307] -flto causes binary to vary

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||10.0
 Resolution|--- |FIXED

--- Comment #12 from Richard Biener  ---
Fixed for trunk.

[Bug target/90834] Header and startup objects not found on macOS 10.15

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90834

--- Comment #13 from Iain Sandoe  ---
The /usr/local/include thing needs to be handled carefully

"bare" clang (at least up to 9.x) behaves as per GCC, and prepends a given
--sysroot= to the usr/local paths too.

This is correct; imagine that you want to do a cross-compile to a different
Darwin version, so you do ...

... gcc --sysroot=/path/to/darwinXX/SDK -mmacosx-version-min=XX foo.c ... 

you *do not* want that compile line to look in /usr/local/include - since that
directory might have nothing to do with darwinXX (imagine different APIs).

So, if we wanted to do something "automatic" it would have to be predicated on:
1) That there was no --with-sysroot= given at configure time
2) That this is not a cross-compiler
3) That there is no --sysroot= on the invocation line
4) That target = host at invocation time



While one could do something at configure time to choose between "/" and
"Library/Developer/CommandLineTools/SDKs/MacOSX.sdk" based on build=host=target
and what the build system has installed, that's guaranteed to fail if the built
compiler is moved to a system with different configuration.

So, we keep coming back to needing something at invocation time - and that
something needs to be efficient (i.e. not a process launch)

[Bug c++/91500] [9 Regression] gcc-9 ICE on valid code

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91500

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Marek Polacek  ---
I bet this is 90393 which was just fixed by r274550 on trunk and r274597 on
gcc-9-branch.  gcc8 is not affected.

Verified both trunk and gcc 9.

[Bug lto/91307] -flto causes binary to vary

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91307

--- Comment #11 from Richard Biener  ---
Author: rguenth
Date: Tue Aug 20 13:14:59 2019
New Revision: 274748

URL: https://gcc.gnu.org/viewcvs?rev=274748=gcc=rev
Log:
2019-08-20  Richard Biener  

PR lto/91307
* ipa.c (cgraph_build_static_cdtor_1): Use names not recognizable
by collect2 when targetm.have_ctors_dtors which avoids dragging
in temporary filenames from LTO input objects.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa.c

[Bug tree-optimization/91491] [9 Regression] glib2.0 build not working when built with -O2 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91491

--- Comment #3 from Richard Biener  ---
Eh, "interesting".  Thanks for the clarifications.

I suppose you did things like running under valgrind or compiling with
-fsanitize=address.  The most obvious thing I expect from -fno-tree-pre
is stack layout changes which then smells like some bogus stack smashing
going on.  Can you try building gtestutils.c with
-O2 -fno-optimize-sibling-calls?

[Bug ada/91492] [10 regression] Ada documentation issue starting with r274637

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91492

--- Comment #5 from seurer at gcc dot gnu.org ---
It looks like all is well now:

New passes:
FAIL: compiler driver --help=ada option(s): "^ +-.*[^:.]\$" absent from output:
"  -fdump-scos Dump Source Coverage Obligations"

Re: SHA-512 of gcc-9.2.0.tar.gz

[Richard Biener]

On Tue, Aug 20, 2019 at 12:34 PM Andrea Carretti Mambrini
 wrote:
>
> Hi,
> calculated sha512 of *gcc-9.2.0.tar.gz* is:
> 55fead9cac2374b18134c17a143fc9317f67be834589303d31a7c3a6878e6bef22a0590fda902a07cb60f802df035e67975a8ab6a641048e0baa89af439a46ca
>
> but it's reported as:
> a916970e1d02c218d913744b171be5123475e2a31179812297c6812e93a6535eaf6aea0a52e0d5b0b6eb47410921d08306f96869777cc9400bd091611d2d8d15
>
> *gcc-9.2.0.tar.gz.sig*, *gcc-9.2.0.tar.xz* and *gcc-9.2.0.tar.xz.sig* sums 
> are ok.
> Contents of *gcc-9.2.0.tar.gz* and *gcc-9.2.0.tar.xz* are identical.

I've removed the bougs sha512.sum file, it should be regenerated soon.

Richard.

> Regards,
> Andrea
>

Re: [PATCH 2/3] Add simplify rules for wrapped binary operations.

[Richard Biener]

On Tue, Aug 20, 2019 at 10:37 AM Robin Dapp  wrote:
>
> > So - which case is it?  IIRC we want to handle small signed
> > constants but the code can end up unsigned.  For the
> > above we could write (unsigned long)((int)a + 1 - 1) and thus
> > sign-extend?  Or even avoid this if we know the range.
> > That is, it becomes the first case again (operation performed
> > in a smaller type).
>
> Both :) But in order to move forward the second transform suffices to
> get rid of the redundant subtraction/addition of the ivopts candidate.
>
> Attached is a new version as single file that disregards the other
> possible cases (3/3 from before), only performs this transform and
> checks for gimple_simplified in vrp2 after ivopts now.

  gimple_set_modified (stmt, true);
}

+  /* Also fold if we want to fold all statements.  */
+  if (!did_replace && substitute_and_fold_engine->fold_all_stmts
+ && fold_stmt (, follow_single_use_edges))
+   {
+ did_replace = true;
+ stmt = gsi_stmt (i);
+ gimple_set_modified (stmt, true);

make it

   } else if (substitute_and_fold_engine->fold_all_stmts
&& fold_stmt (&...

also please make initialization of fold_all_stmts via
a new constructor argument defaulted to false and
elide the set_fold_all_stmts method.

Are the various testcase adjustments still needed
(-fno-tree-ccp, etc.)?  I guess not.

+ && int_fits_type_p (@1, TREE_TYPE (@0)))

while this properly guards against bogus truncation
of @1 I think it says false to -1ul fitting int.  So
we wouldn't handle (unsigned long)intvar + -1ul.
But it's conservatively correct for now.  Eventually
changing it to wi::min_precision (wi::to_wide (@1),
TYPE_SIGN (TREE_TYPE (@0))) <= TYPE_PRECISION (TREE_TYPE (@0))
might work for that special case.

> Bootstrapped, no regressions on s390 and x86.

OK with the first suggested change and the testcase changes
audited.  We can do the rest as followup.

Thanks,
Richard.

> Regards
>  Robin