[Bug middle-end/92037] [10 Regression] LTO bootstrap broken in selftests

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Fixed.

[Bug tree-optimization/92085] [10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.c:86

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
.

[Bug ipa/91088] IPA-cp cost evaluation is too conservative for "if (f(param) cmp const_val)" condition

[fxue at gcc dot gnu.org]

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

--- Comment #4 from fxue at gcc dot gnu.org ---
Author: fxue
Revision: 277054
Modified property: svn:log

Modified: svn:log at Wed Oct 16 07:41:24 2019
--
--- svn:log (original)
+++ svn:log Wed Oct 16 07:41:24 2019
@@ -1,1 +1,36 @@
-generalized IPA predicate on parameter
+Generalized IPA predicate on parameter reference
+
+2019-10-16  Feng Xue  
+
+PR ipa/91088
+* doc/invoke.texi (ipa-max-param-expr-ops): Document new option.
+* params.def (PARAM_IPA_MAX_PARAM_EXPR_OPS): New.
+* ipa-predicat.h (struct expr_eval_op): New struct.
+(expr_eval_ops): New typedef.
+(struct condition): Add type and param_ops fields, remove size field.
+(add_condition): Replace size parameter with type parameter, add
+param_ops parameter.
+* ipa-predicat.c (expr_eval_ops_equal_p): New function.
+(predicate::add_clause): Add comparisons on type and param_ops.
+(dump_condition): Add debug dump for param_ops.
+(remap_after_inlining): Adjust call arguments to add_condition.
+(add_condition): Replace size parameter with type parameter, add
+param_ops parameter. Unshare constant value used in conditions.
+* ipa-fnsummary.c (evaluate_conditions_for_known_args): Fold
+parameter expressions using param_ops.
+(decompose_param_expr):  New function.
+(set_cond_stmt_execution_predicate): Use call to decompose_param_expr
+to replace call to unmodified_parm_or_parm_agg_item.
+(set_switch_stmt_execution_predicate): Likewise.
+(will_be_nonconstant_expr_predicate): Likewise. Replace usage of size
+with type.
+(inline_read_section): Read param_ops from summary stream.
+(ipa_fn_summary_write): Write param_ops to summary stream.
+
+2019-10-16  Feng Xue  
+
+PR ipa/91088
+* gcc.dg/ipa/pr91088.c: New test.
+* gcc.dg/ipa/pr91089.c: Add sub-test for range analysis.
+* g++.dg/tree-ssa/ivopts-3.C: Force a function to be noinline.
+

[Bug c++/91369] Implement P0784R7: constexpr new

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Another question is whether:
constexpr int
bar ()
{
  auto a = static_cast (::operator new (sizeof (int)));
  *a = 1;
  *a = *a + 2;
  int r = *a;
  ::operator delete (a);
  return r;
}

constexpr auto p = bar ();

is valid or not (i.e. when there is no placement new at all, just static_cast
and dereferencing of the pointer.  Or if it is required to use
std::allocator::allocate for that, and in that case, does one need to use
placement new or can it be dereferenced without it?

[Bug libgomp/92116] New: Potential null pointer dereference in 'gomp_acc_remove_pointer'

[tschwinge at gcc dot gnu.org]

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

Bug ID: 92116
   Summary: Potential null pointer  dereference in
'gomp_acc_remove_pointer'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, jules at gcc dot gnu.org,
msebor at gcc dot gnu.org
  Target Milestone: ---

As reported in
:

| PS I tried compiling GCC with [a new] patch.  It fails in libgomp
| with:
| 
|libgomp/oacc-mem.c: In function ‘gomp_acc_remove_pointer’:
|cc1: warning: invalid use of a null pointer [-Wnonnull]
| 
| so clearly it's missing location information.  With
| -Wnull-dereference enabled we get more detail:
| 
|libgomp/oacc-mem.c: In function ‘gomp_acc_remove_pointer’:
|libgomp/oacc-mem.c:1013:31: warning: potential null pointer dereference
[-Wnull-dereference]
| 1013 |   for (size_t i = 0; i < t->list_count; i++)
|  |  ~^~~~
|libgomp/oacc-mem.c:1012:19: warning: potential null pointer dereference
[-Wnull-dereference]
| 1012 |   t->refcount = minrefs;
|  |   ^
|libgomp/oacc-mem.c:1013:31: warning: potential null pointer dereference
[-Wnull-dereference]
| 1013 |   for (size_t i = 0; i < t->list_count; i++)
|  |  ~^~~~
|libgomp/oacc-mem.c:1012:19: warning: potential null pointer dereference
[-Wnull-dereference]
| 1012 |   t->refcount = minrefs;
|  |   ^
|cc1: warning: invalid use of a null pointer [-Wnonnull]
| 
| I didn't spend too long examining the code but it seems like
| the warnings might actually be justified.  When the first loop
| terminates with t being null the subsequent dereferences are
| invalid:
| 
|if (t->refcount == minrefs)
| {
|   /* This is the last reference, so pull the descriptor off the
|  chain. This prevents gomp_unmap_vars via gomp_unmap_tgt from
|  freeing the device memory. */
|   struct target_mem_desc *tp;
|   for (tp = NULL, t = acc_dev->openacc.data_environ; t != NULL;
|tp = t, t = t->prev)
| {
|   if (n->tgt == t)
| {
|   if (tp)
| tp->prev = t->prev;
|   else
| acc_dev->openacc.data_environ = t->prev;
|   break;
| }
| }
| }
| 
|/* Set refcount to 1 to allow gomp_unmap_vars to unmap it.  */
|n->refcount = 1;
|t->refcount = minrefs;
|for (size_t i = 0; i < t->list_count; i++)

[Bug libgomp/92116] Potential null pointer dereference in 'gomp_acc_remove_pointer'

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-16
   Assignee|unassigned at gcc dot gnu.org  |jules at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Thomas Schwinge  ---
Julian, I'm aware you're largely changing this code in your "OpenACC reference
count overhaul" patch,
. 
So, this PR appears to be relevant for the latter; please verify that the issue
truly gets fixed, and the presumedly buggy code not just moved elsewhere, etc. 
(Or, of course, first do a separate commit to fix this PR's bug, if that makes
sense.)

[Bug debug/91887] [7/8/9/10 Regression] -fdebug-types-section ICE building chromium

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
The issue seems to be that during late dwarf2out_function_decl we no longer
identify formal parameter packs as such, generating a bogus new
DW_TAG_formal_parameter via

  if (generic_decl_parm
  && lang_hooks.function_parameter_pack_p (generic_decl_parm))
gen_formal_parameter_pack_die (generic_decl_parm,
   parm, subr_die,
   &parm);
  else if (parm)
{
  dw_die_ref parm_die = gen_decl_die (parm, NULL, NULL, subr_die);

and the latter doesn't re-use the DIE because

  /* If the contexts differ, we may not be talking about the same
 thing.
 ???  When in LTO the DIE parent is the "abstract" copy and the
 context_die is the specification "copy".  But this whole block
 should eventually be no longer needed.  */
  if (parm_die && parm_die->die_parent != context_die && !in_lto_p)
{

but then parm_die->die_parent is DW_TAG_GNU_formal_parameter_pack while
context_die is DW_TAG_subprogram.

We go different routes here because that generic_decl_parm thing is only
handled during early_dwarf:

  /* Generate DIEs to represent all known formal parameters.  */
  tree parm = DECL_ARGUMENTS (decl); 
  tree generic_decl = early_dwarf
? lang_hooks.decls.get_generic_function_decl (decl) : NULL;
  tree generic_decl_parm = generic_decl
? DECL_ARGUMENTS (generic_decl)
: NULL;

The question is how the DWARF should look like and whether those
parameter pack DIEs should be annotated late with locations at all
and if not how we can identify the PARM_DECLs that need no such handling.
Since both paths create a DIE for 'parm' either one has to deal with
"completing" the other.

In any case, creatig a new type DIE late as we do here wrecks with the comdat
type handling.

So I think we need to adjust

  /* If the contexts differ, we may not be talking about the same
 thing.
 ???  When in LTO the DIE parent is the "abstract" copy and the
 context_die is the specification "copy".  But this whole block
 should eventually be no longer needed.  */
  if (parm_die && parm_die->die_parent != context_die && !in_lto_p)

to consider a formal parameter pack parent.  Note the comment is
a bit misleading since the handling is needed for the case we
are creating a concrete instance DIE (which we do late) when
the original DIE was the abstract copy used for inline instances,
the inline copies get handled by

  /* If we have a previously generated DIE, use it, unless this is an
 concrete instance (origin != NULL), in which case we need a new
 DIE with a corresponding DW_AT_abstract_origin.  */
  bool reusing_die;
  if (parm_die && origin == NULL)
reusing_die = true;


So - a fix could look like

Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 277053)
+++ gcc/dwarf2out.c (working copy)
@@ -22284,19 +22284,18 @@ gen_formal_parameter_die (tree node, tre
   /* If the contexts differ, we may not be talking about the same
 thing.
 ???  When in LTO the DIE parent is the "abstract" copy and the
-context_die is the specification "copy".  But this whole block
-should eventually be no longer needed.  */
-  if (parm_die && parm_die->die_parent != context_die && !in_lto_p)
+context_die is the specification "copy".  */
+  if (parm_die
+ && parm_die->die_parent != context_die
+ && (parm_die->die_parent->die_tag != DW_TAG_GNU_formal_parameter_pack
+ || parm_die->die_parent->die_parent != context_die)
+ && !in_lto_p)
{
- if (!DECL_ABSTRACT_P (node))
-   {
- /* This can happen when creating an inlined instance, in
-which case we need to create a new DIE that will get
-annotated with DW_AT_abstract_origin.  */
- parm_die = NULL;
-   }
- else
-   gcc_unreachable ();
+ gcc_assert (!DECL_ABSTRACT_P (node));
+ /* This can happen when creating a concrete instance, in
+which case we need to create a new DIE that will get
+annotated with DW_AT_abstract_origin.  */
+ parm_die = NULL;
}

   if (parm_die && parm_die->die_parent == NULL)

[Bug tree-optimization/92115] [10 Regression] ICE in gimple_cond_get_ops_from_tree, at gimple-expr.c:577

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-16
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 47044
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47044&action=edit
gcc10-pr92115.patch

Untested fix.  The other two spots in the same file seems to be dealing with
integer conditions only, so should be ok.

[Bug tree-optimization/92115] [10 Regression] ICE in gimple_cond_get_ops_from_tree, at gimple-expr.c:577

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug middle-end/78884] [7/8] ICE when gimplifying VLA in OpenMP SIMD region

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #15 from Jakub Jelinek  ---
*** Bug 87752 has been marked as a duplicate of this bug. ***

[Bug fortran/87752] ICE in omp_add_variable, at gimplify.c:6776

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #4 from Jakub Jelinek  ---
Fixed with r273096.

*** This bug has been marked as a duplicate of bug 78884 ***

[Bug tree-optimization/92115] [10 Regression] ICE in gimple_cond_get_ops_from_tree, at gimple-expr.c:577

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #1)
> Created attachment 47044 [details]
> gcc10-pr92115.patch
> 
> Untested fix.  The other two spots in the same file seems to be dealing with
> integer conditions only, so should be ok.

LGTM.

[Bug tree-optimization/92111] [10 Regression] ICE during GIMPLE pass: dom

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||lto
 CC||aldyh at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|ICE during GIMPLE pass: dom |[10 Regression] ICE during
   ||GIMPLE pass: dom

--- Comment #2 from Richard Biener  ---
VRP stuff.

[Bug middle-end/92110] too many -Warray-bounds warnings for a loop buffer overflow

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-16
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  This asks for TREE_NO_WARNING to be recorded per location.
Or rather record we already warned for -Warray-bounds for a specific location.
Or rather gathering all of them and emitting a combined warning like

c.c:4:10: warning: array subscripts 4 to 7 are outside array bounds of
‘char[4]’ [-Warray-bounds]

[Bug fortran/92113] [8 regression] r276673 causes segfault in gfortran.dg/pr51434.f90

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.3.0
   Target Milestone|--- |8.4
  Known to fail||8.3.1

[Bug c/92117] New: Warning from -Wbad-function-cast when casting from bool to int

[thomas.kolb at iis dot fraunhofer.de]

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

Bug ID: 92117
   Summary: Warning from -Wbad-function-cast when casting from
bool to int
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.kolb at iis dot fraunhofer.de
  Target Milestone: ---

Created attachment 47045
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47045&action=edit
Preprocessed test source

Hello,

when I try to compile the following code, I get the warning below:

| #include 
| 
| static bool safe_read_bool(void)
| {
| return false;
| }
| 
| void pb_enc_bool(void)
| {
| int value = (int)safe_read_bool();
| }

| $ gcc -O2 -std=c99 -Wbad-function-cast --save-temps -c -o test.o test.c
| test.c: In function 'pb_enc_bool':
| test.c:10:17: warning: cast from function call of type '_Bool' to
non-matching type 'int' [-Wbad-function-cast]
|10 | int value = (int)safe_read_bool();
|   | ^

The pre-processed source file is attached.

As a bool can be fully represented by an integer, I would expect that is is a
valid cast. When the return value is assigned directly to the integer variable,
no warning is given.

This was tested on various versions of GCC which all show this behaviour. Here
are the details of the latest version:

| $ gcc -v
| Using built-in specs.
| COLLECT_GCC=gcc
| COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper
| OFFLOAD_TARGET_NAMES=hsa:nvptx-none
| Target: x86_64-suse-linux
| Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d
--enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none, --without-cuda-driver
--disable-werror --with-gxx-include-dir=/usr/include/c++/9 --enable-ssp
--disable-libssp --disable-libvtv --disable-cet --disable-libcc1
--enable-plugin --with-bugurl=https://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-libphobos
--enable-version-specific-runtime-libs --with-gcc-major-version-only
--enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function
--program-suffix=-9 --without-system-libunwind --enable-multilib
--with-arch-32=x86-64 --with-tune=generic
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=x86_64-suse-linux --host=x86_64-suse-linux
| Thread model: posix
| gcc version 9.2.1 20190903 [gcc-9-branch revision 275330] (SUSE Linux) 

Thanks for your time and attention.

[Bug c/92118] New: warning with [-Wmaybe-uninitialized] in -O1

[tangyixuan at mail dot dlut.edu.cn]

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

Bug ID: 92118
   Summary: warning with [-Wmaybe-uninitialized] in -O1
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tangyixuan at mail dot dlut.edu.cn
  Target Milestone: ---

[-Wmaybe-uninitialized] should be independent of optimization levels
(-O0/O1/../O3) or may be a spurious Warnings on -O1:

$ cat s.c
  int main()
  {
int i;
for(;i<5;i++){
}
return 0;
  }

$ gcc-trunk -O1 -Wmaybe-uninitialized s.c

s.c: In function ‘main’:
s.c:4:13: warning: ‘i’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
   for(;i<5;i++){
 ~^~

gcc version 10.0.0 20190913 (experimental) (GCC)
target: Ubuntu 4.8.5-4ubuntu8~14.04.2

Since the default value of ‘i’ is 0, there is no warning with -O0/O2/O3.

[Bug middle-end/92118] warning with [-Wmaybe-uninitialized] in -O1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end
   Severity|normal  |enhancement

[Bug tree-optimization/92115] [10 Regression] ICE in gimple_cond_get_ops_from_tree, at gimple-expr.c:577

[iii at linux dot ibm.com]

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

--- Comment #3 from Ilya Leoshkevich  ---
Thanks again, Jakub.

Arseny, how did you find this? Did you just run the regtest? I wonder why
didn't I see it during my test runs.

[Bug c++/91369] Implement P0784R7: constexpr new

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely  ---
That's not valid, because operator new is not a constexpr function.

You have to use a new-expression (that resolves to one of the standard operator
new allocation functions), or std::allocator::allocate, or
std::allocator_traits>::allocate.

The result of std::allocator::allocate can't be dereferenced until you've
constructed an object there (and attempting to do so in a constexpr function
should be ill-formed).

This should work:

constexpr int
bar ()
{
  auto a = new int; // obtain storage for an int and begin its lifetime
  *a = 1;
  *a = *a + 2;
  int r = *a;
  delete a; // end lifetime and release storage
  return r;
}

constexpr auto p = bar ();

And this:

constexpr int
baz ()
{
  auto a = std::allocator::allocate(1); // obtain storage for an int
  std::construct_at(a);  // begin lifetime of an int
  *a = 1;
  *a = *a + 2;
  int r = *a;
  std::destroy_at(a);// end lifetime
  std::allocator::deallocate(a, 1); // release storage
  return r;
}

constexpr auto q = baz ();

And the equivalent using std::allocator_traits:

constexpr int
baz2 ()
{
  std::allocator alloc;
  using A = std::allocator_traits>;
  auto a = A::allocate(alloc, 1);// obtain storage for an int
  A::construct(a);   // calls std::construct_at
  *a = 1;
  *a = *a + 2;
  int r = *a;
  A::destroy(alloc, a);  // calls std::destroy_at
  A::deallocate(alloc, a, 1);// release storage
  return r;
}

constexpr auto q = baz2 ();

[Bug c++/91369] Implement P0784R7: constexpr new

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
I'll commit a patch to add std::construct_at today or tomorrow.

[Bug c++/91606] [9 regression] Optimization leads to invalid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #14 from Richard Biener  ---
Fixed.

[Bug lto/91772] [8/9 Regression] ICE in add_dwarf_attr, at dwarf2out.c:4412 since r259749

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 16 09:25:34 2019
New Revision: 277055

URL: https://gcc.gnu.org/viewcvs?rev=277055&root=gcc&view=rev
Log:
2019-10-16  Richard Biener  

Backport from mainline
2019-10-04  Richard Biener  

PR lto/91968
* tree.c (find_decls_types_r): Do not remove LABEL_DECLs from
BLOCK_VARS.

2019-10-02  Richard Biener  

PR c++/91606
* decl.c (build_ptrmemfunc_type): Mark pointer-to-member
fat pointer structure members as DECL_NONADDRESSABLE_P.

* g++.dg/torture/pr91606.C: New testcase.

2019-09-19  Richard Biener  

PR tree-optimization/91812
* tree-ssa-phiprop.c (propagate_with_phi): Do not replace
volatile loads.

* gcc.dg/torture/pr91812.c: New testcase.

2019-09-17  Richard Biener  

PR debug/91772
* dwarf2out.c (dwarf2out_late_global_decl): If early dwarf
was missing generate locations only once.

2019-09-17  Richard Biener  

PR tree-optimization/91790
* tree-vect-stmts.c (vectorizable_load): For BB vectorization
use the correct DR for setting up realignment.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/torture/pr91606.C
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91812.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/decl.c
branches/gcc-9-branch/gcc/dwarf2out.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-ssa-phiprop.c
branches/gcc-9-branch/gcc/tree-vect-stmts.c
branches/gcc-9-branch/gcc/tree.c

[Bug tree-optimization/91812] [7/8/9 Regression] GCC ignores volatile modifier

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 16 09:25:34 2019
New Revision: 277055

URL: https://gcc.gnu.org/viewcvs?rev=277055&root=gcc&view=rev
Log:
2019-10-16  Richard Biener  

Backport from mainline
2019-10-04  Richard Biener  

PR lto/91968
* tree.c (find_decls_types_r): Do not remove LABEL_DECLs from
BLOCK_VARS.

2019-10-02  Richard Biener  

PR c++/91606
* decl.c (build_ptrmemfunc_type): Mark pointer-to-member
fat pointer structure members as DECL_NONADDRESSABLE_P.

* g++.dg/torture/pr91606.C: New testcase.

2019-09-19  Richard Biener  

PR tree-optimization/91812
* tree-ssa-phiprop.c (propagate_with_phi): Do not replace
volatile loads.

* gcc.dg/torture/pr91812.c: New testcase.

2019-09-17  Richard Biener  

PR debug/91772
* dwarf2out.c (dwarf2out_late_global_decl): If early dwarf
was missing generate locations only once.

2019-09-17  Richard Biener  

PR tree-optimization/91790
* tree-vect-stmts.c (vectorizable_load): For BB vectorization
use the correct DR for setting up realignment.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/torture/pr91606.C
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91812.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/decl.c
branches/gcc-9-branch/gcc/dwarf2out.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-ssa-phiprop.c
branches/gcc-9-branch/gcc/tree-vect-stmts.c
branches/gcc-9-branch/gcc/tree.c

[Bug debug/91968] DW_AT_low_pc missing for DW_TAG_label with LTO

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 16 09:25:34 2019
New Revision: 277055

URL: https://gcc.gnu.org/viewcvs?rev=277055&root=gcc&view=rev
Log:
2019-10-16  Richard Biener  

Backport from mainline
2019-10-04  Richard Biener  

PR lto/91968
* tree.c (find_decls_types_r): Do not remove LABEL_DECLs from
BLOCK_VARS.

2019-10-02  Richard Biener  

PR c++/91606
* decl.c (build_ptrmemfunc_type): Mark pointer-to-member
fat pointer structure members as DECL_NONADDRESSABLE_P.

* g++.dg/torture/pr91606.C: New testcase.

2019-09-19  Richard Biener  

PR tree-optimization/91812
* tree-ssa-phiprop.c (propagate_with_phi): Do not replace
volatile loads.

* gcc.dg/torture/pr91812.c: New testcase.

2019-09-17  Richard Biener  

PR debug/91772
* dwarf2out.c (dwarf2out_late_global_decl): If early dwarf
was missing generate locations only once.

2019-09-17  Richard Biener  

PR tree-optimization/91790
* tree-vect-stmts.c (vectorizable_load): For BB vectorization
use the correct DR for setting up realignment.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/torture/pr91606.C
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91812.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/decl.c
branches/gcc-9-branch/gcc/dwarf2out.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-ssa-phiprop.c
branches/gcc-9-branch/gcc/tree-vect-stmts.c
branches/gcc-9-branch/gcc/tree.c

[Bug c++/91606] [9 regression] Optimization leads to invalid code

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 16 09:25:34 2019
New Revision: 277055

URL: https://gcc.gnu.org/viewcvs?rev=277055&root=gcc&view=rev
Log:
2019-10-16  Richard Biener  

Backport from mainline
2019-10-04  Richard Biener  

PR lto/91968
* tree.c (find_decls_types_r): Do not remove LABEL_DECLs from
BLOCK_VARS.

2019-10-02  Richard Biener  

PR c++/91606
* decl.c (build_ptrmemfunc_type): Mark pointer-to-member
fat pointer structure members as DECL_NONADDRESSABLE_P.

* g++.dg/torture/pr91606.C: New testcase.

2019-09-19  Richard Biener  

PR tree-optimization/91812
* tree-ssa-phiprop.c (propagate_with_phi): Do not replace
volatile loads.

* gcc.dg/torture/pr91812.c: New testcase.

2019-09-17  Richard Biener  

PR debug/91772
* dwarf2out.c (dwarf2out_late_global_decl): If early dwarf
was missing generate locations only once.

2019-09-17  Richard Biener  

PR tree-optimization/91790
* tree-vect-stmts.c (vectorizable_load): For BB vectorization
use the correct DR for setting up realignment.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/torture/pr91606.C
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91812.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/decl.c
branches/gcc-9-branch/gcc/dwarf2out.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-ssa-phiprop.c
branches/gcc-9-branch/gcc/tree-vect-stmts.c
branches/gcc-9-branch/gcc/tree.c

[Bug tree-optimization/91790] ICE: verify_ssa failed (error: definition in block 2 follows the use)

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 16 09:25:34 2019
New Revision: 277055

URL: https://gcc.gnu.org/viewcvs?rev=277055&root=gcc&view=rev
Log:
2019-10-16  Richard Biener  

Backport from mainline
2019-10-04  Richard Biener  

PR lto/91968
* tree.c (find_decls_types_r): Do not remove LABEL_DECLs from
BLOCK_VARS.

2019-10-02  Richard Biener  

PR c++/91606
* decl.c (build_ptrmemfunc_type): Mark pointer-to-member
fat pointer structure members as DECL_NONADDRESSABLE_P.

* g++.dg/torture/pr91606.C: New testcase.

2019-09-19  Richard Biener  

PR tree-optimization/91812
* tree-ssa-phiprop.c (propagate_with_phi): Do not replace
volatile loads.

* gcc.dg/torture/pr91812.c: New testcase.

2019-09-17  Richard Biener  

PR debug/91772
* dwarf2out.c (dwarf2out_late_global_decl): If early dwarf
was missing generate locations only once.

2019-09-17  Richard Biener  

PR tree-optimization/91790
* tree-vect-stmts.c (vectorizable_load): For BB vectorization
use the correct DR for setting up realignment.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/torture/pr91606.C
branches/gcc-9-branch/gcc/testsuite/gcc.dg/torture/pr91812.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/decl.c
branches/gcc-9-branch/gcc/dwarf2out.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/gcc/tree-ssa-phiprop.c
branches/gcc-9-branch/gcc/tree-vect-stmts.c
branches/gcc-9-branch/gcc/tree.c

[Bug tree-optimization/91790] ICE: verify_ssa failed (error: definition in block 2 follows the use)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #5 from Richard Biener  ---
Fixed for GCC 9 as well.

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
Bug 53947 depends on bug 91790, which changed state.

Bug 91790 Summary: ICE: verify_ssa failed (error: definition in block 2 follows 
the use)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91790

   What|Removed |Added

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

[Bug debug/91968] DW_AT_low_pc missing for DW_TAG_label with LTO

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Fixed for GCC 9 as well, not backporting further.

[Bug tree-optimization/92119] New: [10 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3380) with -Os -fno-tree-dce -fno-tree-dse -ftree-slp-vectorize

[zsojka at seznam dot cz]

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

Bug ID: 92119
   Summary: [10 Regression] ICE: SIGSEGV in contains_struct_check
(tree.h:3380) with -Os -fno-tree-dce -fno-tree-dse
-ftree-slp-vectorize
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

Created attachment 47046
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47046&action=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -fno-tree-dce -fno-tree-dse -ftree-slp-vectorize
testcase.c -wrapper valgrind,-q,--track-origins=yes
==28823== Invalid read of size 2
==28823==at 0x1838D81: contains_struct_check (tree.h:3380)
==28823==by 0x1838D81: vect_recog_rotate_pattern(_stmt_vec_info*,
tree_node**) (tree-vect-patterns.c:2202)
==28823==by 0x18319C7: vect_pattern_recog_1(vect_recog_func*,
_stmt_vec_info*) (tree-vect-patterns.c:5167)
==28823==by 0x183DAEE: vect_pattern_recog(vec_info*)
(tree-vect-patterns.c:5323)
==28823==by 0x10D0AA2: vect_slp_analyze_bb_1 (tree-vect-slp.c:2928)
==28823==by 0x10D0AA2: vect_slp_bb(basic_block_def*) (tree-vect-slp.c:3065)
==28823==by 0x10D343F: (anonymous
namespace)::pass_slp_vectorize::execute(function*) (tree-vectorizer.c:1310)
==28823==by 0xDB5A7B: execute_one_pass(opt_pass*) (passes.c:2494)
==28823==by 0xDB639F: execute_pass_list_1(opt_pass*) (passes.c:2580)
==28823==by 0xDB63B1: execute_pass_list_1(opt_pass*) (passes.c:2581)
==28823==by 0xDB63B1: execute_pass_list_1(opt_pass*) (passes.c:2581)
==28823==by 0xDB63D8: execute_pass_list(function*, opt_pass*)
(passes.c:2591)
==28823==by 0xA93771: cgraph_node::expand() (cgraphunit.c:2194)
==28823==by 0xA944F7: expand_all_functions (cgraphunit.c:2332)
==28823==by 0xA944F7: symbol_table::compile() [clone .part.0]
(cgraphunit.c:2688)
==28823==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==28823== 
during GIMPLE pass: slp
testcase.c: In function 'foo':
testcase.c:4:1: internal compiler error: Segmentation fault
4 | foo (void)
  | ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-277054-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-277054-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.0 20191016 (experimental) (GCC)

[Bug tree-optimization/60206] IVOPT has no idea of inline asm

[crazylht at gmail dot com]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #9 from Hongtao.liu  ---
Created attachment 47047
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47047&action=edit
0001-x86-Enable-spill-from-integer-registers-to-mask-regi.patch

I encouter the same problem when i am implementing patch of spilling to mask
register when integer register pressure is high.

Attachment is my patch
Issue can be reproduced by applying patch to gcc10_20191007 or later version, 
config as 
---
./configure --disable-bootstrap --with-arch=native --with-cpu=native
--enable-languages=c,c++,fortran,lto,objc,obj-c++,go 


build gcc on avx512 machine then there will be an error when building libgcc

Error as

---
../../../../../gnu-toolchain/gcc/libgcc/config/i386/32/sfp-machine.h:37:3:
error: ‘asm’ operand has impossible constraints
   37 |   __asm__ ("sub{l} {%11,%3|%3,%11}\n\t"\
  |   ^~~
../../../../../gnu-toolchain/gcc/libgcc/soft-fp/op-4.h:168:3: note: in
expansion of macro ‘__FP_FRAC_SUB_4’
  168 |   __FP_FRAC_SUB_4 (R##_f[3], R##_f[2], R##_f[1], R##_f[0], \
  |   ^~~
../../../../../gnu-toolchain/gcc/libgcc/soft-fp/op-4.h:524:8: note: in
expansion of macro ‘_FP_FRAC_SUB_4’
  524 |_FP_FRAC_SUB_4 (X, Y, X); \
  |^~
../../../../../gnu-toolchain/gcc/libgcc/config/i386/32/sfp-machine.h:87:33:
note: in expansion of macro ‘_FP_DIV_MEAT_4_udiv’
   87 | #define _FP_DIV_MEAT_Q(R,X,Y)   _FP_DIV_MEAT_4_udiv(Q,R,X,Y)
  | ^~~
../../../../../gnu-toolchain/gcc/libgcc/soft-fp/op-common.h:1174:4: note: in
expansion of macro ‘_FP_DIV_MEAT_Q’
 1174 |_FP_DIV_MEAT_##fs (R, X, Y);\
  |^
../../../../../gnu-toolchain/gcc/libgcc/soft-fp/quad.h:183:29: note: in
expansion of macro ‘_FP_DIV’
  183 | # define FP_DIV_Q(R, X, Y)  _FP_DIV (Q, 4, R, X, Y)
  | ^~~
../../../../../gnu-toolchain/gcc/libgcc/soft-fp/divtf3.c:46:3: note: in
expansion of macro ‘FP_DIV_Q’
   46 |   FP_DIV_Q (R, A, B);

[Bug tree-optimization/92033] ICE during dom with -march=armv8.2-a+sve

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Wed Oct 16 09:50:44 2019
New Revision: 277056

URL: https://gcc.gnu.org/viewcvs?rev=277056&root=gcc&view=rev
Log:
Deal with incoming POLY_INT_CST ranges (PR92033)

This patch makes value_range_base::set convert POLY_INT_CST bounds
into the worst-case INTEGER_CST bounds.  The main case in which this
gives useful ranges is a lower bound of A + B * X becoming A when B >= 0.
E.g.:

  [32 + 16X, 100] -> [32, 100]
  [32 + 16X, 32 + 16X] -> [32, MAX]

But the same thing can be useful for the upper bound with negative
X coefficients.

2019-10-16  Richard Sandiford  

gcc/
PR middle-end/92033
* poly-int.h (constant_lower_bound_with_limit): New function.
(constant_upper_bound_with_limit): Likewise.
* doc/poly-int.texi: Document them.
* tree-vrp.c (value_range_base::set): Convert POLY_INT_CST bounds
into the worst-case INTEGER_CST bounds.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/poly-int.texi
trunk/gcc/poly-int.h
trunk/gcc/tree-vrp.c

[Bug tree-optimization/92119] [10 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3380) with -Os -fno-tree-dce -fno-tree-dse -ftree-slp-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-16
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

#1  0x021a8ad9 in vect_recog_rotate_pattern (stmt_vinfo=0x34753f0, 
type_out=0x7fffd030) at /tmp/trunk/gcc/tree-vect-patterns.c:2202
2202  if (TYPE_PRECISION (TREE_TYPE (lhs)) != 16
(gdb) p lhs
$1 = 
(gdb) l
2197 The vectorizer has bswap support, but only if the argument
isn't
2198 promoted.  */
2199  lhs = gimple_call_lhs (last_stmt);
2200  oprnd0 = gimple_call_arg (last_stmt, 0);
2201  type = TREE_TYPE (oprnd0);
2202  if (TYPE_PRECISION (TREE_TYPE (lhs)) != 16
2203  || TYPE_PRECISION (type) <= 16
2204  || TREE_CODE (oprnd0) != SSA_NAME
2205  || BITS_PER_UNIT != 8
2206  || !TYPE_UNSIGNED (TREE_TYPE (lhs)))
(gdb) p last_stmt
$2 = 
(gdb) p debug_gimple_stmt (last_stmt)
__builtin_bswap16 (_7);

[Bug middle-end/92120] New: OpenMP 5 – implicit mapping of this->member variable access – "this[:1]" shall be mapped

[burnus at gcc dot gnu.org]

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

Bug ID: 92120
   Summary: OpenMP 5 – implicit mapping of this->member variable
access – "this[:1]" shall be mapped
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

Loosely related to PR 66053 which is about explicit mapping.

The original code boils down to:
  this->j = this->i[1] + this->i[2]

This ends up in omp_notice_variable (via gimplify_var_or_parm_decl) as "this",
but it is – in line with OpenMP 4.5 – only mapped as:

map(alloc:MEM[(char *)this] [len: 0]) map(firstprivate:this [pointer assign,
bias: 0])

However, for OpenMP 5 – and to be usable – one also needs the actual data, i.e.
map(tofrom:this[:1]).


OpenMP 4.5, "2.15.5 Data-mapping Attribute Rules and Clauses":
"A variable that is of type reference to pointer is treated as if it had
appeared in a map clause as a1zero-length array section."

OpenMP 5.0: "If the target construct is within a class non-static member
function, and a variable is an accessible data member of the object for which
the non-static data member function is invoked, the variable is treated as if
the this[:1] expression had appeared in a map clause with a map-type of tofrom.
[…]"


#include   // For abort.

class foo {
public:
  int i[2], j;

  void func() {
int k[2];
#pragma omp target
j = i[1]+i[2];
  }
};

int bar(int x)
{
  foo cl;
  cl.i[1] = x;
  cl.i[2] = 42;
  cl.func();
  return cl.j;
}

int main()
{
  if (bar(3) != 45)
abort();
  return 0;
}

[Bug tree-optimization/92119] [10 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3380) with -Os -fno-tree-dce -fno-tree-dse -ftree-slp-vectorize

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 16 10:05:21 2019
New Revision: 277057

URL: https://gcc.gnu.org/viewcvs?rev=277057&root=gcc&view=rev
Log:
2019-10-16  Richard Biener  

PR tree-optimization/92119
* tree-vect-patterns.c (vect_recog_rotate_pattern): Guard
against missing bswap lhs.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-vect-patterns.c

[Bug tree-optimization/92119] [10 Regression] ICE: SIGSEGV in contains_struct_check (tree.h:3380) with -Os -fno-tree-dce -fno-tree-dse -ftree-slp-vectorize

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug middle-end/92120] OpenMP 5 – implicit mapping of this->member variable access – "this[:1]" shall be mapped

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords||openmp
 CC||jakub at gcc dot gnu.org

--- Comment #1 from Tobias Burnus  ---
[Tacking bug, just to not to forget it. – It is not completely clear to me
whether it shall be handled in gimplify.c or in the front end.]

[Bug other/92121] New: Error using GCC 4.9.4 -- arch/x86/Makefile:166: *** CONFIG_RETPOLINE=y,

[dhgopal at gmail dot com]

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

Bug ID: 92121
   Summary: Error using GCC 4.9.4 -- arch/x86/Makefile:166: ***
CONFIG_RETPOLINE=y,
   Product: gcc
   Version: 4.9.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhgopal at gmail dot com
  Target Milestone: ---

We are setting up new centos build server and while configuring the gcc and
when we tried to compile the project code, we are getting the below error. we
did compile the code in Centos 3.10.0-693.17.1.el7.x86_64 using the gcc 4.9.4,
where - we installed gcc from the gcc 4.9.4 source code 


1) Error:

scripts/kconfig/conf --silentoldconfig Kconfig
make[2]: Leaving directory `'
arch/x86/Makefile:166: *** CONFIG_RETPOLINE=y, but not supported by the
compiler. Compiler update recommended..  Stop.
make[1]: *** [.config] Error 2
make[1]: Leaving directory `'
make: *** [kernel.rpm] Error 2
$ 


Note: ** are replaced with the directory path


2) we are using gcc 4.9.4 as shown below 

$ gcc --version
gcc (GCC) 4.9.4
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$

[Bug other/92121] Error using GCC 4.9.4 -- arch/x86/Makefile:166: *** CONFIG_RETPOLINE=y,

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-10-16
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
GCC 4.9.4 has been unsupported by the GCC project for many years.

This bug report will be closed unless you can reproduce the problem with a
current release, and provide MUCH more information. You were asked to read
https://gcc.gnu.org/bugs before creating this bug report, which explains the
information needed for a useful bug report.

[Bug other/92121] Error using GCC 4.9.4 -- arch/x86/Makefile:166: *** CONFIG_RETPOLINE=y,

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
   Last reconfirmed|2019-10-16 00:00:00 |
 Resolution|--- |INVALID

--- Comment #2 from Andrew Pinski  ---
This is not related to gcc but rather the linux kernel config option is saying
you dont have a new enough gcc to compile with that config option.

[Bug other/92121] Error using GCC 4.9.4 -- arch/x86/Makefile:166: *** CONFIG_RETPOLINE=y,

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(It looks like the kernel is simply telling you that you cannot enable
retpoline support when using GCC 4.9.4, which seems self-explanatory, and not a
GCC bug).

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[iii at linux dot ibm.com]

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

--- Comment #10 from Ilya Leoshkevich  ---
> Question is how to figure out which to do when.

I would always do the former before reload, and always the latter after
reload.

However, I have a concern regarding this approach: in more complicated
cases instead of just a single 11/COLD we might have a larger lump of
cold basic blocks.  In order to avoid introducing new crossing edges, we
would have to make them all hot (using e.g. a simple worklist
algorithm).  Is such an end result desirable?

I'd also still like to understand the motivation behind doing this pass
after reload.  When I introduced it in r266734, the only goal was to
clean up the CFG after combine.  I was advised to put it where it is
now, and back then I did not see any downsides to doing so.  But now
that this problem has arisen - what is the advantage of doing this after
the following 16 additional passes?  What would be the downside of doing
it between pass_combine and pass_partition_blocks?

  NEXT_PASS (pass_combine);
--
  NEXT_PASS (pass_if_after_combine);
  NEXT_PASS (pass_partition_blocks);
  NEXT_PASS (pass_outof_cfg_layout_mode);
  NEXT_PASS (pass_split_all_insns);
  NEXT_PASS (pass_lower_subreg3);
  NEXT_PASS (pass_df_initialize_no_opt);
  NEXT_PASS (pass_stack_ptr_mod);
  NEXT_PASS (pass_mode_switching);
  NEXT_PASS (pass_match_asm_constraints);
  NEXT_PASS (pass_sms);
  NEXT_PASS (pass_live_range_shrinkage);
  NEXT_PASS (pass_sched);
  NEXT_PASS (pass_early_remat);
  NEXT_PASS (pass_ira);
  NEXT_PASS (pass_reload);
  NEXT_PASS (pass_postreload);
  PUSH_INSERT_PASSES_WITHIN (pass_postreload)
--
  NEXT_PASS (pass_postreload_jump);

[Bug rtl-optimization/92007] [9/10 Regression] ICE: verify_flow_info failed (error: EH edge crosses section boundary in bb 7)

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
Well, it apparently has found new jump threading opportunities after
partition_blocks.  Are such changes useful?  Does it happen often?

[Bug fortran/81827] Large compile time with derived-type rrays

[pault at gcc dot gnu.org]

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

--- Comment #24 from Paul Thomas  ---
(In reply to Luke Robison from comment #23)
> (In reply to Luke Robison from comment #22)
> > (In reply to Luke Robison from comment #21)
> > > (1) Changing some or all of the "type(levelNN)" definitions to
> > > "class(levelNN)" definitions
> > > (2) Changing from "allocatable" to "pointer"
> > > 
> > 
> > Although these work-arounds seem sufficient for this test case, they did not
> > alleviate the problem in the original program.  We are still unable to use
> > recent gfortran versions on our main codebase due to this error.
> > 
> > 
> > Luke
> 
> Correction: I found an additional few declarations which I had not
> converted.  The work-around I describe above does reduce compile time to a
> feasible (yet still slow) level.  Compiling with -O3 is substantially slower
> than -O0, despite my module containing only type declarations (no
> procedures).

Hi Luke,

I have a rather more conclusive fix in mind, which will greatly reduce the code
cascade that the declarations produce.

At present, the copy and finalize functions nest the copy and deallocate for
the allocatable components in line. The better approach is to call the
corresponding vtable functions.

I'll give it a whirl this weekend.

Regards

Paul

[Bug c++/57025] Solaris g++ defines __STDC_VERSION__=199901L

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #9 from Alan Coopersmith  ---
> And I got here this week due to the discussion on
> https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2258/diffs?commit_id=78cd9c60eef40650bba1182d8bb51fc9beb938e2#note_254374
> about why Mesa needed to check for _cplusplus and not just __STDC_VERSION__
> when deciding whether or not to use the "restrict" keyword.

Fortunately that's resolved now.

> I too fear you'll be carrying this code for a while - even in the latest
> patches, Solaris 10 has in the  header:
>
> #if __STDC_VERSION__ - 0 >= 199901L
> #define _STDC_C99
> #endif
>
> [...]
>
> #if defined(_STDC_C99) && (defined(__XOPEN_OR_POSIX) && !defined(_XPG6))
> #error "Compiler or options invalid for pre-UNIX 03 X/Open applications \
> and pre-2001 POSIX applications"
> #elif !defined(_STDC_C99) && \
> (defined(__XOPEN_OR_POSIX) && defined(_XPG6))
> #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications \
> require the use of c99"
> #endif

Right.  However, Solaris 10 support was removed after GCC 9, so we won't
have to worry about that any longer.

> That's also in the initial release of Solaris 11.3 - you either need to have
> Solaris 11.3 support updates or to upgrade to Solaris 11.4 to get a version
> of  without that check.

Indeed.  Solaris 11.3 is the oldest Solaris 11 update I can (and do)
check regularly.  However, people without access to the support repo
will either be stuck with S11.3 FCS or need a reinstall of S11.4 FCS
given the lack of an upgrade path without the support repo.

Since I don't want to leave Solaris users under the development and
testing clause out in the cold, I'm not yet prepared to declare S11.3
unsupported, so even on GCC trunk we cannot think about removing the
__STDC_VERSION__ and _XOPEN_SOURCE defines for C++.

[Bug middle-end/92120] OpenMP 5 – implicit mapping of this->member variable access – "this[:1]" shall be mapped

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
For OpenMP 5 there is quite a lot of mapping related changes that need to be
implemented, first of all, the C/C++ array section support needs to be
rewritten because the rules changed there too much and the current limited
parsing is not usable, this[:1] needs to be handled (this PR), declare mapper
support added, non-contiguous arrays in to/from, etc.  This all is deferred for
GCC 11.

[Bug tree-optimization/92056] [10 Regression] ice in expr_object_size, at tree-object-si ze.c:675 with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Cleaned up testcase:
const char *d;

void
foo (int c, char *e, const char *a, const char *b)
{
  switch (c)
{
case 33:
  for (;; d++)
if (__builtin_strcmp (b ? : "", d))
  return;
  break;
case 4:
  __builtin_sprintf (e, a);
}
}

[Bug fortran/92122] New: [coarrays, polymophism] Error 'must be a scalar of type LOCK_TYPE'

[burnus at gcc dot gnu.org]

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

Bug ID: 92122
   Summary: [coarrays, polymophism] Error 'must be a scalar of
type LOCK_TYPE'
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: pault at gcc dot gnu.org
  Target Milestone: ---

From thread starting at
   https://mailman.j3-fortran.org/pipermail/j3/2019-October/011681.html
The issue there is not yet fully triaged at J3.

But the thread comes with two example programs – shown below.
- the first one is the original one
- the second one is a modified program, which compiles with the Intel compiler

With gfortran, the error messages are:

5 | Type(lock_type),Pointer :: q
  |1
Error: Component q at (1) of type LOCK_TYPE must have a codimension or be a
subcomponent of a coarray, which is not possible as the component has the
pointer attribute

And:

   11 |   type is ( lock_type )
  |   1
Error: Variable __tmp_type_lock_type at (1) of type LOCK_TYPE or with
subcomponent of type LOCK_TYPE must be a coarray

The latter also exposes the tmp variable name, which is also not that nice.


!--- One -
Program co428
  Use Iso_Fortran_Env
  Type(lock_type),Target :: p[*]
  Type lockpointer
Type(lock_type),Pointer :: q
  End Type
  Type(lockpointer) x

  x%q => p
  Lock(x%q)
  Print *,'Is this really ok?'
End Program


!--- Two -
   use, intrinsic :: iso_fortran_env, only : lock_type

   type :: lock_t
   class(*), pointer :: q
   end type
   type(lock_type), target :: p[*]
   type(lock_t) :: x

   x%q => p
   select type ( q => x%q )
  type is ( lock_type )
 lock( q )
   end select
end

[Bug tree-optimization/92033] ICE during dom with -march=armv8.2-a+sve

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed.

[Bug fortran/92123] New: [F2018/array-descriptor] Scalar allocatable/pointer with array descriptor (via bind(C)): ICE with select rank or error scalar variable with POINTER or ALLOCATABLE in procedur

[burnus at gcc dot gnu.org]

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

Bug ID: 92123
   Summary: [F2018/array-descriptor]  Scalar allocatable/pointer
with array descriptor (via bind(C)): ICE with select
rank or error scalar variable with POINTER or
ALLOCATABLE in procedure with BIND(C) is not yet
supported
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code, rejects-valid
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: pault at gcc dot gnu.org
  Target Milestone: ---

Found on https://mailman.j3-fortran.org/pipermail/j3/2019-October/011669.html

The following shall use the array descriptor – and should work (TM):

  subroutine Fsub( dat ) bind(C, name="Fsub")
integer(c_int), allocatable, intent(out) :: dat

Currently, it fails with:
  Error: Scalar variable ‘dat’ at (1) with POINTER or ALLOCATABLE in procedure
‘fsub’ with BIND(C) is not yet supported

Test program, see link to the J3 mailing list.


 * * * 

If one uses assumed-rank variables and adds 'select rank', it give an ICE. That
is with
subroutine fsub( dat ) bind(C, name="fsub")
  integer(c_int), allocatable, intent(out) :: dat(..)
  select rank (dat)
 rank (0)
 !dat = 42  !<-- A
 allocate( dat ) ; dat = 42  !<--- B
  end select 

It ICEs in gfc_conv_descriptor_data_get, at fortran/trans-array.c:145

 Breakpoint 3, trans_associate_var (sym=0x24d8ed0, block=0x7fffd5f0) at
../../repos/gcc/gcc/fortran/trans-stmt.c:1845
1845  tmp = gfc_conv_descriptor_data_get (desc);

(gdb) p debug_tree(desc)
 

[Bug target/70010] powerpc: -flto forgets 'no-vsx' function attributes

[guojiufu at gcc dot gnu.org]

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

--- Comment #7 from Jiu Fu Guo  ---
Author: guojiufu
Date: Wed Oct 16 13:35:41 2019
New Revision: 277065

URL: https://gcc.gnu.org/viewcvs?rev=277065&root=gcc&view=rev
Log:
In PR70010, a function is marked with target(no-vsx) to disable VSX code
generation.  To avoid VSX code generation, this function should not be
inlined into VSX function.  To fix the bug, in the current logic when
checking whether the caller's ISA flags supports the callee's ISA flags, we
just need to add a test that enforces that the caller's ISA flags match
exactly the callee's flags, for those flags that were explicitly set in the
callee.  If caller without target attribute then using options from command
line.

gcc/
2019-10-16  Peter Bergner 
Jiufu Guo  

PR target/70010
* config/rs6000/rs6000.c (rs6000_can_inline_p): Prohibit inlining if
the callee explicitly disables some isa_flags the caller is using.

gcc.testsuite/
2019-10-16  Peter Bergner 
Jiufu Guo  

PR target/70010
* gcc.target/powerpc/pr70010.c: New test.
* gcc.target/powerpc/pr70010-1.c: New test.
* gcc.target/powerpc/pr70010-2.c: New test.
* gcc.target/powerpc/pr70010-3.c: New test.
* gcc.target/powerpc/pr70010-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr70010-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr70010-2.c
trunk/gcc/testsuite/gcc.target/powerpc/pr70010-3.c
trunk/gcc/testsuite/gcc.target/powerpc/pr70010-4.c
trunk/gcc/testsuite/gcc.target/powerpc/pr70010.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/testsuite/ChangeLog

[Bug target/92071] [10 regression][ARM] ice in gen_movsi, at config/arm/arm.md:5378

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-16
 CC||wilco at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|ice in gen_movsi, at|[10 regression][ARM] ice in
   |config/arm/arm.md:5378  |gen_movsi, at
   ||config/arm/arm.md:5378
 Ever confirmed|0   |1

--- Comment #1 from Wilco  ---
Confirmed. It's another unaligned movsi being generated during Expand, similar
to pr91708.

[Bug tree-optimization/92056] [10 Regression] ice in expr_object_size, at tree-object-si ze.c:675 with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 47048
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47048&action=edit
gcc10-pr92056.patch

Untested fix.

[Bug tree-optimization/92056] [10 Regression] ice in expr_object_size, at tree-object-si ze.c:675 with -O3

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Seems a bug introduced in r120581, COND_EXPR really needs to be handled like a
PHI node, which is handled as:
for (i = 0; i < gimple_phi_num_args (stmt); i++)
  {
tree rhs = gimple_phi_arg (stmt, i)->def;

if (object_sizes[object_size_type][varno]
== unknown[object_size_type])
  break;

if (TREE_CODE (rhs) == SSA_NAME)
  reexamine |= merge_object_sizes (osi, var, rhs, 0);
else if (osi->pass == 0)
  expr_object_size (osi, var, rhs);
  }
and the break once we reach unknown size is what was missing in the COND_EXPR
handling code.

That said, I'm additionally wondering if determine_min_objsize shouldn't call
init_object_sizes ();
because otherwise it will handle only a very small subset of what
compute_builtin_object_size can do.  get_destination_size from
gimple-ssa-sprintf.c calls it during the strlen pass if *printf is encountered,
but if it is not, then no SSA_NAME objsz computation is done.

[Bug fortran/92122] [coarrays, polymophism] Error 'must be a scalar of type LOCK_TYPE'

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

   Keywords|rejects-valid   |ice-on-valid-code

--- Comment #1 from Tobias Burnus  ---
Bill wrote to J3:
> > • Type lockpointer does not have a potential subobject component of 
> > lock_type.
> "Type locktype has a component of type lock_type (obviously).  A subobject is
> just a part of an object that can be referenced (3.141), so the component is
> clearly a subobject of x.  So, could you explain how the word “potential” 
> makes
> the statement above true?"
>
> > • In the LOCK statement, the lock variable is not a coarray
> > (though it is pointer-associated with a coarray).
>
> Having something pointer associated with a coarray does not make the pointer 
> itself a coarray.  Only being declared to be a coarray (having a codimension)
> makes something a coarray.

I concur.

Hence, that makes the code in comment 0 invalid – threre is still the issue
with the __tmp_type_… name which leaks through.


Additionally, motivated by the second code in comment 0, I wrote the following
program (four). It and the simplified 'three' resolve but then give an ICE at

0x5d9c7c convert(tree_node*, tree_node*)
../../repos/gcc/gcc/fortran/convert.c:119
0x969fba trans_associate_var
../../repos/gcc/gcc/fortran/trans-stmt.c:2139

! -- three 
class(*), allocatable :: q[:]
allocate(integer :: q[*])

select type (q)
type is (integer)
q[1] = 5
end select
end

! -- four 
use, intrinsic :: iso_fortran_env, only : lock_type

class(*), allocatable :: q[:]
allocate(lock_type :: q[*])

select type (q)
type is (lock_type)
lock(q)
end select
end

[Bug target/70010] powerpc: -flto forgets 'no-vsx' function attributes

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc-
   |patches/2019-10/msg01037.ht |patches/2019-10/msg01154.ht
   |ml  |ml
 Resolution|--- |FIXED

--- Comment #8 from Peter Bergner  ---
Fixed on trunk.  Back ports waiting for trunk burn in.

[Bug libstdc++/92124] New: std::vector copy-assigning when it should move-assign.

[cassio.neri at gmail dot com]

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

Bug ID: 92124
   Summary: std::vector copy-assigning when it should move-assign.
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cassio.neri at gmail dot com
  Target Milestone: ---

Consider two vectors a and rv. In the situation below a = std::move(rv)
copy-assigns elements of rv into a, violating
[container.requirements.general]/4, Table 83: "All existing elements of a are
either move assigned to or destroyed" (See [1].)

It happens with std::vector> such that:

1) X's move-constructor might throw (though I'm assigning and not
constructing);
2) A does not propagate on move-assignment and allocators used by source and
target vectors do not compare equal.

The following MCVE contains some boiler plate and the most important parts are
indicated by comments.

#include 
#include 
#include 
#include 

struct X {
X() = default;
X(const X&) = default;

// Move constructor might throw
X(X&&) noexcept(false) {} // "= default" changes reported behaviour

// Tracking calls to assignment functions
X& operator=(const X&) {
putchar('c'); return *this;
}
X& operator=(X&&) noexcept(true) {
putchar('m'); return *this;
}
};

unsigned counter = 0;

template 
struct A : std::allocator {

template 
struct rebind { using other = A; };

A() : std::allocator(), id(++counter) {}

// Does not propagate
using propagate_on_container_move_assignment = std::false_type;

// Does not always compare equal
using is_always_equal = std::false_type;
bool operator ==(const A& o) { return id == o.id; }
bool operator !=(const A& o) { return id != o.id; }

unsigned id;
};

int main() {
std::vector> a(2), rv(2);
a = std::move(rv);
}

Running the code above outputs "cc" (instead of "mm") confirming the two
elements of rv are copy-assigned into a.

See relevant discussion in [2] (with link to possible culprit lines of code in
libstdc++) and life example above in [3]

[1]
https://timsong-cpp.github.io/cppwp/n4659/container.requirements#tab:containers.container.requirements
[2]
https://stackoverflow.com/questions/58378051/issue-when-compiling-libstdc-with-clang?noredirect=1#comment103136248_58378051
[3] https://godbolt.org/z/EgkPrP

[Bug tree-optimization/92115] [10 Regression] ICE in gimple_cond_get_ops_from_tree, at gimple-expr.c:577

[asolokha at gmx dot com]

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

--- Comment #4 from Arseny Solokha  ---
(In reply to Ilya Leoshkevich from comment #3)
> Arseny, how did you find this? Did you just run the regtest? I wonder why
> didn't I see it during my test runs.

My test harness continuously compiles a corpus of C, C++, and Fortran code with
the latest weekly trunk snapshot, picking a random set of compiler options and
parameters for each file. gcc and libstdc++ test suites constitute an important
part of that corpus. When compiling files from these test suites, my test
harness ignores compiler options specified there for DejaGNU and uses its own
randomly chosen ones instead. Of course, this approach is not suitable for
testing run-time correctness.

So, if there are no testcases in the test suite yet which could trigger that
specific code path in gcc internals, probably due to an unusual set of compiler
options, your testing won't reveal a problem reported here. That is probably
OK, as regression testing have to be deterministic, after all.

[Bug testsuite/92125] New: New test gcc.dg/ipa/pr91088.c introduced in r277054 fails

[seurer at gcc dot gnu.org]

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

Bug ID: 92125
   Summary: New test gcc.dg/ipa/pr91088.c introduced in r277054
fails
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

I saw this on both LE and BE powerpc64 systems.

Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/pr91088.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never   -O3 -fdump-ipa-cp-details
-fno-inline -S -o pr91088.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/pr91088.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O3 -fdump-ipa-cp-details
-fno-inline -S -o pr91088.s
PASS: gcc.dg/ipa/pr91088.c (test for excess errors)
PASS: gcc.dg/ipa/pr91088.c scan-ipa-dump-times cp "Creating a specialized node
of callee1" 1
PASS: gcc.dg/ipa/pr91088.c scan-ipa-dump-times cp "Creating a specialized node
of callee2" 1
PASS: gcc.dg/ipa/pr91088.c scan-ipa-dump-times cp "Creating a specialized node
of callee3" 1
PASS: gcc.dg/ipa/pr91088.c scan-ipa-dump cp "op0\\[offset: 32],\\(\\(short
int\\) #\\),\\(\\(int\\) #\\),\\(1300 / #\\) == 19"
PASS: gcc.dg/ipa/pr91088.c scan-ipa-dump cp "op0\\[ref offset: 0],\\(# \\^ 1\\)
<"
FAIL: gcc.dg/ipa/pr91088.c scan-ipa-dump cp "op0,\\(\\(char\\)
#\\),\\(\\(int\\) #\\),\\(1 - #\\),\\(# \\* 3\\),\\(27 % #\\) <"
testcase /home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/ipa/ipa.exp completed
in 0 seconds

=== gcc Summary ===

# of expected passes6
# of unexpected failures1

[Bug middle-end/92110] too many -Warray-bounds warnings for a loop buffer overflow

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
The __builtin_warning patch implements the per-location solution
(https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01015.html) but I think the more
aggregate approach would be more informative and so preferable.

[Bug c++/92015] [9/10 Regression] internal compiler error: in cxx_eval_array_reference, at cp/constexpr.c:2568

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
So, we try to constexpr evaluate
(TARGET_EXPR ("hello")}>).c[0]
which has a location wrapper in.  Normally location wrappers are stripped early
in cxx_eval_constant_expression: STRIP_ANY_LOCATION_WRAPPER (t);
The problem is that when cxx_eval_constant_expression is called on CONSTRUCTOR,
it does:
5233  if (TREE_CONSTANT (t) && reduced_constant_expression_p (t))
5234{
5235  /* Don't re-process a constant CONSTRUCTOR, but do fold it to
5236 VECTOR_CST if applicable.  */
5237  verify_constructor_flags (t);
5238  if (TREE_CONSTANT (t))
5239return fold (t);
5240}
5241  r = cxx_eval_bare_aggregate (ctx, t, lval,
5242   non_constant_p, overflow_p);
While cxx_eval_bare_aggregate strips them away, as it recurses on each element,
if the CONSTRUCTOR is TREE_CONSTANT and reduced constant expression (which is
happy about STRING_CSTs wrapped in VIEW_CONVERT_EXPRs or about INTEGER_CSTs
wrapped in NON_LVALUE_EXPRs, because initializer_constant_valid_p_1 recurses on
both), nothing is changed.
The easiest fix is IMHO when we are picking something out of a CONSTRUCTOR add
the STRIP_ANY_LOCATION_WRAPPER there.

[Bug c++/92015] [9/10 Regression] internal compiler error: in cxx_eval_array_reference, at cp/constexpr.c:2568

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 47049
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47049&action=edit
gcc10-pr92015.patch

Like this.  Untested.

[Bug fortran/78260] ICE in gimplify_expr, at gimplify.c:11939

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org
 Depends on||85701
   Assignee|unassigned at gcc dot gnu.org  |burnus at gcc dot 
gnu.org

--- Comment #6 from Thomas Schwinge  ---
(In reply to Tobias Burnus from comment #3)
> This one is fixed with GCC 9:
> 5 | !$acc declare present(s)
>   |1
> Error: Object ‘s’ is not a variable at (1)

(Given 'subroutine s'.)

For the record (in case we ever get to backporting these things to release
branches), that was fixed in PR85701.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85701
[Bug 85701] [openacc] ICE in mark_scope_block_unused, at tree-ssa-live.c:364

[Bug testsuite/92126] New: [10 regression] gcc.dg/vect/pr62171.c fails after r276876 on power7

[seurer at gcc dot gnu.org]

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

Bug ID: 92126
   Summary: [10 regression] gcc.dg/vect/pr62171.c fails after
r276876 on power7
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This appears to be working OK everywhere else, just not on power 7.

Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr62171.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never   -maltivec -mvsx
-mno-allow-movmisalign -ftree-vectorize -fno-tree-loop-distribute-patterns
-fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S -o pr62171.s  
 (timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr62171.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -maltivec -mvsx
-mno-allow-movmisalign -ftree-vectorize -fno-tree-loop-distribute-patterns
-fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S -o pr62171.s
PASS: gcc.dg/vect/pr62171.c (test for excess errors)
PASS: gcc.dg/vect/pr62171.c scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/pr62171.c scan-tree-dump-not vect "versioned"
Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr62171.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -flto -ffat-lto-objects
-maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize
-fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2
-fdump-tree-vect-details -S -o pr62171.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/pr62171.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -flto -ffat-lto-objects
-maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize
-fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2
-fdump-tree-vect-details -S -o pr62171.s
PASS: gcc.dg/vect/pr62171.c -flto -ffat-lto-objects (test for excess errors)
PASS: gcc.dg/vect/pr62171.c -flto -ffat-lto-objects  scan-tree-dump-times vect
"vectorized 1 loops" 1
FAIL: gcc.dg/vect/pr62171.c -flto -ffat-lto-objects  scan-tree-dump-not vect
"versioned"
testcase /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/vect.exp completed
in 2 seconds

=== gcc Summary ===

# of expected passes4
# of unexpected failures2

[Bug c++/91055] alignof () evaluated before layout is complete?

[kamleshbhalui at gmail dot com]

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

Kamlesh Kumar  changed:

   What|Removed |Added

 CC||kamleshbhalui at gmail dot com

--- Comment #1 from Kamlesh Kumar  ---
This fixes it.

diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index f427c4f4d3e..928dc887956 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -1791,6 +1791,11 @@ cxx_alignof_expr (tree e, tsubst_flags_t complain)
   if (e == error_mark_node)
 return error_mark_node;

+  if (current_class_type && TYPE_BEING_DEFINED (current_class_type))
+{
+  error ("invalid application of % to a field of a class still
being defined");
+  return error_mark_node;
+}
   if (processing_template_decl)
 {
   e = build_min (ALIGNOF_EXPR, size_type_node, e);

[Bug testsuite/92127] New: [10 regression] gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c fails after r276645 on power7

[seurer at gcc dot gnu.org]

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

Bug ID: 92127
   Summary: [10 regression]
gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr2
9925.c fails after r276645 on power7
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Only seeing this on power 7.

Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/-fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never  -maltivec -c -o
powerpc_altivec_ok7704.o powerpc_altivec_ok7704.c(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/ -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never -maltivec -c -o
powerpc_altivec_ok7704.o powerpc_altivec_ok7704.c
Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/ vmx_hw_available7704.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -mno-vsx  -lm  -o vmx_hw_available7704.exe   
(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/ vmx_hw_available7704.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -mno-vsx -lm -o vmx_hw_available7704.exe
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test/gcc::/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c
   -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never   -O2 -ftree-vectorize -fvect-cost-model=dynamic
-fno-common -maltivec -fdump-tree-vect-details -ffast-math  -lm  -o
./costmodel-fast-math-vect-pr29925.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -ftree-vectorize -fvect-cost-model=dynamic
-fno-common -maltivec -fdump-tree-vect-details -ffast-math -lm -o
./costmodel-fast-math-vect-pr29925.exe
PASS: gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c (test for
excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test/gcc::/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
PASS: gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c execution
test
Executing on host: /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/ p8vector_hw_available7704.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -mpower8-vector  -lm  -o
p8vector_hw_available7704.exe(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/ p8vector_hw_available7704.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -mpower8-vector -lm -o p8vector_hw_available7704.exe
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test/gcc::/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c: pattern found 0
times
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-

[Bug fortran/92114] equivalence in module causes ICE

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to urbanjost from comment #0)
> module minimal
> implicit none
> logical,private :: help,h,version,v
> equivalence (help,h),(version,v)
> end module minimal
> 
>  GNU Fortran (GCC) 7.4.0
>  gfortran bug.f90
>  f951: internal compiler error: Segmentation fault
> 
>  might be similar to bug 77381, but error message is different.
>  
>  The only restriction in the standard that seemed to bear on this is
> 
>   C593 (R567) The name of an equivalence-object shall not be a name made
> accessible by use association.
> 
>  but all the variables are PRIVATE. It failed with all variable types I
> tried, not just LOGICAL.

C593 applies to a USEd associated variable.  Nothing is USEd associated
in your example.  C593 covers

% cat a.f90
module m
  integer num
end module m

program foo
   use m
   integer k
   equivalence(k,num)
   num = 1
   print *, k
end program foo
% gfcx -c a.f90
a.f90:8:20:

8 |equivalence(k,num)
  |1
Error: EQUIVALENCE attribute conflicts with USE ASSOCIATED attribute in 'num'
at (1)


For me, the code you posted compiles with 
GNU Fortran (GCC) 10.0.0 20191014 (experimental)
GNU Fortran (GCC) 9.2.1 20191011
GNU Fortran (GCC) 8.3.1 20191010
GNU Fortran (GCC) 7.4.1 20191010
GNU Fortran (GCC) 6.5.0

This may have been fixed by

r242802 | kargl | 2016-11-23 13:44:05 -0800 (Wed, 23 Nov 2016) | 10 lines

2016-11-23  Steven G. Kargl  

PR fortran/78297
* trans-common.c (finish_equivalences): Do not dereference a NULL 
pointer.

2016-11-23  Steven G. Kargl  

PR fortran/78297
* gfortran.dg/pr78297.f90: New test.

[Bug fortran/92114] equivalence in module causes ICE

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #2 from Steve Kargl  ---
On Wed, Oct 16, 2019 at 05:02:50PM +, kargl at gcc dot gnu.org wrote:
> > 
> >  GNU Fortran (GCC) 7.4.0

This was released in Dec 2018, so ...

> This may have been fixed by
> 
> r242802 | kargl | 2016-11-23 13:44:05 -0800 (Wed, 23 Nov 2016) | 10 lines
> 

..., this is certainly in the version of gfortran you have.

[Bug tree-optimization/91996] fold non-constant strlen relational expressions

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Wed Oct 16 17:18:57 2019
New Revision: 277076

URL: https://gcc.gnu.org/viewcvs?rev=277076&root=gcc&view=rev
Log:
PR tree-optimization/91996 - fold non-constant strlen relational expressions

gcc/testsuite/ChangeLog:

PR tree-optimization/91996
* gcc.dg/strlenopt-80.c: New test.
* gcc.dg/strlenopt-81.c: New test.

gcc/ChangeLog:

PR tree-optimization/91996
* tree-ssa-strlen.c (maybe_warn_pointless_strcmp): Improve location
information.
(compare_nonzero_chars): Add an overload.
(count_nonzero_bytes): Add an argument.  Call overload above.
Handle non-constant lengths in some range.
(handle_store): Add an argument.
(check_and_optimize_stmt): Pass an argument to handle_store.


Added:
trunk/gcc/testsuite/gcc.dg/strlenopt-80.c
trunk/gcc/testsuite/gcc.dg/strlenopt-81.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-strlen.c

[Bug tree-optimization/92128] New: fold more non-constant strlen relational expressions

[msebor at gcc dot gnu.org]

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

Bug ID: 92128
   Summary: fold more non-constant strlen relational expressions
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

With pr91996 resolved GCC can make use of strlen range information in some
contexts but not in others.  The test for pr91996 only enabled on a subset of
those where GCC is known to be able to do this, but even for those it is
specially crafted to exercise only the contexts where the optimization was
implemented.  On other targets (e.g., arm-*-*), or even on others such as
aarch64-*-* where the test passes, other similar test cases fail.  This is
because the solution for pr91996 was only put in place for multi-byte
assignments via MEM_REF but not also for calls to memcpy.

$ cat c.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout c.c
typedef __SIZE_TYPE__ size_t;

void f (char *d, const char *s)
{
  if (__builtin_strlen (s) < 5) return;

  __builtin_memcpy (d, s, 16); // when size is a small power of two

  size_t n1 = __builtin_strlen (d);
  if (n1 < 5)  // this is folded to false
__builtin_abort ();
}

void g (char *d, const char *s)
{
  if (__builtin_strlen (s) < 5) return;

  __builtin_memcpy (d, s, 32); // with larger power of two or
non-power-of-two sizes

  size_t n1 = __builtin_strlen (d);
  if (n1 < 5)  // this is not folded
__builtin_abort ();
}


;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=0)

Removing basic block 5
f (char * d, const char * s)
{
  long unsigned int _1;
  __int128 unsigned _5;

   [local count: 1073741824]:
  _1 = __builtin_strlen (s_4(D));
  if (_1 <= 4)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 708669605]:
  _5 = MEM <__int128 unsigned> [(char * {ref-all})s_4(D)];
  MEM <__int128 unsigned> [(char * {ref-all})d_6(D)] = _5;

   [local count: 1073741829]:
  return;

}



;; Function g (g, funcdef_no=1, decl_uid=1937, cgraph_uid=2, symbol_order=1)

Removing basic block 6
Removing basic block 7
g (char * d, const char * s)
{
  size_t n1;
  long unsigned int _1;

   [local count: 1073741824]:
  _1 = __builtin_strlen (s_4(D));
  if (_1 <= 4)
goto ; [51.12%]
  else
goto ; [48.88%]

   [local count: 524845004]:
  __builtin_memcpy (d_5(D), s_4(D), 32);
  n1_7 = __builtin_strlen (d_5(D));
  if (n1_7 <= 4)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741828]:
  return;

}

[Bug tree-optimization/92128] fold more non-constant strlen relational expressions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||83819
   Severity|normal  |enhancement


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 91996, which changed state.

Bug 91996 Summary: fold non-constant strlen relational expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91996

   What|Removed |Added

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

[Bug tree-optimization/91996] fold non-constant strlen relational expressions

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=92128
 Resolution|--- |FIXED

--- Comment #4 from Martin Sebor  ---
Patch committed in 277076.  Bug 92128 tracks some of the remaining folding
opportunities in this are as well as the limited scope of one of the added
tests (strlenopt-80.c).

[Bug tree-optimization/63945] Missing vectorization optimization

[witold.baryluk+gcc at gmail dot com]

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

Witold Baryluk  changed:

   What|Removed |Added

 CC||witold.baryluk+gcc at gmail 
dot co
   ||m

--- Comment #1 from Witold Baryluk  ---
It does vectorize for me on gcc 9.2.1:

-march=skylake-avx512

aa.cpp:34:29: optimized: loop vectorized using 32 byte vectors
aa.cpp:25:27: optimized: loop vectorized using 32 byte vectors


  if (val<100.)
1279:   c5 fb 10 0b vmovsd (%rbx),%xmm1
127d:   c5 fb 10 05 8b 0d 00vmovsd 0xd8b(%rip),%xmm0# 2010
<_IO_stdin_used+0x10>
1284:   00 
1285:   c5 f9 2f c1 vcomisd %xmm1,%xmm0
1289:   76 2b   jbe12b6 <_ZN4TEST4testEv+0xc6>
128b:   c4 e2 7d 19 c9  vbroadcastsd %xmm1,%ymm1
1290:   31 c0   xor%eax,%eax
1292:   66 0f 1f 44 00 00   nopw   0x0(%rax,%rax,1)
  c[i] = val*a[i]+b[i];
1298:   c4 c1 7d 10 04 04   vmovupd (%r12,%rax,1),%ymm0
129e:   c4 c2 f5 a8 44 05 00vfmadd213pd
0x0(%r13,%rax,1),%ymm1,%ymm0
12a5:   c5 fd 11 04 07  vmovupd %ymm0,(%rdi,%rax,1)
for (unsigned int i=0; i
::operator delete(__p);
12b6:   c5 f8 77vzeroupper 


Similarly:

-march=knm

aa.cpp:34:29: optimized: loop vectorized using 64 byte vectors
aa.cpp:25:27: optimized: loop vectorized using 64 byte vectors

  if (val<100.)
15bc:   31 c0   xor%eax,%eax
15be:   66 90   xchg   %ax,%ax
  c[i] = val*a[i]+b[i];
15c0:   62 f1 fd 48 28 04 01vmovapd (%rcx,%rax,1),%zmm0
15c7:   62 f2 ed 48 a8 04 06vfmadd213pd (%rsi,%rax,1),%zmm2,%zmm0
15ce:   62 d1 fd 48 11 04 01vmovupd %zmm0,(%r9,%rax,1)
for (unsigned int i=0; i

(plus a lot of handling for unaligned stack).

-march=znver2

aa.cpp:34:29: optimized: loop vectorized using 32 byte vectors
aa.cpp:25:27: optimized: loop vectorized using 32 byte vectors

  if (val<100.)
1279:   c5 fb 10 0b vmovsd (%rbx),%xmm1
127d:   c5 fb 10 05 8b 0d 00vmovsd 0xd8b(%rip),%xmm0# 2010
<_IO_stdin_used+0x10>
1284:   00 
1285:   c5 f9 2f c1 vcomisd %xmm1,%xmm0
1289:   76 33   jbe12be <_ZN4TEST4testEv+0xce>
128b:   c4 e2 7d 19 c9  vbroadcastsd %xmm1,%ymm1
1290:   31 c0   xor%eax,%eax
1292:   66 66 2e 0f 1f 84 00data16 nopw %cs:0x0(%rax,%rax,1)
1299:   00 00 00 00 
129d:   0f 1f 00nopl   (%rax)
  c[i] = val*a[i]+b[i];
12a0:   c4 c1 7d 10 04 04   vmovupd (%r12,%rax,1),%ymm0
12a6:   c4 c2 f5 a8 44 05 00vfmadd213pd
0x0(%r13,%rax,1),%ymm1,%ymm0
12ad:   c5 fd 11 04 07  vmovupd %ymm0,(%rdi,%rax,1)
for (unsigned int i=0; i

-march=core2

aa.cpp:34:29: optimized: loop vectorized using 16 byte vectors
aa.cpp:25:27: optimized: loop vectorized using 16 byte vectors

  if (val<100.)
1276:   f2 0f 10 13 movsd  (%rbx),%xmm2
127a:   f2 0f 10 05 8e 0d 00movsd  0xd8e(%rip),%xmm0# 2010
<_IO_stdin_used+0x10>
1281:   00 
1282:   66 0f 2f c2 comisd %xmm2,%xmm0
1286:   76 40   jbe12c8 <_ZN4TEST4testEv+0xd8>
1288:   31 c0   xor%eax,%eax
128a:   66 0f 14 d2 unpcklpd %xmm2,%xmm2
128e:   66 90   xchg   %ax,%ax
  c[i] = val*a[i]+b[i];
1290:   f3 0f 7e 44 05 00   movq   0x0(%rbp,%rax,1),%xmm0
1296:   f3 41 0f 7e 0c 04   movq   (%r12,%rax,1),%xmm1
129c:   66 0f 16 44 05 08   movhpd 0x8(%rbp,%rax,1),%xmm0
12a2:   66 0f 59 c2 mulpd  %xmm2,%xmm0
12a6:   66 41 0f 16 4c 04 08movhpd 0x8(%r12,%rax,1),%xmm1
12ad:   66 0f 58 c1 addpd  %xmm1,%xmm0
12b1:   66 0f 13 04 07  movlpd %xmm0,(%rdi,%rax,1)
12b6:   66 0f 17 44 07 08   movhpd %xmm0,0x8(%rdi,%rax,1)
for (unsigned int i=0; i



Looks all pretty optimally vectorized to me.

The code can be made even better, if you ensure proper alignment of std::vector
arrrays, which they might not be at the moment.

[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Created attachment 47050
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47050&action=edit
self-contained program

[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Here's a self-contained program.  AFAICT, pos= has an effect only within the
first record, and thereafter it is ignored.

F2018, 12.3.3.4(4) gives a bulleted list of things that can cause problems for
a user.  My unsolicited advice: Don't mix stream access and formatted output.
:(

[Bug c/92117] Warning from -Wbad-function-cast when casting from bool to int

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
-Wbad-function-cast is a strange legacy warning that is more about GCC's
internal implementation details (of TREE_CODEs) than anything in user code:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00250.html
IOW I wouldn't worry too much about it. But I guess if someone really wants to
change it, they could...

[Bug tree-optimization/92129] New: [10 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:5869

[asolokha at gmx dot com]

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

Bug ID: 92129
   Summary: [10 Regression] ICE in vectorizable_reduction, at
tree-vect-loop.c:5869
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.0-alpha20191013 snapshot (r276943) ICEs when compiling the following
testcase w/ -O1 -ftree-loop-vectorize -fno-tree-copy-prop:

unsigned int lq;
int aw;

void
m2 (int o9)
{
  while (o9 < 2)
{
  for (aw = 0; aw < 2; ++aw)
lq *= aw ? 2 : lq < 2;

  ++o9;
}
}

% gcc-10.0.0-alpha20191013 -O1 -ftree-loop-vectorize -fno-tree-copy-prop -c
k2t5fs2w.c
during GIMPLE pass: vect
k2t5fs2w.c: In function 'm2':
k2t5fs2w.c:5:1: internal compiler error: in vectorizable_reduction, at
tree-vect-loop.c:5869
5 | m2 (int o9)
  | ^~
0x6b8023 vectorizable_reduction(_stmt_vec_info*, _slp_tree*, _slp_instance*,
vec*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191013/work/gcc-10-20191013/gcc/tree-vect-loop.c:5869
0xe91b61 vect_analyze_loop_operations
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191013/work/gcc-10-20191013/gcc/tree-vect-loop.c:1561
0xe91b61 vect_analyze_loop_2
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191013/work/gcc-10-20191013/gcc/tree-vect-loop.c:2033
0xe91b61 vect_analyze_loop(loop*, _loop_vec_info*, vec_info_shared*)
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191013/work/gcc-10-20191013/gcc/tree-vect-loop.c:2336
0xeaa308 try_vectorize_loop_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191013/work/gcc-10-20191013/gcc/tree-vectorizer.c:887
0xeaad0a vectorize_loops()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191013/work/gcc-10-20191013/gcc/tree-vectorizer.c:1107

[Bug tree-optimization/92130] New: Missed vectorization for iteration dependent loads and simple multiplicative accumulators

[witold.baryluk+gcc at gmail dot com]

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

Bug ID: 92130
   Summary: Missed vectorization for iteration dependent loads and
simple multiplicative accumulators
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: witold.baryluk+gcc at gmail dot com
  Target Milestone: ---

Created attachment 47051
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47051&action=edit
Perlin2D noise mesh generation

So,

I do have pretty complex multi level loop spread across many functions, but it
can be all vectorized, but under certain scenarios gcc does not vectorize it
with gcc 9.2.1

I am attaching somehow simplified code with few defines inside to play with it.

The one exposed by default present the biggest challenge to gcc, despite me
able to vectorize it manually.

I tested this on SSE2, AVX2 (cascadelake and znver2), AVX512 (-march=knm and
-march=skylake-avx512) and ARM SVE, with all same effects. I am using
associative math and other flags mentioned in the sourcefile at the top.

The high level overview is like this:

input: A, F, W, maxO, sufficiently aligned d.

foreach y:
  foreach x:
float v = 0.0
float a = 1.0
float f = 1.0
foreach o in [0, maxO):
  v += a * g(f * x, f * y, o, h(o, p))
  a *= A
  f *= F
d[y*W + x] = v

where both g and h are pure functions (relatively complex tho) with no control
flow or data dependent flow.

In some situations if a and f are replaced by a precomputed table of
coefficient for every o, and then used as v += a[o] * g(f[o] * x, f[o] * y,
h(o, p)), it does vectorize, but not always. h(o, p) could also be precomputed,
but I didn't bother as it appears to not have any bad effect on vectorizer.

Vectorizater should vectorize along the 'foreach x', and compute multiple x-s
per-lane completely independently. It is true that when updating a and f, each
lane need to be duplicated, but that can be done by computing it scalarly, and
then broadcasting, or by repeating same constants updates in each lane.

[Bug libstdc++/92124] std::vector copy-assigning when it should move-assign.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-10-16
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
I'm testing a patch now.

[Bug tree-optimization/92129] [10 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:5869

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-10-16
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r276700.

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

[witold.baryluk+gcc at gmail dot com]

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

--- Comment #1 from Witold Baryluk  ---
Created attachment 47052
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47052&action=edit
Minimized test case

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

[witold.baryluk+gcc at gmail dot com]

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

--- Comment #2 from Witold Baryluk  ---
Added a minimized test case that has only one outer loop, and f and h are
removed for simple inlined replacement.

Example diagnostic:

$ gcc -std=c17 -march=knm -O3 -ffast-math -fassociative-math
-ftree-vectorizer-verbose=2 -fopt-info-vec-all -ggdb -Wall mesh_minimal.c -o
mesh_minimal_knm -lm

mesh_minimal.c:34:3: missed: couldn't vectorize loop
mesh_minimal.c:34:3: missed: not vectorized: latch block not empty.
mesh_minimal.c:33:13: note: vectorized 0 loops in function.

[Bug tree-optimization/92131] New: incorrect assumption that (ao >= 0) is always false

[arigo at tunes dot org]

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

Bug ID: 92131
   Summary: incorrect assumption that (ao >= 0) is always false
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arigo at tunes dot org
  Target Milestone: ---

Created attachment 47053
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47053&action=edit
creduce'd C source that miscompiles in -O>=1

The attached reduced snippet miscompiles with "gcc -O1 foo.c -S", or with any
higher optimization level.  It works fine with "gcc -Og foo.c -S".  It also
works fine with "gcc -O1 -fwrapv foo.c -S".  This may sound suspicious, but I'm
rather convinced that it is a bug anyway: -fwrapv should have no effect here,
which should be easy to check because the code contains only a few arithmetic
operations.  Most values involved are loaded from unknown globals, too.

The problem is that the compiled code removes the "if (ao >= 0) {..}"
completely.  This is unexpected, and most likely wrong, because there is no
reason for why ao should always be negative here.  In fact, we can check that
during the first iteration of the loop it will be equal to 0.

The various apparently unrelated checks that come before the loop cannot be
removed.  This code contains a lot of "goto" because it comes from generated
code (pypy project); attempting to change them into equivalent if-else logic
usually makes the bug disappear too.

Reproducers:

* gcc (GCC) 9.1.0 (arch linux x86-64)

$ gcc -O1 foomin1.c -S
$ cat foomin1.s
...
callsee_me_here@PLT
.L11:
callerror@PLT
...

* gcc (Debian 8.3.0-6) 8.3.0, aarch64

$ gcc -O1 foomin1.c -S
$ cat foomin1.s
...
bl  see_me_here
bl  error
...

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

[witold.baryluk+gcc at gmail dot com]

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

--- Comment #3 from Witold Baryluk  ---
If only the frequency is updated in the inner loop:

frequency *= 2.131f;

function fill_data is vectorized:

mesh_minimal.c:34:3: optimized: loop vectorized using 64 byte vectors
mesh_minimal.c:33:13: note: vectorized 1 loops in function.


However if amplitude is updated in the inner loop:

amplitude *= 0.781f;

function fill_data is NOT vectorized.

mesh_minimal.c:34:3: missed: couldn't vectorize loop
mesh_minimal.c:34:3: missed: not vectorized: latch block not empty.
mesh_minimal.c:33:13: note: vectorized 0 loops in function.


Here for reference:


/* line 20 */ static float perlin1d(float x) {
  float accum = 0.0;
  float frequency = 1.0;
  float amplitude = 1.0;
  for (int i = 0; i < 8; i++) {
accum += amplitude * (sinf(x * frequency + (float)i));
frequency *= 2.131f;
amplitude *= 0.781f;
  }
  return accum;
}

__attribute__((noinline))
/* line 33 */ static void fill_data(int width, float * __restrict__
height_data, float scale) {
  /* line 34 */ for (int i = 0; i < width; i++) {
height_data[i] = perlin1d(i);
  }
}

[Bug target/87243] FSF GCC needs to do something special (like using xcrun) on darwin18 to find system headers in SDK

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
Author: iains
Date: Wed Oct 16 19:22:17 2019
New Revision: 277079

URL: https://gcc.gnu.org/viewcvs?rev=277079&root=gcc&view=rev
Log:
[Darwin] Pick up SDKROOT as the sysroot fallback.

For compatibility with xcrun and the behaviour of the clang driver, make use
of the setting of the SDKROOT environment variable when it is available.
This applies to both finding headers and libraries (i.e. it is also passed to
ld64).

Priority:
1. User's command-line specified --sysroot= or -isysroot.
2. The SDKROOT variable when set, and validated.
3. Any sysroot provided by --with-sysroot= configuration parameter.

SDKROOT is checked thus:
1. Presence.
2. That it starts with / (i.e. 'absolute').
3. That it is not / only (since that's the default).
4. That it is readable by the process executing the driver.

This is pretty much the same rule set as used by the clang driver.

NOTE: (3) might turn out to be overly restrictive in the case that we
have configured with --with-sysroot= and then we want to run on a system
with an installation of the headers/libraries in /. We can revisit this
if that turns out to be an important use-case.

So one can do:

xcrun --sdk macosx /path/to/gcc 

and that provides the SDK path as the sysroot to GCC as expected.

CAVEAT: An unfortunate effect of the fact that gcc (and g++) are
executables in the Xcode installation, which are found ahead of any such
named in the
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/TeX/texbin:/usr/local/tools/gcc-2016/bin:

PATH=/path/to/gcc/install:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/TeX/texbin:/usr/local/tools/gcc-2016/bin
xcrun --sdk macosx gcc 

does *not* work, instead that executes the clang from the xcode/commmand
line tools installation.

PATH=/path/to/gcc/install:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Library/TeX/texbin:/usr/local/tools/gcc-2016/bin
xcrun --sdk macosx x64_64-apple-darwinXX-gcc ...

does work as expected, however.

2019-10-16  Iain Sandoe  

Backport from mainline
2019-10-03  Iain Sandoe  

PR target/87243
* config/darwin-driver.c (maybe_get_sysroot_from_sdkroot): New.
(darwin_driver_init): Use the sysroot provided by SDKROOT when that
is available and the user has not set one on the command line.


Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/darwin-driver.c

[Bug tree-optimization/83821] local aggregate initialization defeats strlen optimization

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
Author: msebor
Date: Wed Oct 16 19:24:36 2019
New Revision: 277080

URL: https://gcc.gnu.org/viewcvs?rev=277080&root=gcc&view=rev
Log:
PR tree-optimization/83821 - local aggregate initialization defeats strlen
optimization

gcc/ChangeLog:

PR tree-optimization/83821
* tree-ssa-strlen.c (maybe_invalidate): Add argument.  Consider
the length of a string when available.
(handle_builtin_memset) Add argument.
(handle_store, strlen_check_and_optimize_call): Same.
(check_and_optimize_stmt): Same.  Pass it to callees.

gcc/testsuite/ChangeLog:

PR tree-optimization/83821
* c-c++-common/Warray-bounds-4.c: Remove XFAIL.
* gcc.dg/strlenopt-82.c: New test.
* gcc.dg/strlenopt-83.c: Same.
* gcc.dg/strlenopt-84.c: Same.
* gcc.dg/strlenopt-85.c: Same.
* gcc.dg/strlenopt-86.c: Same.
* gcc.dg/tree-ssa/calloc-4.c: Same.
* gcc.dg/tree-ssa/calloc-5.c: Same.


Added:
trunk/gcc/testsuite/gcc.dg/strlenopt-82.c
trunk/gcc/testsuite/gcc.dg/strlenopt-83.c
trunk/gcc/testsuite/gcc.dg/strlenopt-84.c
trunk/gcc/testsuite/gcc.dg/strlenopt-85.c
trunk/gcc/testsuite/gcc.dg/strlenopt-86.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/calloc-4.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/calloc-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Warray-bounds-4.c
trunk/gcc/tree-ssa-strlen.c

[Bug tree-optimization/92131] incorrect assumption that (ao >= 0) is always false

[arigo at tunes dot org]

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

--- Comment #1 from Armin Rigo  ---
Comment on attachment 47053
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47053
creduce'd C source that miscompiles in -O>=1

BTW I just noticed that the reduced code is highly self-recursive, but that's
just an artifact of the reduction: if we rename the recursive calls so that
they call some other declared-but-not-implemented function, then the results
are the same.

[Bug tree-optimization/83821] local aggregate initialization defeats strlen optimization

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||10.0
 Resolution|--- |FIXED
   Target Milestone|--- |10.0
  Known to fail||7.3.0, 8.3.0, 9.2.0

--- Comment #7 from Martin Sebor  ---
Patch committed in r277080.

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

[witold.baryluk+gcc at gmail dot com]

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

--- Comment #4 from Witold Baryluk  ---
If I reduce minimized test case even further:

only frequency update: VECTORIZED:

static float perlin1d(float x) {
  float accum = 0.0f;
  float amplitude = 1.0f;
  float frequency = 1.0f;
  for (int i = 0; i < 8; i++) {
accum += amplitude * sinf(x * frequency);
frequency *= 2.131f;
  }
  return accum;
}

__attribute__((noinline))
static void fill_data(int width, float * __restrict__ height_data, float scale)
{
  for (int i = 0; i < width; i++) {
height_data[i] = perlin1d(i);
  }
}


only amplitude update: VECTORIZED:

static float perlin1d(float x) {
  float accum = 0.0f;
  float amplitude = 1.0f;
  float frequency = 1.0f;
  for (int i = 0; i < 8; i++) {
accum += amplitude * sinf(x * frequency);
amplitude *= 0.781f;
  }
  return accum;
}

__attribute__((noinline))
static void fill_data(int width, float * __restrict__ height_data, float scale)
{
  for (int i = 0; i < width; i++) {
height_data[i] = perlin1d(i);
  }
}

both frequency and amplitude update: NOT VECTORIZED:

static float perlin1d(float x) {
  float accum = 0.0f;
  float amplitude = 1.0f;
  float frequency = 1.0f;
  for (int i = 0; i < 8; i++) {
accum += amplitude * sinf(x * frequency);
amplitude *= 0.781f;
frequency *= 2.131f;
  }
  return accum;
}

__attribute__((noinline))
static void fill_data(int width, float * __restrict__ height_data, float scale)
{
  for (int i = 0; i < width; i++) {
height_data[i] = perlin1d(i);
  }
}

[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
Bug 83819 depends on bug 83821, which changed state.

Bug 83821 Summary: local aggregate initialization defeats strlen optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83821

   What|Removed |Added

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

[Bug tree-optimization/83543] strlen of a local array member not optimized on some targets

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
The test committed for the solution for pr83821 is disabled for all targets
except LP64 x86_64 to get around this limitation.  Once this is implemented
across all targets the test should be enabled everywhere.

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

[witold.baryluk+gcc at gmail dot com]

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

--- Comment #5 from Witold Baryluk  ---
As a bonus:


static float perlin1d(float x) {
  float accum = 0.0f;
  for (int i = 0; i < 8; i++) {
accum += powf(0.781f, i) * sinf(x * powf(2.131f, i));
  }
  return accum;
}


claims to be vectorized, but really isn't, and has non inline or lowered calls
to sinf and expf_finite.

[Bug target/59888] Darwin linker error "illegal text-relocation" with -shared

[iains at gcc dot gnu.org]

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

--- Comment #19 from Iain Sandoe  ---
(In reply to Zaak from comment #18)
> (In reply to Iain Sandoe from comment #17)
> > by the way, I haven't been able to find a C reproducer for this issue - if
> > you feel we should have a testcase for it perhaps a link test for the
> > fortran example would work?

The Fortran FE folks might also want to convince themselves that the behaviour
FX describes in comment #8 is correct.

> It would be great to have a test to prevent future regressions here. I have
> no experience contributing to GCC or using dejagnu but if people are having
> trouble cooking up a C source to produce an object/library to link the
> Fortran against, I can try to find something to trigger this.

That's not the problem;
When C generates initialisers for function pointers, these end up in the
correct section already, the problem is triggered by something that the 
Fortran FE does differently.

So that means it's going to be hard to make a test that lives outside the
Fortran testsuite.

A testcase does not have to execute to be useful (a link test using the code at
comment #12 would be OK).  However someone has to package the test and decide
where it should live in the Fortran testsuite :-)

> As I mentioned previously this blocks gtk-fortran from linking on Darwin,
> however both GTK and gtk-fortran are not adequately small reproducers.

I will back port this in due course.

[Bug testsuite/92132] New: new test case gcc.dg/vect/vect-cond-reduc-4.c fails with its introduction in r277067

[seurer at gcc dot gnu.org]

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

Bug ID: 92132
   Summary: new test case gcc.dg/vect/vect-cond-reduc-4.c fails
with its introduction in r277067
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This fails on powerpc64 both BE and LE

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/vect-cond-reduc-4.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -flto -ffat-lto-objects
-maltivec -mvsx -mno-allow-movmisalign -ftree-vectorize
-fno-tree-loop-distribute-patterns -fno-vect-cost-model -fno-common -O2
-fdump-tree-vect-details -lm -o ./vect-cond-reduc-4.exe
PASS: gcc.dg/vect/vect-cond-reduc-4.c -flto -ffat-lto-objects (test for excess
errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test/gcc::/home/seurer/gcc/build/gcc-test/gcc:/home/seurer/gcc/build/gcc-test/./gmp/.libs:/home/seurer/gcc/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/build/gcc-test/./isl/.libs:/home/seurer/gcc/build/gcc-test/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
PASS: gcc.dg/vect/vect-cond-reduc-4.c -flto -ffat-lto-objects execution test
gcc.dg/vect/vect-cond-reduc-4.c -flto -ffat-lto-objects : pattern found 0 times
FAIL: gcc.dg/vect/vect-cond-reduc-4.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "LOOP VECTORIZED" 2
PASS: gcc.dg/vect/vect-cond-reduc-4.c -flto -ffat-lto-objects 
scan-tree-dump-times vect "condition expression based on integer induction." 2
testcase /home/seurer/gcc/gcc-test/gcc/testsuite/gcc.dg/vect/vect.exp completed
in 2 seconds

=== gcc Summary ===

# of expected passes6
# of unexpected failures2

[Bug tree-optimization/92130] Missed vectorization for iteration dependent loads and simple multiplicative accumulators

[witold.baryluk+gcc at gmail dot com]

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

--- Comment #6 from Witold Baryluk  ---
I also tested clang with LLVM 10~svn374655 and it does vectorize the loop
properly, even when both frequency and amplitude variables are updated every
loop. 

It still doesn't inline calls to sinf, even if I set -fno-math-errno and other
things from -ffast-math. My random guess is that it is because there is no
hardware support for vectorized sinf, and there is no vectorized variant of
sinf software implementation either. If I provide my own version of sinf using
simple Taylor expansion, clang fully vectorized the code:



  401320:   62 e1 7d 58 fe 3d 56vpaddd 0xd56(%rip){1to16},%zmm0,%zmm23 
  # 402080 <_IO_stdin_used+0x80>
  401327:   0d 00 00 
  40132a:   62 61 7c 48 5b c0   vcvtdq2ps %zmm0,%zmm24
  401330:   62 a1 7c 48 5b ff   vcvtdq2ps %zmm23,%zmm23
  401336:   62 f1 7c 48 10 4c 24vmovups 0x140(%rsp),%zmm1
  40133d:   05 
  40133e:   62 61 3c 40 59 d1   vmulps %zmm1,%zmm24,%zmm26
  401344:   62 61 44 40 59 f9   vmulps %zmm1,%zmm23,%zmm31
  40134a:   62 f1 7c 48 10 4c 24vmovups 0x100(%rsp),%zmm1
  401351:   04 
  401352:   62 61 3c 40 59 d9   vmulps %zmm1,%zmm24,%zmm27
  401358:   62 f1 44 40 59 c9   vmulps %zmm1,%zmm23,%zmm1
  40135e:   62 01 2c 40 59 ca   vmulps %zmm26,%zmm26,%zmm25
  401364:   62 f1 7c 48 10 54 24vmovups 0x80(%rsp),%zmm2
  40136b:   02 
  40136c:   62 61 3c 40 59 e2   vmulps %zmm2,%zmm24,%zmm28
  401372:   62 f1 44 40 59 d2   vmulps %zmm2,%zmm23,%zmm2
  401378:   62 02 25 40 ac ca   vfnmadd213ps %zmm26,%zmm27,%zmm25
  40137e:   62 f1 7c 48 10 5c 24vmovups 0x40(%rsp),%zmm3
  401385:   01 
  401386:   62 61 3c 40 59 eb   vmulps %zmm3,%zmm24,%zmm29
  40138c:   62 f1 44 40 59 db   vmulps %zmm3,%zmm23,%zmm3
  401392:   62 01 1c 40 59 d4   vmulps %zmm28,%zmm28,%zmm26
  401398:   62 01 04 40 59 df   vmulps %zmm31,%zmm31,%zmm27
  40139e:   62 02 15 40 ac d4   vfnmadd213ps %zmm28,%zmm29,%zmm26
  4013a4:   62 f1 7c 48 10 6c 24vmovups -0x40(%rsp),%zmm5
  4013ab:   ff 
  4013ac:   62 f1 3c 40 59 e5   vmulps %zmm5,%zmm24,%zmm4
  4013b2:   62 f1 44 40 59 ed   vmulps %zmm5,%zmm23,%zmm5
  4013b8:   62 61 6c 48 59 e2   vmulps %zmm2,%zmm2,%zmm28
  4013be:   62 f1 7c 48 10 7c 24vmovups -0x80(%rsp),%zmm7
  4013c5:   fe 
  4013c6:   62 f1 3c 40 59 f7   vmulps %zmm7,%zmm24,%zmm6
  4013cc:   62 f1 44 40 59 ff   vmulps %zmm7,%zmm23,%zmm7
  4013d2:   62 61 5c 48 59 ec   vmulps %zmm4,%zmm4,%zmm29
  4013d8:   62 61 54 48 59 f5   vmulps %zmm5,%zmm5,%zmm30
  4013de:   62 62 4d 48 ac ec   vfnmadd213ps %zmm4,%zmm6,%zmm29
  4013e4:   62 d1 3c 40 59 e3   vmulps %zmm11,%zmm24,%zmm4
  4013ea:   62 d1 44 40 59 f3   vmulps %zmm11,%zmm23,%zmm6
  4013f0:   62 02 75 48 ac df   vfnmadd213ps %zmm31,%zmm1,%zmm27
  4013f6:   62 d1 3c 40 59 cc   vmulps %zmm12,%zmm24,%zmm1
  4013fc:   62 41 44 40 59 fc   vmulps %zmm12,%zmm23,%zmm31
  401402:   62 71 5c 48 59 c4   vmulps %zmm4,%zmm4,%zmm8
  401408:   62 62 65 48 ac e2   vfnmadd213ps %zmm2,%zmm3,%zmm28
  40140e:   62 72 75 48 ac c4   vfnmadd213ps %zmm4,%zmm1,%zmm8
  401414:   62 d1 3c 40 59 ce   vmulps %zmm14,%zmm24,%zmm1
  40141a:   62 d1 44 40 59 d6   vmulps %zmm14,%zmm23,%zmm2
  401420:   62 62 45 48 ac f5   vfnmadd213ps %zmm5,%zmm7,%zmm30
  401426:   62 d1 3c 40 59 df   vmulps %zmm15,%zmm24,%zmm3
  40142c:   62 d1 44 40 59 e7   vmulps %zmm15,%zmm23,%zmm4
  401432:   62 f1 74 48 59 e9   vmulps %zmm1,%zmm1,%zmm5
  401438:   62 f1 4c 48 59 fe   vmulps %zmm6,%zmm6,%zmm7
  40143e:   62 71 6c 48 59 ca   vmulps %zmm2,%zmm2,%zmm9
  401444:   62 f2 65 48 ac e9   vfnmadd213ps %zmm1,%zmm3,%zmm5
  40144a:   62 b1 3c 40 59 c9   vmulps %zmm17,%zmm24,%zmm1
  401450:   62 f2 05 40 ac fe   vfnmadd213ps %zmm6,%zmm31,%zmm7
  401456:   62 b1 44 40 59 d9   vmulps %zmm17,%zmm23,%zmm3
  40145c:   62 b1 3c 40 59 f2   vmulps %zmm18,%zmm24,%zmm6
  401462:   62 21 44 40 59 fa   vmulps %zmm18,%zmm23,%zmm31
  401468:   62 72 5d 48 ac ca   vfnmadd213ps %zmm2,%zmm4,%zmm9
  40146e:   62 f1 74 48 59 d1   vmulps %zmm1,%zmm1,%zmm2
  401474:   62 f1 64 48 59 e3   vmulps %zmm3,%zmm3,%zmm4
  40147a:   62 f2 4d 48 ac d1   vfnmadd213ps %zmm1,%zmm6,%zmm2
  401480:   62 f2 05 40 ac e3   vfnmadd213ps %zmm3,%zmm31,%zmm4
  401486:   62 b1 3c 40 59 cc   vmulps %zmm20,%zmm24,%zmm1
  40148c:   62 b1 3c 40 59 dd   vmulps %zmm21,%zmm24,%zmm3
  401492:   62 f1 74 48 59 f1   vmulps %zmm1,%zmm1,%zmm6
  401498:   62 21 44 40 59 fc   vmulps %zmm20,%zmm23,%zmm31
  40149e:   62 f2 65 48 ac f1   vfnmadd213ps %zmm1,%zmm3,%z

[Bug tree-optimization/92131] incorrect assumption that (ao >= 0) is always false

[arigo at tunes dot org]

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

--- Comment #2 from Armin Rigo  ---
Created attachment 47054
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47054&action=edit
slightly different version, with comments showing the expected values

[Bug tree-optimization/92131] incorrect assumption that (ao >= 0) is always false

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The testcase is not very good because it is missing main and calling the
function with some arguments that will trigger the miscompilation.
Anyway, at least at -O2 it seems to be a VRP bug to me:
ao_31 = ASSERT_EXPR ;
Intersecting
  long int ~[-7, -1]  EQUIVALENCES: { ao_23 } (1 elements)
and
  long int [-INF, e.7_8 + 9223372036854775806]  EQUIVALENCES: { } (0 elements)
to
  long int [-INF, -8]  EQUIVALENCES: { ao_23 } (1 elements)
where e.7_8 is VARYING and am_13 is too.
  am_28 = ASSERT_EXPR ;
  b.9_11 = b;
  ao_23 = b.9_11 + am_28;
  ao_31 = ASSERT_EXPR ;
ao_31 is the ao value at the see_me_here call.
There is
  if (am >= 0)
b = -am;
  ao = am + b;
  f = ao & 7;
  if (f == 0)
so if am is non-negative, then ao is 0, but if am is negative, then a VARYING
long is added to it and all we know is that am < e (am_13 < e.7_8) for a
VARYING e.7_8.  The 9223372036854775806 is 0x7ffe and that looks
wrong to me.
>From the (unsigned long) ao_23 <= 18446744073709551608 assertion we know that
the low 3 bits are 0, e.g. ~[-7, -1], but where the  + 9223372036854775806
comes from is unclear.  I'd think that for ao_23 we should have [-INF, e.7_8-1]
range or so.

[Bug testsuite/92127] [10 regression] gcc.dg/vect/costmodel/ppc/costmodel-fast-math-vect-pr29925.c fails after r276645 on power7

[seurer at gcc dot gnu.org]

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

--- Comment #1 from seurer at gcc dot gnu.org ---
Also this test:  

FAIL: gcc.dg/vect/costmodel/ppc/costmodel-pr37194.c scan-tree-dump-times vect
"vectorization not profitable" 1