[Bug c++/85866] [8/9 Regression] too few arguments to function when sfinae on calling pointer to member function

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed May 23 03:52:49 2018
New Revision: 260562

URL: https://gcc.gnu.org/viewcvs?rev=260562=gcc=rev
Log:
PR c++/85866 - error with .* in default template arg.

* pt.c (tsubst_copy_and_build): Handle partial instantiation.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/85866] [8/9 Regression] too few arguments to function when sfinae on calling pointer to member function

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed May 23 03:53:14 2018
New Revision: 260564

URL: https://gcc.gnu.org/viewcvs?rev=260564=gcc=rev
Log:
PR c++/85866 - error with .* in default template arg.

* pt.c (tsubst_copy_and_build): Handle partial instantiation.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/cpp0x/fntmpdefarg9.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/pt.c

[Bug c++/81420] When a reference is bound to a member in the base of a temporary, lifetime of the temporary is not extended

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed May 23 03:52:56 2018
New Revision: 260563

URL: https://gcc.gnu.org/viewcvs?rev=260563=gcc=rev
Log:
PR c++/81420 - not extending temporary lifetime.

* call.c (extend_ref_init_temps_1): Handle ARRAY_REF.
* class.c (build_base_path): Avoid redundant move of an rvalue.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/temp-extend1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/class.c

[Bug c++/66476] Erroneous initializer_list lifetime extension from temporary initializer_list

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Jason Merrill  ---
11.6.4 [dcl.init.list] paragraph 6:

The array has the same lifetime as any other temporary object (15.2), except
that initializing an initializer_list object from the array extends the
lifetime of the array exactly like binding a reference to a temporary.

So the array shares the lifetime of the initializer_list.

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

[neil.n.carlson at gmail dot com]

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

Neil Carlson  changed:

   What|Removed |Added

Version|8.0.1   |8.1.1

--- Comment #27 from Neil Carlson  ---
Still present in 8.1.1 (nearly the 7th anniversary of the initial report!)

[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type

[neil.n.carlson at gmail dot com]

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

Neil Carlson  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|DUPLICATE   |---

--- Comment #6 from Neil Carlson  ---
It doesn't fix the test case of comment 4 (which I only gave as a mod to the
comment 0 example).  Here it is explicitly:

type :: any_vector
  class(*), allocatable :: v(:)
end type
type(any_vector) :: x, y
x%v = ['foo','bar']
select type (v => x%v)
type is (character(*))
  print '("orig=[""",a,''","'',a,''"]'')', v ! expect orig=["foo","bar"]
end select
y = x ! THIS ASSIGNMENT IS NOT BEING DONE CORRECTLY
select type (v => y%v)
type is (character(*))
  print '("copy=[""",a,''","'',a,''"]'')', v ! expect copy=["foo","bar"]
end select
end

$ gfortran --version
GNU Fortran (GCC) 8.1.1 20180521

$ gfortran gfortran-20171122b.f90 
$ ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0x7f249667794f in ???
#1  0x0 in ???
Segmentation fault (core dumped)

[Bug tree-optimization/85700] Spurious -Wstringop-truncation warning with strncat

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01189.html

[Bug c++/85883] New: class template argument deduction fails in new-expression

[barry.revzin at gmail dot com]

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

Bug ID: 85883
   Summary: class template argument deduction fails in
new-expression
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Slightly reduced from https://stackoverflow.com/q/50478019/2069064:

template 
struct Bar
{
Bar(T1, T2) { }
};

int main()
{
auto x = Bar(1, 2);
auto y = new Bar(3, 4);
}

The declaration of x works, the declaration of y fails with:

: In function 'int main()':
:10:26: error: class template argument deduction failed:
 auto y = new Bar(3, 4);
  ^
:10:26: error: no matching function for call to 'Bar()'
:4:5: note: candidate: 'template Bar(T1, T2)->
Bar'
 Bar(T1, T2) { }
 ^~~
:4:5: note:   template argument deduction/substitution failed:
:10:26: note:   candidate expects 2 arguments, 0 provided
 auto y = new Bar(3, 4);
  ^

[Bug tree-optimization/85882] Value of local variable changes unintentionally if certain optimization are enabled

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
  Component|c++ |tree-optimization

--- Comment #5 from Andrew Pinski  ---
I suspect this is a dup of bug 85822.

[Bug c++/85882] Value of local variable changes unintentionally if certain optimization are enabled

[mednafen at sent dot com]

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

mednafen at sent dot com changed:

   What|Removed |Added

 CC||mednafen at sent dot com

--- Comment #4 from mednafen at sent dot com ---
Created attachment 44170
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44170=edit
smaller test case

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
Proposed patch here:  https://gcc.gnu.org/ml/gcc-patches/2018-05/msg01183.html

[Bug fortran/85868] Subarray of a pointer array associated with a pointer dummy argument

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
According to NAG, the example is supposedly valid F2008, but invalid F2003:

% nagfor pr85868.f90 -f2003 
NAG Fortran Compiler Release 6.2(Chiyoda) Build 6207
Extension: pr85868.f90, line 16: Argument A (no. 1) of TE is a pointer but
actual argument T(1:,:) has the TARGET attribute
[NAG Fortran Compiler normal termination, 1 warning]

% nagfor pr85868.f90 -f2008
NAG Fortran Compiler Release 6.2(Chiyoda) Build 6207
[NAG Fortran Compiler normal termination]

% ./a.out 
   1.000


Re comment #1, I think it is unrelated to the other PR.

[Bug c++/85882] Value of local variable changes unintentionally if certain optimization are enabled

[stefan.bolus at gmx dot de]

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

--- Comment #3 from Stefan Bolus  ---
btw. The code in the example is an adaption from Apache Thrift.

[Bug c++/85882] Value of local variable changes unintentionally if certain optimization are enabled

[stefan.bolus at gmx dot de]

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

--- Comment #2 from Stefan Bolus  ---
Created attachment 44169
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44169=edit
Example to reproduce the error.

[Bug c++/85882] New: Value of local variable changes unintentionally if certain optimization are enabled

[stefan.bolus at gmx dot de]

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

Bug ID: 85882
   Summary: Value of local variable changes unintentionally if
certain optimization are enabled
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stefan.bolus at gmx dot de
  Target Milestone: ---

In the method ...

  void readMessageBegin() {
int32_t sz;
readI32(sz); // Emulates reading from wire, `sz` passed by ref.

// Here, the value of `sz` is -2147418110.
std::cout << "Value before if-throw: " << sz << std::endl;

int32_t version = sz & ((int32_t) 0x);
if (version != ((int32_t) 0x8001)) {
  // This seems to have a `throw` for the error to happen.
  throw 123;
}

// But here, the value of `sz` suddenly is -2147418112.
std::cout << "Value after if-throw : " << sz << std::endl;
  }

... the value of `sz` changes between the `cout` line if `-O2` is turned on. If
any of the optimizations `-ftree-vrp -finline -ftree-fre` is turned off, then
the change does not occur.

A minimal example is attached to the ticket. Additionally, a Makefile which
disables most other optimizations with the error still being there, is also
attached.

$ g++ --version
g++ (GCC) 8.1.1 20180502 (Red Hat 8.1.1-1)

$ uname -a
Linux blackbox 4.16.8-300.fc28.x86_64 #1 SMP Wed May 9 20:23:40 UTC 2018 x86_64
x86_64 x86_64 GNU/Linux

--- Comment #1 from Stefan Bolus  ---
Created attachment 44168
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44168=edit
Makefile to disable most optimization options.

[Bug tree-optimization/81953] Code sinking increases register pressure

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kelvin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kelvin at gcc dot 
gnu.org

--- Comment #5 from kelvin at gcc dot gnu.org ---
I am going to experiment with better selection of the sink block.

Suppose there are multiple blocks C1, C2, ... , CN that are dominated by the
original defining expression and post-dominated by the block that uses the
defined value.

The preferred sink location is the beginning of the basic block Ci, where Ci
dominates Cj for 1 <= j <= N.

In other words, the sink destination is the first control point at which
eventual control flow to the definition's use block is no longer conditional. 
By sinking to this control point, we "minimize" the lifetimes of any variables
that contribute to evaluation of the original definition, and we increase the
amount of scheduling flexibility, "maximizing" the amount of time available to
finish calculation of value before the definition is used.

I'm not entirely confident this is a good tradeoff in general.  By moving the
sink spot forward, I may be creating a different kind of register pressure. 
Consider this third variation on the theme:

