[Bug tree-optimization/77689] Missing vectorization lead to huge performance loss

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #12 from Jeffrey A. Law  ---
WRT c#5.  Rather than jump threading this seems more suited to the erroneous
path isolation code.

I suspect the reason that code does not fire is the shape of the CFG.If the
PHI for iftmp.2_40 were in BB 8, then I'd expect the erroneous path optimizer
to catch this.  It's a known limitation.

To catch it, the erroneous path optimizer would have to do block duplication in
a manner similar to what jump threading does for join blocks (or the backwards
threader does for regions with embedded control flow).

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

[yyc1992 at gmail dot com]

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

--- Comment #2 from Yichao Yu  ---
I should add that turning on lto works around the issue both in the simple code
attached and for the original issue I was having in julia (i.e. compiling llvm
with LTO makes the issue go away).

[Bug tree-optimization/77719] [7 Regression] ICE in pp_string, at pretty-print.c:955

[kugan at gcc dot gnu.org]

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

--- Comment #7 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Mon Sep 26 18:16:23 2016
New Revision: 240505

URL: https://gcc.gnu.org/viewcvs?rev=240505=gcc=rev
Log:
Fix PR77719
gcc/testsuite/ChangeLog:

2016-09-26  Kugan Vivekanandarajah  

PR middle-end/77719
* gfortran.dg/pr77719.f90: New test.

gcc/ChangeLog:

2016-09-26  Kugan Vivekanandarajah  

PR middle-end/77719
* tree-ssa-reassoc.c (make_new_ssa_for_def): Use gimple_get_lhs to get
lhs
instead of gimple_assign_lhs as stmt can be builtins too.



Added:
trunk/gcc/testsuite/gfortran.dg/pr77719.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

[Bug fortran/77420] [5/6/7 Regression] gfortran and equivalence produces internal compiler error

[kargl at gcc dot gnu.org]

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

--- Comment #6 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Sep 26 18:44:36 2016
New Revision: 240506

URL: https://gcc.gnu.org/viewcvs?rev=240506=gcc=rev
Log:
2016-09-26  Steven G. Kargl  

PR fortran/77420
* trans-common.c:  Handle array elements in equivalence when
the lower and upper bounds of array spec are NULL.

2016-09-26  Steven G. Kargl  

PR fortran/77420
* gfortran.dg/pr77420_1.f90: New test.
* gfortran.dg/pr77420_2.f90: Ditto.
* gfortran.dg/pr77420_3.f90: New test. Requires ...
* gfortran.dg/pr77420_4.f90: this file.

Added:
trunk/gcc/testsuite/gfortran.dg/pr77420_1.f90
trunk/gcc/testsuite/gfortran.dg/pr77420_2.f90
trunk/gcc/testsuite/gfortran.dg/pr77420_3.f90
trunk/gcc/testsuite/gfortran.dg/pr77420_4.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-common.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/77420] [5/6/7 Regression] gfortran and equivalence produces internal compiler error

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from kargl at gcc dot gnu.org ---
Let's try this again.

[Bug fortran/77746] [5 Regression] Wrong subroutine called, clash of specific procedure name and binding-name

[vladimir.fuka at gmail dot com]

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

--- Comment #1 from Vladimir Fuka  ---
-fdump-tree-original

random_name ()
{

}


p_execute (integer(kind=4) & restrict i)
{
  p_execute ();
}


MAIN__ ()
{
  {
static integer(kind=4) C.3388 = 1;

p_execute ();
  }
}


main (integer(kind=4) argc, character(kind=1) * * argv)
{
  static integer(kind=4) options.0[9] = {68, 1023, 0, 0, 1, 1, 0, 0, 31};

  _gfortran_set_args (argc, argv);
  _gfortran_set_options (9, [0]);
  MAIN__ ();
  return 0;
}

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

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-26
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed the exception on GCC 5 and later

[Bug middle-end/77718] [7 Regression] expand_builtin_memcmp swaps args

[acsawdey at gcc dot gnu.org]

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

--- Comment #3 from acsawdey at gcc dot gnu.org ---
Bernd,
  I identified the problem on powerpc64le. I think it may not show up on x86_64
because of differences in how builtin memcmp gets expanded. Normally this is
hidden because if both strings are constant, this gets handled by folding. It
only shows up in the test case because the length given is longer than the
string length, which prevents folding (undefined behavior).

It seems clear to me that it is only legitimate to swap the args in the
result_eq case because otherwise you are changing the sign of the result.

[Bug target/60563] FAIL: g++.dg/ext/sync-4.C on *-apple-darwin*

[mrs at gcc dot gnu.org]

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

--- Comment #13 from mrs at gcc dot gnu.org  ---
The change in c12 is ok if you'd like to do that.  The only problem with it is
that then we will not be able to discover when radr://19802258 is fixed.  When
people notice that that bug is fixed, we should revert the c12 patch. 
Essentially, we allow the test case to track any _other_ issue that prevents
things from just working (to catch any regressions), so that when ld64 is
fixed, the test case will remain working.

[Bug gcov-profile/62267] disable fprofile-use at coverage-mismatch

[ioctl at yandex dot ru]

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

--- Comment #3 from ioctl at yandex dot ru ---
Unfortunatelly I cannot check it now.

[Bug gcov-profile/62267] disable fprofile-use at coverage-mismatch

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX
   Severity|normal  |enhancement

--- Comment #4 from Martin Liška  ---
Ok, please reopen the issue if it's still valid.

[Bug c++/77747] New: GCC allows inheriting constructors from indirect base

[vasek.potocek at post dot cz]

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

Bug ID: 77747
   Summary: GCC allows inheriting constructors from indirect base
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vasek.potocek at post dot cz
  Target Milestone: ---

Created attachment 39690
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39690=edit
Minimal test case (preprocessed file)

According to the standard ([namespace.udecl] §3), it should only be possible to
inherit constructors from a direct base class. The following example shows a
good example why this is important:

class X {

public:
  X() { std::cout << "Default" << std::endl; }
  X(int a) { std::cout << a << std::endl; }
};

class Y : public X { };

class Z : public Y {
  using X::X;
};

int main() {
  Z instance{3};  // how is Y constructed?
}

G++ accepts this code even with strictest warning level settings with the
following result: Y is default-constructed, default-constructing X on its way,
and the parameter provided in the last line is silently ignored.

System version:

Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array
--disable-libgcj --with-isl --enable-libmpx --enable-gnu-indirect-function
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 6.2.1 20160916 (Red Hat 6.2.1-2) (GCC) 

Command line:

g++ -Weffc++ -Wall -Wextra -pedantic -fno-diagnostics-show-caret -save-temps
skip.cpp -o skip

Compiler output: none

[Bug gcov-profile/48361] gcov freezes when using --all-blocks (-a) flag.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #7 from Martin Liška  ---
No reply, closing as WORKSFORME.

[Bug go/77715] go-system.h includes C++ header files before GCC system.h

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-26
 CC||tony.reix at atos dot net
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
Confirmed.

Note that GCC system.h currently does not include hooks for all of the C++
headers used by go-system.h.

The detailed problem is the inclusion of the C++ headers inhibit the definition
of PRIx64 and PRIu64 on AIX.  One could include specific code in go-system.h to
define those macros for AIX, but that has not been the solution used in other
parts of the compiler that wish to utilize standard C++ header file features.

[Bug gcov-profile/57115] Cannot merge separate single counters for function

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
-fprofile-update=atomic option was added, closing as resolved.

[Bug tree-optimization/77745] Inconsistent application of aliasing rules

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Runtime example, e.g.:

#include 
long foo(char *c1, char *c2) {
  long *p1 = new (c1) long;
  *p1 = 100;
  long long *p2 = new (c2) long long;
  *p2 = 200;
  long *p3 = new (c2) long;
  *p3 = 200;
  return *p1;
}
int main() {
  char c[128];
  if (foo(c, c) == 100)
__builtin_abort();
}

gcc hits the abort with -O2, all other compilers (clang, icc, visual c++) not.

[Bug tree-optimization/77745] Inconsistent application of aliasing rules

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
This is all due to life time of objects rather than aliasing. If c1==c2, the
lifetime of p1 ends at the operator new.

[Bug fortran/77666] ICE in gfc_omp_clause_default_ctor, at fortran/trans-openmp.c:471

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 39689
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39689=edit
gcc7-pr77666.patch

