[Bug fortran/80484] Three syntax errors involving derived-type I/O

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle  ---
As an example of what I just said:

$ gfc pr80484.f03 
f951: internal compiler error: in gfc_match_use, at fortran/module.c:689

With no module defined. This is an unrelated bug I just stumbled on... with
your example the original post here.

[Bug fortran/80484] Three syntax errors involving derived-type I/O

[jvdelisle at gcc dot gnu.org]

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

--- Comment #2 from Jerry DeLisle  ---
(In reply to Walt Brainerd from comment #0)
> Windows 10, gcc 7.0.1 20170416
> 
> If the commented versions of the USE or WRITE statements
> are used, the program works fine.
> 
> The function B converts wage to a structure with one component.
> 
> I can provide all the supporting code if needed,
> but that doesn't seem relevant.
> 

Yes, please provide. I need complete 'valid' code to test debug. I will
eventually create a new test case for the testsuite. It is relevant because I
need to reproduce exact conditions. Yes I could contrive something but I might
miss something doing so.

[Bug c++/80488] New: Erroneous error "lambda-expression in template argument"

[eric.niebler at gmail dot com]

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

Bug ID: 80488
   Summary: Erroneous error "lambda-expression in template
argument"
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

Compile with -std=gnu++1z:

  template  using x = void;
  using Y = x<+[]{}>;

The above code creates a lambda and then applies unary operator +, forcing it
to decay to a function pointer. Since that's constexpr, it should be a valid
template argument.

clang-trunk accepts this code.

[Bug tree-optimization/80487] New: redundant memset/memcpy/strcpy calls not eliminated

[msebor at gcc dot gnu.org]

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

Bug ID: 80487
   Summary: redundant memset/memcpy/strcpy calls not eliminated
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Somewhat similar to bug 79716 but (IIUC) with a different root cause, the
redundant clearing of the array prior to the call to strncpy in the following
function is not eliminated as it could be.  (Strncpy is specified to append
NULs to fill the destination.)

$ cat t.c && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout t.c

void sink (void*);

void f (const char *s)
{
  char a[256] = "";   // redundant initialization

  __builtin_strncpy (a, s, sizeof a);

  sink (a);
}

void g (const char *s)
{
  char a[256];

  __builtin_memset (a, 0, sizeof a);   // redundant memset
  __builtin_strncpy (a, s, sizeof a);

  sink (a);
}

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

f (const char * s)
{
  char a[256];

   [100.00%]:
  a = "";
  __builtin_strncpy (, s_3(D), 256);
  sink ();
  a ={v} {CLOBBER};
  return;

}



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

g (const char * s)
{
  char a[256];

   [100.00%]:
  __builtin_memset (, 0, 256);
  __builtin_strncpy (, s_3(D), 256);
  sink ();
  a ={v} {CLOBBER};
  return;

}

[Bug fortran/80484] Three syntax errors involving derived-type I/O

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-21
 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jerry DeLisle  ---
I will have a look at these.

[Bug fortran/80361] [5/6/7/8 Regression] [OOP] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #27 from janus at gcc dot gnu.org ---
Fixed for the upcoming releases 7.0, 6.4 and 5.5. Closing.

[Bug fortran/80361] [5/6/7/8 Regression] [OOP] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[janus at gcc dot gnu.org]

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

--- Comment #26 from janus at gcc dot gnu.org ---
Author: janus
Date: Fri Apr 21 21:37:16 2017
New Revision: 247071

URL: https://gcc.gnu.org/viewcvs?rev=247071=gcc=rev
Log:
2017-04-21  Janus Weil  

Backport from trunk
PR fortran/80361
* class.c (generate_finalization_wrapper): Give the finalization
wrapper
the recursive attribute.

2017-04-21  Janus Weil  

Backport from trunk
PR fortran/80361
* gfortran.dg/class_62.f90: New test case.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/class_62.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/class.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/77671] missing -Wformat-overflow warning on sprintf overflow with "%s"

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
Patch posted for review:
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00968.html

[Bug target/80482] [7 Regression] vec_mul produces compilation error if 1 of its parms is const or volatile

[seurer at gcc dot gnu.org]

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

--- Comment #1 from seurer at gcc dot gnu.org ---
I see the problem.  The compiler is enforcing "the parameter types must match"
too tightly.  It should be checking the unqualified types (sans const/volatile)
instead of the types directly.

[Bug testsuite/80221] Contrib script to rewrite testcase from absolute to relative line numbers

[vries at gcc dot gnu.org]

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

--- Comment #16 from Tom de Vries  ---
Created attachment 41243
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41243=edit
tentative patch implementing dg-save-linenr

[Bug bootstrap/80486] spurious -Walloc-size-larger-than and -Wstringop-overflow in dominance.c during profiledbootstrap

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #1 from Martin Sebor  ---
Configured with --disable-werror the warnings don't break boootstrap but they
suggest a bug or limitation in GCC (especially since replacing the new
expression with the equivalent libiberty macros eliminates the warnings).

[Bug fortran/80361] [5/6/7/8 Regression] [OOP] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[janus at gcc dot gnu.org]

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

--- Comment #25 from janus at gcc dot gnu.org ---
Author: janus
Date: Fri Apr 21 21:11:22 2017
New Revision: 247070

URL: https://gcc.gnu.org/viewcvs?rev=247070=gcc=rev
Log:
2017-04-21  Janus Weil  

Backport from trunk
PR fortran/80361
* class.c (generate_finalization_wrapper): Give the finalization
wrapper
the recursive attribute.

2017-04-21  Janus Weil  

Backport from trunk
PR fortran/80361
* gfortran.dg/class_62.f90: New test case.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/class_62.f90
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/class.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug bootstrap/80486] New: spurious -Walloc-size-larger-than and -Wstringop-overflow in dominance.c during profiledbootstrap

[msebor at gcc dot gnu.org]

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

Bug ID: 80486
   Summary: spurious -Walloc-size-larger-than and
-Wstringop-overflow in dominance.c during
profiledbootstrap
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

A profiledbootstrap on powerpc64le and x86_64 shows a bunch of
-Walloc-size-larger-than and -Wstringop-overflow warnings that don't show up
otherwise.  They also don't show when the C++ new expression the former
warnings point is replaced with the libiberty XCNEWVEC and XNEWVEC macros.

/src/gcc/trunk/gcc/dominance.c:303:0: warning: argument 1 value
‘18446744073709551615’ exceeds maximum object size 9223372036854775807
[-Walloc-size-larger-than=]
   edge_iterator *stack = new edge_iterator[m_n_basic_blocks + 1];

/src/gcc/trunk/gcc/dominance.c: In member function ‘calc_dfs_tree’:
/src/gcc/trunk/libstdc++-v3/libsupc++/new:122:7: note: in a call to allocation
function ‘operator new []’ declared here
 void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
   ^
In function ‘new_zero_array’,
inlined from ‘dom_init’ at /src/gcc/trunk/gcc/dominance.c:164:0,
inlined from
‘_ZN12_GLOBAL__N_18dom_infoC2EP8function13cdi_direction.isra.8’ at
/src/gcc/trunk/gcc/dominance.c:194:0,
inlined from ‘verify_dominators’ at /src/gcc/trunk/gcc/dominance.c:1158:0:
/src/gcc/trunk/gcc/dominance.c:153:0: warning: argument 1 value
‘18446744073709551615’ exceeds maximum object size 9223372036854775807
[-Walloc-size-larger-than=]
   T *result = new T[num];

/src/gcc/trunk/gcc/dominance.c: In function ‘verify_dominators’:
/src/gcc/trunk/libstdc++-v3/libsupc++/new:122:7: note: in a call to allocation
function ‘operator new []’ declared here
 void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
   ^
In function ‘new_zero_array’,
inlined from ‘dom_init’ at /src/gcc/trunk/gcc/dominance.c:164:0,
inlined from
‘_ZN12_GLOBAL__N_18dom_infoC2EP8function13cdi_direction.isra.8’ at
/src/gcc/trunk/gcc/dominance.c:194:0,
inlined from ‘verify_dominators’ at /src/gcc/trunk/gcc/dominance.c:1158:0:
/src/gcc/trunk/gcc/dominance.c:154:0: warning: ‘memset’: specified size between
18446744065119617024 and 18446744073709551612 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]
   memset (result, 0, sizeof (T) * num);

In function ‘new_zero_array’,
inlined from ‘dom_init’ at /src/gcc/trunk/gcc/dominance.c:165:0,
inlined from
‘_ZN12_GLOBAL__N_18dom_infoC2EP8function13cdi_direction.isra.8’ at
/src/gcc/trunk/gcc/dominance.c:194:0,
inlined from ‘verify_dominators’ at /src/gcc/trunk/gcc/dominance.c:1158:0:
/src/gcc/trunk/gcc/dominance.c:153:0: warning: argument 1 value
‘18446744073709551615’ exceeds maximum object size 9223372036854775807
[-Walloc-size-larger-than=]
   T *result = new T[num];

/src/gcc/trunk/gcc/dominance.c: In function ‘verify_dominators’:
/src/gcc/trunk/libstdc++-v3/libsupc++/new:122:7: note: in a call to allocation
function ‘operator new []’ declared here
 void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
   ^
In function ‘new_zero_array’,
inlined from ‘dom_init’ at /src/gcc/trunk/gcc/dominance.c:165:0,
inlined from
‘_ZN12_GLOBAL__N_18dom_infoC2EP8function13cdi_direction.isra.8’ at
/src/gcc/trunk/gcc/dominance.c:194:0,
inlined from ‘verify_dominators’ at /src/gcc/trunk/gcc/dominance.c:1158:0:
/src/gcc/trunk/gcc/dominance.c:154:0: warning: ‘memset’: specified size between
18446744065119617024 and 18446744073709551612 exceeds maximum object size
9223372036854775807 [-Wstringop-overflow=]
   memset (result, 0, sizeof (T) * num);

In member function ‘dom_init’,
inlined from
‘_ZN12_GLOBAL__N_18dom_infoC2EP8function13cdi_direction.isra.8’ at
/src/gcc/trunk/gcc/dominance.c:194:0,
inlined from ‘verify_dominators’ at /src/gcc/trunk/gcc/dominance.c:1158:0:
/src/gcc/trunk/gcc/dominance.c:167:0: warning: argument 1 value
‘18446744073709551615’ exceeds maximum object size 9223372036854775807
[-Walloc-size-larger-than=]
   m_path_min = new TBB[num];

/src/gcc/trunk/gcc/dominance.c: In function ‘verify_dominators’:
/src/gcc/trunk/libstdc++-v3/libsupc++/new:122:7: note: in a call to allocation
function ‘operator new []’ declared here
 void* operator new[](std::size_t) _GLIBCXX_THROW (std::bad_alloc)
   ^