void bar();
int j, x, y, z;
void foo (int a, int b) {
  int l, m, n;
  l = a + 3 * b;
  m = a * 5 + b;
  n = a * 7 + b * 9;
  if (a != 5) {
/* my heuristic moves computations of l, m, n to here,
   resulting in increased register pressure across call to bar (), since
   now we have b, l, m, and n in registers.  that's no worse than the code
   as written, but a better solution would have computed these expressions
   after bar (), maintaining only a and b in registers across the call to 
   bar ().  */
bar ();
if (b != 3;
  x = 3;
else
  x = 5;
j = l;
y = m;
z = n;
  }
}

I need to ponder further before experimenting.

Feel free to share thoughts and advice.  This is a new area for me.  Am using
this "exercise" to become more familiar with middle end.

[Bug tree-optimization/85814] [8 Regression] ICE Segmentation fault during GIMPLE pass: strlen -O3 and above

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
Thanks for the bug report.  Fixed on trunk and GCC 8 branch.

[Bug testsuite/63177] Powerpc no-vfa-vect-depend-2.c and no-vfa-vect-depend-3.c failures

[carll at gcc dot gnu.org]

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

--- Comment #6 from Carl Love  ---
Printing the results rather then aborting, we see the value of ib[1] and ib[3]
are swapped; ib[2] and ib[4] are swapped, then  ib[5] and ib[7] are swapped and
ib[6] and ib[8] are swapped.  The pattern continues.

ib[1] = 168, res[1] = 192  <-R1 
ib[2] = 156, res[2] = 180   <-R2
ib[3] = 192, res[3] = 168  <-R1 
ib[4] = 180, res[4] = 156   <-R2
ib[5] = 120, res[5] = 144  <-R3 
ib[6] = 108, res[6] = 132   <-R4
ib[7] = 144, res[7] = 120  <-R3 
ib[8] = 132, res[8] = 108   <-R4
ib[9] = 72, res[9] = 96<-R5 
ib[10] = 60, res[10] = 84   <-R6
ib[11] = 96, res[11] = 72  <-R5 
ib[12] = 84, res[12] = 60   <-R6
ib[13] = 24, res[13] = 48  <-R7 
ib[14] = 12, res[14] = 36   <-R8
ib[15] = 48, res[15] = 24  <-R7 
ib[16] = 36, res[16] = 12   <-R8

[Bug c++/80485] rejects-valid: constexpr static_cast of pointer-to-member-function to bool

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Created attachment 44167
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44167=edit
proposed fix

https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00968.html

[Bug fortran/85841] [F2018] reject deleted features

[janus at gcc dot gnu.org]

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

--- Comment #13 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue May 22 20:05:53 2018
New Revision: 260555

URL: https://gcc.gnu.org/viewcvs?rev=260555=gcc=rev
Log:
2018-05-22  Janus Weil  

PR fortran/85841
* gfortran.dg/pr30667.f: Add option "-std=legacy".

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr30667.f

[Bug c++/80485] rejects-valid: constexpr static_cast of pointer-to-member-function to bool

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/85877] [6/7/8/9 Regression] ICE in fold_convert_loc, at fold-const.c:2449

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
  Known to work||4.8.5
   Keywords||ice-on-valid-code
   Last reconfirmed||2018-05-22
 Ever confirmed|0   |1
   Target Milestone|--- |6.5
  Known to fail||6.4.0, 7.3.0, 8.1.0, 9.0

--- Comment #1 from Dominique d'Humieres  ---
Confirmed.

[Bug middle-end/85880] Different code generation for uninitialized variables

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #4 from Fredrik Hederstierna 
 ---
Ok, you are probably right. I just was surprised that all GCC 4,5,6,7 gave same
result, but something changed with 8. But you are right, its unpredictable
results since its undefined. I practice it gave me some issues though to some
benchmarking suites have code that have undefined variabled, but thats an issue
for benchmarks, not GCC itself.
So you are right, me can close it, just wanted it to be confirmed as
unimportant.
Thanks, Fredrik

[Bug middle-end/85643] attribute nonstring fails to squash -Wstringop-truncation warning at an offset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Sebor  ---
Fix also applied to gcc-8-branch in r260553.

[Bug middle-end/85643] attribute nonstring fails to squash -Wstringop-truncation warning at an offset

[msebor at gcc dot gnu.org]

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

--- Comment #8 from Martin Sebor  ---
Author: msebor
Date: Tue May 22 19:46:44 2018
New Revision: 260553

URL: https://gcc.gnu.org/viewcvs?rev=260553=gcc=rev
Log:
PR middle-end/85643 - attribute nonstring fails to squash -Wstringop-truncation
warning

gcc/ChangeLog:

PR middle-end/85643
* calls.c (get_attr_nonstring_decl): Handle MEM_REF.

gcc/testsuite/ChangeLog:

PR middle-end/85643
* c-c++-common/attr-nonstring-7.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/c-c++-common/attr-nonstring-7.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/calls.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug middle-end/85359] duplicate -Wstringop-overflow for a strcmp call with a nonstring pointer

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Adjusted patch committed in r260550.

[Bug middle-end/85359] duplicate -Wstringop-overflow for a strcmp call with a nonstring pointer

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Tue May 22 19:37:48 2018
New Revision: 260550

URL: https://gcc.gnu.org/viewcvs?rev=260550=gcc=rev
Log:
PR middle-end/85359 - duplicate -Wstringop-overflow for a strcmp call with a
nonstring pointer

gcc/ChangeLog:

PR middle-end/85359
* builtins.c (expand_builtin_strcpy): Call maybe_warn_nonstring_arg
only when expasion succeeds.
(expand_builtin_strcmp): Same.
(expand_builtin_strncmp): Same.

gcc/testsuite/ChangeLog:

PR middle-end/85359
* gcc.dg/attr-nonstring.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/attr-nonstring.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtins.c
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85866] [8/9 Regression] too few arguments to function when sfinae on calling pointer to member function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug testsuite/63177] Powerpc no-vfa-vect-depend-2.c and no-vfa-vect-depend-3.c failures

[carll at gcc dot gnu.org]

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

--- Comment #5 from Carl Love  ---
Created attachment 44166
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44166=edit
diff file

The attachment is a side by side diff of good code and bad code.  It shows the
difference in the code generation that leads to the abort.  It has been edited
down to just where the code differs.

[Bug middle-end/85881] New: [9 Regression] FAIL: g++.dg/pr80481.C -std=gnu++11 scan-assembler-not vmovaps

[hjl.tools at gmail dot com]

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

Bug ID: 85881
   Summary: [9 Regression] FAIL: g++.dg/pr80481.C  -std=gnu++11
scan-assembler-not vmovaps
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: richard.sandiford at linaro dot org
  Target Milestone: ---

On x86-64, r260348 caused:

FAIL: g++.dg/pr80481.C  -std=gnu++11  scan-assembler-not vmovaps
FAIL: g++.dg/pr80481.C  -std=gnu++14  scan-assembler-not vmovaps
FAIL: g++.dg/pr80481.C  -std=gnu++98  scan-assembler-not vmovaps

[Bug target/85345] Missing ENDBR in IFUNC resolver

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Tue May 22 19:10:34 2018
New Revision: 260547

URL: https://gcc.gnu.org/viewcvs?rev=260547=gcc=rev
Log:
Don't mark IFUNC resolver as only called directly

Since IFUNC resolver is called indirectly, don't mark IFUNC resolver as
only called directly.  This patch adds ifunc_resolver to cgraph_node,
sets ifunc_resolver for ifunc attribute and checks ifunc_resolver
instead of looking up ifunc attribute.

gcc/

PR target/85345
* cgraph.h (cgraph_node::create): Set ifunc_resolver for ifunc
attribute.
(cgraph_node::create_alias): Likewise.
(cgraph_node::get_availability): Check ifunc_resolver instead
of looking up ifunc attribute.
* cgraphunit.c (maybe_diag_incompatible_alias): Likewise.
* varasm.c (do_assemble_alias): Likewise.
(assemble_alias): Likewise.
(default_binds_local_p_3): Likewise.
* cgraph.h (cgraph_node): Add ifunc_resolver.
(cgraph_node::only_called_directly_or_aliased_p): Return false
for IFUNC resolver.
* lto-cgraph.c (input_node): Set ifunc_resolver for ifunc
attribute.
* symtab.c (symtab_node::verify_base): Verify that ifunc_resolver
is equivalent to lookup_attribute ("ifunc", DECL_ATTRIBUTES (decl)).
(symtab_node::binds_to_current_def_p): Check ifunc_resolver
instead of looking up ifunc attribute.

gcc/testsuite/

PR target/85345
* gcc.target/i386/pr85345.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr85345.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cgraph.c
trunk/gcc/cgraph.h
trunk/gcc/cgraphunit.c
trunk/gcc/lto-cgraph.c
trunk/gcc/symtab.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/varasm.c

[Bug testsuite/63177] Powerpc no-vfa-vect-depend-2.c and no-vfa-vect-depend-3.c failures

[carll at gcc dot gnu.org]

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

