[Bug tree-optimization/15596] [8/9/10 Regression] Missed optimization with bitfields with return value

[rguenther at suse dot de]

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

--- Comment #33 from rguenther at suse dot de  ---
On Tue, 14 Jan 2020, pinskia at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15596
> 
> Andrew Pinski  changed:
> 
>What|Removed |Added
> 
>Assignee|rguenth at gcc dot gnu.org |pinskia at gcc dot 
> gnu.org
>Target Milestone|8.4 |11.0
> 
> --- Comment #32 from Andrew Pinski  ---
> Mine for GCC 11.  I have patches which improve this a lot.
> The problem right now is the padding.
> 
> I have an idea where we initialize all structs non-addressed local variables
> that have a non VOIDmode right before their first use.
> Kinda like init-regs does on the RTL but a little more complex.
> 
> That is having:
> bitstr fun(int s, int l)
> {
>   bitstr res;
>   *(int*)&res = 0;
>   res.a  = s;
>   res.b  = 1;
>   res.c  = 0;
>   res.d  = l;
>   return res;
> }
> 
> Will produce better code always :).

Something like init-regs I'd not like.  But the above should be
detectable by store-merging in some way - store-merging can
merge across "uninitialized" bits (by using zeroing or any
other convenient value).

[Bug middle-end/45274] __restrict__ type qualifier does not work on pointers to bitfields

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|rguenth at gcc dot gnu.org |pinskia at gcc dot 
gnu.org

--- Comment #5 from Andrew Pinski  ---
Mine.  With my bit-field lowering and a patch to reassociation to some handle
BIT_INSERT optimizations, we are able to optimize this to just load/store.

[Bug fortran/93253] Regression on non-standard hex constant syntax

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||markeggleston at gcc dot 
gnu.org
 Resolution|--- |INVALID

--- Comment #2 from markeggleston at gcc dot gnu.org ---
As indicated in comment 1. Non-standard BOZ can be used with the
-fallow-invalid-boz option.

Standard use is encouraged.

[Bug ipa/93252] Warning for symbols that could be internalized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-14
 CC||marxin at gcc dot gnu.org
  Component|c   |ipa
Version|unknown |10.0
 Ever confirmed|0   |1

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

[Bug tree-optimization/15596] [8/9/10 Regression] Missed optimization with bitfields with return value

[pinskia at gcc dot gnu.org]

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