In member function ‘dom_init’,
inlined from
‘_ZN12_GLOBAL__N_18dom_infoC2EP8function13cdi_direction.isra.8’ at
/src/gcc/trunk/gcc/dominance.c:194:0,
inlined from ‘verify_dominators’ at /src/gcc/trunk/gcc/dominance.c:1158:0:
/src/gcc/trunk/gcc/dominance.c:168:0: warning: argument 1 value
‘18446744073709551615’ exceeds maximum object size 9223372036854775807
[-Walloc-size-larger-than=]
   m_key = new TBB[num];

[Bug fortran/80392] [5/6/7/8 Regression] [OOP] ICE with allocatable polymorphic function result in a procedure pointer component

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
Author: janus
Date: Fri Apr 21 20:47:12 2017
New Revision: 247069

URL: https://gcc.gnu.org/viewcvs?rev=247069=gcc=rev
Log:
2017-04-21  Janus Weil  

PR fortran/80392
* trans-types.c (gfc_get_derived_type): Prevent an infinite loop when
building a derived type that includes a procedure pointer component
with a polymorphic result.

2017-04-21  Janus Weil  

PR fortran/80392
* gfortran.dg/proc_ptr_comp_49.f90: New test case.

Added:
trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_49.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-types.c
trunk/gcc/testsuite/ChangeLog

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

[TonyELewis at hotmail dot com]

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

Bug ID: 80485
   Summary: rejects-valid: constexpr static_cast of
pointer-to-member-function to bool
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: TonyELewis at hotmail dot com
  Target Milestone: ---