Carl Love  changed:

   What|Removed |Added

 CC||carll at gcc dot gnu.org

--- Comment #4 from Carl Love  ---
The test is compiled with the options 

-maltivec -mpower9-vector -ftree-vectorize -fno-vect-cost-model -fno-common -O2
-fdump-tree-vect-details --param vect-max-version-for-alias-checks=0 

The test call abort and exits.

The compile options can be reduced to 

 -mpower9-vector -ftree-vectorize  -O2

and still reproduce the error. Removing any of the three and the test will
pass.

[Bug middle-end/85682] Regression: gcc.dg/tree-ssa/prefetch-5.c at r259995

[luis.machado at linaro dot org]

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

Luis Machado  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Luis Machado  ---
Fixed.

[Bug target/85833] [AVX512] use mask registers instructions instead of scalar code

[wojciech_mula at poczta dot onet.pl]

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

--- Comment #3 from Wojciech Mula  ---
Uroš, thank you very much. I didn't pay attention on the AVX512 variant, as I
thought this is so basic instruction that it should be available from AVX512F.

[Bug fortran/85841] [F2018] reject deleted features

[janus at gcc dot gnu.org]

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

--- Comment #12 from janus at gcc dot gnu.org ---
(In reply to Christophe Lyon from comment #8)
> Since this change (r260433), I've noticed that:
> UNRESOLVED: gfortran.dg/vect/pr52580.f   -O   scan-tree-dump-times vect
> "LOOP VECTORIZED" 1

Those problems should be gone with r260544.

[Bug middle-end/85880] Different code generation for uninitialized variables

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
I don't see any value in this bug report.  Undefined code changes behavior (and
code generation) between different versions of GCC all the time.  In your
example, GCC could have decided to just return -1 for test_1 and test_2 or it
could have called call_external_func.
Or it could have left in the checks for variables (via not setting registers)
and done all three checks in both functions.

There is no requirement for GCC to any of the above.  In fact it could have
also just done a trap instructions too.

[Bug fortran/85841] [F2018] reject deleted features

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org ---
Author: janus
Date: Tue May 22 18:22:29 2018
New Revision: 260544

URL: https://gcc.gnu.org/viewcvs?rev=260544=gcc=rev
Log:
2018-05-22  Janus Weil  

PR fortran/85841
* gfortran.dg/gomp/appendix-a/a.6.1.f90: Replace dg-options by
dg-additional-options.
* gfortran.dg/graphite/block-2.f: Ditto.
* gfortran.dg/graphite/id-19.f: Ditto.
* gfortran.dg/vect/Ofast-pr50414.f90: Ditto.
* gfortran.dg/vect/cost-model-pr34445a.f: Ditto.
* gfortran.dg/vect/pr52580.f: Ditto.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/gomp/appendix-a/a.6.1.f90
trunk/gcc/testsuite/gfortran.dg/graphite/block-2.f
trunk/gcc/testsuite/gfortran.dg/graphite/id-19.f
trunk/gcc/testsuite/gfortran.dg/vect/Ofast-pr50414.f90
trunk/gcc/testsuite/gfortran.dg/vect/cost-model-pr34445a.f
trunk/gcc/testsuite/gfortran.dg/vect/pr52580.f

[Bug middle-end/85880] Different code generation for uninitialized variables

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #2 from Fredrik Hederstierna 
 ---
All old GCC < 8
---

Disassembly of section .text:

 :
   0:   2000movsr0, #0
   2:   4770bx  lr

0004 :
   4:   b500push{lr}
   6:   2000movsr0, #0
   8:   bd00pop {pc}

000a :
   a:   b500push{lr}
   c:   2000movsr0, #0
   e:   bd00pop {pc}

--

From GCC 8.1.0
---

Disassembly of section .text:

 :
   0:   2000movsr0, #0
   2:   4770bx  lr

0004 :
   4:   b500push{lr}
   6:   2000movsr0, #0
   8:   bd00pop {pc}

000a :
   a:   2380movsr3, #128; 0x80
   c:   b510push{r4, lr}
   e:   005blslsr3, r3, #1
  10:   2000movsr0, #0
  12:   2b00cmp r3, #0
  14:   d101bne.n   1a 
  16:   f7ff fffe   bl  0 
  1a:   bd10pop {r4, pc}

[Bug c/85880] Different code generation for uninitialized variables

[fredrik.hederstie...@securitas-direct.com]

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

--- Comment #1 from Fredrik Hederstierna 
 ---
Created attachment 44165
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44165=edit
Makefile

[Bug c/85880] New: Different code generation for uninitialized variables

[fredrik.hederstie...@securitas-direct.com]

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

Bug ID: 85880
   Summary: Different code generation for uninitialized variables
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fredrik.hederstie...@securitas-direct.com
  Target Milestone: ---

Created attachment 44164
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44164=edit
Example file

Starting with GCC-8.1.0 the code generation for unitialized variables seems to
be changed.

This is not necessarily a bug perhaps, but became a problem for me since the
CSiBE code size benchmark have some files in the Linux code that have
unitialized variables.

When compiling CSiBE with Gcc-8.1.0 suddenly some files increased remarkably in
size, example is the file "capability.c" which doubled in size many times.

Though this might be a CSiBE issue as root cause, but just wanted to confirm
that this is as expected and maybe it can have impact on other benchmarks that
includes uninitialized variables.

See attached stripped down case taken from CSiBE "capability.c"

[Bug fortran/85879] New: [6/7/8/9 Regression] ICE in expand_debug_locations, at cfgexpand.c:5405

[gs...@t-online.de]

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

Bug ID: 85879
   Summary: [6/7/8/9 Regression] ICE in expand_debug_locations, at
cfgexpand.c:5405
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

A release version needs option -g at -O[gs123] :


$ cat z1.f90
program p
   integer, pointer :: i
   integer, target :: j
   j = 2
   i => j
   !$acc parallel
   j = i
   !$acc end parallel
end


$ gfortran-5 -c z1.f90 -g -O2 -fopenacc
$
$ gfortran-9-20180520 -c z1.f90 -g -O2 -fopenacc
during RTL pass: expand
z1.f90:6:0:

!$acc parallel

internal compiler error: in expand_debug_locations, at cfgexpand.c:5405
0x80bcca expand_debug_locations
../../gcc/cfgexpand.c:5401
0x80bcca execute
../../gcc/cfgexpand.c:6444



Configured with --enable-checking=yes :

$ gfortran-9-20180520 -c z1.f90 -g -O2 -fopenacc
z1.f90:7:0:

j = i

Error: non-trivial conversion at assignment
integer(kind=4)
integer(kind=4) *
i.4 = *D.3808;
during GIMPLE pass: lower
z1.f90:7:0: internal compiler error: verify_gimple failed
0xd3b7bd verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.c:5013
0xc0d220 execute_function_todo
../../gcc/passes.c:1996
0xc0daf9 execute_todo
../../gcc/passes.c:2048

[Bug fortran/85878] New: [6/7/8/9 Regression] ICE in convert_mode_scalar, at expr.c:287

[gs...@t-online.de]

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

Bug ID: 85878
   Summary: [6/7/8/9 Regression] ICE in convert_mode_scalar, at
expr.c:287
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to 5 at -O[gs123], with undefined variable "a" :

$ cat z1.f90
program p
   real :: a
   complex :: c = (2.0, 3.0)
   print *, c
   print *, transfer(a, c)
end


$ gfortran-4.9 z1.f90 -O2
$ a.out
 (  2.,  3.)
 (  0.,  0.)


$ gfortran-9-20180520 -c z1.f90 -O2
during RTL pass: expand
z1.f90:5:0:

print *, transfer(a, c)

internal compiler error: in convert_mode_scalar, at expr.c:287
0x8f9fe9 convert_mode_scalar
../../gcc/expr.c:287
0x8f9fe9 convert_move(rtx_def*, rtx_def*, int)
../../gcc/expr.c:271
0x900ba5 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
../../gcc/expr.c:5728
0x902093 expand_assignment(tree_node*, tree_node*, bool)
../../gcc/expr.c:5159
0x8041cc expand_gimple_stmt_1
../../gcc/cfgexpand.c:3714
0x8041cc expand_gimple_stmt
../../gcc/cfgexpand.c:3810
0x8059fd expand_gimple_basic_block
../../gcc/cfgexpand.c:5835
0x80ae86 execute
../../gcc/cfgexpand.c:6441

[Bug fortran/85877] New: [6/7/8/9 Regression] ICE in fold_convert_loc, at fold-const.c:2449

[gs...@t-online.de]

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

Bug ID: 85877
   Summary: [6/7/8/9 Regression] ICE in fold_convert_loc, at
fold-const.c:2449
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Down to version 4.9, gfortran-4.8 compiles this :