Untested fix.

[Bug fortran/77746] New: [5 Regression] Wrong subroutine called, clash of specific procedure name and binding-name

[vladimir.fuka at gmail dot com]

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

Bug ID: 77746
   Summary: [5 Regression] Wrong subroutine called, clash of
specific procedure name and binding-name
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vladimir.fuka at gmail dot com
  Target Milestone: ---

This program finishes successfully with 4.9 and crashes with 5.3.1

The generic resolution selects wrong procedure. The calling procedure happens
to have the same binding-name as the name of the correct specific procedure and
gets called recursively instead of the correct one.

See also similar: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695 (I have
already 15 still open bugs in gfortran and this is the 16th!)

Output:

> gfortran-5 bug1.F90 
> ./a.out 
Segmentation fault

> gfortran-5 -fcheck=all bug1.F90 
> ./a.out 
At line 22 of file bug1.F90
Fortran runtime error: Recursive call to nonrecursive procedure 'p_execute'



module first
  private
  public execute

  interface execute
module procedure random_name
  end interface

contains

  subroutine random_name()
  end subroutine
end module

module test
  use first

  implicit none

contains

  subroutine p_execute(i)  bind(C, name="random_name")
integer :: i

call execute()
  end subroutine

end module

  use test
  call p_execute(1)
end

[Bug tree-optimization/77745] Inconsistent application of aliasing rules

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
I think the issue is with
Deleted redundant store MEM[(long int *)c2_7(D)] = 200;

It is considered as redundant with
  MEM[(long long int *)c2_7(D)] = 200;

but they do not define the same dynamic type, so it seems that we cannot remove
this store. In this case we could remove the other one, but of course that's
harder in general.

[Bug libstdc++/77537] [6 Regression] pair constructors do not properly SFINAE

[Casey at Carter dot net]

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

--- Comment #11 from Casey Carter  ---
Thanks again Ville - I owe you a beer in Issaquah.

[Bug target/27077] [x86, 4.1] builtin strlen poor performance

[var at schellong dot biz]

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

--- Comment #8 from Helmut Schellong  ---
Test case is a special measurement program.
See assembler code below:
strlen / repnz scasb
clock_gettime
gcc6 + gcc5

The exact gcc version is not critical.
Each gcc that injects an intel string instruction
injects slow code (on many cpus).
Practical experience (use) is important.

CPU: Intel(R) Core(TM)2 Duo CPU E8600  @ 3.33GHz (.40-MHz K8-class CPU)
Origin = "GenuineIntel"  Id = 0x1067a  Family = 0x6  Model = 0x17  Stepping =
10
Features=0xbfebfbff
Features2=0xc08e3fd
  AMD Features=0x20100800
  AMD Features2=0x1
  VT-x: HLT,PAUSE
  TSC: P-state invariant, performance statistics

gcc6 -v
Using built-in specs.
COLLECT_GCC=gcc6
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc6/gcc/x86_64-portbld-freebsd10.1/6.2.0/lto-wrapper
Target: x86_64-portbld-freebsd10.1
Configured with: ...
Thread model: posix
gcc version 6.2.0 (FreeBSD Ports Collection) 

gcc5 -v
Using built-in specs.
COLLECT_GCC=gcc5
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc5/gcc/x86_64-portbld-freebsd10.0/5.0.0/lto-wrapper
Target: x86_64-portbld-freebsd10.0
Configured with: ...
Thread model: posix
gcc version 5.0.0 20140921 (experimental) (FreeBSD Ports Collection) 



gcc6 -O1 -static -s -opt -fno-builtin-strlen -DSTRLENF pt.c ptf.o
==
lea rsi, [rsp+32]   #,
mov edi, 1  #,
callclock_gettime   #
mov ebx, DWORD PTR CntA[rip]# is, CntA
.p2align 2
.L10:
mov edi, OFFSET FLAT:DA #,
callstrlen  #
mov QWORD PTR [rsp+112], rax# L, _80
sub ebx, 1  # is,
testebx, ebx# is
jg  .L10#,
lea rsi, [rsp+64]   # tmp273,
mov edi, 1  #,
callclock_gettime   #
imulrax, QWORD PTR [rsp+64], 10 # tmp216, cb[0].tv_sec,
add rax, QWORD PTR [rsp+72] # tmp218, cb[0].tv_nsec
imulrdx, QWORD PTR [rsp+32], 10 # tmp220, ca[0].tv_sec,
add rdx, QWORD PTR [rsp+40] # tmp222, ca[0].tv_nsec
sub rax, rdx# tmp224, tmp222
pxorxmm7, xmm7  # _94
cvtsi2sdq   xmm7, rax   # _94, tmp224
movsd   QWORD PTR [rsp+8], xmm7 # %sfp, _94
mov rsi, QWORD PTR [rsp+112]# L.7_105, L
mov edi, OFFSET FLAT:.LC3   #,
mov eax, 0  #,
callprintf  #
lea rsi, [rsp+32]   #,
mov edi, 1  #,
callclock_gettime   #
mov ebx, DWORD PTR CntA[rip]# is, CntA
.p2align 2
.L11:
mov edi, OFFSET FLAT:DA #,
callstrlen  #
mov QWORD PTR [rsp+112], rax# L, _112
mov edi, OFFSET FLAT:DA #,
callstrlen  #
mov QWORD PTR [rsp+112], rax# L, _115
sub ebx, 1  # is,
testebx, ebx# is
jg  .L11#,
lea rsi, [rsp+64]   # tmp275,
mov edi, 1  #,
callclock_gettime   #
==

gcc6 -O1 -static -s -opt -DSTRLENF pt.c ptf.o
==
lea rsi, [rsp+32]   #,
mov edi, 1  #,
callclock_gettime   #
mov edx, DWORD PTR CntA[rip]# is, CntA
mov rsi, -1 # tmp225,
mov eax, 0  # tmp226,
.p2align 2
.L10:
mov edi, OFFSET FLAT:DA # tmp224,
mov rcx, rsi# tmp222, tmp225
repnz scasb
not rcx # tmp223
sub rcx, 1  # _80,
mov QWORD PTR [rsp+112], rcx# L, _80
sub edx, 1  # is,
testedx, edx# is
jg  .L10#,
lea rsi, [rsp+64]   # tmp299,
mov edi, 1  #,
callclock_gettime   #
imulrax, QWORD PTR [rsp+64], 10 # tmp228, cb[0].tv_sec,
add rax, QWORD PTR [rsp+72] # tmp230, cb[0].tv_nsec
imulrdx, QWORD PTR [rsp+32], 10 # tmp232, ca[0].tv_sec,
add rdx, QWORD PTR [rsp+40] # tmp234, ca[0].tv_nsec
sub rax, rdx# tmp236, tmp234
pxorxmm7, xmm7  # _94
cvtsi2sdq   xmm7, rax   # _94, tmp236
movsd   QWORD PTR [rsp+8], xmm7 # %sfp, _94
mov rsi, QWORD PTR [rsp+112]# L.7_105, L
mov edi, OFFSET FLAT:.LC3   #,
mov eax, 0  #,
callprintf  #
lea rsi, [rsp+32]   #,
mov edi, 1  #,
call

[Bug libstdc++/77537] [6 Regression] pair constructors do not properly SFINAE

[eric.niebler at gmail dot com]

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

--- Comment #12 from Eric Niebler  ---
Likewise

[Bug libstdc++/77537] [6 Regression] pair constructors do not properly SFINAE

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Ville Voutilainen  ---
Fixed on gcc-6 branch, thus done.

[Bug libstdc++/77727] Unwrapping std::optional constructor is not working for non-transferable object

[ville at gcc dot gnu.org]

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

--- Comment #3 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Sep 26 20:51:42 2016
New Revision: 240511

URL: https://gcc.gnu.org/viewcvs?rev=240511=gcc=rev
Log:
PR libstdc++/77727
* include/std/optional (optional(const optional<_Up>&)):
Default-initialize the base and use emplace.
(optional(optional<_Up>&&)): Likewise.
* testsuite/20_util/optional/cons/77727.cc: New.

Added:
trunk/libstdc++-v3/testsuite/20_util/optional/cons/77727.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/include/std/optional