--- Comment #34 from Andrew Pinski  ---
(In reply to rguent...@suse.de from comment #33) 
> Something like init-regs I'd not like.  But the above should be
> detectable by store-merging in some way - store-merging can
> merge across "uninitialized" bits (by using zeroing or any
> other convenient value).

The problem is store merging might be too late.  I have bit-field lowering
right now right before PRE.  that means we have lost information before we get
to store-merging.  I have been working on the regressions that bit-field
lowering and store-merging testcases are the biggest one; I have decided to
implement that inside reassoc instead as we are really reassociating
BIT_INSERT_EXPRs and are able to optimize some of them into byte swaps, vector
constructors, etc.

[Bug ipa/69678] Missed function specialization + partial devirtualization opportunity

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||luoxhu at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
@luoxhu: Can we close this PR?

[Bug ipa/69678] Missed function specialization + partial devirtualization opportunity

[luoxhu at gcc dot gnu.org]

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

luoxhu at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from luoxhu at gcc dot gnu.org ---
Fixed.

[Bug middle-end/93246] [8/9/10 Regression] Unexpected program behavior when -fsanitize=address and -O2/O3 used

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Richard Guenther :

https://gcc.gnu.org/g:6b8df3e421b56bb7853a158b889f5e45611fd31f

commit r10-5940-g6b8df3e421b56bb7853a158b889f5e45611fd31f
Author: Richard Biener 
Date:   Tue Jan 14 08:43:32 2020 +0100

PR middle-end/93246 - missing alias subsets

Starting with the introduction of TYPE_TYPELESS_STORAGE the situation
of having a alias-set zero aggregate field became more common which
prevents recording alias-sets of fields of said aggregate as subset
of the outer aggregate.  component_uses_parent_alias_set_from in the
past fended off some of the issues with that but the alias oracles
use of the alias set of the base of an access path never appropriately
handled it.

The following makes it so that alias-sets of fields of alias-set zero
aggregate fields are still recorded as subset of the container.

2020-01-14  Richard Biener  

PR middle-end/93246
* alias.c (record_component_aliases): Take superset to record
into, recurse for alias-set zero fields.
(record_component_aliases): New oveerload wrapping around the above.

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

[Bug tree-optimization/93258] New: [10 regression] Missed constant folding from constructor

[hubicka at gcc dot gnu.org]

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

Bug ID: 93258
   Summary: [10 regression] Missed constant folding from
constructor
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

In the testcase (reduced from folly by Mark Williams):

typedef int a;
template  struct d { static constexpr b e = c; };
template  using f = d;
template  struct g;
template  struct g : h {};
template  struct j : f {};
template  struct an;
class m {
  struct n {};

public:
  using bm = an, int>::e>;
  using bn = n;
  template  m(bn, bo);
};
class o {
  m bq;
  using bn = m::bn;
  bn k;
  o(o &&) : bq(k, 0) {}
};
namespace bw {
template  class by {
public:
  constexpr by(bx ca, a cb) : cc(ca), cd(ca + cb) {}
  long cb() { return cd - cc; }
  bx cc, cd;
};
typedef by ch;
class ci {
public:
  static o cj(void *, long);
  static o cj(by p) {
long l = p.cb();
cj(0, l);
  }
};
}
constexpr bw::ch ck{"", 6};
auto fn1() { bw::ci::cj(ck); }

compiled with -O3 both GCC 9 and 10 arrive to the following code before fre3:

;; Function fn1 (_Z3fn1v, funcdef_no=9, decl_uid=2560, cgraph_uid=8,
symbol_order=8) (executed once)

fn1 ()  
{   
  struct o D.2587;  
  struct by p;  
  const char * _3;  
  const char * _4;  
  long int _5;  

   [local count: 1073741824]: 
  p = ck;   
  _3 = MEM[(const char * *)&p]; 
  _4 = MEM[(const char * *)&p + 8B];
  _5 = _4 - _3; 
  D.2587 = bw::ci::cj (0B, _5); [return slot optimization]  
  D.2587 ={v} {CLOBBER};
  __builtin_unreachable (); 

}   

Now GCC9 optimizes in fre3 to:
fn1 ()
{
  struct o D.2585;
  struct by p;

   [local count: 1073741824]:
  p = ck;
  D.2585 = bw::ci::cj (0B, 6); [return slot optimization]
  D.2585 ={v} {CLOBBER};
  __builtin_unreachable ();

}


and GCC10:
fn1 ()
{
  struct o D.2587;
  struct by p;
  const char * _4;
  long int _5;

   [local count: 1073741824]:
  p = ck;
  _4 = MEM[(const char * *)&p + 8B];
  _5 = _4 - "";
  D.2587 = bw::ci::cj (0B, _5); [return slot optimization]
  D.2587 ={v} {CLOBBER};
  __builtin_unreachable ();

}

This seems to be caused by fact that the constructor gets is not formed as
valid min invariant:
(gdb) p debug_generic_stmt (res)
(const char *) "" + 6;
$19 = void
(gdb) n
1487  if (is_gimple_min_invariant (res))
(gdb)
1501  return NULL_TREE;

Is this missed gimplification? GCC9 gets it as &MEM[(void *)"" + 6B]

Mark bisected it to the following:

commit 7a429a9d52a77e4db2eac6d23d8edb69d26d4f9b (HEAD,
refs/bisect/good-7a429a9d52a77e4db2eac6d23d8edb69d26d4f9b)  
Author: jason   
AuthorDate: Mon Jun 10 19:31:49 2019 +  
Commit: jason   
CommitDate: Mon Jun 10 19:31:49 2019 +  

Reduce constexpr_call memory consumption.   

* constexpr.c (cxx_bind_parameters_in_call): Use TREE_VEC rather
than TREE_LIST. 
(constexpr_call_hasher::equal, cxx_bind_parameters_in_call) 
(cxx_eval_call_expression): Adjust. 

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

[Bug fortran/81095] fcheck=bounds and empty forall

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed|2017-06-15 00:00:00 |2020-1-14
 CC||markeggleston at gcc dot 
gnu.org

--- Comment #2 from markeggleston at gcc dot gnu.org ---
Confirmed trunk (10.0 - revision 280100)

As mentioned in the description the body of the forall should not be executed
because the range of values is not valid.

Where the range values are constants as they are in the example a warning could
be issued.

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

[baptiste.cartier at ertosgener dot com]

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

--- Comment #1 from BCartier  ---
Hello, I see this bug has been marked as unconfirmed, are there any updates
about this issue ?

[Bug testsuite/91955] g++.dg/warn/Wstringop-truncation-1.C should not rely on early inlinng

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Component|tree-optimization   |testsuite

--- Comment #1 from Martin Sebor  ---
I assume this is just about the test and not the implementation of the warning
-- so changing Component to testsuite.

The --param early-inlining-insns option was added to the test in r276416
presumably to cope with some prior changes to the inlining parameters.  The
test needs to continue to verify the absence of the warning in the presence of
inlining, so if tweaking the --param value in lockstep with the inliner
parameters is inconvenient then perhaps the test should force the (already
implicitly inline) functions to be inlined by adding attribute always_inline. 
Does that work for you?  (The test passes for me with as well as without the
--param option and with the attribute so I'm not sure how to verify the changes
have the desired effect.)

Please feel free to tweak the test as you see fit yourself just as long as it
continues to do what it's supposed to.

[Bug testsuite/91955] g++.dg/warn/Wstringop-truncation-1.C should not rely on early inlinng

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Here's what I'm proposing:

diff --git a/gcc/testsuite/g++.dg/warn/Wstringop-truncation-1.C
b/gcc/testsuite/g++.dg/warn/Wstringop-truncation-1.C
index 8f5e7da2c2e..8e2491ca2b3 100644
--- a/gcc/testsuite/g++.dg/warn/Wstringop-truncation-1.C
+++ b/gcc/testsuite/g++.dg/warn/Wstringop-truncation-1.C
@@ -1,7 +1,7 @@
-/* PR/tree-optimization/84480 - bogus -Wstringop-truncation despite
+/* PR tree-optimization/84480 - bogus -Wstringop-truncation despite
assignment with an inlined string literal
{ dg-do compile }
-   { dg-options "-O2 -Wstringop-truncation --param early-inlining-insns=14" } 
*/
+   { dg-options "-O2 -Wstringop-truncation" }  */

 #include 

@@ -9,7 +9,7 @@ template 
 class GoodString
 {
 public:
-  GoodString (const char *s, size_t slen = N)
+  __attribute__ ((always_inline)) GoodString (const char *s, size_t slen = N)
   {
 if (slen > N)
   slen = N;
@@ -53,7 +53,7 @@ template 
 class BadString1
 {
 public:
-  BadString1 (const char *s, size_t slen = N)
+  __attribute__ ((always_inline)) BadString1 (const char *s, size_t slen = N)
   {
 if (slen > N)
   slen = N;

[Bug c++/93259] New: Unsized temporary array initialization problem

[m.cencora at gmail dot com]

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

Bug ID: 93259
   Summary: Unsized temporary array initialization problem
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m.cencora at gmail dot com
  Target Milestone: ---

using Array = int[];
auto && array = Array { 1, 2, 3 };

decltype(array) differs depending on if it is declared inside function, or
function template.

I.e. following program fails to compile:
#include 

using Array = int[];

template 
void bar1(Ts ...)
{
auto && array = Array{ 1, 2, 3 };

static_assert(std::is_same{}, ""); // this
fails, deduces array as int (&&) []
}

template 
void bar2()
{
auto && array = Array{ 1, 2, 3 };

static_assert(std::is_same{}, "");  // this
fails, deduces array as int (&&) []
}

void bar3()
{
auto && array = Array{ 1, 2, 3 };

static_assert(std::is_same{}, ""); // OK
}

int main()
{
bar1(1, 2, 3);
bar2();
bar3();
}

[Bug fortran/93253] Regression on non-standard hex constant syntax

[fx at gnu dot org]

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

--- Comment #3 from Dave Love  ---
You wrote: 

> Do you read the document that comes with your compiler?

Do you appreciate how that sort of response sounds is likely to drive
people off (not for the first time)?

I read two sets of release notes, and the current info node that says
it's a deprecated extension.

> Try adding the -fallow-invalid-boz option to your command line.

How am I supposed to know to look for that and know that it's meant to
cover this contrary to its doc?  (I don't read every word in docs when
quickly debunking bad PR for the compiler, but I do read release notes.)

Anyhow, it doesn't affect the result, so there's at least one behaviour
and two (including release notes) documentation bugs if it's meant to.

I'd have thought NPB would provide useful performance regression testing
anyhow.

[Bug fortran/93253] Regression on non-standard hex constant syntax

[fx at gnu dot org]

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

--- Comment #4 from Dave Love  ---
Apologies, I was misled by something else; that option does affect the result.

However, this change in behaviour isn't mentioned in release notes, the error
message doesn't point to that option, and documentation suggests the code is
supported and that option is for something else.

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-14
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed, This is a front-end issue.
In fact you can workaround the issue by using a const reference inside doStuff.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[tnfchris at gcc dot gnu.org]

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

Bug 90838 Summary: Detect table-based ctz implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90838

   What|Removed |Added

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

[Bug tree-optimization/90838] Detect table-based ctz implementation

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||tnfchris at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #11 from Tamar Christina  ---
Fixed on master

[Bug tree-optimization/92029] [10 Regression] 'libgomp.fortran/pr90779.f90' ICE for nvptx offloading

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-14
 Ever confirmed|0   |1

--- Comment #6 from Thomas Schwinge  ---
(I can't look into this in more detail right now, but wanted to dump the
following information in case that's useful in any way.)

To restore PASSing of this test case, until recently it was sufficient to
revert r273435 "Support folding from array ctor spanning multiple elements" and
(before reverting that one) r274114 "Fix tree-optimization/91169" (PR91169) as
a prerequisite, but as of recently, r280141 "Optimize reads from multiple elts
in fold_ctor_reference (PR tree-optimization/93210)" has to be reverted too, or
the same ICE shows up again.

[Bug fortran/93253] Regression on non-standard hex constant syntax

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
By the way this is from the email thread that added that option
(https://gcc.gnu.org/ml/fortran/2019-07/msg00054.html):

The code for deprecated items is still present and can sometimes
be used via the -fallow-invalid-boz option.  After 10.1 is released,
and if I am still contributing to gfortran, I will remove the code.
If someone feels strongly that a previous undocument extension
should be retain, feel free to fix it after I commit the patch.
I think I've weighed the pros and cons, and have made prudent
decision of want to deprecate.


 CUT 
So using an undocumented extension 
Basically BOZ is finally standardized in Fortran2018 and the NAS benchmark
could be re-written in a standard format instead ...

[Bug tree-optimization/93249] [10 Regression] wrong code with __builtin_strncpy() copying empty string

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug libgomp/93260] New: Deal with missing CUDA etc. installation in libgomp '-lcuda' etc. test cases

[tschwinge at gcc dot gnu.org]

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

Bug ID: 93260
   Summary: Deal with missing CUDA etc. installation in libgomp
'-lcuda' etc. test cases
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: enhancement
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: frederik at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

As Jakub mentioned in
, and we recently
discussed internally in context of PR93074, it is possible to build GCC with
nvptx offloading support, but without having a CUDA etc. installation on the
build and host systems: the libgomp nvptx plugin then "doesn't compile/link
against a CUDA Driver installation, but instead uses its own stub header file
('libgomp/plugin/cuda/cuda.h') and then 'dlopen's 'libcuda.so'".

Yet, there are test cases that '#include' various CUDA header files and '-lcuda
-lcublas -lcudart'.  This causes FAIL/UNRESOLVED in '--without-cuda-driver'
configurations.

We can either add some DejaGnu magic to make these UNSUPPORTED in such
configurations, or keep them supported by means of replicating the relevant
parts of the header files (hopefully shouldn't be too much in addition to the
existing 'cuda.h'), and adding a small helper file to the testsuite to 'dlopen'
the shared libraries instead of directly linking against them.

[Bug libgomp/93260] Deal with missing CUDA etc. installation in libgomp '-lcuda' etc. test cases

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Yeah.  Just note that even the testing could be done when libcuda.so can't be
dlopened, and in that case the test that need it should be UNSUPPORTED.

[Bug tree-optimization/93249] [10 Regression] wrong code with __builtin_strncpy() copying empty string

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
"Proven not to contain any zeros in the first N bytes" where N is the source
offset in strncpy, would suggest the strlen pass might be more suitable for
this transformation than DSE.

[Bug libgomp/65155] libgomp-plugin-host_nonshm installation failure

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||tschwinge at gcc dot gnu.org
 Resolution|--- |WONTFIX
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

--- Comment #2 from Thomas Schwinge  ---
(We don't understand how/why the libgomp host_nonshm plugin is special in that
regard, however) the libgomp host_nonshm plugin has been removed long ago
(r226763 "[PR libgomp/65742, PR middle-end/66332] libgomp: Remove plugin for
non-shared memory host execution"), so this specific issue cannot be a problem
anymore.

[Bug tree-optimization/93249] [10 Regression] wrong code with __builtin_strncpy() copying empty string

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #5)
> "Proven not to contain any zeros in the first N bytes" where N is the source
> offset in strncpy, would suggest the strlen pass might be more suitable for
> this transformation than DSE.

That is not really possible, because the change it is doing heavily relies on
the DSE pass infrastructure as well as being called from within it.
With get_range_strlen, it can handle some cases, and will just avoid head
trimming of strncpy otherwise, no big deal.  Tail trimming and full trimming is
still possible.

[Bug middle-end/93246] [8/9 Regression] Unexpected program behavior when -fsanitize=address and -O2/O3 used

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||10.0
Summary|[8/9/10 Regression] |[8/9 Regression] Unexpected
   |Unexpected program behavior |program behavior when
   |when -fsanitize=address and |-fsanitize=address and
   |-O2/O3 used |-O2/O3 used

--- Comment #14 from Richard Biener  ---
Fixed on trunk sofar.

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

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
The problem is here:
  /* Also strip a TARGET_EXPR that would force an extra copy.  */
  if (TREE_CODE (*arg_p) == TARGET_EXPR)
{
  tree init = TARGET_EXPR_INITIAL (*arg_p);
  if (init
  && !VOID_TYPE_P (TREE_TYPE (init)))
*arg_p = init;
}

--- CUT ---
We don't do what gimplify_target_expr does:
  /* Add a clobber for the temporary going out of scope, like
 gimplify_bind_expr.  */

[Bug libgomp/93260] Deal with missing CUDA etc. installation in libgomp '-lcuda' etc. test cases

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-14
 Ever confirmed|0   |1

--- Comment #2 from Thomas Schwinge  ---
(In reply to Jakub Jelinek from comment #1)
> Yeah.  Just note that even the testing could be done when libcuda.so can't
> be dlopened, and in that case the test that need it should be UNSUPPORTED.

Such test cases are for CUDA/nvptx offloading only by definition (they're
testing CUDA internals), so already must be UNSUPPORTED for anything else.  If
nvptx offloading works by means of 'dlopen'ing CUDA, then the same must work
for the test cases, too.

If GCC is built with nvptx offloading configured but there is no CUDA
installation on the testing system, or there is no Nvidia GPU
(present/accessible), then you'll get globally for the '*.exp' file a suitable
UNTESTED status ("[...] offloading: supported, but hardware not accessible").

[Bug tree-optimization/93261] New: fold strstr(a, b) to zero when b is longer than a

[msebor at gcc dot gnu.org]

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

Bug ID: 93261
   Summary: fold strstr(a, b) to zero when b is longer than a
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Similarly to pr90879, pr90626, pr90876 and pr83026, the expression strstr(a, b)
can be folded to null when the string b is longer than the string a, or the
object in which the string a is stored.  The latter should avoid problems like
some of those discussed in pr92765.

$ cat z.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout z.c
void f (const char *s)
{
  if (__builtin_strlen (s) > 2)
return;

  if (__builtin_strstr (s, "bar"))   // can be folded to false
__builtin_abort ();
}

void g (void)
{
  extern char a[6];   // strlen (a) must be less than 6

  if (__builtin_strstr (a, "foobar"))   // can be folded to false
__builtin_abort ();
}


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

Removing basic block 6
Removing basic block 7
f (const char * s)
{
  long unsigned int _1;
  char * _2;

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

   [local count: 708669605]:
  _2 = __builtin_strstr (s_4(D), "bar");
  if (_2 != 0B)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return;

}



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

g ()
{
  char * _1;

   [local count: 1073741824]:
  _1 = __builtin_strstr (&a, "foobar");
  if (_1 != 0B)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

   [local count: 1073741824]:
  return;

}

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

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> The problem is here:
>   /* Also strip a TARGET_EXPR that would force an extra copy.  */
>   if (TREE_CODE (*arg_p) == TARGET_EXPR)
>   {
> tree init = TARGET_EXPR_INITIAL (*arg_p);
> if (init
> && !VOID_TYPE_P (TREE_TYPE (init)))
>   *arg_p = init;
>   }
> 
> --- CUT ---
> We don't do what gimplify_target_expr does:
>   /* Add a clobber for the temporary going out of scope, like
>gimplify_bind_expr.  */

But that temp is not created until much later in internal_get_tmp_var.

Someone who understands the gimplifier better can/should be able to handle this
easily.

[Bug tree-optimization/93262] New: [8/9/10 Regression] DSE memstar call trimming affecting -D_FORTIFY_SOURCE since r244444

[jakub at gcc dot gnu.org]

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

Bug ID: 93262
   Summary: [8/9/10 Regression] DSE memstar call trimming
affecting -D_FORTIFY_SOURCE since r24
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

char a[16];

__attribute__((noipa, noinline, noclone)) void
foo (char *b)
{
  __builtin___memcpy_chk (a, b, 24, __builtin_object_size (a, 0));
  __builtin___memset_chk (a, ' ', 8, __builtin_object_size (a, 0));
}

int
main ()
{
  foo ("0123456789abcdef");
  return 0;
}

properly warns at compile time:
warning: ‘__builtin_memcpy’ writing 16 bytes into a region of size 8 overflows
the destination [-Wstringop-overflow=]
6 |   __builtin___memcpy_chk (a, b, 24, __builtin_object_size (a, 0));
  |   ^~~
but since (I believe) r24 at -O2 it no longer fails at runtime like:
*** buffer overflow detected ***: ./pr93249-7 terminated
Aborted (core dumped)
(at -O0 it properly fails).

The bug is that when doing head_trim for the __builtin_*_chk calls, we can't
just decrease count and increment addresses, but we also need to decrement the
4th argument (and punt on head trimming if the decrement would overflow).

[Bug tree-optimization/93262] [8/9/10 Regression] DSE memstar call trimming affecting -D_FORTIFY_SOURCE since r244444

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||law at gcc dot gnu.org
   Target Milestone|--- |8.4

--- Comment #1 from Jakub Jelinek  ---
P1 as it has security consequences.

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

[baptiste.cartier at ertosgener dot com]

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

--- Comment #5 from BCartier  ---
Thanks for the heads up, nice to know a fix could be possible.

As for the const reference in doStuff, do you mean

void __attribute__((noinline)) doStuff(const struct TestStruct &myStruct)
{
...
}

?

By doing so, wouldn't you use the address of a temporary variable (created by
the macro and the function) ?

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

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to BCartier from comment #5)
> Thanks for the heads up, nice to know a fix could be possible.
> 
> As for the const reference in doStuff, do you mean
> 
> void __attribute__((noinline)) doStuff(const struct TestStruct &myStruct)
> {
> ...
> }
> 
> ?

Yes.

> 
> By doing so, wouldn't you use the address of a temporary variable (created
> by the macro and the function) ?

Yes.  But note myStruct was already passed by reference so it does not change
that much.  And that temp goes out of scope after the statement is done.

[Bug fortran/93263] New: -fno-automatic and RECURSIVE

[gcc.bugzilla at he dot sk]

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

Bug ID: 93263
   Summary: -fno-automatic and RECURSIVE
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc.bugzilla at he dot sk
  Target Milestone: ---

The combination of -fno-automatic and RECURSIVE does not seem to behave
correctly in gfortran 9.2.1. 

The output of the following program depends on whether it is compiled with or
without -fno-automatic, while according to the manual it should not.

  program main
  implicit none
  call check(2)
  end 

  recursive subroutine check(n)
  implicit none
  integer n, a
  a = 10
  print*,"n=",n
  if (n==1) then
 a=a-1
 print*,"assigning a=",a
  else
 a=a-2
 print*,"assigning a=",a
 call check(n-1)
  endif
  print*,"a=",a
  end 

Output without -fno-automatic:
 n=   2
 assigning a=   8
 n=   1
 assigning a=   9
 a=   9
 a=   8

Output with -fno-automatic:
 n=   2
 assigning a=   8
 n=   1
 assigning a=   9
 a=   9
 a=   9

It seems like with -fno-automatic the variable a is not AUTOMATIC while
according to the manual it should because the relevant program unit is marked
as RECURSIVE:

-fno-automatic

Treat each program unit (except those marked as RECURSIVE) as if the SAVE
statement were specified for every local variable and array referenced in it.
Does not affect common blocks. (Some Fortran compilers provide this option
under the name -static or -save.) The default, which is -fautomatic, uses the
stack for local variables smaller than the value given by -fmax-stack-var-size.
Use the option -frecursive to use no static memory. 

https://gcc.gnu.org/onlinedocs/gfortran/Code-Gen-Options.html

Note that this behaviour changes with respect to previous versions of gfortran.

Thanks!

Tomas

[Bug tree-optimization/92765] [10 Regression] Wrong code caused by folding of -Wstring-compare since r276773

[rguenth at gcc dot gnu.org]

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

--- Comment #23 from Richard Biener  ---
(In reply to Martin Sebor from comment #22)
> I've been going through the test cases here.  IIUC, the one in comment #10
> is a separate issue and should get its own bug.  (Arguably, so is the one in
> comment #7.)
> 
> It's unfortunate that GIMPLE doesn't preserve the basic property mentioned
> in comment #2.  Not only does it make working with it error-prone (vis-a-vis
> this bug and others like it), it also prevents interesting optimizations,
> and makes warnings that depend on the property regardless inconsistent with
> the guarantees GCC does provide.  I'm hoping this can change in the future.

I don't think this will change in future.  You have to look at this from
the angle of value-equivalences which is the number one thing a compiler
is supposed to compute and utilize.  All this analyzer work and also
this stupid pointer provenance stuff makes value-equivalences no longer
work.  At the same time the compiler is still expected it exploit those
equivalences unless it breaks something.  That's never going to work.

[Bug tree-optimization/93262] [8/9/10 Regression] DSE memstar call trimming affecting -D_FORTIFY_SOURCE since r244444

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-14
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug tree-optimization/93258] [10 regression] Missed constant folding from constructor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-14
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Global CTORs are not gimplified at all, we have to work hard in
canonicalize_constructor_val to make it "valid".  Like

  /* In CONSTRUCTORs we may see unfolded constants like (int (*) ()) 0.  */
  if (TREE_CODE (cval) == INTEGER_CST)
{
  if (TREE_OVERFLOW_P (cval))
cval = drop_tree_overflow (cval);
  if (!useless_type_conversion_p (TREE_TYPE (orig_cval), TREE_TYPE (cval)))
cval = fold_convert (TREE_TYPE (orig_cval), cval);
  return cval;
}

(const char *) "" + 6; looks like it should be handled by

  if (TREE_CODE (cval) == POINTER_PLUS_EXPR
  && TREE_CODE (TREE_OPERAND (cval, 1)) == INTEGER_CST)
{
  tree ptr = TREE_OPERAND (cval, 0);
  if (is_gimple_min_invariant (ptr))
cval = build1_loc (EXPR_LOCATION (cval),
   ADDR_EXPR, TREE_TYPE (ptr),
   fold_build2 (MEM_REF, TREE_TYPE (TREE_TYPE (ptr)),
ptr,
fold_convert (ptr_type_node,
  TREE_OPERAND (cval,
1;
}

but we need another STRIP_NOPS before the is_gimple_min_invariant (ptr) check
on ptr I guess?

Btw, on trunk I see it optimized, maybe some recent CTOR "fixing" fixed it
again?  Can you double-check?

If it's fixed again I suggest to add the testcase (ck should be elided
in the assembly?)

[Bug tree-optimization/93258] [10 regression] Missed constant folding from constructor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |10.0

[Bug tree-optimization/93262] [8/9/10 Regression] DSE memstar call trimming affecting -D_FORTIFY_SOURCE since r244444

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Untested trunk fix on top of the PR93249 fix, so won't apply cleanly to older
stuff, will need reindentation:
--- tree-ssa-dse.c.jj2  2020-01-14 12:13:39.900589819 +0100
+++ tree-ssa-dse.c  2020-01-14 13:47:50.085009665 +0100
@@ -508,6 +508,22 @@ maybe_trim_memstar_call (ao_ref *ref, sb
   /* Head trimming requires adjusting all the arguments.  */
   if (head_trim)
{
+ /* For __*_chk need to adjust also the last argument.  */
+ if (gimple_call_num_args (stmt) == 4)
+   {
+ tree size = gimple_call_arg (stmt, 3);
+ if (!tree_fits_uhwi_p (size))
+   break;
+ if (!integer_all_onesp (size))
+   {
+ unsigned HOST_WIDE_INT sz = tree_to_uhwi (size);
+ if (sz < (unsigned) head_trim)
+   break;
+ tree arg = wide_int_to_tree (TREE_TYPE (size),
+  sz - head_trim);
+ gimple_call_set_arg (stmt, 3, arg);
+   }
+   }
  tree *dst = gimple_call_arg_ptr (stmt, 0);
  increment_start_addr (stmt, dst, head_trim);
  tree *src = gimple_call_arg_ptr (stmt, 1);
@@ -527,6 +543,22 @@ maybe_trim_memstar_call (ao_ref *ref, sb
   /* Head trimming requires adjusting all the arguments.  */
   if (head_trim)
{
+ /* For __*_chk need to adjust also the last argument.  */
+ if (gimple_call_num_args (stmt) == 4)
+   {
+ tree size = gimple_call_arg (stmt, 3);
+ if (!tree_fits_uhwi_p (size))
+   break;
+ if (!integer_all_onesp (size))
+   {
+ unsigned HOST_WIDE_INT sz = tree_to_uhwi (size);
+ if (sz < (unsigned) head_trim)
+   break;
+ tree arg = wide_int_to_tree (TREE_TYPE (size),
+  sz - head_trim);
+ gimple_call_set_arg (stmt, 3, arg);
+   }
+   }
  tree *dst = gimple_call_arg_ptr (stmt, 0);
  increment_start_addr (stmt, dst, head_trim);
  decrement_count (stmt, head_trim);

Now to figure out if we want a runtime testcase in
gcc.c-torture/execute/builtins/ or not...

[Bug rtl-optimization/93264] New: [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522

[zhroma at gcc dot gnu.org]

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

Bug ID: 93264
   Summary: [10 Regression] ICE in
cfg_layout_redirect_edge_and_branch_force, at
cfgrtl.c:4522
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhroma at gcc dot gnu.org
Blocks: 90040
  Target Milestone: ---

Opening bug 90040 comment 2 as a separate regression PR to achieve more
attention to the issue.  As modulo-scheduler maintainer I cannot solve it,
issue happens early in the pass when loop_optimizer_init is called after bbro
finished its job.  There are much more discussion in the meta-bug itself
(PR90040).

Although I'm pretty sure this was latent before, technically, since r10-4447 we
have a regression (ICE on valid code):

$ aarch64-unknown-linux-gnueabi-gcc -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions -fmodulo-sched
-freorder-blocks-and-partition -S gcc/testsuite/gcc.c-torture/execute/pr71550.c

gcc/testsuite/gcc.c-torture/execute/pr71550.c: In function 'main':
gcc/testsuite/gcc.c-torture/execute/pr71550.c:26:1: internal compiler error: in
cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
   26 | }
  | ^
0xb4a9d9 cfg_layout_redirect_edge_and_branch_force
/mnt/scratch/zhroma/gcc/src/master/gcc/cfgrtl.c:4522
0xb2e57d redirect_edge_and_branch_force(edge_def*, basic_block_def*)
/mnt/scratch/zhroma/gcc/src/master/gcc/cfghooks.c:490
0xb2f2fe make_forwarder_block(basic_block_def*, bool (*)(edge_def*), void
(*)(basic_block_def*))
/mnt/scratch/zhroma/gcc/src/master/gcc/cfghooks.c:897
0xb33214 merge_latch_edges
/mnt/scratch/zhroma/gcc/src/master/gcc/cfgloop.c:780
0xb33314 disambiguate_multiple_latches
/mnt/scratch/zhroma/gcc/src/master/gcc/cfgloop.c:831
0xb3335d disambiguate_loops_with_multiple_latches()
/mnt/scratch/zhroma/gcc/src/master/gcc/cfgloop.c:844
0xf1d3d0 apply_loop_flags
/mnt/scratch/zhroma/gcc/src/master/gcc/loop-init.c:54
0xf1d539 loop_optimizer_init(unsigned int)
/mnt/scratch/zhroma/gcc/src/master/gcc/loop-init.c:123
0x1f339f6 sms_schedule
/mnt/scratch/zhroma/gcc/src/master/gcc/modulo-sched.c:1350
0x1f38a16 execute
/mnt/scratch/zhroma/gcc/src/master/gcc/modulo-sched.c:3341


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90040
[Bug 90040] [meta-bug] modulo-scheduler and partitioning issues

[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[hubicka at gcc dot gnu.org]

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

--- Comment #16 from Jan Hubicka  ---
OK, i get an ICE because type is not compatible with its main variant. the two
types are:

  constant 384>
unit-size  constant 48>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76f913f0
fields 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76f91348
attributes 
value 
readonly constant static "cxx11\000">>> fields
 context >
ignored BLK files/file3.ii:47:0 size 
unit-size 
align:8 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context 
chain 
ignored BLK files/file3.ii:47:0
size 
unit-size 
align:64 warn_if_not_align:0 offset_align 128 offset 
bit-offset  context
>> context 
pointer_to_this >

and

  constant 384>
unit-size  constant 48>
align:64 warn_if_not_align:0 symtab:0 alias-set 74 canonical-type
0x76f913f0
fields 
unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set 75 canonical-type
0x76f91348
attributes 
value 
readonly constant static "cxx11\000">>> fields
 context >
ignored QI files/file2.ii:46:0 size 
unit-size 
align:8 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context 
chain 
ignored BLK files/file2.ii:46:0
size 
unit-size 
align:64 warn_if_not_align:0 offset_align 128 offset 
bit-offset  context
>> context >

and the reason for incompatibilty is TYPE_MODE here:

(gdb)  p debug_tree ((tree)0x76f91348)
  constant 8>
unit-size  constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set 75 canonical-type
0x76f91348
attributes 
value 
readonly constant static "cxx11\000">>>
fields  unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set 76 canonical-type
0x76f912a0 attributes  context >
nonlocal QI files/file2.ii:46:475 size 
unit-size 
align:8 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context > context >
$7 = void
(gdb)  p debug_tree ((tree)0x76fc02a0)
  constant 8>
unit-size  constant 1>
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76f91348
attributes 
value 
readonly constant static "cxx11\000">>>
fields  unit-size 
align:8 warn_if_not_align:0 symtab:0 alias-set 76 canonical-type
0x76f912a0 attributes  context >
nonlocal QI files/file3.ii:47:471 size 
unit-size 
align:8 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context > context >

So they are indeed not compatible. We do not detect any ODR violation on them.

[Bug tree-optimization/65178] incorrect -Wmaybe-uninitialized when using nested loops

[winter-...@bfw-online.de]

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

--- Comment #16 from Leon Winter  ---
I just checked again with gcc 9.2.1 and the issue disappeared.

[Bug c++/90916] [10 Regression] ICE in retrieve_specialization, at cp/pt.c:1258

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug tree-optimization/93258] [10 regression] Missed constant folding from constructor

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
> Btw, on trunk I see it optimized, maybe some recent CTOR "fixing" fixed it
> again?  Can you double-check?
> 
> If it's fixed again I suggest to add the testcase (ck should be elided
> in the assembly?)

I can confirm it's not an issue:

gcc-bisect.py bisect 'g++ pr93258.cc -O3 -Wno-return-type -c
-fdump-tree-optimized=/dev/stdout | grep ", 6)"'
Releases
  7.1.0 (303f81ad7e9f278d)(02 May 2017 12:42): [took: 2.503s] result: OK
  D.2542 = bw::ci::cj (0B, 6); [return slot optimization]
  7.2.0 (586a0829dc38626c)(14 Aug 2017 07:59): [took: 2.480s] result: OK
  D.2542 = bw::ci::cj (0B, 6); [return slot optimization]
  7.3.0 (6184085fc664265d)(25 Jan 2018 08:17): [took: 2.520s] result: OK
  D.2542 = bw::ci::cj (0B, 6); [return slot optimization]
  7.4.0 (adafdb1e7212d53a)(06 Dec 2018 10:00): [took: 2.439s] result: OK
  D.2542 = bw::ci::cj (0B, 6); [return slot optimization]
  7.5.0 (b2d961e7342b5ba4)(14 Nov 2019 07:40): [took: 2.347s] result: OK
  D.2542 = bw::ci::cj (0B, 6); [return slot optimization]
  8.1.0 (406c2abec3f998e9)(02 May 2018 10:13): [took: 2.623s] result: OK
  D.2637 = bw::ci::cj (0B, 6); [return slot optimization]
  8.2.0 (ddeb81e76461fc00)(26 Jul 2018 09:47): [took: 2.563s] result: OK
  D.2637 = bw::ci::cj (0B, 6); [return slot optimization]
  8.3.0 (4c44b708f11eec6f)(22 Feb 2019 14:20): [took: 2.659s] result: OK
  D.2641 = bw::ci::cj (0B, 6); [return slot optimization]
  9.1.0 (c8913260b0756f97)(03 May 2019 07:59): [took: 2.714s] result: OK
  D.2585 = bw::ci::cj (0B, 6); [return slot optimization]
  9.2.0 (a0c06cc27d2146b7)(12 Aug 2019 09:38): [took: 2.714s] result: OK
  D.2585 = bw::ci::cj (0B, 6); [return slot optimization]

  3d77686d2eddf76d(13 Jan 2020 16:39)(jos...@codesourcery.com): [took: 3.305s]
result: OK
  D.2606 = bw::ci::cj (0B, 6); [return slot optimization]

[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[hubicka at gcc dot gnu.org]

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

--- Comment #17 from Jan Hubicka  ---
Created attachment 47651
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47651&action=edit
proposed patch

This is patch I plan to test which fixes the last testcase.  It adds warning
about TREE_ADDRESSABLE mismatch which means that type needs constructing and in
addition TYPE_MODE check. Problem of that one is that we can not give user any
good reason why TYPE_MODEs mismatch and thus I hope it will not trip and
everything should be caught earlier.

There are two problems metled together. Other is the bug with stmt verifier.
Does it still reproduce.

Martin, did you try to get some testsuite scale version of the last testcase?

[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[hubicka at gcc dot gnu.org]

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

--- Comment #18 from Jan Hubicka  ---
OK, other testcases does not reproduce for me. However if they do it seems like
fallout from the change dropping type checking from call statements.

[Bug tree-optimization/93262] [8/9/10 Regression] DSE memstar call trimming affecting -D_FORTIFY_SOURCE since r244444

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Full patch with the testsuite stuff.

[Bug c/93265] New: memcmp comparisons of structs wrapping a primitive type not as compact/efficient as direct comparisons of the underlying primitive type under -Os

[pskocik at gmail dot com]

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

Bug ID: 93265
   Summary: memcmp comparisons of structs wrapping a primitive
type not as compact/efficient as direct comparisons of
the underlying primitive type under -Os
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pskocik at gmail dot com
  Target Milestone: ---

`memcmp` comparisons of types such as `struct Int { int x; };` generate full
`memcmp` calls under `-Os` (also `-O1`)
These are much larger (/less efficient) than the direct primitive-type
comparisons that could have been used.

Example code:

#include 
//a contiguous struct wrapping a primitive type
typedef struct a_tp { int x; }a_tp; 
_Static_assert(sizeof(a_tp)==sizeof(int),"");

//compare a contiguous lvalue
#define CONTIG_EQ_EH(Ap,Bp) (!memcmp(Ap,Bp,sizeof(*(1?(Ap):(Bp) 

/
//>>
//A FULL MEMCPY :( under -Os (and -O1)
_Bool a_is42(a_tp X) {return CONTIG_EQ_EH(&X,&(a_tp const){42});}
//>>
/

_Bool i_is42(int X) {return X==42; } //direct cmp
_Bool i2_is42(a_tp X) {return X.x==42; } //same
_Bool i3_is42(a_tp X) {return CONTIG_EQ_EH(&X,&(int const){42});} //still a
direct cmp

https://gcc.godbolt.org/z/BC_QsN

[Bug lto/88081] [8/9/10 Regression] ICE in lto_varpool_replace_node, at lto/lto-symtab.c:109

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #8 from Jan Hubicka  ---
This bug does not reproduce for me and since it did not surface in other
variant lets hope it is fixed. I have fixed some issues in the area
independently.

[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug ipa/92240] [10 regression] ICE in duplicate, at ipa-prop.c:3883

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||mjambor at suse dot cz

--- Comment #5 from Jan Hubicka  ---
Adding Maritn to CC since it is his code.

[Bug ipa/92749] [10 Regression] warning: inlining failed in call to ‘salsa20’: --param max-inline-insns-single limit reached after r276516

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
This is intentional, we got less aggressive at inlining inline functions for
-O2 (since we do not need to do all inlining we want for -O3 when we have
independent set of attributes).

Indeed -Winline -Werror is not the best idea - if you want that there is
always_inline attribute.

[Bug tree-optimization/93266] New: strlen pass could optimize strncpy with known strlen (src) == 0 into memset

[jakub at gcc dot gnu.org]

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

Bug ID: 93266
   Summary: strlen pass could optimize strncpy with known strlen
(src) == 0 into memset
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

In:

char b[32];

void
foo ()
{
  char a[16];
  __builtin_memcpy (a, "\0foobarbazquuxy", 16);
  __builtin_strncpy (b, a, 32);
}

we could turn the strncpy into memset (b, ' ', 32);

[Bug tree-optimization/93265] memcmp comparisons of structs wrapping a primitive type not as compact/efficient as direct comparisons of the underlying primitive type under -Os

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-14
  Component|c   |tree-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
So I see it already resolved to a direct compare during GENERIC folding
which is probably confused by the COMPOUND_LITERAL_EXPR:

  return memcmp ((const void *) &X, (const void *) &<<< Unknown tree:
compound_literal_expr
const struct a_tp D.2112 = {.x=42}; >>>, 4) == 0;

I think tree-ssa-strlen.c has code to change memcmp to memcmp_eq which can
be more optimally expanded.  It also has code to directly emit more optimal
GIMPLE.

Not sure why that doesn't fire here.  Confirmed.

[Bug ipa/93144] [10 Regression] 459.GemsFDTD debug info size increase by 50% since r279563

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Well, the problem was debug info getting bigger due to more inlining? I guss in
that case we could close it. That patch is expected to allow more inlines.

[Bug lto/89358] [8 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

[hubicka at gcc dot gnu.org]

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

--- Comment #19 from Jan Hubicka  ---
I think backporting would be a good idea :) If you beat me on it even better.
Now I need to set up my trees in git...

[Bug c/92935] typeof() on an atomic type doesn't always return the corresponding unqualified type

[pskocik at gmail dot com]

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

pskocik at gmail dot com changed:

   What|Removed |Added

 CC||pskocik at gmail dot com

--- Comment #1 from pskocik at gmail dot com ---
I don't think typeof is supposed to lose qualifiers. _Generic(Expr,...) loses
them for Expr in an rvalue conversion (also decays arrays to pointer), but
__typeof is supposed to preserve everything--it does preserve qualifiers in
other compilers (clang/tinycc) and in gcc:

_Atomic const int aci=0;
_Generic(&aci, _Atomic const int*: (void)0); //ok
_Atomic typeof(const int) aci2=0;
_Generic(&aci2, _Atomic const int*: (void)0); //ok

but there does seem to be a bug in gcc in how typeof combines with pointer
symbols (*) and other qualifiers where gcc appears to be curiously dropping all
qualifiers if (and only if) one of the original qualifiers was _Atomic

_Generic((typeof(aci)*)0, _Atomic const int*: (void)0); //gcc error (int*),
ok on clang
_Generic((typeof(aci2)*)0, _Atomic const int*: (void)0); //gcc error
(int*), ok on clang
 _Generic((typeof(aci2) volatile*)0, _Atomic const volatile int*: (void)0);
//gcc error (int volatile*), ok on clang


Clang doesn't do this, and neither gcc or clang typeof drops any qualifiers if
there's no _Atomic among them:

 //no qualifs dropped if no _Atomic was involved
 const int ci=0;
_Generic(&ci,  const int*: (void)0); //ok
 typeof(const int) ci2=0;
_Generic(&ci2,  const int*: (void)0); //ok


_Generic((typeof(ci)*)0,  const int*: (void)0); //ok
_Generic((typeof(ci2)*)0,  const int*: (void)0);  //ok
 _Generic((typeof(ci2) volatile*)0,  const volatile int*: (void)0); //ok

https://gcc.godbolt.org/z/TwtEGP

[Bug lto/92600] [9/10 Regression] ICE: symtab_node::verify failed, building 523.xalancbmk_r with -flto -fno-inline since r267359

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka  ---
Well, because the source files differs, the comdat group differs and the
loosing one has fewer symbols in it.  So we end up keeping some symbols from
the other comdat group that happens to have same name.  The compilation is
bound to fail, so I guess question is how best to silence the ICE.  I suppose
we may get around by dissoling comdat groups of all UNDEF symbols

[Bug lto/91576] [10 Regression] error: invalid conversion in gimple call since r272749

[marxin at gcc dot gnu.org]

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

--- Comment #19 from Martin Liška  ---
> 
> Martin, did you try to get some testsuite scale version of the last testcase?

Sorry, but no. So please apply the patch and we can close it.

[Bug ipa/92240] [10 regression] ICE in duplicate, at ipa-prop.c:3883

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-14
 Ever confirmed|0   |1

--- Comment #6 from Martin Liška  ---
@Dmitry: Can you please attach a pre-processed source file (-E option)?

[Bug libstdc++/93267] New: std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[pilarlatiesa at gmail dot com]

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

Bug ID: 93267
   Summary: std::ranges::begin|end do not work for iota_view when
the element and bound type are the same
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pilarlatiesa at gmail dot com
  Target Milestone: ---

The following testcase emits errors at the specified locations:

#include 
#include 

int main()
{
std::size_t const Zero = 0u;
std::size_t const Size = 10u;

auto const Test1 = std::ranges::views::iota(0, Size);
auto beginTest1 = std::ranges::begin(Test1); // OK

auto const Test2 = std::ranges::views::iota(Zero, Size);
auto beginTest2 = std::ranges::begin(Test2); // Error

std::ranges::iota_view const Test3(Zero, Size);
auto beginTest3 = std::ranges::begin(Test3); // Error

std::ranges::iota_view const Test4(0, Size);
auto beginTest4 = std::ranges::begin(Test4); // Error

std::ranges::iota_view const Test5(0, Size);
auto beginTest4 = std::ranges::begin(Test5); // OK
}

The error reads:

error: no match for call to '(const std::ranges::__cust_access::_Begin) (const
std::ranges::iota_view&)'


/home/pililatiesa/gcc-trunk-20200114/include/c++/10.0.0/bits/range_access.h:420:2:
note: candidate: 'constexpr auto
std::ranges::__cust_access::_Begin::operator()(_Tp&&) const [with _Tp = const
std::ranges::iota_view&]'

  420 |  operator()(_Tp&& __t) const noexcept(_S_noexcept<_Tp>())

  |  ^~~~

/home/pililatiesa/gcc-trunk-20200114/include/c++/10.0.0/bits/range_access.h:420:2:
note: constraints not satisfied

: In instantiation of 'constexpr auto
std::ranges::__cust_access::_Begin::operator()(_Tp&&) const [with _Tp = const
std::ranges::iota_view&]':

:10:34:   required from here

/home/pililatiesa/gcc-trunk-20200114/include/c++/10.0.0/bits/range_access.h:420:2:
  required by the constraints of 'template  requires
(__maybe_safe_range<_Tp>) && ((is_array_v::remove_reference_t>) || (__member_begin<_Tp>) ||
(__adl_begin<_Tp>)) constexpr auto
std::ranges::__cust_access::_Begin::operator()(_Tp&&) const'

/home/pililatiesa/gcc-trunk-20200114/include/c++/10.0.0/bits/range_access.h:418:4:
note: neither operand of the disjunction is satisfied

  418 ||| __adl_begin<_Tp>

[Bug c/93268] New: ICE with gcc-10 when compiling hypre library with -O3

[kristopher.kuhlman at gmail dot com]

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

Bug ID: 93268
   Summary: ICE with gcc-10 when compiling hypre library with -O3
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kristopher.kuhlman at gmail dot com
  Target Milestone: ---

I am building petsc, and the hypre library being built as part of that triggers
this ICE when using optimization. When building the same library with -Og there
is no ICE.

This library didn't trigger this ICE with a gcc version from a month or two
ago, so this is maybe due to a recent change?

I created a pre-processed version of the relevant source file, but it is
enormous (12k lines). I can attach it if desired.

Kris

--

/home/klkuhlm/src/petsc/tgcc-c-perf/bin/mpicc -fstack-protector -O3
-march=native  -DHAVE_CONFIG_H -I.. -I. -I./.. -I./../blas -I./../lapack
-I./../utilities -I./../seq_mv  -I/home/klkuhlm/src/petsc/tgcc-c-perf/include
-c par_csr_matop_marked.c 
../config/Makefile.config:49: recipe for target 'par_csr_matop.o' failed
make[1]: Leaving directory
'/home/klkuhlm/src/petsc/tgcc-c-perf/externalpackages/hypre-2.15.1/src/parcsr_mv'
Makefile:90: recipe for target 'all' failedduring GIMPLE pass: vect
par_csr_matop.c: In function ‘hypre_ParCSRMatrixExtractBExt_Arrays_Overlap’:
par_csr_matop.c:1063:6: internal compiler error: in get_load_store_type, at
tree-vect-stmts.c:2462
 1063 | void hypre_ParCSRMatrixExtractBExt_Arrays_Overlap(
  |  ^~~~
0x6f7de9 get_load_store_type
../../gcc-trunk/gcc/tree-vect-stmts.c:2462
0xfb254b vectorizable_load
../../gcc-trunk/gcc/tree-vect-stmts.c:8708
0xfc8f0e vect_transform_stmt(_stmt_vec_info*, gimple_stmt_iterator*,
_slp_tree*, _slp_instance*)
../../gcc-trunk/gcc/tree-vect-stmts.c:10989
0xfcac1e vect_transform_loop_stmt
../../gcc-trunk/gcc/tree-vect-loop.c:8299
0xfe1c6c vect_transform_loop(_loop_vec_info*)
../../gcc-trunk/gcc/tree-vect-loop.c:8690
0xffd6f9 try_vectorize_loop_1
../../gcc-trunk/gcc/tree-vectorizer.c:989
0xffd8f7 try_vectorize_loop_1
../../gcc-trunk/gcc/tree-vectorizer.c:1026
0xffe3f9 vectorize_loops()
../../gcc-trunk/gcc/tree-vectorizer.c:1125
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[1]: *** [par_csr_matop.o] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [all] Error 1

[Bug tree-optimization/90576] [10 regression] SPEC CPU2006 450.soplex miscompiled with -Os -flto after r271413

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
(In reply to Maxim Kuvyrkov from comment #7)
> Apologies for delay.  Kicked off SPEC2k6 builds, and will report results
> tomorrow.

PING

[Bug tree-optimization/93266] strlen pass could optimize strncpy with known strlen (src) == 0 into memset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2020-01-14
 CC||msebor at gcc dot gnu.org
 Blocks||83819
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81433,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81704
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Martin Sebor  ---
Into memset (b, 0, N) sounds right, for any empty source string, as in: 

void f (char *b, const char *a, unsigned n)
{
  if (__builtin_strlen (a))
return;

  __builtin_strncpy (b, a, n);
}

Unfortunately, determining that a is empty in the strncpy call above is
defeated by the super-early strlen() != 0 folding, so the strlen pass has no
idea of a's length.


Referenced Bugs:

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

[Bug c/93268] ICE with gcc-10 when compiling hypre library with -O3

[kristopher.kuhlman at gmail dot com]

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

--- Comment #1 from Kris  ---
sorry. I guess I should add this version of gcc is built from the git version
pulled this morning.

gcc (GCC) 10.0.0 20200114 (experimental)

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-01-14
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Please provide the output of 'gcc -v' as requested by https://gcc.gnu.org/bugs/

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Your testcase is invalid:

iota.cc: In function 'int main()':
iota.cc:22:6: error: conflicting declaration 'auto beginTest4'
   22 | auto beginTest4 = std::ranges::begin(Test5); // OK
  |  ^~
iota.cc:19:6: note: previous declaration as 'std::ranges::iota_view::_Iterator beginTest4'
   19 | auto beginTest4 = std::ranges::begin(Test4); // Error
  |  ^~


It compiles for me if I fix that.

[Bug c/93268] ICE with gcc-10 when compiling hypre library with -O3

[kristopher.kuhlman at gmail dot com]

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

--- Comment #2 from Kris  ---
It builds with -O2, fails with -O3.

[Bug tree-optimization/90576] [10 regression] SPEC CPU2006 450.soplex miscompiled with -Os -flto after r271413

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

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

--- Comment #9 from Maxim Kuvyrkov  ---
Confirmed fixed on both aarch64-linux-gnu and arm-linux-gnueabihf for -Os
-flto.  Thanks!

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[pilarlatiesa at gmail dot com]

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

--- Comment #3 from Pilar Latiesa  ---
(In reply to Jonathan Wakely from comment #1)
> Please provide the output of 'gcc -v' as requested by
> https://gcc.gnu.org/bugs/

Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20200114/configure --prefix=/usr
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--disable-bootstrap --with-abi=m64 --enable-clocale=gnu
--enable-languages=c,c++,fortran --enable-ld=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix --enable-libatomic --enable-libcilkrts
--enable-libgomp 
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20200111 (experimental)

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[pilarlatiesa at gmail dot com]

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

--- Comment #4 from Pilar Latiesa  ---
(In reply to Jonathan Wakely from comment #1)
> Please provide the output of 'gcc -v' as requested by
> https://gcc.gnu.org/bugs/

Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-linux-gnu
Configured with: ../gcc-trunk-20200114/configure --prefix=/usr
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
--disable-bootstrap --with-abi=m64 --enable-clocale=gnu
--enable-languages=c,c++,fortran --enable-ld=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix --enable-libatomic --enable-libcilkrts
--enable-libgomp 
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20200111 (experimental)

(In reply to Jonathan Wakely from comment #2)
> Your testcase is invalid:
> 
> iota.cc: In function 'int main()':
> iota.cc:22:6: error: conflicting declaration 'auto beginTest4'
>22 | auto beginTest4 = std::ranges::begin(Test5); // OK
>   |  ^~
> iota.cc:19:6: note: previous declaration as 'std::ranges::iota_view unsigned int, long unsigned int>::_Iterator beginTest4'
>19 | auto beginTest4 = std::ranges::begin(Test4); // Error
>   |  ^~

Sorry. I composed the testcase from several pieces but didn't test the whole.

> It compiles for me if I fix that.

Strange. I see the same errors on Compiler Explorer:
https://godbolt.org/z/pcq7fS

[Bug ipa/92240] [10 regression] ICE in duplicate, at ipa-prop.c:3883

[dimhen at gmail dot com]

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

--- Comment #7 from Dmitry G. Dyachenko  ---
(In reply to Martin Liška from comment #6)
> @Dmitry: Can you please attach a pre-processed source file (-E option)?

@Martin: FAIL start for me during gcc bootstrap somewhere between r277460 and
r277485. bootstrap was restored for me at r277486.

Fedora 31, x86_64

For reproduce you can try download gcc sources, run
contrib/download_prerequesites, run configure as c#1 and make.

I"ll download preprocessed file tomorrow.

[Bug fortran/93253] Regression on non-standard hex constant syntax

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl  ---
On Tue, Jan 14, 2020 at 11:18:45AM +, pinskia at gcc dot gnu.org wrote:
>  CUT 
> So using an undocumented extension 

The 'X' extension was documented, but I doubt anyone reads
documentation.  Prior to my patch, the docs read

6.1.10 BOZ literal constants
...
   As an extension, GNU Fortran allows hexadecimal BOZ literal constants
to be specified using the 'X' prefix, in addition to the standard 'Z'
prefix.  The BOZ literal can also be specified by adding a suffix to the
string, for example, 'Z'ABC'' and ''ABC'Z' are equivalent.
...

The docs now read

...
   As a deprecated extension, GNU Fortran allows hexadecimal BOZ literal
constants to be specified using the 'X' prefix.  The BOZ literal
constant can also be specified by adding a suffix to the string, for
example, 'Z'ABC'' and ''ABC'X' are equivalent.
...

> Basically BOZ is finally standardized in Fortran2018 and the NAS benchmark
> could be re-written in a standard format instead ...

The first part is indeed true.  User fixing invalid Fortran code
to use standard conforming syntax is encouraged.

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[pilarlatiesa at gmail dot com]

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

--- Comment #5 from Pilar Latiesa  ---
It compiles with -std=gnu++2a but not with -std=c++2a. Hope this helps.

[Bug target/92055] [avr] Support 64-bit double

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Georg-Johann Lay :

https://gcc.gnu.org/g:780e19f87c8a69e425b6f98703e6931f49518a80

commit r10-5942-g780e19f87c8a69e425b6f98703e6931f49518a80
Author: Georg-Johann Lay 
Date:   Tue Jan 14 17:45:40 2020 +0100

The mentioned auto-generated file is no more part of the

GCC sources, it's auto-generated in $(builddir) during build.

PR target/92055
* contrib/gcc_update (files_and_dependencies): Remove
entry for gcc/config/avr/t-multilib.

[Bug c/93241] [8/9/10 Regression] _Bool casts in dead branches of integer constant expressions cause undesirable warnings under -pedantic iff the dead branch contains overflow

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Joseph Myers :

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

commit r8-9933-ga2a2a06cafff858f3211a53a6ecc215f5b296565
Author: Joseph Myers 
Date:   Tue Jan 14 16:53:26 2020 +

Fix handling of overflow in C casts in integer constant expressions (PR
c/93241).

Bug 93241 reports a case where certain C expressions involving casts,
that would not be valid in an evaluated part of an integer constant
expression (because of e.g. involving integer overflow), are wrongly
rejected in an unevaluated part of an integer constant expression even
though all the operands and operations are ones that are valid in that
context.  This is a rejects-valid regression in GCC 4.5 and later
relative to 4.4 (for some testcases; the one in the bug uses
_Static_assert which isn't supported in those older releases).

The rule in the C front end is that an expression with those
properties (valid in an unevaluated part of an integer constant
expression but not an evaluated part) must be represented either as an
INTEGER_CST with TREE_OVERFLOW set or as a C_MAYBE_CONST_EXPR with
C_MAYBE_CONST_EXPR_INT_OPERANDS set.  This patch fixes build_c_cast to
check for that case and call note_integer_operands as needed.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR c/93241
gcc/c:
* c-typeck.c (build_c_cast): Check for expressions with integer
operands that can occur in an unevaluated part of an integer
constant expression and call note_integer_operands as needed.

gcc/testsuite:
* gcc.dg/c11-static-assert-10.c, gcc.dg/c99-const-expr-15.c: New
tests.

(cherry picked from commit 3d77686d2eddf76d3498169d0ca5653db45a8662)

[Bug fortran/93253] Regression on non-standard hex constant syntax

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #7 from Steve Kargl  ---
On Tue, Jan 14, 2020 at 10:48:30AM +, fx at gnu dot org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93253
> 
> --- Comment #4 from Dave Love  ---
> Apologies, I was misled by something else; that option does affect the result.
> 
> However, this change in behaviour isn't mentioned in release notes, the error
> message doesn't point to that option, and documentation suggests the code is
> supported and that option is for something else.
> 

We're in luck.  10.1 has not been released, yet; and, trunk 10.0.0
has entered stage 4 (regression and documentation fixes only).  It
seems like a good time for a new contributor to step up and fix what
s/he does not like with documentation.

And, as our good fortunate will have, the move to git means that
I'll not longer be committing changes to gfortran.  We won't have
to deal with a 1000 or so bug fixes, a few 1000 code reviews,
and design decisions based on the Fortran standard.

[Bug c++/92594] [10 Regression] internal compiler error: in build_value_init_noctor, at cp/init.c:400 using std::tuple

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:8982b5535c2762f566fd15e5862acf4702a78690

commit r10-5945-g8982b5535c2762f566fd15e5862acf4702a78690
Author: Jason Merrill 
Date:   Tue Jan 14 01:00:48 2020 -0500

PR c++/92594 - ICE with inherited trivial default ctor.

Here we were getting confused about whether or not pod_tuple has a trivial
default constructor.  bar inherits the trivial e default constructor; the
effect of calling that inherited constructor is equivalent to calling a
defaulted default constructor in bar, so let's treat it as such.

* method.c (trivial_fn_p): Treat an inherited default constructor
like a normal default constructor.

[Bug c++/92009] [10 Regression] ICE: Segmentation fault (in is_really_empty_class)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:80de0002429c74626198cefa168c3081c9d90566

commit r10-5944-g80de0002429c74626198cefa168c3081c9d90566
Author: Jason Merrill 
Date:   Tue Jan 14 00:05:47 2020 -0500

PR c++/92009 - ICE with punning of typeid.

There were two issues in this PR:

1) We were crashing in is_really_empty_class because we say that the
internal RTTI types are classes, but never gave them TYPE_BINFO.

2) We were allowing the cast to a different pointer type because STRIP_NOPS
in cxx_fold_indirect_ref ignored REINTERPRET_CAST_P.

* rtti.c (get_tinfo_desc): Call xref_basetypes.
* constexpr.c (cxx_fold_indirect_ref): Don't strip
REINTERPRET_CAST_P.

[Bug c++/92009] [10 Regression] ICE: Segmentation fault (in is_really_empty_class)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c/93268] ICE with gcc-10 when compiling hypre library with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Yes, the preprocessed file is something that is essential for us, see
https://gcc.gnu.org/bugs/ for details.

[Bug c++/92594] [10 Regression] internal compiler error: in build_value_init_noctor, at cp/init.c:400 using std::tuple

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug c++/93101] [10 Regression] ICE - aggregate initialization of base

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #2 from Jason Merrill  ---
Yep, seems to have been fixed by the patch for bug 93173.

[Bug c++/92590] [10 Regression] Cannot expose protected default constructor with "using" keyword in gcc 10

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/93266] strlen pass could optimize strncpy with known strlen (src) == 0 into memset

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
If the strlen pass would handle if (__builtin_strlen (a)) return; if we
disabled the early folding, then it should be taught to handle whatever it is
folded to.
Though, I'm not sure it can, there is no code to handle sizes only for certain
parts of cfg and others for different ones.

[Bug c/93268] ICE with gcc-10 when compiling hypre library with -O3

[kristopher.kuhlman at gmail dot com]

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

--- Comment #4 from Kris  ---
Created attachment 47653
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47653&action=edit
preprocessed source file

gzipped preprocessed source file attached

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #6 from Jonathan Wakely  ---
(In reply to Pilar Latiesa from comment #5)
> It compiles with -std=gnu++2a but not with -std=c++2a. Hope this helps.

This is why you're supposed to provide the command, and 'gcc -v' info etc.

[Bug c/93268] ICE with gcc-10 when compiling hypre library with -O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-14
 Ever confirmed|0   |1

--- Comment #5 from Jakub Jelinek  ---
Reduced testcase for -O3 -march=skylake-avx512:
int
foo (int *a, double *b, int *c)
{
  int f, g = 0;
  for (f = 0; f < 100; f++)
if (b[f] && c[a[f]])
  g++;
  return g;
}

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
The problem happens when the first template argument is an integer with no
larger integer type available. I try to use __int128 but that's not usable with
-std=c++2a.

#include 

int main()
{
  std::ranges::iota_view i(0, 3);
  std::ranges::begin(i);
}

[Bug target/92424] [aarch64] Broken code with -fpatchable-function-entry and BTI

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-14
 Ever confirmed|0   |1

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Marking as confirmed

[Bug tree-optimization/93268] ICE with gcc-10 when compiling hypre library with -O3 since r10-5877

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||rsandifo at gcc dot gnu.org
  Component|c   |tree-optimization
   Target Milestone|--- |10.0
Summary|ICE with gcc-10 when|ICE with gcc-10 when
   |compiling hypre library |compiling hypre library
   |with -O3|with -O3 since r10-5877

--- Comment #6 from Jakub Jelinek  ---
Started with r10-5877-gac190fcea1bebf87a2c8c3963548a0e5272c42ec

[Bug tree-optimization/93262] [10 Regression] DSE memstar call trimming affecting -D_FORTIFY_SOURCE since r10-1985

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|8.4 |10.0
Summary|[8/9/10 Regression] DSE |[10 Regression] DSE memstar
   |memstar call trimming   |call trimming affecting
   |affecting -D_FORTIFY_SOURCE |-D_FORTIFY_SOURCE since
   |since r24   |r10-1985

--- Comment #4 from Jakub Jelinek  ---
Actually sorry, it really started with
r10-1985-g192ece9e15d25fd9b6534b2a8bd271684bf76d38 (while that commit looks
like only changing strncpy, it actually changed the num_args > 3 case too.

[Bug tree-optimization/93266] strlen pass could optimize strncpy with known strlen (src) == 0 into memset

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The strlen pass sets the range for non-constant strlen results so it can handle
(and make use of) this sort of thing by querying the range of the strlen lhs. 
For example, it detects the buffer overflow in the test case below, but not if
the size and length are changed to 1, because of the strlen() == 0 folding. 
(This is in the early stages so it doesn't work as well as it should.)  

char b[2];

void f (char *a)
{
  if (__builtin_strlen (a) < 2)
return;

  __builtin_strcpy (b, a);
}

[Bug tree-optimization/90917] Propagate constants into loads if dominated by str(n)cmp/memcmp

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The solution for pr83431 doesn't handle the case in comment #2 but hopefully a
future improvement (in GCC 11) will.

[Bug tree-optimization/93258] [10 regression] Missed constant folding from constructor

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Can't reproduce on x86_64-linux:
$ rm pr93258.C.*; /opt/notnfs/gcc-bisect/obj/gcc/cc1plus.272123 -quiet -w -O3
pr93258.C -fdump-tree-fre3; cat pr93258.C.* | tail -n 9
   [local count: 1073741824]:
  p = ck;
  D.2585 = bw::ci::cj (0B, 6); [return slot optimization]
  D.2585 ={v} {CLOBBER};
  __builtin_unreachable ();

}


$ rm pr93258.C.*; /opt/notnfs/gcc-bisect/obj/gcc/cc1plus.272125 -quiet -w -O3
pr93258.C -fdump-tree-fre3; cat pr93258.C.* | tail -n 9
   [local count: 1073741824]:
  p = ck;
  D.2585 = bw::ci::cj (0B, 6); [return slot optimization]
  D.2585 ={v} {CLOBBER};
  __builtin_unreachable ();

}


$ rm pr93258.C.*; /opt/notnfs/gcc-bisect/obj/gcc/cc1plus.280156 -quiet -w -O3
pr93258.C -fdump-tree-fre3; cat pr93258.C.* | tail -n 9
   [local count: 1073741824]:
  p = ck;
  D.2606 = bw::ci::cj (0B, 6); [return slot optimization]
  D.2606 ={v} {CLOBBER};
  __builtin_unreachable ();

}

[Bug target/93254] g++ -m32 -mfpmath=sse -msse generates sse2 instructions

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

https://gcc.gnu.org/g:6bd65ad89c202aba3929b9a03ef7e84de873380a

commit r10-5947-g6bd65ad89c202aba3929b9a03ef7e84de873380a
Author: Uros Bizjak 
Date:   Tue Jan 14 19:07:47 2020 +0100

PR target/93254 - -msse generates sse2 instructions

* config/i386/i386.md (*movsf_internal): Require SSE2 ISA for
alternatives 9 and 10.

[Bug c++/92590] [10 Regression] Cannot expose protected default constructor with "using" keyword in gcc 10

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
This is a consequence of the change Jonathan cites, to treat the inherited
constructor as a user-declared constructor that prevents the implicit
declaration of a default constructor in Derived.

The difference in access behavior follows from this; the standard says,

"A synonym created by a using-declaration has the usual accessibility for a
member-declaration. A using-declarator that names a constructor does not create
a synonym; instead, the additional constructors are accessible if they would be
accessible when used to construct an object of the corresponding base class,
and the accessibility of the using-declaration is ignored."

So if constructing 'd' calls the inherited constructor, it's ill-formed; if it
calls the implicitly-declared default constructor, it's well-formed.

I thought my change was an obvious bug fix, but it seems that other compilers
have the old semantics, so I should probably undo it.