$ cat z1.f90
program p
   bind(c) f
   x = f()
end


$ gfortran-4.8 -c z1.f90
$
$ gfortran-9-20180520 -c z1.f90
z1.f90:3:0:

x = f()

internal compiler error: in fold_convert_loc, at fold-const.c:2449
0x928f83 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2449
0x7783cc gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:8959
0x786d69 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10264
0x74aef7 trans_code
../../gcc/fortran/trans.c:1828
0x772219 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6507
0x7012a0 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x7012a0 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x74809f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug fortran/85544] [6/7/8/9 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.c:3385

[gs...@t-online.de]

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

--- Comment #3 from G. Steinmetz  ---
For special case +-1 :

$ cat zz1.f90
program p
   integer, parameter :: na = -3, ne = 10
   integer :: i, a(na:ne), b(na:ne)
   a = [(i, i=na, ne)]
   b = [1**a]
end


$ gfortran-9-20180520 -c zz1.f90 -O2
zz1.f90:5:0:

b = [1**a]

internal compiler error: in gfc_trans_array_constructor_subarray, at
fortran/trans-array.c:1633
0x75b1dc gfc_trans_array_constructor_subarray
../../gcc/fortran/trans-array.c:1633
0x75b1dc gfc_trans_array_constructor_value
../../gcc/fortran/trans-array.c:1762
0x75ba63 trans_array_constructor
../../gcc/fortran/trans-array.c:2543
0x75ba63 gfc_add_loop_ss_code
../../gcc/fortran/trans-array.c:2819
0x75c295 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
../../gcc/fortran/trans-array.c:5110
0x78656c gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10058
0x74aef7 trans_code
../../gcc/fortran/trans.c:1828
0x772219 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6507
0x7012a0 translate_all_program_units
../../gcc/fortran/parse.c:6121
0x7012a0 gfc_parse_file()
../../gcc/fortran/parse.c:6324
0x74809f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204

[Bug rtl-optimization/85876] New: ICE in move_op_ascend, at sel-sched.c:6164

[asolokha at gmx dot com]

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

Bug ID: 85876
   Summary: ICE in move_op_ascend, at sel-sched.c:6164
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---
Target: x86_64-unknown-linux-gnu

gcc-9.0.0-alpha20180520 snapshot (r260425), 8.1, 7.3, 6.3, 5.4, 4.9.4 all ICE
when compiling the following snippet w/ -march=bdver1 -O2 (-O3, -Ofast)
-fschedule-insns -fsel-sched-pipelining -fselective-scheduling
-fno-if-conversion -fno-tree-dce:

int ov, rq, ac;

int
y2 (int);

void
f8 (int vn)
{
  while (rq < 1)
{
  ov *= y2 (ac);
  vn += (!!ov && !!ac) + ac;
}
}

% x86_64-unknown-linux-gnu-gcc-9.0.0-alpha20180520 -march=bdver1 -O2
-fschedule-insns -fsel-sched-pipelining -fselective-scheduling
-fno-if-conversion -fno-tree-dce -c nnsbuwm9.c
during RTL pass: sched1
nnsbuwm9.c: In function 'f8':
nnsbuwm9.c:14:1: internal compiler error: in move_op_ascend, at
sel-sched.c:6164
 }
 ^
0x64f8c9 move_op_ascend
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180520/work/gcc-9-20180520/gcc/sel-sched.c:6164
0xc64d61 code_motion_path_driver
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180520/work/gcc-9-20180520/gcc/sel-sched.c:6660
0xc65872 move_op
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180520/work/gcc-9-20180520/gcc/sel-sched.c:6714
0xc65872 move_exprs_to_boundary
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180520/work/gcc-9-20180520/gcc/sel-sched.c:5237
0xc65872 schedule_expr_on_boundary
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180520/work/gcc-9-20180520/gcc/sel-sched.c:5450
0xc6973c fill_insns
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180520/work/gcc-9-20180520/gcc/sel-sched.c:5592
0xc6973c schedule_on_fences
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180520/work/gcc-9-20180520/gcc/sel-sched.c:7366
0xc6973c sel_sched_region_2
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180520/work/gcc-9-20180520/gcc/sel-sched.c:7504
0xc6ae26 sel_sched_region_1
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180520/work/gcc-9-20180520/gcc/sel-sched.c:7546
0xc6b61e sel_sched_region(int)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180520/work/gcc-9-20180520/gcc/sel-sched.c:7647
0xc6c511 run_selective_scheduling()
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180520/work/gcc-9-20180520/gcc/sel-sched.c:7733
0xc4c29d rest_of_handle_sched
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180520/work/gcc-9-20180520/gcc/sched-rgn.c:3718
0xc4c29d execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20180520/work/gcc-9-20180520/gcc/sched-rgn.c:3828

I hope this is not a duplicate of some other sel-sched PR.

[Bug c/85623] strncmp() warns about attribute 'nonstring' incorrectly in -Wstringop-overflow

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Patch committed to trunk in r260541.

[Bug c/85623] strncmp() warns about attribute 'nonstring' incorrectly in -Wstringop-overflow

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
Author: msebor
Date: Tue May 22 17:45:35 2018
New Revision: 260541

URL: https://gcc.gnu.org/viewcvs?rev=260541=gcc=rev
Log:
PR c/85623 - strncmp() warns about attribute 'nonstring' incorrectly in
-Wstringop-overflow

gcc/ChangeLog:

PR c/85623
* calls.c (maybe_warn_nonstring_arg): Use string length to set
or ajust the presumed bound on an operation to avoid unnecessary
warnings.

gcc/testsuite/ChangeLog:

PR c/85623
* c-c++-common/attr-nonstring-3.c: Adjust.
* c-c++-common/attr-nonstring-4.c: Adjust.
* c-c++-common/attr-nonstring-6.c: New test.


Added:
trunk/gcc/testsuite/c-c++-common/attr-nonstring-6.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/attr-nonstring-3.c
trunk/gcc/testsuite/c-c++-common/attr-nonstring-4.c

[Bug c++/85875] -Weffc++ can't understand auto return values

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-22
 Blocks||81930
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81930
[Bug 81930] [meta-bug] Issues with -Weffc++

[Bug tree-optimization/85814] [8 Regression] ICE Segmentation fault during GIMPLE pass: strlen -O3 and above

[rsandifo at gcc dot gnu.org]

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue May 22 17:32:37 2018
New Revision: 260540

URL: https://gcc.gnu.org/viewcvs?rev=260540=gcc=rev
Log:
Fix tree-ssa-strlen handling of partial clobbers (PR85814)

Backport trunk fix (r260488).

2018-05-22  Richard Sandiford  

gcc/
PR tree-optimization/85814
* tree-ssa-strlen.c (get_stridx_plus_constant): Cope with
a null return from get_strinfo when unsharing the next
strinfo in the chain.

gcc/testsuite/
PR tree-optimization/85814
* gcc.dg/torture/pr85814.c: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gcc.dg/torture/pr85814.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/tree-ssa-strlen.c

[Bug c++/85875] New: -Weffc++ can't understand auto return values

[msharov at users dot sourceforge.net]

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

Bug ID: 85875
   Summary: -Weffc++ can't understand auto return values
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msharov at users dot sourceforge.net
  Target Milestone: ---

struct C {
struct const_iterator {
auto& operator++() { return *this; }
};
};

Compiling with -Weffc++ gives warning:

t.cc:3:24: warning: prefix ‘auto& C::const_iterator::operator++()’
 should return ‘C::const_iterator&’ [-Weffc++]  

even though auto& evaluates to C::const_iterator&

[Bug rtl-optimization/80318] GCC takes too much RAM and time compiling a template file (var-tracking)

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov  ---
Second largest seems to be the frontend, as with -fsyntax-only we still need
18s and 1.8GB (this is 8.1 with release checking):

Time variable   usr   sys  wall
  GGC
 phase setup:   0.00 (  0%)   0.00 (  0%)   0.00 (  0%)
   1381 kB (  0%)
 phase parsing  :   4.01 ( 22%)   0.80 ( 30%)   4.82 ( 23%)
 519422 kB ( 27%)
 phase lang. deferred   :  13.96 ( 78%)   1.83 ( 70%)  15.82 ( 77%)
1414614 kB ( 73%)
 |name lookup   :   1.89 ( 11%)   0.35 ( 13%)   2.08 ( 10%)
  99986 kB (  5%)
 |overload resolution   :   8.94 ( 50%)   1.29 ( 49%)  10.10 ( 49%)
 934750 kB ( 48%)
 garbage collection :   1.79 ( 10%)   0.00 (  0%)   1.80 (  9%)
  0 kB (  0%)
 preprocessing  :   0.14 (  1%)   0.12 (  5%)   0.37 (  2%)
   2890 kB (  0%)
 parser (global):   0.58 (  3%)   0.21 (  8%)   0.73 (  4%)
 115783 kB (  6%)
 parser struct body :   0.74 (  4%)   0.09 (  3%)   0.77 (  4%)
  81383 kB (  4%)
 parser enumerator list :   0.01 (  0%)   0.00 (  0%)   0.00 (  0%)