[Bug libstdc++/77727] Unwrapping std::optional constructor is not working for non-transferable object

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #4 from Ville Voutilainen  ---
Fixed.

[Bug libstdc++/77537] [6 Regression] pair constructors do not properly SFINAE

[ville at gcc dot gnu.org]

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

--- Comment #9 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Sep 26 19:56:14 2016
New Revision: 240507

URL: https://gcc.gnu.org/viewcvs?rev=240507=gcc=rev
Log:
Backport from mainline
2016-09-21  Ville Voutilainen  

PR libstdc++/77537
Implement LWG 2729 for pair.
* include/bits/stl_pair.h (_PCC): New.
(_ConstructiblePair, _ImplicitlyConvertiblePair):
Turn into static member functions of _PCC.
(_MoveConstructiblePair, _ImplicitlyMoveConvertiblePair): Likewise.
(_PCCP): New.
(pair(const _T1&, const _T2&)): Adjust.
(_PCCFP): New.
(pair(const pair<_U1, _U2>&)): Adjust.
(pair(_U1&&, const _T2&)): Likewise.
(pair(const _T1&, _U2&&)): Likewise.
(pair(_U1&&, _U2&&)): Likewise.
(pair(pair<_U1, _U2>&&)): Likewise.
(operator=(const pair&)): Make conditionally deleted.
(operator=(pair&&)): Make conditionally suppressed.
(operator=(const pair<_U1, _U2>&)): Constrain.
(operator=(pair<_U1, _U2>&&): Likewise.
* include/std/type_traits (__nonesuch): New.
* testsuite/20_util/pair/traits.cc: New.

Added:
branches/gcc-6-branch/libstdc++-v3/testsuite/20_util/pair/traits.cc
Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/include/bits/stl_pair.h
branches/gcc-6-branch/libstdc++-v3/include/std/type_traits

[Bug middle-end/77720] -Wformat-length= wit -O3 emit warning twice with incorrect linenumbers

[dimhen at gmail dot com]

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

Dmitry G. Dyachenko  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #2 from Dmitry G. Dyachenko  ---
r240462 PASS : print diagnostique one time

$ gcc -Wall -c -O3 x.c
x.c: In function ‘bar’:
x.c:15:21: warning: ‘%3u’ directive output may be truncated writing between 3
and 10 bytes into a region of size 4 [-Wformat-length=]
 snprintf(p, 4, "%3u", k);
 ^~~
x.c:15:20: note: directive argument in the range [0u, 4294967295u]
 snprintf(p, 4, "%3u", k);
^
x.c:15:5: note: format output between 4 and 11 bytes into a destination of size
4
 snprintf(p, 4, "%3u", k);
 ^~~~

[Bug middle-end/77740] New: [7 regression] internal compiler error: in format_floating, at gimple-ssa-sprintf.c:1165

[gerald at pfeifer dot com]

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

Bug ID: 77740
   Summary: [7 regression] internal compiler error: in
format_floating, at gimple-ssa-sprintf.c:1165
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerald at pfeifer dot com
  Target Milestone: ---

Created attachment 39685
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39685=edit
Preprocessed input file (generated with -save-temps)

About four, five days ago, I started to see Wine fail to build with my daily
builds of GCC on i?86-unknown-freebsd10:

gmake[1]: Entering directory '/home/gerald/wine/dlls/msvcr100'
/home/gerald/gcc-ref10-i386/bin/gcc -c -o math.o ../msvcrt/math.c -I.
-I../msvcrt -I../../include -D__WINESRC__ -D_MT \
  -D_MSVCR_VER=100 -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing
-Wdeclaration-after-statement \
  -Wduplicated-cond -Wempty-body -Wignored-qualifiers -Wshift-overflow=2
-Wstrict-prototypes \
  -Wtype-limits -Wunused-but-set-parameter -Wno-unused-const-variable -Wvla
-Wwrite-strings \
  -Wpointer-arith -Wlogical-op -gdwarf-2 -gstrict-dwarf -fno-omit-frame-pointer
\
  -I/home/gerald/10-i386/include -g -O2
../msvcrt/math.c: In function ‘MSVCRT__ecvt’:
../msvcrt/math.c:1370:14: internal compiler error: in format_floating, at
gimple-ssa-sprintf.c:1165
 char * CDECL MSVCRT__ecvt( double number, int ndigits, int *decpt, int *sign )
  ^~~~

[Bug rtl-optimization/77714] [7 Regression] Wrong code generation for gcc.c-torture/execute/pr51447.c

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
Summary|Wrong code generation for   |[7 Regression] Wrong code
   |gcc.c-torture/execute/pr514 |generation for
   |47.c|gcc.c-torture/execute/pr514
   ||47.c

[Bug libstdc++/65122] std::vector doesn't honor element alignment

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-26
 Ever confirmed|0   |1

--- Comment #20 from Jonathan Wakely  ---
In C++17 std::allocator no longer says "It is implementation-defined whether
over-aligned types are supported" and is no longer required to call operator
new(size_t), it is supposed to use the over-aligned form as appropriate.

We should do that when __cpp_aligned_new is defined.

[Bug c++/77739] internal compiler error: in create_tmp_var, at gimple-expr.c:524

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-26
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.2.0, 7.0

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed. All supported gcc versions are affected.

markus@x4 /tmp % cat ice.ii
struct A {
  A();
  A(const A &);
};
struct B {
  B();
  template  auto g(Args &&... p1) {
return [=] { f(p1...); };
  }
  void f(A, const char *);
};
B::B() { g(A(), ""); }

markus@x4 /tmp % g++ -c ice.ii
ice.ii: In member function ‘auto B::g(Args&& ...) [with Args = {A, const char
(&)[1]}]’:
ice.ii:8:28: internal compiler error: in create_tmp_var, at gimple-expr.c:473
 return [=] { f(p1...); };
^
0xafcb20 create_tmp_var(tree_node*, char const*)
../../gcc/gcc/gimple-expr.c:473
0xb2f384 create_tmp_from_val
../../gcc/gcc/gimplify.c:500
0xb2f384 lookup_tmp_var
../../gcc/gcc/gimplify.c:521
0xb2f384 internal_get_tmp_var
../../gcc/gcc/gimplify.c:574
0xb26cc1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:11483
0xb2ab27 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10701
0xb301a6 gimplify_compound_lval
../../gcc/gcc/gimplify.c:2195
0xb27165 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10495
0xb3a6cf gimplify_modify_expr
../../gcc/gcc/gimplify.c:4824
0xb29008 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10543
0xb2c407 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5805
0xb2c5e8 gimplify_and_add(tree_node*, gimple**)
../../gcc/gcc/gimplify.c:427
0xb2c5e8 gimplify_init_ctor_eval
../../gcc/gcc/gimplify.c:3799
0xb32e9f gimplify_init_constructor
../../gcc/gcc/gimplify.c:4171
0xb33d17 gimplify_modify_expr_rhs
../../gcc/gcc/gimplify.c:4432
0xb3a4d0 gimplify_modify_expr
../../gcc/gcc/gimplify.c:4769
0xb29008 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gcc/gimplify.c:10543
0xb2c407 gimplify_stmt(tree_node**, gimple**)
../../gcc/gcc/gimplify.c:5805
0xb28116 gimplify_and_add(tree_node*, gimple**)
../../gcc/gcc/gimplify.c:427
0xb28116 gimplify_return_expr
../../gcc/gcc/gimplify.c:1371

[Bug debug/77692] [7 regression] gcc.dg/debug/dwarf2/const-2b.c FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Mon Sep 26 07:33:33 2016
New Revision: 240483

URL: https://gcc.gnu.org/viewcvs?rev=240483=gcc=rev
Log:
2016-09-26  Richard Biener  

PR debug/77692
* cgraphunit.c (analyze_functions): Before early removing
global vars calls the late_global_decl debug handler mark
the variable as readonly.

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

[Bug debug/77692] [7 regression] gcc.dg/debug/dwarf2/const-2b.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug middle-end/77740] [7 regression] internal compiler error: in format_floating, at gimple-ssa-sprintf.c:1165

[gerald at pfeifer dot com]

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

--- Comment #1 from Gerald Pfeifer  ---
The minimum invocation to reproduce the issue is

  /some/where/gcc -c math.i -Wall -O1

Both warnings _and_ at least -O1 are required.