GCC rejects the following code (partly adapted from Boost's tribool), which I
think is valid:


struct dummy {
  void nonnull() {};
};

typedef void (dummy::*safe_bool)();

constexpr safe_bool a = ::nonnull;

static_assert( static_cast( a ), "" );

int main () { return 0; }


I'm compiling with -std=c++14 and I'm seeing these errors:


:9:1: error: non-constant condition for static assertion
 static_assert( static_cast( a ), "" );
 ^
:9:16: error: '(dummy::nonnull != 0)' is not a constant expression
 static_assert( static_cast( a ), "" );
^~
Compiler exited with result code 1


This code is accepted by Clang.

This looks related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71896 but
that has status "RESOLVED FIXED" but I'm seeing this on "GCC 7 (snapshot)" on
godbolt.org (see https://godbolt.org/g/JnrZss ) as well as on my GCC 6.2.0.

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[tulipawn at gmail dot com]

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

--- Comment #18 from PeteVine  ---
> Well that sounds like the same issue.

> Note -fprofile-generate simple inserts counters in the generated code. In 
> fact the generated code is practically identical between Cortex-A5 and 
> Cortex-A7.

As long as the gcda file is not present, -fprofile-use yields an equally good
binary (obviously!), so clearly it's about the profile data somehow. If you
have any ideas or debugging suggestions, go ahead, I'll gladly test them.

[Bug sanitizer/80349] [6 Regression] UBSAN: compile time crash with "type mismatch in binary expression" message

[babokin at gmail dot com]

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

--- Comment #7 from Dmitry Babokin  ---
One more. GCC r247062.

> cat f.cpp
unsigned long int ll;
int foo() {
  return (2036854775807 >> ll & char(207648476159223) | 502810590243120797UL)
<< 0;
}

> g++ -fsanitize=undefined -O0 -c f.cpp
f.cpp: In function ‘int foo()’:
f.cpp:2:5: error: type mismatch in binary expression
 int foo() {
 ^~~
long unsigned int

long int

long unsigned int

D.2746 = _2 | 502810590243120797;
f.cpp:2:5: internal compiler error: verify_gimple failed

[Bug fortran/80484] New: Three syntax errors involving derived-type I/O

[walt.brainerd at gmail dot com]

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

Bug ID: 80484
   Summary: Three syntax errors involving derived-type I/O
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: walt.brainerd at gmail dot com
  Target Milestone: ---

Windows 10, gcc 7.0.1 20170416

If the commented versions of the USE or WRITE statements
are used, the program works fine.

The function B converts wage to a structure with one component.

I can provide all the supporting code if needed,
but that doesn't seem relevant.

program test_b_format

   use b_format_mod, only: B, write (formatted)
!   use b_format_mod
   implicit none

   real :: wage = 15.10
   integer :: ios
   character(len=99) :: iom = "OK"

!   write (unit=*, fmt="(DT'$$$Z.##')", iostat=ios, iomsg=iom) B(wage)
   write (unit=*, fmt="(2DT'$$$Z.##')", iostat=ios, iomsg=iom) B(wage)
   write (unit=*, fmt="(DT'$$$Z.##'/)", iostat=ios, iomsg=iom) B(wage)
   print *, trim(iom)

end program test_b_format

test_b_format.f90:3:47:

use b_format_mod, only: B, write (formatted)
   1
Error: Module nature in USE statement at (1) shall be either INTRINSIC or
NON_INTRINSIC
test_b_format.f90:12:36:

write (unit=*, fmt="(2DT'$$$Z.##')", iostat=ios, iomsg=iom) B(wage)
1
Error: Unexpected element ''' in format string at (1)
test_b_format.f90:13:35:

write (unit=*, fmt="(DT'$$$Z.##'/)", iostat=ios, iomsg=iom) B(wage)
   1
Error: Unexpected element '/' in format string at (1)

[Bug c++/80179] [6/7/8 Regression] ICE initializing a static local object with flexible array member in verify_ctor_sanity, at cp/constexpr.c:2641

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Apr 21 19:26:54 2017
New Revision: 247067

URL: https://gcc.gnu.org/viewcvs?rev=247067=gcc=rev
Log:
PR c++/80179 - ICE with initialized flexible array member.

* constexpr.c (verify_ctor_sanity): Handle flexible array members.

Added:
trunk/gcc/testsuite/g++.dg/ext/flexary24.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug target/80479] [7/8 Regression] strcmp() produces valgrind errors on ppc64le

[acsawdey at gcc dot gnu.org]

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

--- Comment #10 from acsawdey at gcc dot gnu.org ---
OK, so I'm the culprit who added the strncmp/strcmp inline expansion.

If both strings have alignment > 8 we cannot inadvertently cross a page
boundary doing 8B loads. For any argument that has smaller alignment, it emits
a runtime check to see if the inline code would cross a 4k boundary. If so, the
library function call is used instead of the inline code. The testcase
gcc.dg/strncmp-2.c tests that we don't step over this by allocating 2 pages and
using mprotect PROT_NONE on the second, then trying to provoke things by
putting strings right up to the boundary. The code generation for
strncmp/strcmp is done by the same code in rs6000.c so testing strncmp for this
mostly also tests whether strcmp has any issues.

The generated comparison code, while it does use 8B loads, also makes use of
cmpb to make sure that data beyond the 0 byte is not significant in the result.

Startup: load two doublewords, are they equal?

ldbrx 9,28,10
ldbrx 10,30,10
subf. 3,10,9
beq 0,.L23

If they are, go to this piece that looks to see if there was a zero byte:

.L23:
cmpb 10,9,3
cmpdi 7,10,0
beq 7,.L22

If we don't branch, the strings are equal, result of zero is in r3 and we are
done.

If we didn't branch to .L23 above, we fall through to this piece that computes
the final result by finding the correct differing byte and subtracting:

.L11:
cmpb 3,9,10
cmpb 8,9,26
addi 31,31,1
orc 3,8,3
cntlzd 3,3
addi 3,3,8
rldcl 9,9,3,56
rldcl 3,10,3,56
subf 3,3,9
extsw 9,3

If we did go to .L22 then we have a repeating sequence like this to load and
compare 8B at a time:

.L22:
addi 9,8,8
addi 10,4,8
ldbrx 9,0,9
ldbrx 10,0,10
subf. 3,10,9
bne 0,.L11
cmpb 10,9,3
cmpdi 7,10,0
bne 7,.L10

Here we either go to the L11 piece to extract the differing bytes and subtract,
or we found a zero byte and strings are equal (r3=0) and bail out to L10.

At the end of our 64 bytes of inline comparison we bail out to strcmp:

addi 4,4,64
addi 3,8,64
bl strcmp

So, yes we do read 8B at a time, but the code makes use of cmpb so that the
bytes following the zero byte are never significant to the comparison.

On the other hand I've already had to fix this a couple times so it is
certainly possible that errors remain -- please do let me know if you see
something.

[Bug libstdc++/80316] std::promise treats no shared state as undefined

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Author: redi
Date: Fri Apr 21 14:49:19 2017
New Revision: 247064

URL: https://gcc.gnu.org/viewcvs?rev=247064=gcc=rev
Log:
PR libstdc++/80316 make promise::set_value throw no_state error

PR libstdc++/80316
* include/std/future (_State_baseV2::_Setter::operator()): Remove
_S_check calls that are done after the pointer to the shared state is
already dereferenced.
(_State_baseV2::_Setter<_Res, void>): Define specialization for void
as partial specialization so it can be defined within the definition
of _State_baseV2.
(_State_baseV2::__setter): Call _S_check.
(_State_baseV2::__setter(promise*)): Add overload for use by
promise::set_value and promise::set_value_at_thread_exit.
(promise, promise, promise): Make _State a friend.
(_State_baseV2::_Setter): Remove explicit specialization.
(promise::set_value, promise::set_value_at_thread_exit):
Use new __setter overload.
* testsuite/30_threads/promise/members/at_thread_exit2.cc: New test.
* testsuite/30_threads/promise/members/set_exception.cc: Test
promise and promise specializations.
* testsuite/30_threads/promise/members/set_exception2.cc: Likewise.
Test for no_state error condition.
* testsuite/30_threads/promise/members/set_value2.cc: Likewise.

Added:
trunk/libstdc++-v3/testsuite/30_threads/promise/members/at_thread_exit2.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/future
trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_exception.cc
trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_exception2.cc
trunk/libstdc++-v3/testsuite/30_threads/promise/members/set_value2.cc

[Bug target/77728] [5/6/7/8 Regression] Miscompilation multiple vector iteration on ARM

[ramana at gcc dot gnu.org]

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

--- Comment #22 from Ramana Radhakrishnan  ---
(In reply to Jakub Jelinek from comment #20)
> BTW, the wording e.g. i386 backend has is:
>   inform (input_location,
>   "the ABI of passing structure with complex float"
>   " member has changed in GCC 4.4");
> In this arm/aarch64 case, the wording can't be as specific, because it isn't
> all arguments of this type, but only some arguments of certain type (at some
> positions; for some types like those that have more aligned static data
> members it is all such positioned arguments, for others, e.g. the templates
> where the alignment used to depend on instantiation vs. non-instantiation
> something earlier, only some), but you should consider using inform rather
> than warning for consistency, and you should mention the GCC version where
> it has changed and maybe also print the type in the diagnostic, so that user
> at least knows what type it is that is problematic (but as it is not
> something as simple as in the i386 case, there should not be a single inform
> per TU, but about each case this is encountered).
> 
> Richard said we should defer RC1 till this is done, do you think you can
> have a patch for both architectures written today, tested over the weekend,
> so that we could do RC1 on Monday or Tuesday at latest?

I'll see what I can do but it's going to be tough to finish that by today.

> Is there an agreement in ARM that what the patch does (for aarch64, and
> similar one for arm) is what the AAPCS says?

 I don't see agreement being reached until next week. Sorry about the delay but
it's just bad timing unfortunately.

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[wilco at gcc dot gnu.org]

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

--- Comment #17 from wilco at gcc dot gnu.org ---
(In reply to PeteVine from comment #16)
> Also, I'd like to repeat the fact using -mcpu=cortex-a7 fixes the issue (no
> library calls present). 

Cortex-A7 has hardware division so it doesn't emit library calls.

> Incidentally, having run that A7 profiled binary on a Cortex-A53, I'm seeing
> a 10% hit compared to a vanilla A7 binary. Hopefully that's just an artifact
> of profiling a different CPU architecture.

Well that sounds like the same issue.

Note -fprofile-generate simple inserts counters in the generated code. In fact
the generated code is practically identical between Cortex-A5 and Cortex-A7.

[Bug c++/80480] The compiler gets killed by an internal error when compiling ZNC

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

[Bug c++/80480] The compiler gets killed by an internal error when compiling ZNC

[abel at abelromero dot com]

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

Abel Romero  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Abel Romero  ---
I rebooted and it appears.

Sorry. I didn't know that the kernel log gets overflowed.

# dmesg | grep -i oom
[   33.073516] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=-500
[   33.073688]  [] oom_kill_process+0x202/0x3c0
[   33.074034] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name
[  240.201283] cc1plus invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=0
[  240.201490]  [] oom_kill_process+0x202/0x3c0
[  240.201684] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[tulipawn at gmail dot com]

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

--- Comment #16 from PeteVine  ---
Also, I'd like to repeat the fact using -mcpu=cortex-a7 fixes the issue (no
library calls present). 

Incidentally, having run that A7 profiled binary on a Cortex-A53, I'm seeing a
10% hit compared to a vanilla A7 binary. Hopefully that's just an artifact of
profiling a different CPU architecture.

[Bug fortran/79430] [7/8 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #65 from Jürgen Reuter  ---
(In reply to Thomas Koenig from comment #64)
> (In reply to Jürgen Reuter from comment #63)
> > (In reply to Thomas Koenig from comment #62)
> 
> > > I am currently at a loss how to proceed.
> > 
> > Darn Did you apply the patch from PR79344?
> 
> Yes.
> 

> +  IDENTIFIER= u
> *
> *
> *** ERROR: This PDG-array variable is undefined at this point
> *

There is obviously something wrong.

> Oh well... maybe I will bisect that one first, to find out what
> went wrong there, and then another bisection to find out which patch
> fixed that, and then

There were 4 regressions ca. 12/2016 that I can remember that affected our
code: 1) PR79229 which started in r241439 but affected only -fcheck=mem, fixed
in r245581
2) PR79230, started with r243480, affected many tests generally, fixed in
r245191
3) PR79344, started with r242875. affected many things, fixed in r245194.
4) this ugly one here. 
There is another one (PR80361), which is older, and affects only
-fcheck=recursive. 
From what I can see these are all.

[Bug target/80482] New: [7 Regression] vec_mul produces compilation error if 1 of its parms is const or volatile

[seurer at gcc dot gnu.org]

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

Bug ID: 80482
   Summary: [7 Regression] vec_mul produces compilation error if 1
of its parms is const or volatile
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

If one (just one) of its parameters is const, volatile, or const volatile
vec_mul produces a compilation error.  This occurs for gcc 7 but not 5 nor 6.

For example:

#include 

void P() {

  const volatile vector float cvva = vec_splats(0.00187682f);
  volatile vector float vva = vec_splats(0.00187682f);
  const vector float cva = vec_splats(0.00187682f);
  vector float va = vec_splats(0.00187682f);
  vector float dx = {1.0f, 2.0f, 3.0f, 4.0f};

  vector float X1m0 = vec_mul(va, va);
  vector float X2m0 = vec_mul(va, dx);
  vector float X3m0 = vec_mul(dx, va);

  vector float X1m1 = vec_mul(cva, cva);
  vector float X2m1 = vec_mul(cva, dx);
  vector float X3m1 = vec_mul(dx, cva);

  vector float Y1m2 = vec_mul(vva, vva);
  vector float Y2m2 = vec_mul(vva, dx);
  vector float Y3m2 = vec_mul(dx, vva);

  vector float X1m3 = vec_mul(cvva, cvva);
  vector float X2m3 = vec_mul(cvva, dx);
  vector float X3m3 = vec_mul(dx, cvva);
}

bii.c:16:3: error: invalid parameter combination for AltiVec intrinsic
__builtin_vec_mul
   vector float X2m1 = vec_mul(cva, dx);
   ^~
bii.c:17:3: error: invalid parameter combination for AltiVec intrinsic
__builtin_vec_mul
   vector float X3m1 = vec_mul(dx, cva);
   ^~
bii.c:20:3: error: invalid parameter combination for AltiVec intrinsic
__builtin_vec_mul
   vector float Y2m2 = vec_mul(vva, dx);
   ^~
bii.c:21:3: error: invalid parameter combination for AltiVec intrinsic
__builtin_vec_mul
   vector float Y3m2 = vec_mul(dx, vva);
   ^~
bii.c:24:3: error: invalid parameter combination for AltiVec intrinsic
__builtin_vec_mul
   vector float X2m3 = vec_mul(cvva, dx);
   ^~
bii.c:25:3: error: invalid parameter combination for AltiVec intrinsic
__builtin_vec_mul
   vector float X3m3 = vec_mul(dx, cvva);
   ^~

I tried a few of the other vec_XYZ built-ins and they do not produce the same
error (though I did not test them all).

Note that I am investigating this further.

[Bug fortran/79430] [7/8 Regression] action of statement incorrectly optimised away

[tkoenig at gcc dot gnu.org]

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

--- Comment #64 from Thomas Koenig  ---
(In reply to Jürgen Reuter from comment #63)
> (In reply to Thomas Koenig from comment #62)

> > I am currently at a loss how to proceed.
> 
> Darn Did you apply the patch from PR79344?

Yes.

What I get if I do


> `make check TESTS=mlm_matching_isr.run`.

==
   WHIZARD 2.4.1: tests/functional_tests/test-suite.log
==

# TOTAL: 1
# PASS:  0
# SKIP:  0
# XFAIL: 0
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

is

FAIL: mlm_matching_isr.run
==

Running script ./mlm_matching_isr.run
| Writing log to 'mlm_matching_isr.log'
| (Logging turned off.)
| Preloaded model: SM
| Process library 'mlm_matching_isr_lib': initialized
| Preloaded library: mlm_matching_isr_lib
| Reading commands from file
'../../share/tests/functional_tests/mlm_matching_isr.sin'
| Switching to model 'SM', scheme 'default'
?logging => true
?openmp_logging = false
?vis_history = false
?integration_timer = false
?pacify = true
+  IDENTIFIER= u
**
*** ERROR: This PDG-array variable is undefined at this point
**
| (WHIZARD run continues)
+  IDENTIFIER= d
**
*** ERROR: This PDG-array variable is undefined at this point
**
| (WHIZARD run continues)
[user variable] quark = PDG()
+  IDENTIFIER= U
**
*** ERROR: This PDG-array variable is undefined at this point
**
| (WHIZARD run continues)
+  IDENTIFIER= D

This occurred between 242780 (OK) and 242981 (not OK).

Oh well... maybe I will bisect that one first, to find out what
went wrong there, and then another bisection to find out which patch
fixed that, and then

[Bug c++/80480] The compiler gets killed by an internal error when compiling ZNC

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

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

--- Comment #5 from Andreas Schwab  ---
(In reply to Abel Romero from comment #3)
> The OOM killer doesn't show any killing to process g++ .

That just means that the kernel log overflowed.  Given the multitude of OOM
messages your system is definitely far from having enough memory.

[Bug target/80479] [7/8 Regression] strcmp() produces valgrind errors on ppc64le

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #9 from Alan Modra  ---
The following doesn't fail, but the strcmp optimization doesn't trigger
either..

#include 
#include 
#include 

int
main ()
{
#if 0
  char str1[15];
  char str2[15];
#else
  const size_t len = 65536;
  char *buf1, *buf2, *str1, *str2;

  buf1 = mmap (NULL, 2 * len, PROT_READ | PROT_WRITE,
   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
  if (buf1 == MAP_FAILED)
{
  perror ("mmap failed");
  return 0;
}
  if (munmap (buf1 + len, len) < 0)
{
  perror ("munmap failed");
  return 0;
}

  buf2 = mmap (NULL, 2 * len, PROT_READ | PROT_WRITE,
   MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
  if (buf2 == MAP_FAILED)
{
  perror ("mmap failed");
  return 0;
}
  if (munmap (buf2 + len, len) < 0)
{
  perror ("munmap failed");
  return 0;
}
  str1 = buf1 + len - 7;
  str2 = buf2 + len - 7;
#endif
  strcpy (str1, "abcdef");
  strcpy (str2, "ABCDEF");
  return strcmp (str1, str2);
}

For the #if 1 case, valgrind is complaining about the compare of two eight byte
words read from the stack, which indeed do have one uninitialized byte past the
string terminating zero.  I don't believe it matters.  (The generated asm looks
OK to me, but that might be because my brain has shut down for the night.)

[Bug rtl-optimization/78116] [7/8 regression] Performance drop after r241173 on avx512 target

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #19 from amker at gcc dot gnu.org ---
(In reply to Andrew Senkevich from comment #18)
> Created pr80481.

Thanks very much, consider this one fixed then.

[Bug fortran/80477] Polymorphic functions (thus operators) generates memory leaks

[stefano.zaghi at cnr dot it]

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

--- Comment #2 from Stefano Zaghi  ---
A very kind and great Fortraner (Chris MacMackin) has just let me know that a
very similar (or really the same) bug has been already reported (60913) here

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

Probably my test is slightly more simple.

I read that the other bug report is dated 2014: can I conclude that such a bug
will need a long time to be fixed? 

Please, consider that this is not a "polemic" question: I consider all of you
my superheros! However, this bug really stops me to use OOP thus I have to
decide about my future work: without GNU I have no other compilers, thus if I
will decide to invest more on OOP I have probably to left Fortran, probably for
Julia...

My best regards.

[Bug c++/80480] The compiler gets killed by an internal error when compiling ZNC

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-04-21
 Ever confirmed|0   |1

--- Comment #4 from Markus Trippelsdorf  ---
If you want to report a memory hog, the please attach the preprocessed file in
question. See: https://gcc.gnu.org/bugs/

[Bug tree-optimization/79547] duplicate strlen calls with same argument not folded

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Fri Apr 21 12:47:02 2017
New Revision: 247062

URL: https://gcc.gnu.org/viewcvs?rev=247062=gcc=rev
Log:
2017-04-21  Richard Biener  

PR tree-optimization/79547
* tree-ssa-structalias.c (find_func_aliases_for_builtin_call):
Handle strlen, strcmp, strncmp, strcasecmp, strncasecmp, memcmp,
bcmp, strspn, strcspn, __builtin_object_size and __builtin_constant_p
without any constraints.

* gcc.dg/tree-ssa/strlen-2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/strlen-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug tree-optimization/79547] duplicate strlen calls with same argument not folded

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Fri Apr 21 12:47:02 2017
New Revision: 247062

URL: https://gcc.gnu.org/viewcvs?rev=247062=gcc=rev
Log:
2017-04-21  Richard Biener  

PR tree-optimization/79547
* tree-ssa-structalias.c (find_func_aliases_for_builtin_call):
Handle strlen, strcmp, strncmp, strcasecmp, strncasecmp, memcmp,
bcmp, strspn, strcspn, __builtin_object_size and __builtin_constant_p
without any constraints.

* gcc.dg/tree-ssa/strlen-2.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/strlen-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-structalias.c

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[tulipawn at gmail dot com]

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

--- Comment #15 from PeteVine  ---
I don't have a cross-compiler built/installed.

If you're positive the bug doesn't reproduce on your end (targeting generic or
A5 codegen), then maybe it's about some interaction between gcc instrumentation
and the slightly dated system libraries.  

I think my little A5->A53 experiment shows once the instrumented binary is
built, it doesn't matter how the profile data is gathered.

[Bug c++/80480] The compiler gets killed by an internal error when compiling ZNC

[abel at abelromero dot com]

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

Abel Romero  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |---

--- Comment #3 from Abel Romero  ---
The OOM killer doesn't show any killing to process g++ .

# dmesg | grep -i oom
[6071354.290556] sshd invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=0
[6071354.290697]  [] oom_kill_process+0x202/0x3c0
[6071354.290881] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name
[6092958.118942] sshd invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=0
[6092958.119083]  [] oom_kill_process+0x202/0x3c0
[6092958.119286] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name
[6114741.218529] freshclam invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=0
[6114741.218655]  [] oom_kill_process+0x202/0x3c0
[6114741.218837] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name
[6136104.105414] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=-500
[6136104.105553]  [] oom_kill_process+0x202/0x3c0
[6136104.105738] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name
[6157693.098063] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=-500
[6157693.098242]  [] oom_kill_process+0x202/0x3c0
[6157693.098507] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name
[6179343.973294] /usr/sbin/amavi invoked oom-killer: gfp_mask=0x24201ca,
order=0, oom_score_adj=0
[6179343.973434]  [] oom_kill_process+0x202/0x3c0
[6179343.973639] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name
[6200925.008085] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=-500
[6200925.008212]  [] oom_kill_process+0x202/0x3c0
[6200925.008388] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name
[6222509.488296] tail invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=0
[6222509.488435]  [] oom_kill_process+0x202/0x3c0
[6222509.488619] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name
[6244171.974954] docker-proxy invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=-500
[6244171.975085]  [] oom_kill_process+0x202/0x3c0
[6244171.975272] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name
[6265735.007848] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=-500
[6265735.007976]  [] oom_kill_process+0x202/0x3c0
[6265735.008211] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name
[6287454.932900] docker-containe invoked oom-killer: gfp_mask=0x24201ca,
order=0, oom_score_adj=-500
[6287454.933078]  [] oom_kill_process+0x202/0x3c0
[6287454.933383] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name
[6308984.614383] docker-containe invoked oom-killer: gfp_mask=0x24201ca,
order=0, oom_score_adj=-500
[6308984.614520]  [] oom_kill_process+0x202/0x3c0
[6308984.614701] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name
[6330490.947849] kworker/u2:2 invoked oom-killer: gfp_mask=0x2420848, order=0,
oom_score_adj=0
[6330490.948021]  [] oom_kill_process+0x202/0x3c0
[6330490.948486] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds swapents
oom_score_adj name
[11989690.430639] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=-500
[11989690.430773]  [] oom_kill_process+0x202/0x3c0
[11989690.430959] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds
swapents oom_score_adj name
[15256553.392370] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=-500
[15256553.392481]  [] oom_kill_process+0x202/0x3c0
[15256553.392682] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds
swapents oom_score_adj name
[15272895.669235] dockerd invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=-500
[15272895.669355]  [] oom_kill_process+0x202/0x3c0
[15272895.669587] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds
swapents oom_score_adj name
[15289024.964421] docker-containe invoked oom-killer: gfp_mask=0x24201ca,
order=0, oom_score_adj=-500
[15289024.964537]  [] oom_kill_process+0x202/0x3c0
[15289024.964724] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds
swapents oom_score_adj name
[15289107.045937] docker-containe invoked oom-killer: gfp_mask=0x24201ca,
order=0, oom_score_adj=-500
[15289107.046049]  [] oom_kill_process+0x202/0x3c0
[15289107.046211] [ pid ]   uid  tgid total_vm  rss nr_ptes nr_pmds
swapents oom_score_adj name
[15294500.163513] freshclam invoked oom-killer: gfp_mask=0x24201ca, order=0,
oom_score_adj=0
[15294500.163621]  [] oom_kill_process+0x202/0x3c0
[15294500.163787] [ 

[Bug fortran/79430] [7/8 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #63 from Jürgen Reuter  ---
(In reply to Thomas Koenig from comment #62)
> (In reply to Jürgen Reuter from comment #61)
> > (In reply to Thomas Koenig from comment #60)
> > > r242780 works.
> > > 
> > > With both r243586 and r244391, plus the patch for r245191
> > > applied, I got numerous failures in the test suite.
> > > 
> > > Apparently, something else was wrong for some time, which
> > > blocks the attempt at bisection for that particular error
> > > in that range.
> > 
> > There was also this PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79344
> > fixed in r245194. You don't apply any -fcheck= flags, right?
> 
> No, I don't.
> 
> I appear to have hit a wall in bisecting.
> 
> I keep getting lots of failures in your test suite with additional
> errors. Either I am doing something wrong in testing, or there
> were indeed other errors present which keep the intermediate
> versions from working.
> 
> Could you re-check this, for exapmle by doing "svn update -r 243183"
> in trunk, recompiling the compiler, and then running your testsuite
> again?
> 
> Or how could I just, with a single command, run the test case
> you are interested in, without going through all the other tests?
> 
> I am currently at a loss how to proceed.

Darn Did you apply the patch from PR79344? You can run the single test if
you go to the build folder, into the directory tests/functional_test and just
do 
`make check TESTS=mlm_matching_isr.run`. This runs only this one single test. I
tried to produce a smaller test case, but our setup explicitly creates, links
and loads a dynamic library. This is rather hard to emulate. Whenever I tried
to give the routines the input directly, the optimization seems to be gone.

[Bug rtl-optimization/78116] [7/8 regression] Performance drop after r241173 on avx512 target

[andrew.n.senkevich at gmail dot com]

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

--- Comment #18 from Andrew Senkevich  ---
Created pr80481.

[Bug tree-optimization/78847] pointer arithmetic from c++ ranged-based for loop not optimized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #9 from Richard Biener  ---
Fixed for GCC 8.

[Bug tree-optimization/78847] pointer arithmetic from c++ ranged-based for loop not optimized

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
Author: rguenth
Date: Fri Apr 21 12:09:20 2017
New Revision: 247061

URL: https://gcc.gnu.org/viewcvs?rev=247061=gcc=rev
Log:
2017-04-21  Richard Biener  

PR tree-optimization/78847
* fold-const.c (split_tree): Handle POINTER_PLUS_EXPR.

* g++.dg/tree-ssa/pr78847.C: New testcase.

Added:
trunk/gcc/testsuite/g++.dg/tree-ssa/pr78847.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/80481] New: Unoptimal additional copy instructions

[andrew.n.senkevich at gmail dot com]

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

Bug ID: 80481
   Summary: Unoptimal additional copy instructions
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.n.senkevich at gmail dot com
  Target Milestone: ---

Created attachment 41242
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41242=edit
test-case to reproduce

Hi,

as was found in pr78116 attached testcase (compiled with g++ -Ofast -fopenmp
-funroll-loops -march=knl) have series of moves (1) which looks like can be
avoided if set target register of previous vpermps (2) equal to move target
register and rearrange order of vpermps, vmaxps according to data flow (f.e.
(3) should be after (4)).

.L26:
vmaxps  (%r10,%rax), %zmm15, %zmm1
vpermps (%rcx), %zmm9, %zmm2   (2)
vmovaps %zmm2, %zmm14  (1)
vpermps -64(%rcx), %zmm9, %zmm2(2) (3)
vfnmadd132ps(%r14,%rax), %zmm12, %zmm14
leal4(%rsi), %esi
vmaxps  %zmm1, %zmm14, %zmm13  (4) 
vmovaps %zmm2, %zmm14  (1)
vmaxps  64(%r10,%rax), %zmm15, %zmm1
vfnmadd132ps64(%r14,%rax), %zmm12, %zmm14
vpermps -128(%rcx), %zmm9, %zmm2   (2)
cmpl%esi, %r11d
vmovups %zmm13, (%r9,%rax)
leaq-256(%rcx), %rcx
vmaxps  %zmm1, %zmm14, %zmm13
vmovaps %zmm2, %zmm14  (1)
vmaxps  128(%r10,%rax), %zmm15, %zmm1
vfnmadd132ps128(%r14,%rax), %zmm12, %zmm14
vpermps 64(%rcx), %zmm9, %zmm2 (2)
vmovups %zmm13, 64(%r9,%rax)
vmaxps  %zmm1, %zmm14, %zmm13
vmovaps %zmm2, %zmm14  (1)
vmaxps  192(%r10,%rax), %zmm15, %zmm1
vfnmadd132ps192(%r14,%rax), %zmm12, %zmm14
vmovups %zmm13, 128(%r9,%rax)
vmaxps  %zmm1, %zmm14, %zmm13
vmovups %zmm13, 192(%r9,%rax)
leaq256(%rax), %rax
ja  .L26

It is better visible without -funroll-loops:

.L26:
vpermps (%rcx), %zmm10, %zmm1  (2)
leal1(%rsi), %esi
vmovaps %zmm1, %zmm2   (1)
vmaxps  (%r15,%rdx), %zmm3, %zmm1
vfnmadd132ps(%r12,%rdx), %zmm7, %zmm2
cmpl%esi, %r8d
leaq-64(%rcx), %rcx
vmaxps  %zmm1, %zmm2, %zmm1
vmovups %zmm1, (%rdi,%rdx)
leaq64(%rdx), %rdx
ja  .L26

[Bug c++/80480] The compiler gets killed by an internal error when compiling ZNC

[abel at abelromero dot com]

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

--- Comment #2 from Abel Romero  ---
I commit that bug to improve g++ because I solved this issue by installing
version 4.7 and linking to it for the system to be able to access it by this
way:

apt-get install g++-4.7 (as root)

ln -fs /usr/bin/g++-4.7 /usr/bin/g++

good luck.

-D1W0U.

[Bug c++/80480] The compiler gets killed by an internal error when compiling ZNC

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
You need more memory. Look for OOM killer in dmseg.

[Bug tree-optimization/78869] [6/7/8 Regression] Strange __builtin_memcpy optimisations

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Depends on|78687   |80293

--- Comment #4 from Martin Jambor  ---
Richi, I believe you wanted to add a dependency on PR 80293 (and not
on PR 78687).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78687
[Bug 78687] inefficient code generated for eggs.variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80293
[Bug 80293] [6/7/8 Regression] unnecessary code at -O2 (-O1 is fine)

[Bug c++/80480] New: The compiler gets killed by an internal error when compiling ZNC

[abel at abelromero dot com]

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

Bug ID: 80480
   Summary: The compiler gets killed by an internal error when
compiling ZNC
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abel at abelromero dot com
  Target Milestone: ---

I was compiling ZNC-1.6.5 (http://znc.in/releases/znc-1.6.5.tar.gz) and I got
that error:

[...]
Linking  module nickserv...
Building module sample...
Linking  module sample...
Building module log...
g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Makefile:116: recipe for target 'log.o' failed
make[1]: *** [log.o] Error 4
Makefile:105: recipe for target 'modules' failed
make: *** [modules] Error 2

[Bug fortran/79430] [7/8 Regression] action of statement incorrectly optimised away

[tkoenig at gcc dot gnu.org]

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

--- Comment #62 from Thomas Koenig  ---
(In reply to Jürgen Reuter from comment #61)
> (In reply to Thomas Koenig from comment #60)
> > r242780 works.
> > 
> > With both r243586 and r244391, plus the patch for r245191
> > applied, I got numerous failures in the test suite.
> > 
> > Apparently, something else was wrong for some time, which
> > blocks the attempt at bisection for that particular error
> > in that range.
> 
> There was also this PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79344
> fixed in r245194. You don't apply any -fcheck= flags, right?

No, I don't.

I appear to have hit a wall in bisecting.

I keep getting lots of failures in your test suite with additional
errors. Either I am doing something wrong in testing, or there
were indeed other errors present which keep the intermediate
versions from working.

Could you re-check this, for exapmle by doing "svn update -r 243183"
in trunk, recompiling the compiler, and then running your testsuite
again?

Or how could I just, with a single command, run the test case
you are interested in, without going through all the other tests?

I am currently at a loss how to proceed.

[Bug middle-end/70773] Profiled sudoku solver slower due to lack of sdiv/udiv

[wilco at gcc dot gnu.org]

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

--- Comment #14 from wilco at gcc dot gnu.org ---
(In reply to PeteVine from comment #11)
> I've just retested gcc7 on both ARM platforms. 
> 
> AArch64 gets a 3% improvement now, while ARMv7 reproduces the issue, just as
> before. I'm compiling/profiling on a Cortex A5 which could be the main
> reason behind all this, as it doesn't have hard division.

Can you try comparing the .S outputs on both the Cortex-A5 and Cortex-A53
system using exact same options, ie. -marm -mcpu=cortex-a5? Assuming you're
using the same GCC version, you should get identical .S files and the same
.gcda.

[Bug target/80479] [7/8 Regression] strcmp() produces valgrind errors on ppc64le

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |7.2

--- Comment #8 from Richard Biener  ---
So it would be interesting to see if it faults when placing the strings at the
edge of a page boundary...

In any case reading excess bytes from an aligned location is ok but of course
unfortunate for tolls like valgrind.  So not sure if a bug (but see above).

[Bug target/80479] [7/8 Regression] strcmp() produces valgrind errors on ppc64le

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||acsawdey at gcc dot gnu.org

--- Comment #7 from Markus Trippelsdorf  ---
Started with r244598.

[Bug target/80479] [7/8 Regression] strcmp() produces valgrind errors on ppc64le

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
The memcmp is emitted directly by isntructions, it would need someone who can
verify that it's not touching the uninitialized bytes of str{1,2} (bytes 8-15).
After calling memset for these bytes, the error is gone in valgrind.

[Bug target/80479] [7/8 Regression] strcmp() produces valgrind errors on ppc64le

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
Looks more like a missing valgrind suppression.

[Bug ipa/79765] [CHKP] ICE in create_target_clone in multiple_target.c:211

[aivchenk at gmail dot com]

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

Alexander Ivchenko  changed:

   What|Removed |Added

 CC||aivchenk at gmail dot com

--- Comment #1 from Alexander Ivchenko  ---
Multi-versioning pass tries to make versions out of mpx chunks, which have no
bodies and hence it fails. I think there is no reason to keep target_clones
attribute for chunks. The following patch helps:

diff --git a/gcc/ipa-chkp.c b/gcc/ipa-chkp.c
index c7fc3a0..5de11b3 100644
--- a/gcc/ipa-chkp.c
+++ b/gcc/ipa-chkp.c
@@ -718,6 +718,9 @@ chkp_produce_thunks (bool early)
 0, CGRAPH_FREQ_BASE);
  node->create_reference (node->instrumented_version,
   IPA_REF_CHKP, NULL);
+ DECL_ATTRIBUTES (node->decl)
+   = remove_attribute ("target_clones",
+   DECL_ATTRIBUTES (node->decl));
  /* Thunk shouldn't be a cdtor.  */
  DECL_STATIC_CONSTRUCTOR (node->decl) = 0;
  DECL_STATIC_DESTRUCTOR (node->decl) = 0;


.. And at "O0" it works. However it fails later on at O1 and above.

gcc/gcc/testsuite/gcc.target/i386/mvc1.c:18:1: error: virtual definition of
statement not up-to-date
 main ()
 ^~~~
_3 = foo.chkp.ifunc ();
gcc/gcc/testsuite/gcc.target/i386/mvc1.c:18:1: internal compiler error:
verify_ssa failed
r0x113ccab verify_ssa(bool, bool)
../../gcc/gcc/tree-ssa.c:1184
0xd65f4b execute_function_todo
../../gcc/gcc/passes.c:1973
0xd64fab do_per_function
../../gcc/gcc/passes.c:1650
0xd660d6 execute_todo
../../gcc/gcc/passes.c:2016

[Bug target/80479] endless stream of valgrind errors when using trunk build with trunk on ppc64le

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
I'll take a look. It's maybe related to folding improvements I did.

[Bug target/80479] endless stream of valgrind errors when using trunk build with trunk on ppc64le

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-21
 Ever confirmed|0   |1

--- Comment #3 from Markus Trippelsdorf  ---
trippels@gcc2-power8 ~ % cat example.c
#include 

int main ()
{
   char str1[15];
   char str2[15];
   strcpy(str1, "abcdef");
   strcpy(str2, "ABCDEF");
   return strcmp(str1, str2);
}

trippels@gcc2-power8 ~ % ~/gcc_7/usr/local/bin/gcc -O2 -g example.c
trippels@gcc2-power8 ~ % valgrind ./a.out
==28988== Memcheck, a memory error detector
==28988== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==28988== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==28988== Command: ./a.out
==28988== 
==28988== Conditional jump or move depends on uninitialised value(s)
==28988==at 0x14E8: main (example.c:9)

[Bug target/80479] endless stream of valgrind errors when using trunk build with trunk on ppc64le

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
Hmm, all error locations involve calls to strcmp().

[Bug tree-optimization/80153] ivopt generate wrong code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
  Known to work||7.0.1
 Resolution|--- |FIXED

--- Comment #10 from Richard Biener  ---
Fixed for GCC 7.

[Bug target/57796] AVX2 gather vectorization: code bloat and reduction of performance

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #12 from Richard Biener  ---
Cost model is fixed for GCC 8.

[Bug target/80232] Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms

[rguenth at gcc dot gnu.org]

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

Bug 57796 Summary: AVX2 gather vectorization: code bloat and reduction of 
performance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57796

   What|Removed |Added

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

[Bug target/80232] Ofast pessimizes Sparse matmult in scimark2 benchmark on avx platforms

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
I've adjusted the generic cost model for gather/scatter for GCC 8 (doesn't help
here).

[Bug rtl-optimization/80474] ipa-cp wrongly adding LO(symbol) twice

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||mips-o32
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-04-21
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Can you provide unreduced preprocessed source plus command-line options to
reproduce with a cross?

[Bug target/80479] endless stream of valgrind errors when using trunk build with trunk on ppc64le

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Target||ppc64le
   Host||ppc64le

--- Comment #1 from Markus Trippelsdorf  ---
Not sure what is going on. I will try a bootstrap with
--enable-checking=valgrind.

[Bug rtl-optimization/78116] [7/8 regression] Performance drop after r241173 on avx512 target

[amker at gcc dot gnu.org]

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

--- Comment #17 from amker at gcc dot gnu.org ---
(In reply to Andrew Senkevich from comment #16)
> (In reply to amker from comment #13)
> > We should create another PR for additional copy instructions after my patch
> > and close this one.  IMHO they are two different issues.
> 
> I agree, currently there are no fills from stack on both testcases for which
> this PR was created.
> But I have no bugzilla permissions to close it, could somebody from CC close
> it please?
> 
> (In reply to Pat Haugen from comment #14)
> . . . 
> > Additional info, it's really just one copy introduced, but becomes 4 after
> > unrolling. This is the loop from the first testcase without -funroll-loops.
> > Looks like we could get rid of the vmovaps by making zmm2 the dest on the
> > vpermps (assuming I'm understanding the asm correctly).
> > 
> > .L26:
> > vpermps (%rcx), %zmm10, %zmm1
> > leal1(%rsi), %esi
> > vmovaps %zmm1, %zmm2
> > vmaxps  (%r15,%rdx), %zmm3, %zmm1
> > vfnmadd132ps(%r12,%rdx), %zmm7, %zmm2
> > cmpl%esi, %r8d
> > leaq-64(%rcx), %rcx
> > vmaxps  %zmm1, %zmm2, %zmm1
> > vmovups %zmm1, (%rdi,%rdx)
> > leaq64(%rdx), %rdx
> > ja  .L26
> 
> Looks like so. For which optimization/analysis we should file ticket for it?

Put rtl-optimization would be fine for this.  I can close this ticket after new
one is created.  Thanks.

[Bug c/80409] Document that va_arg(ap, void*) can be used to consume any pointer argument

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
On Wed, 12 Apr 2017, pascal_cuoq at hotmail dot com wrote:

> Since the open-source world divides the C compilation platform described by 
> the
> C standard into C compilers (Clang, GCC) and standard libraries (Glibc, musl,
> ...), with the implementation of varargs on the compiler side and the
> implementation of scanf on the standard library side, it would make sense to
> document that on target platforms where the representation of pointers is
> uniform, the compilers allow va_arg(ap, void*) to consume any pointer 
> argument.

Note that this is documented in POSIX (XSI-shaded, in the specification of 
stdarg.h).

[Bug target/80479] New: endless stream of valgrind errors when using trunk build with trunk on ppc64le

[trippels at gcc dot gnu.org]

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

Bug ID: 80479
   Summary: endless stream of valgrind errors when using trunk
build with trunk on ppc64le
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

When I build trunk with trunk on ppc64le (--enable-valgrind-annotations
--disable-bootstrap) the resulting compiler produces many valgrind errors, even
on simple testcases. Building trunk with an older release works fine.

trippels@gcc2-power8 ~ % valgrind --track-origins=yes --trace-children=yes
~/gcc_test/usr/local/bin/g++ -O2 bench.cpp
==140970== Memcheck, a memory error detector
==140970== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==140970== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==140970== Command: /home/trippels/gcc_test/usr/local/bin/g++ -O2 bench.cpp
==140970== 
==140970== Invalid read of size 4
==140970==at 0x100A9630: make_relative_prefix_1
(make-relative-prefix.c:356)
==140970==by 0x1000CFC7: process_command(unsigned int, cl_decoded_option*)
(gcc.c:4222)
==140970==by 0x10019C5F: driver::set_up_specs() const (gcc.c:7416)
==140970==by 0x100037BF: driver::main(int, char**) (gcc.c:7228)
==140970==by 0x10003B97: main (gcc-main.c:46)
==140970==  Address 0x43bd2b4 is 2 bytes after a block of size 2 alloc'd
==140970==at 0x4083E0C: malloc (vg_replace_malloc.c:299)
==140970==by 0x100A9397: save_string (make-relative-prefix.c:108)
==140970==by 0x100A9397: split_directories (make-relative-prefix.c:174)
==140970==by 0x100A951B: make_relative_prefix_1
(make-relative-prefix.c:325)
==140970==by 0x1000CFC7: process_command(unsigned int, cl_decoded_option*)
(gcc.c:4222)
==140970==by 0x10019C5F: driver::set_up_specs() const (gcc.c:7416)
==140970==by 0x100037BF: driver::main(int, char**) (gcc.c:7228)
==140970==by 0x10003B97: main (gcc-main.c:46)
==140970== 
==140970== Invalid read of size 4
==140970==at 0x100A9634: make_relative_prefix_1
(make-relative-prefix.c:356)
==140970==by 0x1000CFC7: process_command(unsigned int, cl_decoded_option*)
(gcc.c:4222)
==140970==by 0x10019C5F: driver::set_up_specs() const (gcc.c:7416)
==140970==by 0x100037BF: driver::main(int, char**) (gcc.c:7228)
==140970==by 0x10003B97: main (gcc-main.c:46)
==140970==  Address 0x43bd474 is 2 bytes after a block of size 2 alloc'd
==140970==at 0x4083E0C: malloc (vg_replace_malloc.c:299)
==140970==by 0x100A9397: save_string (make-relative-prefix.c:108)
==140970==by 0x100A9397: split_directories (make-relative-prefix.c:174)
==140970==by 0x100A95CF: make_relative_prefix_1
(make-relative-prefix.c:348)
==140970==by 0x1000CFC7: process_command(unsigned int, cl_decoded_option*)
(gcc.c:4222)
==140970==by 0x10019C5F: driver::set_up_specs() const (gcc.c:7416)
==140970==by 0x100037BF: driver::main(int, char**) (gcc.c:7228)
==140970==by 0x10003B97: main (gcc-main.c:46)
==140970== 
==140970== Conditional jump or move depends on uninitialised value(s)
==140970==at 0x100A963C: make_relative_prefix_1
(make-relative-prefix.c:356)
==140970==by 0x1000CFC7: process_command(unsigned int, cl_decoded_option*)
(gcc.c:4222)
==140970==by 0x10019C5F: driver::set_up_specs() const (gcc.c:7416)
==140970==by 0x100037BF: driver::main(int, char**) (gcc.c:7228)
==140970==by 0x10003B97: main (gcc-main.c:46)
==140970== 
==140970== Conditional jump or move depends on uninitialised value(s)
==140970==at 0x100A9648: make_relative_prefix_1
(make-relative-prefix.c:356)
==140970==by 0x1000CFC7: process_command(unsigned int, cl_decoded_option*)
(gcc.c:4222)
==140970==by 0x10019C5F: driver::set_up_specs() const (gcc.c:7416)
==140970==by 0x100037BF: driver::main(int, char**) (gcc.c:7228)
==140970==by 0x10003B97: main (gcc-main.c:46)
...
==140970== ERROR SUMMARY: 98 errors from 21 contexts (suppressed: 0 from 0)

[Bug target/77728] [5/6/7/8 Regression] Miscompilation multiple vector iteration on ARM

[jakub at gcc dot gnu.org]

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

--- Comment #21 from Jakub Jelinek  ---
inform, beyond being consistent with what i386 and rs6000 backends do here, has
the advantage that it doesn't break the build even with -Werror, generally
there is nothing wrong on the code we want to inform user about, so there is
nothing to fix unless they want to achieve ABI compatibility with code compiled
by older GCC versions.  For this category i386/rs6000 backends use inform. 
There are also warning uses with OPT_Wpsabi, but those are there for when user
is doing something considered wrong, e.g. passing vector argument by value in a
function without corresponding ISA supporting those vectors enabled.

[Bug target/68390] [5 Regression] Incorrect code due to indirect tail call of varargs function with hard float ABI

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #6 from Christophe Lyon  ---
Should be fixed now.

[Bug target/68390] [5 Regression] Incorrect code due to indirect tail call of varargs function with hard float ABI

[clyon at gcc dot gnu.org]

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

--- Comment #5 from Christophe Lyon  ---
Author: clyon
Date: Fri Apr 21 09:23:59 2017
New Revision: 247057

URL: https://gcc.gnu.org/viewcvs?rev=247057=gcc=rev
Log:
[ARM] PR68390 Incorrect code due to indirect tail call of varargs function with
hard float ABI

2017-04-21  Christophe Lyon  

Backport from mainline
+2015-11-23  Kugan Vivekanandarajah  

PR target/68390
gcc/
* config/arm/arm.c (arm_function_ok_for_sibcall): Get function type
for indirect function call.

gcc/testsuite/
* gcc.c-torture/execute/pr68390.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/execute/pr68390.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/arm/arm.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug rtl-optimization/78116] [7/8 regression] Performance drop after r241173 on avx512 target

[andrew.n.senkevich at gmail dot com]

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

--- Comment #16 from Andrew Senkevich  ---
(In reply to amker from comment #13)
> We should create another PR for additional copy instructions after my patch
> and close this one.  IMHO they are two different issues.

I agree, currently there are no fills from stack on both testcases for which
this PR was created.
But I have no bugzilla permissions to close it, could somebody from CC close it
please?

(In reply to Pat Haugen from comment #14)
. . . 
> Additional info, it's really just one copy introduced, but becomes 4 after
> unrolling. This is the loop from the first testcase without -funroll-loops.
> Looks like we could get rid of the vmovaps by making zmm2 the dest on the
> vpermps (assuming I'm understanding the asm correctly).
> 
> .L26:
> vpermps (%rcx), %zmm10, %zmm1
> leal1(%rsi), %esi
> vmovaps %zmm1, %zmm2
> vmaxps  (%r15,%rdx), %zmm3, %zmm1
> vfnmadd132ps(%r12,%rdx), %zmm7, %zmm2
> cmpl%esi, %r8d
> leaq-64(%rcx), %rcx
> vmaxps  %zmm1, %zmm2, %zmm1
> vmovups %zmm1, (%rdi,%rdx)
> leaq64(%rdx), %rdx
> ja  .L26

Looks like so. For which optimization/analysis we should file ticket for it?

[Bug bootstrap/80476] GCC 7 can't be compiled with bootstrap-O3

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Initializing the variable to zero fixes the issue. Should I install that to
trunk?

[Bug bootstrap/80476] GCC 7 can't be compiled with bootstrap-O3

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Except for the most common --with-build-config options, people should use
--disable-werror, it is too hard to keep the sources warning free for all
possible optimization levels, PGO, LTO etc. variants.

[Bug c/80468] [7 Regression] ICE on invalid AVX512 code with -m32

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[7/8 Regression] ICE on |[7 Regression] ICE on
   |invalid AVX512 code with|invalid AVX512 code with
   |-m32|-m32

--- Comment #3 from Jakub Jelinek  ---
Fixed on the trunk so far, queued for 7.2.

[Bug tree-optimization/79534] [7/8 Regression] tree-ifcombine aarch64 performance regression with trunk@245151

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #12 from James Greenhalgh  ---
So while there's nothing buggy about the if-conversion which causes the
performance issue, it does show an interesting missed optimization that ifcvt
can't handle.

We make the transform through find_if_case_2, which looks for things of the
form:

/* TEST BLOCK  */
if (test)
   goto E; // x not live
/* FALLTHRU  */
/* ELSE BLOCK  */
x = big();
goto L;
E:
/* THEN BLOCK  */
x = b;
goto M;

And transforms them to:

/* Unconditional copy of THEN BLOCK */
x = b;
/* TEST BLOCK  */
if (test)
  goto M;
/* ELSE BLOCK  */
x = big();
goto L;

In the testcase, using the naming conventions above, and snipping irrelevant
details, this looks like:

TEST BLOCK (309)

;; basic block 309, loop depth 4, count 0, freq 3153, maybe hot
;;  prev block 308, next block 311, flags: (REACHABLE, RTL, MODIFIED)
;;  pred:   219 [98.0%] 


(insn 1915 1914 1916 309 (set (reg:CC 66 cc)
(compare:CC (reg:SI 1117)
(const_int 0 [0]))) "foo.cpp":59 391 {cmpsi}
 (expr_list:REG_DEAD (reg:SI 1117)
(nil)))
(jump_insn 1916 1915 1922 309 (set (pc)
(if_then_else (ne (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref 1905)
(pc))) "foo.cpp":59 9 {condjump}
 (expr_list:REG_DEAD (reg:CC 66 cc)
(int_list:REG_BR_PROB 9558 (nil)))
 -> 1905)

;;  succ:   227 [95.6%] 
;;  226 [4.4%]  (FALLTHRU)

ELSE BLOCK (226)

;; basic block 226, loop depth 4, count 0, freq 201, maybe hot
;;  prev block 224, next block 227, flags: (REACHABLE, RTL, MODIFIED)
;;  pred:   309 [4.4%]  (FALLTHRU)
;;  311 [3.8%]  (FALLTHRU)

(code_label 1917 1413 1417 226 141 (nil) [0 uses])
(note 1417 1917 1418 226 [bb 226] NOTE_INSN_BASIC_BLOCK)
(insn 1418 1417 1905 226 (set (reg:SI 690 [ _1517 ])
(plus:SI (reg:SI 703 [ ivtmp.56D.5375 ])
(const_int -3 [0xfffd]))) 95 {*addsi3_aarch64}
 (nil))

;;  succ:   237 [100.0%]  (FALLTHRU)

THEN BLOCK (227)

;; basic block 227, loop depth 4, count 0, freq 3013, maybe hot
;;  prev block 226, next block 228, flags: (REACHABLE, RTL, MODIFIED)
;;  pred:   309 [95.6%] 

(code_label 1905 1418 1421 227 140 (nil) [1 uses])
(note 1421 1905 1422 227 [bb 227] NOTE_INSN_BASIC_BLOCK)
(insn 1422 1421 1802 227 (set (reg:SI 690 [ _1517 ])
(plus:SI (reg:SI 703 [ ivtmp.56D.5375 ])
(const_int -3 [0xfffd]))) 95 {*addsi3_aarch64}
 (nil))

;;  succ:   237 [100.0%]  (FALLTHRU)

So the interesting thing is that the THEN block and the ELSE block are as good
as identical! Both compute (plus (reg 703) (const_int -3)) and both fall
through to block 237.

The normal if-convert machinery won't catch this because basic block 226 (the
ELSE block) has multiple predecessors. But the transformation we make through
find_if_case_2 ends up looking silly! (again, snipping some unrelated
details/insns):

TEST BLOCK (279)

;; basic block 279, loop depth 4, count 0, freq 3153, maybe hot
;;  prev block 278, next block 280, flags: (REACHABLE, RTL, MODIFIED)
;;  pred:   203 [98.0%] 


/* Unconditional copy of THEN BLOCK.  */

(insn 1422 1914 1915 279 (set (reg:SI 690 [ _1517 ])
(plus:SI (reg:SI 703 [ ivtmp.56D.5375 ])
(const_int -3 [0xfffd]))) 95 {*addsi3_aarch64}
 (nil))
(insn 1915 1422 1916 279 (set (reg:CC 66 cc)
(compare:CC (reg:SI 1117)
  (const_int 0 [0]))) "foo.cpp":59 391 {cmpsi}
 (expr_list:REG_DEAD (reg:SI 1117)
(nil)))
(jump_insn 1916 1915 1922 279 (set (pc)
(if_then_else (ne (reg:CC 66 cc)
(const_int 0 [0]))
(label_ref:DI 1470)
(pc))) "foo.cpp":59 9 {condjump}
 (expr_list:REG_DEAD (reg:CC 66 cc)
(int_list:REG_BR_PROB 9558 (nil)))
 -> 1470)
;;  succ:   218 [95.6%] 
;;  209 [4.4%]  (FALLTHRU)

ELSE BLOCK (209):

;; basic block 209, loop depth 4, count 0, freq 201, maybe hot
;;  prev block 208, next block 210, flags: (REACHABLE, RTL, MODIFIED)
;;  pred:   279 [4.4%]  (FALLTHRU)
;;  280 [3.8%]  (FALLTHRU)

(code_label 1917 1413 1417 209 141 (nil) [0 uses])
(note 1417 1917 1418 209 [bb 209] NOTE_INSN_BASIC_BLOCK)
(insn 1418 1417 1802 209 (set (reg:SI 690 [ _1517 ])
(plus:SI (reg:SI 703 [ ivtmp.56D.5375 ])
(const_int -3 [0xfffd]))) 95 {*addsi3_aarch64}
 (nil))
;;  succ:   218 [100.0%]  (FALLTHRU)

Note that if we are on the "else" path, we now we compute 

[Bug demangler/70909] Libiberty Demangler segfaults (4)

[mark at gcc dot gnu.org]

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

--- Comment #53 from Mark Wielaard  ---
Author: mark
Date: Fri Apr 21 09:02:03 2017
New Revision: 247056

URL: https://gcc.gnu.org/viewcvs?rev=247056=gcc=rev
Log:
libiberty: Limit demangler maximum d_print_comp recursion call depth.

The fix for PR demangler/70909 and 67264 (endless demangler recursion)
catches when a demangle_component is printed in a cycle. But that doesn't
protect the call stack blowing up from non-cyclic nested types printed
recursively through d_print_comp. This can happen by a (very) long mangled
string that simply creates a very deep pointer or qualifier chain. Limit
the recursive d_print_comp call depth for a d_print_info to 1K nested
types.

libiberty/ChangeLog:

* cp-demangle.c (MAX_RECURSION_COUNT): New constant.
(struct d_print_info): Add recursion field.
(d_print_init): Initialize recursion.
(d_print_comp): Check and update d_print_info recursion depth.

Modified:
trunk/libiberty/ChangeLog
trunk/libiberty/cp-demangle.c

[Bug target/77728] [5/6/7/8 Regression] Miscompilation multiple vector iteration on ARM

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
BTW, the wording e.g. i386 backend has is:
  inform (input_location,
  "the ABI of passing structure with complex float"
  " member has changed in GCC 4.4");
In this arm/aarch64 case, the wording can't be as specific, because it isn't
all arguments of this type, but only some arguments of certain type (at some
positions; for some types like those that have more aligned static data members
it is all such positioned arguments, for others, e.g. the templates where the
alignment used to depend on instantiation vs. non-instantiation something
earlier, only some), but you should consider using inform rather than warning
for consistency, and you should mention the GCC version where it has changed
and maybe also print the type in the diagnostic, so that user at least knows
what type it is that is problematic (but as it is not something as simple as in
the i386 case, there should not be a single inform per TU, but about each case
this is encountered).

Richard said we should defer RC1 till this is done, do you think you can have a
patch for both architectures written today, tested over the weekend, so that we
could do RC1 on Monday or Tuesday at latest?
Is there an agreement in ARM that what the patch does (for aarch64, and similar
one for arm) is what the AAPCS says?

[Bug tree-optimization/66278] Missed auto-vectorization of an array subtraction

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Liška  ---
Test has been added, closing as resolved.

[Bug c/80468] [7/8 Regression] ICE on invalid AVX512 code with -m32

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr 21 08:51:53 2017
New Revision: 247052

URL: https://gcc.gnu.org/viewcvs?rev=247052=gcc=rev
Log:
PR c/80468
* c-decl.c (finish_declspecs) : If int_n_idx is not
enabled, set specs->type to integer_type_node.

* gcc.dg/pr80468.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr80468.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/66278] Missed auto-vectorization of an array subtraction

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
Author: marxin
Date: Fri Apr 21 08:50:19 2017
New Revision: 247051

URL: https://gcc.gnu.org/viewcvs?rev=247051=gcc=rev
Log:
Add test-case (PR tree-optimization/66278).

2017-04-21  Martin Liska  

PR tree-optimization/66278
* gcc.dg/vect/pr66278.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/vect/pr66278.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/80237] float to double conversion is not optimized away

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed for GCC 8.

[Bug tree-optimization/80426] [6 Regression] wrong manipulation of range based on INT_MIN

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #13 from Eric Botcazou  ---
.

[Bug tree-optimization/80426] [6 Regression] wrong manipulation of range based on INT_MIN

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Apr 21 08:37:13 2017
New Revision: 247050

URL: https://gcc.gnu.org/viewcvs?rev=247050=gcc=rev
Log:
Backport from mainline
2017-04-19  Eric Botcazou  
Jakub Jelinek  

PR tree-optimization/80426
* tree-vrp.c (extract_range_from_binary_expr_1): For an additive
operation on symbolic operands, also compute the overflow for the
invariant part when the operation degenerates into a negation.

Added:
branches/gcc-6-branch/gcc/testsuite/gcc.c-torture/execute/20170419-1.c
  - copied unchanged from r247047,
trunk/gcc/testsuite/gcc.c-torture/execute/20170419-1.c
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/tree-vrp.c

[Bug tree-optimization/80237] float to double conversion is not optimized away

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Author: rguenth
Date: Fri Apr 21 08:17:23 2017
New Revision: 247049

URL: https://gcc.gnu.org/viewcvs?rev=247049=gcc=rev
Log:
2017-04-21  Richard Biener  

PR tree-optimization/80237
* tree-ssa-pre.c (find_leader_in_sets): Add third set argument,
defaulted to NULL.
(phi_translate_1): Also allow a leader in AVAIL_OUT of pred
for a simplified result.

* gcc.dg/tree-ssa/tailcall-9.c: New testcase.
* gcc.dg/tree-ssa/ldist-pr45948.c: Remove undefined behavior,
adjust expected optimizations.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/tailcall-9.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ldist-pr45948.c
trunk/gcc/tree-ssa-pre.c

[Bug bootstrap/80476] GCC 7 can't be compiled with bootstrap-O3

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-21
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Reading Czech error messages, I feel I have to fix the issue. Seriously, I
believe it's just one another false positive of the warning and initialization
will be probably needed. Let me reproduce that.

[Bug tree-optimization/80426] [6 Regression] wrong manipulation of range based on INT_MIN

[ebotcazou at gcc dot gnu.org]

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

--- Comment #11 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Apr 21 08:08:03 2017
New Revision: 247047

URL: https://gcc.gnu.org/viewcvs?rev=247047=gcc=rev
Log:
PR tree-optimization/80426
* gcc.c-torture/execute/20170429-1.c: Rename into...
* gcc.c-torture/execute/20170419-1.c: ...this.

Added:
branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/20170419-1.c
  - copied unchanged from r247046,
branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/20170429-1.c
Removed:
branches/gcc-7-branch/gcc/testsuite/gcc.c-torture/execute/20170429-1.c
Modified:
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/80426] [6 Regression] wrong manipulation of range based on INT_MIN

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou  ---
Author: ebotcazou
Date: Fri Apr 21 08:03:54 2017
New Revision: 247046

URL: https://gcc.gnu.org/viewcvs?rev=247046=gcc=rev
Log:
PR tree-optimization/80426
* gcc.c-torture/execute/20170429-1.c: Rename into...
* gcc.c-torture/execute/20170419-1.c: ...this.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/20170419-1.c
  - copied unchanged from r247045,
trunk/gcc/testsuite/gcc.c-torture/execute/20170429-1.c
Removed:
trunk/gcc/testsuite/gcc.c-torture/execute/20170429-1.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/80345] [5 Regression] ICE in rewrite_use_nonlinear_expr with -O2

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #14 from amker at gcc dot gnu.org ---
Now fixed.

[Bug target/77728] [5/6/7/8 Regression] Miscompilation multiple vector iteration on ARM

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
Indeed, with the above plus:
#include 

int
fn1 (int a, int b, int c, int d, int e, int f, int g, int h, int i, int j, int
k, int l, int m, B<0> n, ...)
{
  va_list ap;
  va_start (ap, n);
  int x = va_arg (ap, int);
  va_end (ap);
  return x;
}

int
fn2 (int a, int b, int c, int d, int e, int f, int g, int h, int i, int j, int
k, int l, int m,
B<1> n, ...)
{
  va_list ap;
  va_start (ap, n);
  int x = va_arg (ap, int);
  va_end (ap);
  return x;
}

there is ABI change for fn1 but not fn2.  But we already get a warning with
your patch on that:
warning: Parameter passing changed for argument in function_arg_boundary
so perhaps no need to emit it for the second time.

[Bug rtl-optimization/80425] Extra inter-unit register move with zero-extension

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Vladimir Makarov from comment #2)

> So I don't know how to fix it in IRA or in LRA.  I am pretty sure the
> old RA and reload would have had the same problem.
> 
> Probably the issue should be fixed in machine dependent code.  But the fix
> might create more problems.

It is possible to create a couple of peephole2 patterns to catch this, but
perhaps REE can be enhanced to optimize the above register propagation, so the
solution would apply to all targets.

GNU gfortran potential bug: polymorphic functions (thus defined operators) generates serious memory leaks

[Stefano Zaghi]

Dear all,
I faced with a possible serious bug: polymorphic functions (necessary
to define polymorphic operators in OOP programs) generate memory leaks
making OOP program not feasible.

I opened a bug report (80477) here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477

I report the details also below.

My best regards.

Issue summary

In the attached example "polymorphic_operators_memory_leaks.f90" I
show the possible bug in less than 100 lines. Essentially, the derived
type "a_type_t" defines the operators "=" and "+" in a polymorphic way
(in order to allow "a_type_t" to be extended while all other "agents"
using "a_type_t" do not need to be changed, OOP). The assignment
operator does not create memory leaks because it is subroutine that
does not allocate temporary. On the contrary, the operator "+" is a
function that allocates a temporary: this temporary generates the
memory leaks because it is not correctly destroyed after its usage.

I checked the above conclusion with "valgrind" and it confirms that
the "+" operator (function) generates the leaks. Note that the same
code compiled and run with Intel Fortran (17.0.2) does not generates
memory leaks and it works as expected. Moreover, is the "+"
operator/function is modified disallowing polymorphic (namely changing
"class(a_type_t), allocatable :: res" with "type(a_type_t) :: res" the
leaks disappear, thus I could conclude that the leaks are generated
only for polymorphic function results.

A word of advice: the test is designed to point out the memory leaks
occurrences, running it your RAM will be quickly consumed! Please, be
rapid to quickly kill it before your OS start swapping on HD. To test
it with valgrind I added a little "ui": it can be executed without
arguments, thus its loop will be very long (and your RAM totally
consumed) or you can pass one integer argument and the loop will do
the iterations you provided, e.g. "a.out 1" will execute 1 iteration
loop. This is written into the code comments.

Please, consider that if this is really a bug, all serious OOP
programs are indeed impossible to be done.

Thank you very much for your help.

Stefano Zaghi  Ph.D. Aerospace Engineer

Research Scientist, Dept. of Computational Hydrodynamics at CNR-INSEAN
p: +39 0650299260 | m: +39 3497730036 | e: stefano.za...@gmail.com

Member of Fortran-FOSS-Programmers

Codes Showcase
OFF  Open source Finite volumes Fluid dynamics code
Lib_VTK_IO   Fortran library to write and read data conforming the VTK standard
FLAP Fortran command Line Arguments Parser for poor men
BeFoR64  Base64 encoding/decoding library for FoRtran poor men
FiNeRFortran INI ParseR and generator for FoRtran poor men
IR_Precision Fortran (standard 2003) module to develop portable codes
FoBis.py Fortran Building System for poor men
PreForM.py   Preprocessor for Fortran poor men
MaTiSSe.py   Markdown To Impressive Scientific Slides
module a_type_m

   implicit none

   integer, parameter :: LENGTH = 100

   type :: a_type_t
  real :: x(LENGTH)
   contains
  ! operators
  generic :: assignment(=) => assign_a_type
  generic :: operator(+) => add_a_type
  procedure, pass(lhs) :: assign_a_type
  procedure, pass(lhs) :: add_a_type
   endtype a_type_t

contains
   subroutine assign_a_type(lhs, rhs)
  ! Operator `=`.
  class(a_type_t), intent(inout) :: lhs
  class(a_type_t), intent(in):: rhs

  lhs%x = rhs%x
   endsubroutine assign_a_type

   function add_a_type(lhs, rhs) result( res )
  ! Operator `+`.
  class(a_type_t), intent(in)  :: lhs
  class(a_type_t), intent(in)  :: rhs
  class(a_type_t), allocatable :: res

  allocate (a_type_t :: res)
  res%x = lhs%x + rhs%x
   endfunction add_a_type
endmodule a_type_m

program polymorphic_operators_memory_leaks
   ! pass one argument to limit the loop iterations, e.g.:
   ! a.out 4 # the loop will be limited to 4 iterations
   ! useful for testing with valgrind;
   ! a.out # the loop will run for LENGHT**3 iterations

   use a_type_m

   implicit none

   character(99)  :: switch
   type(a_type_t) :: a
   type(a_type_t) :: b
   integer:: N
   integer:: i

   a%x = [(i, i=1, LENGTH)]
   b = a

   i = command_argument_count()
   if (i == 1) then
  call get_command_argument(1,switch)
  read(switch, *) N
   else
  N = LENGTH**3
   endif

   do i=1, N
  b = a + b ! here the `+` operator generates memory leaks
  if (mod(i,10**5) == 0) print*, i
   enddo
endprogram polymorphic_operators_memory_leaks

[Bug fortran/80477] Polymorphic functions (thus operators) generates memory leaks

[stefano.zaghi at cnr dot it]

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

--- Comment #1 from Stefano Zaghi  ---
I forget to say that I test this issue with GNU gfortran gcc version 6.3.1
20170306 and gcc version 7.0.0 20161206 (experimental).

My best regards.

[Bug target/77728] [5/6/7/8 Regression] Miscompilation multiple vector iteration on ARM

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek  ---
If you want a testcase for aarch64, e.g.
template 
struct alignas (16) A { char p[16]; };
A<0> v;
template 
struct B
{
  typedef A T;
  int i, j, k, l;
};
int
foo (int a, B<0> b)
{
  return a + b.i;
}
int
bar (int a, B<1> b)
{
  return a + b.i;
}
struct C
{
  static int h alignas (16);
  int i, j, k, l;
};
int
baz (int a, C b)
{
  return a + b.i;
}

will do the job, there is a warning on foo's b argument, because A<0> has been
instantiated first and when instantiating B<0>, we already see A<0>'s alignment
and use it when creating the TYPE_DECL.  Compared to that, for B<1> we don't
have it instantiated yet, so when TYPE_DECL is created, it gets minimal
alignment.  You might want to create e.g. a compat testcase from it too, have
caller of foo with the A<0> v; in it and callee without and vice versa, check
if it is able to pass the argument around properly.  Similarly with baz (in
that case it actually was a stable (but wrong) ABI before, the baz caller and
callee would agree, but they now don't in between unpatched and patched GCC.
For ARM you can easily adjust the testcase by s/16/8/g, and maybe removing k
and l fields too.

Comments on the patch:

#include "print-tree.h"
you don't really need this, that is from some debugging, right?

  unsigned int alignment ; // alignment for FIELD_DECLS in function arguments.
extraneous space before ;, not sure if it is a good idea to mix // and /*
comments and on the next line it is way too long, so maybe better use /* */
comments above each field.

 {
+
+  unsigned int alignment = 0;
+  unsigned int warning_alignment = 0;
extraneous vertical space.  Also, what is the point to have a struct containing
those 2 fields and auto vars mirroring that?  Just use the struct all the time?

alignment = std::max (alignment, DECL_ALIGN (field));
I think we usually use MAX rather than std::max.

+  if (nregs == 2 && (a.warning_alignment == 16 * BITS_PER_UNIT) && ncrn %
2)
+ if (a.warning_alignment < a.alignment
+ && warn_psabi)
+   warning (0, "Parameter passing changed for argument");
The if condition fits on one line.  Do you need the ()s around
a.warning_alignment == 16 * BITS_PER_UNIT?  Can't it be written as
  if (warn_psabi
  && nregs == 2
  && a.warning_alignment == 16 * BITS_PER_UNIT
  && a.alignment != 16 * BITS_PER_UNIT
  && ncrn % 2)
?  That is what is actually tested originally, whether alignment == 16 *
BITS_PER_UNIT.  Also, warnings should not start with capital letter.
And it would be nice to tell user which argument it is (does cumulative_args_t
track the argument number or could it?).

 on_stack:
   pcum->aapcs_stack_words = size / UNITS_PER_WORD;
-  if (aarch64_function_arg_alignment (mode, type) == 16 * BITS_PER_UNIT)
+  struct aarch64_fn_arg_alignment ab = aarch64_function_arg_alignment (mode,
type);
+  if (ab.alignment == 16 * BITS_PER_UNIT)
 pcum->aapcs_stack_size = ROUND_UP (pcum->aapcs_stack_size,
   16 / UNITS_PER_WORD);
No warning here, if ab.alignment is not 16 * BITS_PER_UNIT, but
ab.warning_alignment is and warn_psabi is on?  I must say I don't really know
exactly what pcum->aapcs_stack_size influence, but doesn't it influence the ABI
when the function is varargs?  I mean, with the above testcase, something like:
void
foo (int a, int b, int c, int d, int e, int f, int g, int h, int i, int j, int
k, int l, int m, B<0> n, ...)
with/without the A<0> v; early?

   if (alignment < PARM_BOUNDARY)
 alignment = PARM_BOUNDARY;
   if (alignment > STACK_BOUNDARY)
 alignment = STACK_BOUNDARY;
+
+  if (a.warning_alignment < PARM_BOUNDARY)
+a.warning_alignment = PARM_BOUNDARY;
+
+  if (a.warning_alignment > STACK_BOUNDARY)
+a.warning_alignment = STACK_BOUNDARY;
+
Isn't the above candidate for MAX/MIN to put it into fewer lines?

+  if (a.warning_alignment > alignment
+  && warn_psabi)
+warning (0, "Parameter passing changed for argument in
function_arg_boundary");
+
+  

Again, condition can fit onto a single line.  Due to MAX/MIN, I guess the only
possible values of those 2 are 64 and 128, so the comparison is fine.  But
again, warning should not start with a capital letter and mentioning "in
function_arg_boundary" is not helpful to the users, much better would be to
tell which argument it is or something similar.  And, perhaps remove the
alignment variable and always use a.alignment?  There is also extra vertical
space before return.

+  align =  a.alignment / BITS_PER_UNIT;
Extraneous whitespace after =.