364 kB (  0%)
 parser function body   :   0.05 (  0%)   0.03 (  1%)   0.07 (  0%)
   4688 kB (  0%)
 parser inl. func. body :   0.10 (  1%)   0.01 (  0%)   0.12 (  1%)
   6402 kB (  0%)
 parser inl. meth. body :   0.41 (  2%)   0.06 (  2%)   0.39 (  2%)
  27538 kB (  1%)
 template instantiation :  13.86 ( 77%)   2.06 ( 78%)  16.02 ( 78%)
1694216 kB ( 88%)
 constant expression evaluation :   0.26 (  1%)   0.04 (  2%)   0.27 (  1%)
729 kB (  0%)
 varconst   :   0.01 (  0%)   0.00 (  0%)   0.03 (  0%)
 39 kB (  0%)
 symout :   0.02 (  0%)   0.01 (  0%)   0.07 (  0%)
  0 kB (  0%)
 TOTAL  :  17.97  2.63 20.65   
1935427 kB

[Bug c/85874] gcc points to wrong location when displaying error

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Strict overflow warnings are just so badly implemented ...

[Bug c/85874] gcc points to wrong location when displaying error

[asn at samba dot org]

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

--- Comment #2 from Andreas Schneider  ---
If I add -Wsystem-headers I get:

In file included from /usr/include/stdlib.h:822,
 from ../lib/replace/replace.h:40,
 from ../lib/util/debug.c:22:
/usr/include/bits/stdlib-bsearch.h: In function ‘bsearch’:
/usr/include/bits/stdlib-bsearch.h:32:13: error: cast discards ‘const’
qualifier from pointer target type [-Werror=cast-qual]  
   __p = (void *) (((const char *) __base) + (__idx * __size));
 ^
/usr/include/bits/stdlib-bsearch.h:39:9: error: cast discards ‘const’ qualifier
from pointer target type [-Werror=cast-qual]
  return (void *) __p;
 ^
../lib/util/debug.c: In function ‘debug_parse_levels’:
../lib/util/debug.c:796:6: error: assuming pointer wraparound does not occur
when comparing P +- C1 with P +- C2 [-Werror=strict-overflow]   
 bool debug_parse_levels(const char *params_str)
  ^~

[Bug rtl-optimization/80318] GCC takes too much RAM and time compiling a template file (var-tracking)

[benjamin.redelings at gmail dot com]

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

benjamin.redelings at gmail dot com changed:

   What|Removed |Added

Version|7.0.1   |8.1.0

--- Comment #4 from benjamin.redelings at gmail dot com ---
It seems like the time and RAM usage for me is:

-g:
   5.3g / ~100s
-g -fno-var-tracking -fno-var-tracking-assignments:
   4.6g / ~80s
no -g:
   2.3g / 43s

So, while it is true that var-tracking is a problem, it is clearly not the
whole problem.  Also for clang we have:

clang -g:
   2.2g / 93s
clang no -g:
   1.2g / 42s   

So clang is not suffering from the RAM hogging problems, at least.

Any suggestions for a path forward on identifying (say) the second-largest
memory hog, after var-tracking?

[Bug c/85874] gcc points to wrong location when displaying error

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
Does that change if you use -Wsystem-headers?

[Bug c/85874] New: gcc points to wrong location when displaying error

[asn at samba dot org]

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

Bug ID: 85874
   Summary: gcc points to wrong location when displaying error
   Product: gcc
   Version: 8.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asn at samba dot org
  Target Milestone: ---

Created attachment 44163
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44163=edit
debug.i

Compiling the latest upstream Samba with -O3, -Werror, among other flags, fails
but doesn't point to the correct error location.  The line it's giving us
doesn't make any sense for the error printed.


Below is the failing command and error messages.

gcc -O3 -g -ggdb -Wstrict-overflow -Wall -Wcomment -Wpointer-arith -Wcast-align
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wdeclaration-after-statement -fstrict-aliasing -DDEVELOPER -DDEBUG_PASSWORD
-fPIC -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -fstack-protector -Wshadow
-Wcast-qual -fno-common -Werror=address -Werror=strict-prototypes
-Werror=write-strings -Werror-implicit-function-declaration
-Werror=pointer-arith -Werror=declaration-after-statement -Werror=return-type
-Wreturn-type -Werror=uninitialized -Wuninitialized -Wimplicit-fallthrough
-Werror=strict-overflow -Wstrict-overflow=2 -Wformat=2 -Wno-format-y2k
-Wno-format-zero-length -Werror=format-security -Wformat-security
-Werror=format -Werror -Wno-error=deprecated-declarations
-Wno-error=tautological-compare -DSTATIC_samba_debug_MODULES=NULL
-DSTATIC_samba_debug_MODULES_PROTO='extern void
__samba_debug_dummy_module_proto(void)' -MD -Idefault/include/public
-I../include/public -Idefault/source4 -I../source4 -Idefault/lib -I../lib
-Idefault/source4/lib -I../source4/lib -Idefault/source4/include
-I../source4/include -Idefault/include -I../include -Idefault/lib/replace
-I../lib/replace -Idefault -I.. -I/usr/local/include -D_SAMBA_BUILD_=4
-DHAVE_CONFIG_H=1 -D_GNU_SOURCE=1 -D_XOPEN_SOURCE_EXTENDED=1
../lib/util/debug.c -c -o default/lib/util/debug_11.o
../lib/util/debug.c: In function ‘debug_parse_levels’:
../lib/util/debug.c:788:5: error: assuming pointer wraparound does not occur
when comparing P +- C1 with P +- C2 [-Werror=strict-overflow]   
 bool debug_parse_levels(const char *params_str)
  ^~
cc1: all warnings being treated as errors

[Bug tree-optimization/85697] At -Os nontrivial ctor does not use SSE to zero

[msharov at users dot sourceforge.net]

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

--- Comment #2 from Mike Sharov  ---
I previously filed bug #49127 about the non-SSE version of the same xor/mov
optimization. Perhaps both could be addressed in the same manner with a more
general capability of zeroing with a register when doing so is shorter.

[Bug c++/85873] New: [8 regression] GCC omits array constant in .rodata causing a segmentation fault.

[Kimon.Hoffmann at lawo dot com]

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

Bug ID: 85873
   Summary: [8 regression] GCC omits array constant in .rodata
causing a segmentation fault.
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Kimon.Hoffmann at lawo dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
 Build: x86_64-linux-gnu

Created attachment 44162
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44162=edit
Preprocessed reproducer

GCC 8.1.0 (Debian 8.1.0-3) omits array constant in .rodata when optimizations
are enabled causing a segmentation fault. Previous versions (7.3.0 used for
reference) included the array definition as expected.

Test.cpp:

#include 
#include 

constexpr std::initializer_list retArray() noexcept
{
return std::initializer_list{"Test 1", "Test 2", "Test
3"};
}

int main(int, char const* const*)
{
for (auto&& i : retArray())
{
std::puts(i);
}
return 0;
}

Compiled with:
gcc -std=c++17 -O1 -Wall -Wextra Test.cpp

Expected output:

Test 1
Test 2
Test 3

Actual output:

Segmenation fault.


Notes:
* The preprocessed output has no functional differences between 7.3.0 and
8.1.0, which leads me to believe that this issue is not caused by changes to
the C++ standard library.
* Using objdump -s shows the .rodata section to be basically empty on
8.1.0, while containing the three strings on 7.3.0.
* No error messages or warnings are emitted during compilation.
* Building with -fsanitize=undefined does not result in any runtime
messages prior to the segmentation fault.
* Turning optimizations off yields the expected result.
* Changing the C++ standard to C++11 or C++14 does not affect the result.

Environment details:
g++ -v -std=c++17 -O1 -Wall -Wextra -save-temps Test.cpp

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.1.0-3'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.1.0 (Debian 8.1.0-3) 
COLLECT_GCC_OPTIONS='-v' '-std=c++17' '-O1' '-Wall' '-Wextra' '-save-temps'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE Test.cpp -mtune=generic -march=x86-64 -std=c++17
-Wall -Wextra -O1 -fpch-preprocess -o Test.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/8"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/8
 /usr/include/x86_64-linux-gnu/c++/8
 /usr/include/c++/8/backward
 /usr/lib/gcc/x86_64-linux-gnu/8/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-std=c++17' '-O1' '-Wall' '-Wextra' '-save-temps'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -fpreprocessed Test.ii -quiet
-dumpbase Test.cpp -mtune=generic -march=x86-64 -auxbase Test -O1 -Wall -Wextra
-std=c++17 -version -o Test.s
GNU C++17 (Debian 8.1.0-3) version 8.1.0 (x86_64-linux-gnu)
compiled by GNU C version 8.1.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.19-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++17 (Debian 8.1.0-3) version 8.1.0 

[Bug tree-optimization/85826] [9 Regression] ICE in gimple-ssa-warn-restrict on a variable-length struct starting with r260280

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed.

[Bug tree-optimization/85826] [9 Regression] ICE in gimple-ssa-warn-restrict on a variable-length struct starting with r260280

[msebor at gcc dot gnu.org]

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

--- Comment #2 from Martin Sebor  ---
Author: msebor
Date: Tue May 22 15:22:16 2018
New Revision: 260537

URL: https://gcc.gnu.org/viewcvs?rev=260537=gcc=rev
Log:
PR tree-optimization/85826 - ICE in gimple-ssa-warn-restruct on
   a variable-length struct

gcc/ChangeLog:

PR tree-optimization/85826
* gimple-ssa-warn-restrict.c (builtin_memref::builtin_memref): Avoid
assuming that a DECL necesarily has a constant size.

gcc/testsuite/ChangeLog:

PR tree-optimization/85826
* gcc.dg/Wrestrict-17.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/Wrestrict-17.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/85826] [9 Regression] ICE in gimple-ssa-warn-restrict on a variable-length struct starting with r260280

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Fixed via r260537.