[Bug target/77686] [6/7 Regression] wrong code on arm-linux-gnueabi and arm-linux-gnueabihf

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
This can only uncover another pre-existing issue as it is a 100% obvious fix. 
I do not have a good way to run anything on arm so please help me spot the
wrong-code in the assembler output.

TBAA issues are also often exposed by scheduling so please try
-fno-schedule-insns[2] or -fstrict-aliasing with -O1.

-Updating SSA information for statement MEM[(struct function *) + 4B] =
__f$__dummy_a;
+Updating SSA information for statement MEM[(struct __lambda0 *)] = 

this might also very well be a C++ FE issue.

[Bug middle-end/77720] -Wformat-length= wit -O3 emit warning twice with incorrect linenumbers

[dimhen at gmail dot com]

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

Dmitry G. Dyachenko  changed:

   What|Removed |Added

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

--- Comment #1 from Dmitry G. Dyachenko  ---
r240462 PASS

[Bug c++/77741] Add a warning about inadvertent converting constructor

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Without giving any other opinion, non-standard attributes must be scoped, so it
would have to be gnu::converting not just converting.

[Bug middle-end/77740] [7 regression] internal compiler error: in format_floating, at gimple-ssa-sprintf.c:1165

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org
   Target Milestone|--- |7.0

[Bug debug/77692] [7 regression] gcc.dg/debug/dwarf2/const-2b.c FAILs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
(In reply to Richard Biener from comment #3)
> So -- is it worth trying to handle this special case where we know a variable
> is readonly by means of nothing referencing it?  Then the following fixes it:

It is certainly worth it, at least as long as the initializer isn't huge (but
that is dwarf2out.c business to decide that).  Even if the variable is
optimized out, people might want to ask about its value in the debugger (and
often do).

[Bug c++/77722] -fsanitize=undefined doesn't give runtime error in function without return value, unless at least 2 instructions

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-09-26
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 39684
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39684=edit
gcc7-pr77722.patch

Untested fix.

[Bug tree-optimization/56365] [5 Regression] Missed opportunities for smin/smax standard name patterns when compiling as C++

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
Keeping it open as it is a regression and to mark the last GCC 5 release as
known-to-fail.

[Bug middle-end/77718] [7 Regression] expand_builtin_memcmp swaps args

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-26
   Target Milestone|--- |7.0
Summary|expand_builtin_memcmp swaps |[7 Regression]
   |args|expand_builtin_memcmp swaps
   ||args
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed - we may only swap if result_eq.

[Bug tree-optimization/77719] [7 Regression] ICE in pp_string, at pretty-print.c:955

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug gcov-profile/50228] Incorrect line execution count.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #2 from Martin Liška  ---
No reply, the PR is quite old, closing as WORKFORME.

[Bug target/27077] [x86, 4.1] builtin strlen poor performance

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|RESOLVED|WAITING
   Last reconfirmed||2016-09-26
 CC||tkoenig at gcc dot gnu.org
 Resolution|INVALID |---
 Ever confirmed|0   |1

--- Comment #7 from Thomas Koenig  ---
(In reply to Helmut Schellong from comment #6)
> gcc 6.2
> ...
> builtin strlen: 137.787 ns
> libcstrlen:  12.562 ns   (-fno-builtin-strlen)
> About 12 times faster!
> See table below.

In general, it is better to write a new bug report than to
reopen a 10-year old one.

Can you provide

- your test case, including the test harness

- Architecture (which CPU are you running this on, exactly)

- Which version of gcc you are reporting against

- The assembly output (with -S)

[Bug rtl-optimization/71709] powerpc64le: argument to strcpy() optimised out

[doko at gcc dot gnu.org]

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

Matthias Klose  changed:

   What|Removed |Added

 CC||doko at gcc dot gnu.org

--- Comment #10 from Matthias Klose  ---
https://bugs.debian.org/838892 reports this for the gcc-6 branch too; could
that be backported?

[Bug c++/77748] New: pr77550.C fails on arm-none-eabi

[clyon at gcc dot gnu.org]

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

Bug ID: 77748
   Summary: pr77550.C fails on arm-none-eabi
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Hi,

As discussed at https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01878.html
here is a new PR: the testcase pr77550.C fails at execution time
for target arm-none-eabi (as opposed to arm-*linux*).

I'm attaching the preprocessed file and assembler code.

[Bug c++/77748] pr77550.C fails on arm-none-eabi

[clyon at gcc dot gnu.org]

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

--- Comment #1 from Christophe Lyon  ---
Created attachment 39691
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39691=edit
preprocessed file

[Bug c++/77748] pr77550.C fails on arm-none-eabi

[clyon at gcc dot gnu.org]

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

--- Comment #3 from Christophe Lyon  ---
Created attachment 39693
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39693=edit
qemu trace

[Bug c++/77748] pr77550.C fails on arm-none-eabi

[clyon at gcc dot gnu.org]

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

--- Comment #2 from Christophe Lyon  ---
Created attachment 39692
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39692=edit
assembler code

[Bug middle-end/60962] b+(-2.f)*a generates multiplication instruction while b-2.f*a simplifies to addition

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
Of course the inconsistency with

  /* We want to canonicalize to positive real constants.  Pretend
 that only negative ones can be easily negated.  */

is that we don't transform x + -2.*y to x - 2.*y (which in this case would
also pessimize code, but well...).

IMHO we should canonicalize here in some way and either always prefering
PLUS or positive constants should do the job.  The code generation issue
is something for the RTL expander.

[Bug c++/77741] New: Add a warning about inadvertent converting constructor

[akrzemi1 at gmail dot com]

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

Bug ID: 77741
   Summary: Add a warning about inadvertent converting constructor
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akrzemi1 at gmail dot com
  Target Milestone: ---

PROBLEM DESCRIPTION:

It is a known C++ gotcha: you declare a one-argument non-explicit constructor,
even though you never intend it to participate in any conversion. This later
causes bugs in code due to the inadvertent conversion being silently used.
Everyone agrees that it would be better if C++ reversed the defaults: "a
constructor is by default explicit, if you want it in conversions define it as
/converting/". This cannot be done due to compatibility reasons, but a compiler
can achieve a similar effect by adding a new attribute and a warning.

THE FEATURE REQUEST:

Add a new attribute: [[converting]]. You can apply it to any non-explicit
constructor. Its purpose is to control warning messages.

Add a new warning -Wconverting (or some such) it causes a warning message in
two situations:

1. A constructor that could in C++ be used in conversions (single-argument or
one where a second argument has a default value) that is not a copy or move
constructor declared without attribute [[converting]].

2. An explicit constructor declared with attribute [[converting]].

As an illustration, the following code would trigger a number of -Wconverting
warnings:

```
class X
{
public:
  X (); // no warning
  X (X const&); // no warning: copy ctor
  X (int); // warning: either add `explicit` or [[converting]]
  X (bool, bool = true); // warning: either add `explicit` or [[converting]] 
  explicit X(string); // no warning
  X (double) [[converting]]; // no warning
  explicit X(unsigned) [[converting]]; // warning either remove `explicit` or
[[converting]]
};
```

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||arm
  Known to work||4.9.4
   Target Milestone|--- |5.5
Summary|Miscompilation multiple |[5/6/7 Regression]
   |vector iteration on ARM |Miscompilation multiple
   ||vector iteration on ARM
  Known to fail||5.1.0, 6.2.0

[Bug testsuite/77710] FAIL: gcc.dg/tree-ssa/builtin-sprintf-warn-4.c

[thopre01 at gcc dot gnu.org]

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