[Bug rtl-optimization/85852] [9 Regression] ICE: Segmentation fault (in contains_struct_check)

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Fixed by r260504.  Testcase name fixed in r260536.

[Bug tree-optimization/85853] [9 Regression] ICE in vect_is_simple_use, at tree-vect-stmts.c:10233 on ppc64

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Mine.

[Bug c++/61806] [C++11] Expression sfinae w/o access gives hard error in partial template specializations

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
http://lab.llvm.org:8011/builders/libcxx-libcxxabi-x86_64-linux-ubuntu-gcc-tot-latest-std/builds/310/steps/test.libcxx/logs/FAIL%3A%20libc%2B%2B%3A%3Adeduct.pass.cpp

[Bug fortran/85841] [F2018] reject deleted features

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to Christophe Lyon from comment #8)
> UNRESOLVED: gfortran.dg/vect/pr52580.f   -O   scan-tree-dump-times vect
> "LOOP VECTORIZED" 1

In addition to this one, I also see:

UNRESOLVED: gfortran.dg/graphite/block-2.f   -O   scan-tree-dump-times graphite
"number of SCoPs: 2" 1

This file was modified by Steve in r260480.

[Bug tree-optimization/85712] [8/9 Regression] ICE in all_phi_incrs_profitable_1 at gcc/gimple-ssa-strength-reduction.c:3479

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
There are six vulnerabilities like this in the SLSR code:

replace_mult_candidate (2)
replace_rhs_if_not_dup (1)
replace_one_candidate  (3)

I'll work on a fix.

[Bug c++/61806] [C++11] Expression sfinae w/o access gives hard error in partial template specializations

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2017-09-25 00:00:00 |2018-5-22

--- Comment #4 from Jonathan Wakely  ---
This is still present on trunk, and causing issues for libc++ when trying to
use void_t expressions in deduction guides.

[Bug libgcc/85869] libgcc fails to build in canadian cross: cet.h not found

[arnd at linaro dot org]

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

Arnd Bergmann  changed:

   What|Removed |Added

   Keywords|build   |
 Target|x86_64-*-*, i?86-*-*|
   Host|powerpc64le |
  Build|x86_64-*-*  |

--- Comment #2 from Arnd Bergmann  ---
Ah, found a bug in my scripts: I had built and installed a i386 cross compiler
from these sources, but passed the wrong PATH variable, so it picked up a
native compiler of the wrong version instead. This works fine now after fixing
my script, sorry about the false-positive report.

A related problem still seems to happen for the
build=x86_64/host=ppc64le/target=x86_64 cross compiler when building the 32-bit
libgcc: I have the correct x86_64-linux-gcc binary in the PATH here, and this
gets used for the 64-bit libgcc, but when building the 32-bit libgcc, it uses
'cc -m32' instead, which comes from /usr/bin/.

After manually removing the '/usr/bin/cc -> gcc' symlink, that appears to work
fine as well, but I don't see why that symlink causes this behavior.

[Bug c/85870] [6/7/8/9 Regression][LTO1] ICE in linemap_line_start, at libcpp/line-map.c:794

[sudi at gcc dot gnu.org]

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

sudi at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords|ice-on-invalid-code |ice-on-valid-code

--- Comment #2 from sudi at gcc dot gnu.org ---
Sorry that was my bad..its valid code

[Bug gcov-profile/85871] g++.dg/gcov/gcov-8.C random failures

[clyon at gcc dot gnu.org]

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

--- Comment #4 from Christophe Lyon  ---
I'll try to see if I can isolate that.

We run the tests on arm, aarch64, x86_32 and x86_64 all native targets.
We post the results to https://gcc.gnu.org/ml/gcc-testresults/ as "LINARO TCWG"

[Bug c++/85867] Subscript operator applied to an temporary array results in an lvalue

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
.

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

[Bug c++/79832] [C++14/17] result of subscripting non lvalue array should be xvalue

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||yaghmour.shafik at gmail dot 
com

--- Comment #3 from Jonathan Wakely  ---
*** Bug 85867 has been marked as a duplicate of this bug. ***

[Bug c/85870] [6/7/8/9 Regression][LTO1] ICE in linemap_line_start, at libcpp/line-map.c:794

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-reduction
 CC||marxin at gcc dot gnu.org
Version|lto |7.3.0
   Target Milestone|--- |6.5

--- Comment #1 from Richard Biener  ---
Confirmed.  Why's the code invalid?

[Bug c++/79832] [C++14/17] result of subscripting non lvalue array should be xvalue

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-22
 Ever confirmed|0   |1

[Bug c++/85866] [8/9 Regression] too few arguments to function when sfinae on calling pointer to member function

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Reduced:

  template
_Up
__declval(int);

  template
_Tp
__declval(long);

  template
auto declval() noexcept -> decltype(__declval<_Tp>(0));

template
using void_t = void;

template().*declval())()
)>* = nullptr>
void boom(){}

struct Foo {
void bar(){}
};

int main() {
boom();
}

[Bug c++/85866] [8/9 Regression] too few arguments to function when sfinae on calling pointer to member function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-22
 CC||jason at gcc dot gnu.org
  Known to work||7.3.0
 Ever confirmed|0   |1
  Known to fail||8.1.0, 9.0

--- Comment #2 from Jonathan Wakely  ---
Started with r258824

PR c++/78489 - wrong SFINAE behavior.

PR c++/84489
* pt.c (type_unification_real): Don't defer substitution failure.

[Bug gcov-profile/85871] g++.dg/gcov/gcov-8.C random failures

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
(In reply to Christophe Lyon from comment #2)
> Yes I had spotted this part of gcov.exp, but saw nothing in the logs.
> 
> As I put in the title, it happens randomly, and this is automated testing.
> 
> And it seems there is no way increasing verbosity will print helpful debug
> info in  this area.
> 
> I hoped someone more knowledgeable would have an idea of what could cause
> such an error :)
> 
> 
> It could be that the process was killed for some reason, but there is no
> such clue in the logs. Maybe HJ Lu has some info since I noticed similar
> errors in his reports.

Could you reproduce that with repeatedly executed:
$ make check RUNTESTFLAGS="gcov.exp=gcov-6.C"

or

$ make check -k -j8 RUNTESTFLAGS="gcov.exp"

If yes, then debugging should be much easier. What exactly target do you test.
Is it i686?

[Bug middle-end/85872] False positive for -Wmaybe-unitialized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-22
 Blocks||24639
 Ever confirmed|0   |1
  Known to fail||4.9.4, 6.4.0, 7.2.1, 8.1.0

--- Comment #1 from Richard Biener  ---
The dependence on TEST is beacause we limit the compile-time it takes to emit
those warnings.

The bug is already very old.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug gcov-profile/85871] g++.dg/gcov/gcov-8.C random failures

[clyon at gcc dot gnu.org]

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

--- Comment #2 from Christophe Lyon  ---
Yes I had spotted this part of gcov.exp, but saw nothing in the logs.

As I put in the title, it happens randomly, and this is automated testing.

And it seems there is no way increasing verbosity will print helpful debug info
in  this area.

I hoped someone more knowledgeable would have an idea of what could cause such
an error :)


It could be that the process was killed for some reason, but there is no such
clue in the logs. Maybe HJ Lu has some info since I noticed similar errors in
his reports.

[Bug c++/85847] [6/7/8/9 Regression] unexpected expression of kind template_id_expr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Started with r230081.  I'll take a look.

[Bug c++/85866] [8/9 Regression] too few arguments to function when sfinae on calling pointer to member function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Target Milestone|--- |8.2
Summary|[8 Regression] too few  |[8/9 Regression] too few
   |arguments to function when  |arguments to function when
   |sfinae on calling pointer   |sfinae on calling pointer
   |to member function  |to member function

[Bug c++/85864] [8/9 Regression] template argument string literal operator with default argument doesnt work in templates

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-22
   Target Milestone|--- |8.2
 Ever confirmed|0   |1

[Bug rtl-optimization/85180] Infinite loop in RTL DSE optimizer

[rguenth at gcc dot gnu.org]

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

--- Comment #21 from Richard Biener  ---
*** Bug 85862 has been marked as a duplicate of this bug. ***

[Bug rtl-optimization/85862] infinite loop in find_base_term()

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Richard Biener  ---
Duplicate then.

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

[Bug c/85872] New: False positive for -Wmaybe-unitialized

[jakub.leszczak at nokia dot com]

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

Bug ID: 85872
   Summary: False positive for -Wmaybe-unitialized
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub.leszczak at nokia dot com
  Target Milestone: ---

Created attachment 44161
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44161=edit
File contains informations about the bug and environent (uname, gcc --version,
*.i files etc.)

There is a false positive for maybe-unitialized when using -O1 (but not for
-O0).

Minimal case I got after stripping code:
```
int test1(int *t);

int test(int *t, int e)
{
int i, f = 0;

if (e != 0) {
for(i = 0; t[i] != e; i++);
} else {
f = 1;
}

int j;
if (test1()) return 1;
if (test1()) return 1;
if (test1()) return 1;
if (test1()) return 1;
if (test1()) return 1;

#if TEST
if (test1()) return 1;
#endif

if (!f) {
return t[i];
}

return 0;
}
```

doesn't compile with `$ gcc -Wall -Werror -O1 -DTEST=1 -c bug.c`.  But it
compiles when either I turn off optimizations or set TEST=0.  For some reason
adding one additional `if (test1()) return 1;` makes a difference.

Tested on arch linux, ubuntu 16.04 and gcc.godbolt.org, on multiple gcc
versions: 5.4.0, 7.3.1, 8.1.0, aarch64-linux-gnu-gcc6.4.1 and
arm-linux-gnueabihf-gcc4.7.3.

[Bug target/85860] [8/9 Regression] ICE: in lra_split_hard_reg_for, at lra-assigns.c:1810: unable to find a register to spill with -flive-range-shrinkage -mbmi2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ra
   Priority|P3  |P2
   Target Milestone|--- |8.2

[Bug tree-optimization/85859] [6/7/8/9 Regression] wrong code with -fno-isolate-erroneous-paths-dereference

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||rguenth at gcc dot gnu.org,
   ||vries at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