--- Comment #2 from Thomas Preud'homme  ---
(In reply to Martin Sebor from comment #1)
> I think this failure may have been inadvertently introduced in r240434.  The
> failure should be gone now that r240442 has been checked in to adjust the
> test.

Hi Martin,

Sadly no, I've checked revision 240484 (last commit I could grab) and the
failure is still there.

Best regards.

[Bug target/77686] [6/7 Regression] wrong code on arm-linux-gnueabi and arm-linux-gnueabihf

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC|kyrylo.tkachov at arm dot com  |

--- Comment #7 from ktkachov at gcc dot gnu.org ---
As snippet of the assembly output without scheduling (-fno-schedule-insns2):
.LEHE0:
add r3, sp, #32
str r5, [sp, #32] < I1
add ip, sp, #8
str r5, [sp, #36] < I2
add r4, sp, #16
ldm r3, {r0, r1}  <-I3
add lr, sp, #4
str r5, [sp, #16]
mov r2, #3
str lr, [sp, #20]
movwr5, #:lower16:
stm ip, {r0, r1}
movtr5, #:upper16:
ldm r4, {r0, r1}
movwlr, #:lower16:
str r5, [sp, #40]


The same region with scheduling:
.LEHE0:
add r3, sp, #32
add ip, sp, #8
add r4, sp, #16
ldm r3, {r0, r1} <-- I3
add lr, sp, #4
str r5, [sp, #16]
mov r2, #3
str lr, [sp, #20]
movwlr, #:lower16:
stm ip, {r0, r1}
movtlr, #:upper16:
ldm r4, {r0, r1}
str r5, [sp, #32] <-- I1
str r5, [sp, #36] <-- I2

The stores I1 and I2 were moved past the load I3 that loads from SP + 32
If I manually move those two stores back before I3 the program doesn't abort

[Bug target/77686] [6/7 Regression] wrong code on arm-linux-gnueabi and arm-linux-gnueabihf

[ktkachov at gcc dot gnu.org]

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

--- Comment #6 from ktkachov at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
> This can only uncover another pre-existing issue as it is a 100% obvious
> fix.  I do not have a good way to run anything on arm so please help me spot
> the wrong-code in the assembler output.
> 
> TBAA issues are also often exposed by scheduling so please try
> -fno-schedule-insns[2] or -fstrict-aliasing with -O1.
> 

You're right. -fno-schedule-insns2 makes the testcase pass at -O2

> -Updating SSA information for statement MEM[(struct function *) +
> 4B] = __f$__dummy_a;
> +Updating SSA information for statement MEM[(struct __lambda0 *)] = 
> 
> this might also very well be a C++ FE issue.

[Bug libstdc++/65122] std::vector doesn't honor element alignment

[redi at gcc dot gnu.org]

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

--- Comment #21 from Jonathan Wakely  ---
Created attachment 39686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39686=edit
Make new_allocator support types with new-extended alignment

This works, but currently produces a warning due to PR 77742.

[Bug tree-optimization/77743] New: bogus -Wformat-length sprintf warnings

[amodra at gmail dot com]

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

Bug ID: 77743
   Summary: bogus -Wformat-length sprintf warnings
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amodra at gmail dot com
  Target Milestone: ---

Found during build of current binutils.

bfd/ihex.c:222:19: error: '%03o' directive writing between 3 and 11 bytes into
a region of size 9 [-Werror=format-length=]
  sprintf (buf, "\\%03o", (unsigned int) c & 0xff);
Should not assume full range of unsigned int.

bfd/coff-rs6000.c:3453:4: note: format output between 5 and 11 bytes into a
destination of size 10
sprintf (reloc_type_name, "0x%02x", rel->r_type);
r_type is an unsigned short.  Again seems to assume full range of unsigned int.

bfd/coff-rs6000.c:1659:23: error: '%ld' directive writing between 1 and 20
bytes into a region of size 12 [-Werror=format-length=]
   sprintf (hdr.size, "%ld", (long) (4 + orl_count * 4 + stridx));
Another case where range info says the %ld value is at most 11 bytes.

[Bug libstdc++/77717] testsuite/21_strings/basic_string_view/operations/compare/char/1.cc makes undefined memcmp call

[ville at gcc dot gnu.org]

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

--- Comment #2 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Sep 26 09:46:19 2016
New Revision: 240486

URL: https://gcc.gnu.org/viewcvs?rev=240486=gcc=rev
Log:
PR libstdc++/77717
* testsuite/21_strings/basic_string_view/operations/compare/char/1.cc:
Fix an out-of-bounds access.

Modified:
trunk/libstdc++-v3/ChangeLog
   
trunk/libstdc++-v3/testsuite/21_strings/basic_string_view/operations/compare/char/1.cc

[Bug c/7652] -Wswitch-break : Warn if a switch case falls through

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #61 from Marek Polacek  ---
The -Wimplicit-fallthrough patch has been committed.

[Bug libstdc++/65122] std::vector doesn't honor element alignment

[redi at gcc dot gnu.org]

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

--- Comment #23 from Jonathan Wakely  ---
I think it's supposed to be cover everything, but I'm not sure.

[Bug fortran/48298] [F03] User-Defined Derived-Type IO (DTIO)

[pault at gcc dot gnu.org]

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

--- Comment #25 from Paul Thomas  ---
Author: pault
Date: Mon Sep 26 11:15:23 2016
New Revision: 240493

URL: https://gcc.gnu.org/viewcvs?rev=240493=gcc=rev
Log:
2016-09-26  Paul Thomas  

PR fortran/48298
* interface.c (gfc_find_specific_dtio_proc) : Return NULL if
the derived type is broken, as indicated by a flavor other than
FL_DERIVED.


Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/interface.c

[Bug target/27077] [x86, 4.1] builtin strlen poor performance

[var at schellong dot biz]

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

Helmut Schellong  changed:

   What|Removed |Added

 CC||var at schellong dot biz

--- Comment #6 from Helmut Schellong  ---
gcc 6.2
...
builtin strlen: 137.787 ns
libcstrlen:  12.562 ns   (-fno-builtin-strlen)
About 12 times faster!
See table below.

The slow functions match in the use of string instructions.
E.g. libc: memcmp.S (assembler)
and so on.
Especially compare functions return early at most on the first .. third char!


memcmp/memcmp_F   38.198   2.707  [ns]  ta/tb =  14.11
Bem.:   abcd, AbcD, 2   Core2Duo/FreeBSD_10.1

memcmp/memcmp_F   42.712   4.211  [ns]  ta/tb =  10.14
Bem.:   abcd, abcD, 5   Core2Duo/FreeBSD_10.1

memcmp/memcmp_F   52.509   8.725  [ns]  ta/tb =   6.02
Bem.:   a-h, a-H, 9   Core2Duo/FreeBSD_10.1

memcmp/memcmp_F   27.335  18.058  [ns]  ta/tb =   1.51
Bem.:   a-z, a-Z, 27   Core2Duo/FreeBSD_10.1

memcmp/memcmp_F   47.842  33.706  [ns]  ta/tb =   1.42
Bem.:   a-z, a-Z, 53   Core2Duo/FreeBSD_10.1

memcmp/memcmp_F   67.691  71.879  [ns]  ta/tb =   0.94
Bem.:   a-z, a-Z, 105   Core2Duo/FreeBSD_10.1

memset/memset827.088   7.521  [ns]  ta/tb =   3.60 | 10
memset/memset858.958   8.421  [ns]  ta/tb =   7.00 | 20
memset/memset835.186   6.863  [ns]  ta/tb =   5.13 | 30
memset/memset858.961  10.830  [ns]  ta/tb =   5.44 | 50
memset/memset858.980  17.449  [ns]  ta/tb =   3.38 | 100
memset/memset839.655  24.378  [ns]  ta/tb =   1.63 | 256
memset/memset876.700  53.598  [ns]  ta/tb =   1.43 | 1000
memset/memset8   228.024 204.360  [ns]  ta/tb =   1.12 | 5000
memset/memset8   415.862 391.599  [ns]  ta/tb =   1.06 | 1
memset/memset8  5675.4805859.560  [ns]  ta/tb =   0.97 | 10

memset/memset8  5667.3705993.000  [ns]  ta/tb =   0.95
Bem.:   arr+3, 10   Core2Duo/FreeBSD_10.1

memcpy/memcpy8  50568.300   47217.600  [ns] ta/tb =   1.07
Bem.:   arr+3, arr+1, 10   Core2Duo/FreeBSD_10.1

memcpy/memcpy8  50603.000   8896.300  [ns]  ta/tb =   5.69
Bem.:   arr+3, arr+3, 10   Core2Duo/FreeBSD_10.1

memcpy/memcpy8  9231.9809028.020  [ns]  ta/tb =   1.02
Bem.:   arr+0, arr+0, 10   Core2Duo/FreeBSD_10.1

memcpy/memcpy815.343  17.753  [ns]  ta/tb =   0.86
Bem.:   arr+3, arr+1, 10   Core2Duo/FreeBSD_10.1

memcpy/memcpy842.720  27.385  [ns]  ta/tb =   1.56
Bem.:   arr+3, arr+1, 20   Core2Duo/FreeBSD_10.1

memcpy/memcpy825.781  37.901  [ns]  ta/tb =   0.68
Bem.:   arr+3, arr+1, 50   Core2Duo/FreeBSD_10.1

memcpy/memcpy878.229  64.093  [ns]  ta/tb =   1.22
Bem.:   arr+3, arr+1, 100   Core2Duo/FreeBSD_10.1

memcpy/memcpy875.217  18.964  [ns]  ta/tb =   3.97
Bem.:   arr+3, arr+3, 100   Core2Duo/FreeBSD_10.1

memcmp/memcmp837.584   3.309  [ns]  ta/tb =  11.36
Bem.:   arr+0, arr+0, 2   Core2Duo/FreeBSD_10.1

memcmp/memcmp842.121   5.506  [ns]  ta/tb =   7.65
Bem.:   arr+0, arr+0, 5   Core2Duo/FreeBSD_10.1

memcmp/memcmp843.927   7.518  [ns]  ta/tb =   5.84
Bem.:   arr+0, arr+0, 27   Core2Duo/FreeBSD_10.1

memcmp/memcmp849.618  11.421  [ns]  ta/tb =   4.34
Bem.:   arr+0, arr+0, 53   Core2Duo/FreeBSD_10.1

memcmp/memcmp867.068  20.441  [ns]  ta/tb =   3.28
Bem.:   arr+0, arr+0, 105   Core2Duo/FreeBSD_10.1

memcmp/memcmp867.700  25.281  [ns]  ta/tb =   2.68
Bem.:   arr+3, arr+0, 105   Core2Duo/FreeBSD_10.1

memcmp/memcmp871.608  25.272  [ns]  ta/tb =   2.83
Bem.:   arr+3, arr+1, 105   Core2Duo/FreeBSD_10.1

memcmp/memcmp8  15088.468   10363.376  [ns] ta/tb =   1.46
Bem.:   arr+0, arr+0, 12   Core2Duo/FreeBSD_10.1

memcmp/memcmp8  151610.600  104768.150  [ns]ta/tb =   1.45
Bem.:   arr+0, arr+0, 102   Core2Duo/FreeBSD_10.1

memcmp/memcmp8  13964.650   10280.200  [ns] ta/tb =   1.36
Bem.:   arr+0, arr+0, 12   Core2Duo/FreeBSD_10.1

strlen/strlen_F 11648.990   38192.520  [ns] ta/tb =   0.31
Bem.:   string 10   Core2Duo/FreeBSD_10.1

strlen/strlen_F  137.787  46.930  [ns]  ta/tb =   2.94
Bem.:   string 100; builtin rep scasb   Core2Duo/FreeBSD_10.1

strlen/strlen_F   12.562  43.338  [ns]  ta/tb =   0.29
Bem.:   string 100   Core2Duo/FreeBSD_10.1

strlen/strlen_F5.323  12.635  [ns]  ta/tb =   0.42

[Bug target/77686] [6/7 Regression] wrong code on arm-linux-gnueabi and arm-linux-gnueabihf

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Biener  ---
(In reply to ktkachov from comment #7)
> As snippet of the assembly output without scheduling (-fno-schedule-insns2):
> .LEHE0:
>   add r3, sp, #32
>   str r5, [sp, #32] < I1
>   add ip, sp, #8
>   str r5, [sp, #36] < I2
>   add r4, sp, #16
>   ldm r3, {r0, r1}  <-I3
>   add lr, sp, #4
>   str r5, [sp, #16]
>   mov r2, #3
>   str lr, [sp, #20]
>   movwr5, #:lower16:
>   stm ip, {r0, r1}
>   movtr5, #:upper16:
>   ldm r4, {r0, r1}
>   movwlr, #:lower16:
>   str r5, [sp, #40]
> 
> 
> The same region with scheduling:
> .LEHE0:
>   add r3, sp, #32
>   add ip, sp, #8
>   add r4, sp, #16
>   ldm r3, {r0, r1} <-- I3
>   add lr, sp, #4
>   str r5, [sp, #16]
>   mov r2, #3
>   str lr, [sp, #20]
>   movwlr, #:lower16:
>   stm ip, {r0, r1}
>   movtlr, #:upper16:
>   ldm r4, {r0, r1}
>   str r5, [sp, #32] <-- I1
>   str r5, [sp, #36] <-- I2
> 
> The stores I1 and I2 were moved past the load I3 that loads from SP + 32
> If I manually move those two stores back before I3 the program doesn't abort

which function is the above in?  Also can you please attach preprocessed
source?

[Bug c++/77742] Warning about placement new for over-aligned type

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
As placement new has no control over the memory alignment the warning looks
useless to me.  In this particular case we even know statically the memory is
well-aligned.

[Bug testsuite/77713] gcc.dg/tree-ssa/builtin-sprintf.c compilation failed to produce executable

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from Thomas Preud'homme  ---
Test now builds but execution shows a few FAIL:

FAIL: test_d_i:266: "%hhi" expected result for "-16657" doesn't match function
call return value: 6 not in [1, 4]
FAIL: test_d_i:267: "%hhu" expected result for "48879" doesn't match function
call return value: 5 not in [1, 3]

FAIL: test_x:314: "%2hhx" expected result for "dead" doesn't match function
call return value: 4 != 2
FAIL: test_x:315: "%02hhx" expected result for "dead" doesn't match function
call return value: 4 != 2
FAIL: test_x:316: "%#05hhx" expected result for "0xdead" doesn't match function
call return value: 6 != 5
FAIL: test_x:318: "%2hhx" expected result for "beef" doesn't match function
call return value: 4 != 2
FAIL: test_x:319: "%02hhx" expected result for "beef" doesn't match function
call return value: 4 != 2
FAIL: test_x:320: "%#05hhx" expected result for "0xbeef" doesn't match function
call return value: 6 != 5

FAIL: test_a_double:364: "%a" expected result for "a" doesn't match function
call return value: 1 != 6
FAIL: test_a_double:365: "%a" expected result for "a" doesn't match function
call return value: 1 != 6
FAIL: test_a_double:366: "%a" expected result for "a" doesn't match function
call return value: 1 != 6
FAIL: test_a_double:368: "%.1a" expected result for "a" doesn't match function
call return value: 1 != 8
FAIL: test_a_double:369: "%.2a" expected result for "a" doesn't match function
call return value: 1 != 9

FAIL: test_a_long_double:375: "%La" expected result for "a" doesn't match
function call return value: 1 != 6
FAIL: test_a_long_double:376: "%La" expected result for "a" doesn't match
function call return value: 1 != 6
FAIL: test_a_long_double:377: "%La" expected result for "a" doesn't match
function call return value: 1 != 6
FAIL: test_a_long_double:379: "%.1La" expected result for "a" doesn't match
function call return value: 1 != 8
FAIL: test_a_long_double:380: "%.2La" expected result for "a" doesn't match
function call return value: 1 != 9

Do you want me to open a separate ticket for that?

Best regards.

[Bug libstdc++/77717] testsuite/21_strings/basic_string_view/operations/compare/char/1.cc makes undefined memcmp call

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #3 from Ville Voutilainen  ---
Fixed.

[Bug rtl-optimization/77714] [7 Regression] Wrong code generation for gcc.c-torture/execute/pr51447.c

[edlinger at gcc dot gnu.org]

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

--- Comment #5 from Bernd Edlinger  ---
(In reply to Thomas Preud'homme from comment #4)
> Hi Bernd & Peter,
> 
> Yes the code is still failing on today's trunk. I tested both patch you
> propose Bernd and both seems to work. Thanks a lot for such a quick fix!

OK, thanks for the confirmation.

The problem with the first patch is, that the offset from HFP to SFP
may change in a later iteration, but if I change the destination
register in the first iteration that instruction wont be fixed up
again.  However, there are no test cases where that happens.

The second patch is correct in itself.

But because src != dst register, the chosen thumb1 instruction
is less efficient as it was before r240065.

In the moment I would think that is no big problem, as it only
affects non-local jumps.

[Bug gcov-profile/23332] FIXME in tree-profile.c: tree_gen_const_delta_profiler not implemented

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed on trunk.

[Bug gcov-profile/23332] FIXME in tree-profile.c: tree_gen_const_delta_profiler not implemented

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Mon Sep 26 11:04:18 2016
New Revision: 240492

URL: https://gcc.gnu.org/viewcvs?rev=240492=gcc=rev
Log:
Remove HIST_TYPE_CONST_DELTA counter type (PR gcov-profile/23332)

PR gcov-profile/23332
* profile.c (instrument_values): Do not handle
HIST_TYPE_CONST_DELTA.
* tree-profile.c (gimple_gen_const_delta_profiler):
Remove.
* value-prof.c (dump_histogram_value): Do not handle
HIST_TYPE_CONST_DELTA.
(stream_in_histogram_value): Likewise.
(gimple_find_values_to_profile): Likewise.
* value-prof.h (enum hist_type): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/profile.c
trunk/gcc/tree-profile.c
trunk/gcc/value-prof.c
trunk/gcc/value-prof.h

[Bug target/77686] [6/7 Regression] wrong code on arm-linux-gnueabi and arm-linux-gnueabihf

[ktkachov at gcc dot gnu.org]

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

--- Comment #9 from ktkachov at gcc dot gnu.org ---
Created attachment 39688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39688=edit
Preprocessed source

Attaching the preprocessed source.
The function in question is:
_ZN1C4doCbEv

This is compiled with -std=gnu++14 -O2  -march=armv7-a  -mfpu=vfpv3-d16
-mfloat-abi=hard

[Bug libstdc++/77744] Data race on std::regex_iterator using openmp

[morandidodo at gmail dot com]

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

--- Comment #2 from morandidodo at gmail dot com ---
(In reply to Jakub Jelinek from comment #1)
> If the C++ standards allows these to be used without locking, then it is
> likely a bug in libstdc++, not libgomp.

Sorry, my fault ;)

[Bug libstdc++/77537] [6 Regression] pair constructors do not properly SFINAE

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||5.4.0
   Target Milestone|--- |6.3
Summary|pair constructors do not|[6 Regression] pair
   |properly SFINAE |constructors do not
   ||properly SFINAE
  Known to fail||6.2.0

--- Comment #8 from Jonathan Wakely  ---
With 5.4 only one of assertions failed:

pair.cc:11:1: error: static assertion failed: FAIL
 static_assert(!std::is_constructible::value,
"FAIL");
 ^

So I'm marking this as a regression.

[Bug libstdc++/77744] Data race on std::regex_iterator using openmp

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Component|libgomp |libstdc++

--- Comment #1 from Jakub Jelinek  ---
If the C++ standards allows these to be used without locking, then it is likely
a bug in libstdc++, not libgomp.

[Bug c++/77739] [5/6/7 Regression] internal compiler error: in create_tmp_var, at gimple-expr.c:524

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
   Target Milestone|--- |5.5
Summary|internal compiler error: in |[5/6/7 Regression] internal
   |create_tmp_var, at  |compiler error: in
   |gimple-expr.c:524   |create_tmp_var, at
   ||gimple-expr.c:524

--- Comment #2 from Jakub Jelinek  ---
Started with r202605.

[Bug debug/77692] [7 regression] gcc.dg/debug/dwarf2/const-2b.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||seurer at linux dot 
vnet.ibm.com

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

[Bug lto/77716] [7 regression] test case gcc.dg/debug/dwarf2/const-2.c fails starting with r240228

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
It is the same issue.

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

[Bug sanitizer/69539] ICE in expand_UBSAN_NULL, at internal-fn.c:202

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Seems to be related to PR69254, either we should force in some flag_sanitize
flag whenever we stream in IFN_UBSAN_* builtins (perhaps depending on which
option that was), or throw away the IFN_UBSAN_* calls if corresponding
flag_sanitize isn't enabled at LTO time.

[Bug target/69833] Warning during bootstrap of --with-build-config=bootstrap-asan

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Liška  ---
Can't reproduce that any longer, closing as invalid.

[Bug gcov-profile/68080] gcov returns negative counts

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
OK, couple weeks ago, I added new option -fprofile-update=atomic which prevents
profile corruption. Warning about not joining threads is mentioned in
documentation, I'm closing the PR as fixed.

[Bug gcov-profile/42015] gcov reports incorrect branches executed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Martin Liška  ---
Ok, after code inspection, I came to observation that the output is correct.
Let's assume following example:

$ cat pr42015.c.gcov
-:0:Source:pr42015.c
-:0:Graph:pr42015.gcno
-:0:Data:pr42015.gcda
-:0:Runs:1
-:0:Programs:1
-:1:#include 
-:2:
1:3:int main (void)
-:4:{
-:5:  int i, total;
-:6:
1:7:  total = 0;
-:8:
   11:9:  for (i = 0; i < 10; i++)
   10:   10:total += i;
-:   11:
1:   12:  if (total != )
1:   13:return 0;
-:   14:
#:   15:  if (total != 45)
#:   16:printf ("Failure\n");
-:   17:  else
#:   18:printf ("Success\n");
#:   19:  return 0;
-:   20:}

$ gcov pr42015.c -b
File 'pr42015.c'
Lines executed:60.00% of 10
Branches executed:66.67% of 6
Taken at least once:50.00% of 6
Calls executed:0.00% of 2
Creating 'pr42015.c.gcov'

'Branches executed' means a number of branches whose condition was at least
once evaluated (and obviously one branch is taken).
Thus, as the condition on line 15 is never executed we have 2 branches that
were not executed. On the other hand, 'Taken at least once'
equal to 3 means execution of both branches of 'for' statement and 1 for 'if'
on the line 12.

Hope it's now clear, closing the PR as invalid.

[Bug gcov-profile/62267] disable fprofile-use at coverage-mismatch

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
I've just talked to Honza, who's been building libreoffice with PGO and he
can't see profile mismatch. Is it still issue? If so, I can probably take a
look at a new option for that.

[Bug gcov-profile/62267] disable fprofile-use at coverage-mismatch

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-09-26
 Ever confirmed|0   |1

[Bug libgomp/77744] New: Data race on std::regex_iterator using openmp

[morandidodo at gmail dot com]

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

Bug ID: 77744
   Summary: Data race on std::regex_iterator using openmp
   Product: gcc
   Version: 6.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: morandidodo at gmail dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 39687
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39687=edit
Output of the test program with thread sanitizer

Here this simple piece of code:

#include 
#include 

int main()
{
const std::string test = "this is a test";
const std::regex reTest("[ths]");

auto f = [, ]()
{
std::sregex_iterator iter(std::begin(test), std::end(test), reTest);
};

#pragma omp parallel for
for(unsigned i = 0; i < 10; ++i)
f();
}

If run with thread sanitizer, it will warn about some data races (see
attachment).

A similar example using std::threads...

#include 
#include 
#include 

int main()
{
const std::string test = "this is a test";
const std::regex reTest("[ths]");

std::vector threads;

auto f = [, ]()
{
std::sregex_iterator iter(std::begin(test), std::end(test), reTest);
};

for(unsigned i = 0; i < 10; ++i)
threads.emplace_back(f);

for(std::thread& curThread : threads)
curThread.join();
}

...will not trigger any data race.

[Bug libstdc++/77744] Data race on std::regex_iterator using openmp

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
The std::thread example is similar, but not the same. The OpenMP version shares
f, so is equivalent to creating the std::thread objects with std::ref(f).

More importantly, the OpenMP version does not wait for the loop to finish (or
at least, I see "#pragma omp for nowait" in the GIMPLE dump), so there is no
happens-before relation between the loop body and the reTest destructor.

I see the same races using:

for(unsigned i = 0; i < 10; ++i)
std::thread{std::ref(f)}.detach();

[Bug middle-end/77718] [7 Regression] expand_builtin_memcmp swaps args

[bernds at gcc dot gnu.org]

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

--- Comment #2 from Bernd Schmidt  ---
Over here the testcase seems not to arrive in this function, and it prints the
same value (-5) twice, which I think is supposed to be expected?

Please clarify.

[Bug libstdc++/77744] Data race on std::regex_iterator using openmp

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
This shows the same race, without any library components:

struct regex {
  struct regex_impl { int i; int size() const { return i; } };
  regex_impl* p;
  regex() : p(new regex_impl{42}) { }
  ~regex() { delete p; }
  int size() const { return p->size(); }
  void f(int) const { }
};

struct regex_iterator {
  regex_iterator(const regex& re) { for (int i = 0; i < re.size(); ++i)
re.f(i); }
};

int main()
{
const regex reTest;

auto f = []()
{
regex_iterator iter(reTest);
};

#pragma omp parallel for
for(unsigned i = 0; i < 10; ++i)
f();
}

[Bug libstdc++/77744] Data race on std::regex_iterator using openmp

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Pedantically this isn't valid, because you are mixing C++11 features (lambdas)
with OpenMP, which doesn't support C++11 even in 4.5, so it is all unspecified
behavior.

Also, have you built libgomp with -fsanitize=thread after configuring it with
--disable-linux-futex (otherwise libtsan doesn't understand the barriers etc.
in libgomp)?

[Bug libstdc++/77744] Data race on std::regex_iterator using openmp

[morandidodo at gmail dot com]

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

--- Comment #6 from morandidodo at gmail dot com ---
(In reply to Jakub Jelinek from comment #5)
> Pedantically this isn't valid, because you are mixing C++11 features
> (lambdas) with OpenMP, which doesn't support C++11 even in 4.5, so it is all
> unspecified behavior.
> 
> Also, have you built libgomp with -fsanitize=thread after configuring it
> with --disable-linux-futex (otherwise libtsan doesn't understand the
> barriers etc. in libgomp)?

I was not aware of possible issues between OpenMP and C++11/14 lambda features.
However, in this case, the content of f can be inlined inside the loop, and the
result is the same.

Furthermore, you can try to construct other kind of object, but I am only
getting this data race when using std::regex_iterator (however the empty
constructor works fine).

If you try with other "simpler" objects that allocates memory on the heap (just
a simple std::vector(10, "test") ), the data race is not
triggered.

[Bug c++/77742] New: Warning about placement new for over-aligned type

[redi at gcc dot gnu.org]

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

Bug ID: 77742
   Summary: Warning about placement new for over-aligned type
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

#include 

struct X
{
  alignas(2*__STDCPP_DEFAULT_NEW_ALIGNMENT__) int i;
};

int main()
{
  alignas(alignof(X)) char buf[sizeof(X)];
  ::new((void*)buf) X{1};
}


al.cc: In function ‘int main()’:
al.cc:11:24: warning: ‘new’ of type ‘X’ with extended alignment 32
[-Waligned-new=]
   ::new((void*)buf) X{1};
^
al.cc:11:24: note: uses ‘void* operator new(std::size_t, void*)’, which does
not have an alignment parameter
al.cc:11:24: note: use ‘-faligned-new’ to enable C++17 over-aligned new support
tmp$ g++17 al.cc -faligned-new
al.cc: In function ‘int main()’:
al.cc:11:24: warning: ‘new’ of type ‘X’ with extended alignment 32
[-Waligned-new=]
   ::new((void*)buf) X{1};
^
al.cc:11:24: note: uses ‘void* operator new(std::size_t, void*)’, which does
not have an alignment parameter
al.cc:11:24: note: use ‘-faligned-new’ to enable C++17 over-aligned new support


Should this warning only be given for the non-placement forms of operator new?
That means trusting the programmer to have obtained suitably-aligned memory,
but that's always the case even for types with a fundamental alignment.

The code won't even compile without either -faligned-new or C++17, so the final
note is not helpful.

Also, if the new-expression occurs in a system header then you still get all
the notes but not the warning (unless you use -Wsystem-headers).

[Bug rtl-optimization/77714] [7 Regression] Wrong code generation for gcc.c-torture/execute/pr51447.c

[thopre01 at gcc dot gnu.org]

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

--- Comment #4 from Thomas Preud'homme  ---
Hi Bernd & Peter,

Yes the code is still failing on today's trunk. I tested both patch you propose
Bernd and both seems to work. Thanks a lot for such a quick fix!

[Bug libstdc++/65122] std::vector doesn't honor element alignment

[glisse at gcc dot gnu.org]

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

--- Comment #22 from Marc Glisse  ---
(In reply to Jonathan Wakely from comment #20)
> In C++17 std::allocator no longer says "It is implementation-defined whether
> over-aligned types are supported" and is no longer required to call operator
> new(size_t), it is supposed to use the over-aligned form as appropriate.

Ah, I had missed those last few lines of p0035r4 (they were not in r2). That's
great news! I remember discussions and polls about the fact that the proposal
wasn't handling the library part, is there still anything missing (postponed?)
or did the last couple revisions add everything?

[Bug tree-optimization/77745] [5/6/7 Regression] Inconsistent application of aliasing rules

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||4.5.0
   Target Milestone|--- |5.5
Summary|Inconsistent application of |[5/6/7 Regression]
   |aliasing rules  |Inconsistent application of
   ||aliasing rules
  Known to fail||5.4.0, 7.0

--- Comment #5 from Andrew Pinski  ---
You know what you are right this is wrong code.

Note I am surprised we don't emit clobber barriers before operator new anyways
to say the life time of an object just started.  This will most likely solve
the issue overall.

[Bug rtl-optimization/77714] [7 Regression] Wrong code generation for gcc.c-torture/execute/pr51447.c

[edlinger at gcc dot gnu.org]

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

--- Comment #6 from Bernd Edlinger  ---
Author: edlinger
Date: Tue Sep 27 04:54:49 2016
New Revision: 240518

URL: https://gcc.gnu.org/viewcvs?rev=240518=gcc=rev
Log:
2016-09-27  Bernd Edlinger  

PR rlt-optimization/77714
* lra-eliminations.c (eliminate_regs_in_insn): Avoid alias on
REG_EQUAL note.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lra-eliminations.c

[Bug tree-optimization/77677] [7 Regression] ICE at -O1 and above in both 32-bit and 64-bit modes on x86_64-linux-gnu (internal compiler error: in set_value_range, at tree-vrp.c:361)

[kugan at gcc dot gnu.org]

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

--- Comment #11 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Tue Sep 27 03:41:14 2016
New Revision: 240517

URL: https://gcc.gnu.org/viewcvs?rev=240517=gcc=rev
Log:
Fix ipa-vrp convert value_range

gcc/ChangeLog:

2016-09-27  Kugan Vivekanandarajah  

PR ipa/77677
* ipa-prop.c (ipa_compute_jump_functions_for_edge): Use
extract_range_from_unary_expr to convert value_range.
* tree-vrp.c (extract_range_from_unary_expr_1): Rename to.
(extract_range_from_unary_expr): This.
* tree-vrp.h (extract_range_from_unary_expr): Declare.

gcc/testsuite/ChangeLog:

2016-09-27  Kugan Vivekanandarajah  

PR ipa/77677
* gcc.dg/torture/pr77677-2.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/torture/pr77677-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c
trunk/gcc/tree-vrp.h

[Bug tree-optimization/77745] Inconsistent application of aliasing rules

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-27
 Ever confirmed|0   |1

--- Comment #4 from Markus Trippelsdorf  ---
gcc generates code as if the function was defined as:

long foo(char *__restrict__ c1, char *__restrict__ c2)

[Bug target/77730] Fortran performance on aarch64 (6/7 regression heads-up)

[tulipawn at gmail dot com]

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

--- Comment #6 from PeteVine  ---
There's definitely a problem with mcpu/mtune in GCC6 to the point I wasn't able
to get the expected performance back, please look here:

http://openbenchmarking.org/result/1609269-LO-GCRYPTAAR21

BTW, that benchmark required lots of hacking/patching to run on aarch64. Won't
work OOTB.

[Bug c++/77747] GCC allows inheriting constructors from indirect base

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-09-26
 Ever confirmed|0   |1

[Bug rtl-optimization/77416] [7 Regression] LRA rematerializing use of CA reg across function call

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
The testcase also fails for -m64 for me (on BE).  I have -m64 explicitly
in the RUNTESTFLAGS.  The testcase has

/* { dg-skip-if "do not override -mcpu" { powerpc64*-*-* } { "-mcpu=*" } {
"-mcpu=power7" } } */
/* { dg-options "-mcpu=power7 -O2 -m32" } */

but it doesn't check for overriding -m32 (the RUNTESTFLAGS are inserted
later on the command line than the dg-options).