(In reply to Richard Biener from comment #1)
> Confirmed.  foo is discovered as 'const', it is nothrow anyways
> (-fno-exceptions)
> and thus overall it is considered not having side-effects (in particular not
> trap).  Quoting tree-ssa-ifcombine.c:
> 
> /* Verify if the basic block BB does not have side-effects.  Return
>true in this case, else false.  */
> 
> static bool
> bb_no_side_effects_p (basic_block bb)
> {
>   gimple_stmt_iterator gsi;
> 
>   for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next ())
> {
>   gimple *stmt = gsi_stmt (gsi);
> 
>   if (is_gimple_debug (stmt))
> continue;
> 
>   if (gimple_has_side_effects (stmt)
>   || gimple_uses_undefined_value_p (stmt)
>   || gimple_could_trap_p (stmt)
>   || gimple_vuse (stmt)
>   /* const calls don't match any of the above, yet they could
>  still have some side-effects - they could contain
>  gimple_could_trap_p statements, like floating point
>  exceptions or integer division by zero.  See PR70586.
>  FIXME: perhaps gimple_has_side_effects or gimple_could_trap_p
>  should handle this.  */
>   || is_gimple_call (stmt))
> 
> and it is ifcombine pulling the call out of conditional context.

^^^ err, tail merging.  -fno-tree-tail-merge fixes the bug.

+find_duplicates:  duplicate of 
+Removing basic block 4
...
-   [local count: 536870912]:
   _6 = foo (0);
   iftmp.2_10 = (long int) _6;
-  goto ; [100.00%]
-
-   [local count: 536870912]:
-  iftmp.2_11 = (long int) 
-

[Bug tree-optimization/85859] [6/7/8/9 Regression] wrong code with -fno-isolate-erroneous-paths-dereference

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-22
   Target Milestone|--- |6.5
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  foo is discovered as 'const', it is nothrow anyways
(-fno-exceptions)
and thus overall it is considered not having side-effects (in particular not
trap).  Quoting tree-ssa-ifcombine.c:

/* Verify if the basic block BB does not have side-effects.  Return
   true in this case, else false.  */

static bool
bb_no_side_effects_p (basic_block bb)
{
  gimple_stmt_iterator gsi;

  for (gsi = gsi_start_bb (bb); !gsi_end_p (gsi); gsi_next ())
{
  gimple *stmt = gsi_stmt (gsi);

  if (is_gimple_debug (stmt))
continue;

  if (gimple_has_side_effects (stmt)
  || gimple_uses_undefined_value_p (stmt)
  || gimple_could_trap_p (stmt)
  || gimple_vuse (stmt)
  /* const calls don't match any of the above, yet they could
 still have some side-effects - they could contain
 gimple_could_trap_p statements, like floating point
 exceptions or integer division by zero.  See PR70586.
 FIXME: perhaps gimple_has_side_effects or gimple_could_trap_p
 should handle this.  */
  || is_gimple_call (stmt))

and it is ifcombine pulling the call out of conditional context.

[Bug gcov-profile/85871] g++.dg/gcov/gcov-8.C random failures

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2018-05-22
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
So it only differs in git hashes that are in path, it maybe causes a
difference.
If you take a look at gcov.exp, 'gcov failed' is probably triggered here:

   355  verbose "Running $GCOV $testcase" 2
   356  set testcase [remote_download host $testcase]
   357  set result [remote_exec host $GCOV $gcov_args]
   358  if { [lindex $result 0] != 0 } {
   359  if { $xfailed } {
   360  setup_xfail "*-*-*"
   361  }
   362  fail "$testname gcov failed: [lindex $result 1]"
   363  clean-gcov $testcase
   364  return
   365  }

Can you please debug it why 'gcov' invocation fails?
Is it reproducible always or randomly?

[Bug other/85857] configure problem using local mpfr and gmp

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
So it looks like mpfr uses internal interfaces for DFP?  --with-gmp-build was
stronly discouraged back in time...

Also in-tree mpfr and system gmp is a combination that currently works (but
not with DFP then).

Please work with mpfr/gmp folks on how to address this (update to newer
tarballs?)

[Bug tree-optimization/82726] ICE in verify_ssa during GIMPLE pass: pcom

[amker at gcc dot gnu.org]

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

bin cheng  changed:

   What|Removed |Added

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

--- Comment #8 from bin cheng  ---
Fixed

[Bug fortran/85855] [7/8/9 Regression] (Maybe) uninitialized descriptor fields of an allocatable array component of a function result

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |NEW
   Target Milestone|--- |7.4
Summary|[7 Regression] (Maybe)  |[7/8/9 Regression] (Maybe)
   |uninitialized descriptor|uninitialized descriptor
   |fields of an allocatable|fields of an allocatable
   |array component of a|array component of a
   |function result |function result

--- Comment #3 from Richard Biener  ---
FE issue.  It emits

reduce (struct __class_test_Grid_t & restrict g)
{
  struct grid res;

  res.mask.data = 0B;
  {
...
D.3608 = (integer(kind=4)[0:] * restrict) g->_data->mask.data;
D.3609 = g->_data->mask.offset;
D.3610 = g->_data->mask.dim[0].lbound;
D.3611 = g->_data->mask.dim[0].ubound;
D.3612 = g->_data->mask.dim[1].lbound;
D.3613 = g->_data->mask.dim[1].ubound;
D.3614 = g->_data->mask.dim[2].lbound;
D.3615 = g->_data->mask.dim[2].ubound;
D.3616 = (integer(kind=4)[0:] * restrict) res.mask.data;
D.3617 = res.mask.offset;
D.3618 = res.mask.dim[0].lbound;
D.3619 = res.mask.dim[0].ubound;
D.3620 = res.mask.dim[1].lbound;
D.3621 = res.mask.dim[1].ubound;
D.3622 = res.mask.dim[2].lbound;
D.3623 = res.mask.dim[2].ubound;
D.3624 = D.3618 - D.3610;
D.3625 = D.3620 - D.3612;
D.3626 = D.3622 - D.3614;

thus loads res.mask.dim[] and computes things with it before initializing.
That also means on archs with NaT (IA64) it might even trap.

[Bug tree-optimization/70754] [6 Regression] ICE during predictive commoning

[amker at gcc dot gnu.org]

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

bin cheng  changed:

   What|Removed |Added

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

--- Comment #22 from bin cheng  ---
Consider this fixed, since GCC5 is not maintained.

[Bug target/81084] [8 Regression] powerpcspe port full of confusing configury / command-line options not related to SPE

[andrewjenner at gcc dot gnu.org]

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

--- Comment #58 from Andrew Jenner  ---
(In reply to John Paul Adrian Glaubitz from comment #57)
> Andrew, could you refresh your patch for the current trunk branch?
> 
> It doesn't fully apply for me.

Acknowledged. I will try to get to that later this week.

[Bug tree-optimization/85853] [9 Regression] ICE in vect_is_simple_use, at tree-vect-stmts.c:10233 on ppc64

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug c++/85858] -Weffc++ should not require copy ctor for const pointers

[msharov at users dot sourceforge.net]

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

--- Comment #12 from Mike Sharov  ---
(In reply to Jonathan Wakely from comment #10)
> It's simply not how C++ works.

Quite right. I already agreed with you here; we are arguing about whether it
/should/ work this way :)

> An object's lifetime is distinct from it's constness, and a pointer-to-const 
> doesn't imply anything about whether the pointed-to object is immutable.

Exactly! I can restate my gripe in these terms: C++ has no way of explicitly
marking the owner of the object or its lifetime. When f() creates object const
A a and passes it as const A* to g(), both f() and g() see the same const A
object, but f() is the owner and should be allowed to delete it, while g() has
only been granted read-only access and should not. If delete required a
non-const pointer, then f() would either keep a non-const pointer to indicate
that it owns a, or have to explicitly const_cast it to delete.

> You seem to be saying that a pointer-to-const implies
> an immortal object that will never be destroyed.

Not at all. Object lifetime is a separate subject, but const correctness should
help enforce it by restricting who gets to set it. Ideally, the object will
have exactly one owner (insert rant on the evils of shared_ptr), and that owner
will determine the lifetime of the object. If const prevented delete, the
compiler could help you catch violations of the one-owner rule that may
compromise defined object lifetime and cause undefined behavior in functions
that hold pointers to that object.

A function can only assume that the pointer it was given remains valid if the
object lifetime is explicitly known, and there is no explicit C++ way of making
it known. We can only define the lifetime in documentation. For example:

> Why should that be true for pointers to the heap
> but not pointers to the stack?

Because the stack frees all owned objects when the scope is exited and the heap
does not. The stack will call destructors to cleanup the objects, the heap will
not. Consequently the stack can be said to be the owner of local objects, but
the heap owns nothing because it destroys nothing.

[Bug c/85870] [6/7/8/9 Regression][LTO1] ICE in linemap_line_start, at libcpp/line-map.c:794

[vp at gcc dot gnu.org]

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

Vidya Praveen  changed:

   What|Removed |Added

   Keywords||lto
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-05-22
 CC||vp at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/85216] Performance issue with PHP on ppc64 systems

[wschmidt at gcc dot gnu.org]

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

--- Comment #18 from Bill Schmidt  ---
I asked around a bit.  On x86, user-user attacks are not mitigated by default. 
To enable user-user mitigation:

echo 2 > /sys/kernel/debug/x86/ibrs_enabled

My source tells me:

8<---

Red Hat explains the above setting as follows in
https://access.redhat.com/articles/3311301 -

"When IBRS is set to 2 (spectre_v2=ibrs_always), both userland and kernel runs
with indirect branch restricted speculation. This protects userspace from
hyperthreading/simultaneous multi-threading attacks as well, and is also the
default on certain old AMD processors (family 10h, 12h and 16h). This feature
addresses CVE-2017-5715, variant #2."

If a GCC compiler with support for "thunks" is available, one might also build
their applications, for example, PHP with the following flags added to mitigate
spectre variant #2-
-mindirect-branch=thunk-inline -mfunction-return=thunk-inline
-mindirect-branch-register

However, it is possible that to properly mitigate spectre variant#2 in Skylake
processors, setting ibrs_enabled to 2 AND using thunks may be necessary,
although I am not sure about this.

[Bug gcov-profile/85871] New: g++.dg/gcov/gcov-8.C random failures

[clyon at gcc dot gnu.org]

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

Bug ID: 85871
   Summary: g++.dg/gcov/gcov-8.C random failures
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hi,

It seems g++.dg/gcov/gcov-8.C is failing randomly as one can see by looking at
reports on https://gcc.gnu.org/ml/gcc-testresults/

I'm not sure why this doesn't produce regression reports on
https://gcc.gnu.org/ml/gcc-regression/ though.

My log has:
Executing on host:
/home/tcwg-buildslave/workspace/tcwg-buildfarm/tcwg-x86_32-build/_build/builds/i686-pc-linux-gnu/i686-pc-linux-gnu/gcc.git~master_rev_e4ddfbc4c1d49271c7c17e574c522a53f9152522-stage2/gcc/testsuite/g++/../../gcov
 -i -b gcov-8.C(timeout = 300)
spawn -ignore SIGHUP
/home/tcwg-buildslave/workspace/tcwg-buildfarm/tcwg-x86_32-build/_build/builds/i686-pc-linux-gnu/i686-pc-linux-gnu/gcc.git~master_rev_e4ddfbc4c1d49271c7c17e574c522a53f9152522-stage2/gcc/testsuite/g++/../../gcov
-i -b gcov-8.C
File
'/home/tcwg-buildslave/workspace/tcwg-buildfarm/tcwg-x86_32-build/snapshots/gcc.git~master_rev_e4ddfbc4c1d49271c7c17e574c522a53f9152522/gcc/testsuite/g++.dg/gcov/gcov-8.C'
Lines executed:94.12% of 17
Branches executed:100.00% of 2
Taken at least once:50.00% of 2
Calls executed:100.00% of 4
FAIL: g++.dg/gcov/gcov-8.C  -std=gnu++98  gcov failed: File
'/home/tcwg-buildslave/workspace/tcwg-buildfarm/tcwg-x86_32-build/snapshots/gcc.git~master_rev_e4ddfbc4c1d49271c7c17e574c522a53f9152522/gcc/testsuite/g++.dg/gcov/gcov-8.C'
Lines executed:94.12% of 17
Branches executed:100.00% of 2
Taken at least once:50.00% of 2
Calls executed:100.00% of 4



A working log has:
Executing on host:
/home/tcwg-buildslave/workspace/tcwg-buildfarm/tcwg-x86_32-build/_build/builds/i686-pc-linux-gnu/i686-pc-linux-gnu/gcc.git~master_rev_adcff7d7675a88e2a92e7c76c4cf1e13e0712f95-stage2/gcc/testsuite/g++5/../../gcov
 -i -b gcov-8.C(timeout = 300)
spawn -ignore SIGHUP
/home/tcwg-buildslave/workspace/tcwg-buildfarm/tcwg-x86_32-build/_build/builds/i686-pc-linux-gnu/i686-pc-linux-gnu/gcc.git~master_rev_adcff7d7675a88e2a92e7c76c4cf1e13e0712f95-stage2/gcc/testsuite/g++5/../../gcov
-i -b gcov-8.C
File
'/home/tcwg-buildslave/workspace/tcwg-buildfarm/tcwg-x86_32-build/snapshots/gcc.git~master_rev_adcff7d7675a88e2a92e7c76c4cf1e13e0712f95/gcc/testsuite/g++.dg/gcov/gcov-8.C'
Lines executed:94.12% of 17
Branches executed:100.00% of 2
Taken at least once:50.00% of 2
Calls executed:100.00% of 4
PASS: g++.dg/gcov/gcov-8.C  -std=gnu++98  gcov

which looks similar

[Bug rtl-optimization/85862] infinite loop in find_base_term()

[rsandifo at gcc dot gnu.org]

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

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Tue May 22 12:25:44 2018
New Revision: 260504

URL: https://gcc.gnu.org/viewcvs?rev=260504=gcc=rev
Log:
Handle a null lhs in expand_direct_optab_fn (PR85862)

This PR showed that the normal function for expanding directly-mapped
internal functions didn't handle the case in which the call was only
being kept for its side-effects.

2018-05-22  Richard Sandiford  

gcc/
PR middle-end/85862
* internal-fn.c (expand_direct_optab_fn): Cope with a null lhs.

gcc/testsuite/
PR middle-end/85862
* gcc.dg/torture/pr85862.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr85862.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/internal-fn.c
trunk/gcc/testsuite/ChangeLog