[Bug rtl-optimization/70703] [6 regression] Regression in register usage on x86

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 regression] Regression |[6 regression] Regression
   |in register usage on x86|in register usage on x86

--- Comment #14 from Jakub Jelinek  ---
Fixed on the trunk, not sure about backports if it is desirable or not.
Thanks Vlad!

[Bug target/80327] _mm512_abs_ps intrinsic missing

[m...@sven-woop.de]

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

--- Comment #1 from Sven Woop  ---
This intrinsic is documented here:

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm512_abs_ps=AVX_512=41

This is supported by latest ICC and Clang.

[Bug target/80326] _mm512_trunc_ps intrinsic missing

[m...@sven-woop.de]

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

--- Comment #1 from Sven Woop  ---
Ok that one is in the SVML and only supported by ICC, not by Clang:

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=SVML=_mm512_trunc_ps

There seem to be no SVML for GCC, thus please close this issue.

[Bug target/80325] _mm512_undefined intrinsic missing

[m...@sven-woop.de]

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

--- Comment #2 from Sven Woop  ---
For AVX512 the Intel Intrinsics guide also mentioned the _mm512_undefined as
alias for _mm512_undefined_ps.

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm512_undefined=AVX_512

ICC and Clang support _mm512_undefined.

[Bug target/80324] _mm512_reduce_xxx type instrinsics are missing

[m...@sven-woop.de]

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

--- Comment #1 from Sven Woop  ---
These intrinsics are supported by latest ICC and Clang.

Documentation of these can be found here:

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=reduce=AVX_512

Likely many other reduce intrinsics that show up in the Intrinsics Guide are
missing in GCC too.

[Bug target/80323] _mm512_int2mask and _mm512_mask2int intrinsics are missing

[m...@sven-woop.de]

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

--- Comment #1 from Sven Woop  ---
Documentation of these can be found here:

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mm512_int2mask

These are supported by the latest ICC and Clang.

[Bug tree-optimization/80304] [7 Regression] Wrong result with do concurrent

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Priority|P4  |P3
  Component|fortran |tree-optimization

--- Comment #16 from Thomas Koenig  ---
Not a Fortran bug, then.

[Bug c++/71174] [concepts] Segmentation fault while processing concepts error

[wmx16835 at 126 dot com]

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

wmx16835 at 126 dot com changed:

   What|Removed |Added

 CC||wmx16835 at 126 dot com

--- Comment #4 from wmx16835 at 126 dot com ---
Here's another simple demo triggers the bug:

template 
concept bool A = requires(T t) {
  { t } -> A;
};

template 
void foo() requires A {}

int main() {
  foo();
}

[Bug libstdc++/80335] New: perf of copying std::optional

[glisse at gcc dot gnu.org]

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

Bug ID: 80335
   Summary: perf of copying std::optional
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

I was surprised recently, while profiling some application, to see
boost::optional::assign relatively high (about 4%, while I am only using it in
a single place). After checking, it seems that std::optional in libstdc++ has
the same issue. The point is, copy-assigning an optional involves 2
conditions (is lhs initialized, is rhs initialized) while a brutal
memcpy/memmove would be perfectly safe for a trivial type like int (sanitizers
and valgrind might occasionally complain about reading uninitialized memory
though).

#include 
typedef std::optional O;
void f1(O, O const){ a=b; }
void f2(O, O const){ __builtin_memmove(,,sizeof(O)); }

yields

cmpb$0, 4(%rdi)
movzbl  4(%rsi), %eax
je  .L2
testb   %al, %al
jne .L8
movb$0, 4(%rdi)
ret
.p2align 4,,10
.p2align 3
.L2:
testb   %al, %al
je  .L9
movl(%rsi), %eax
movb$1, 4(%rdi)
movl%eax, (%rdi)
ret
.p2align 4,,10
.p2align 3
.L9:
ret
.p2align 4,,10
.p2align 3
.L8:
movl(%rsi), %eax
movl%eax, (%rdi)
ret

vs

movq(%rsi), %rax
movq%rax, (%rdi)
ret

I am wondering under what conditions we could implement copying this way:
- type small enough: don't want an expensive copy for an empty optional
- type "trivial": no need to run the destructor, copy assignment, etc
- not using a sanitizer, not going to use valgrind: that cannot really be
tested...

[Bug c++/80334] New: Segfault when taking address of copy of unaligned struct

[jagerman at jagerman dot com]

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

Bug ID: 80334
   Summary: Segfault when taking address of copy of unaligned
struct
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jagerman at jagerman dot com
  Target Milestone: ---

I am getting a segfault with g++ 7 when trying to copy an unaligned struct into
an aligned variable when the struct contains a member with alignment greater
than 8 (on my amd64 architecture).

I boiled my code down into the following simplified program which exhibits the
segfault under a recent g++ 7 snapshot (requires compiling with -O2 or above to
trigger):

test.cpp
=
#include 

struct A { alignas(16) char c; };
struct B { A unpacked; char d; } __attribute__((packed));

int main() {
std::cout << "sizeof(A) = " << sizeof(A) << ", sizeof(B) = " << sizeof(B)
<< "\n";
alignas(16) B b[3];

for (int i = 0; i < 3; i++) b[i].unpacked.c = 'a' + i;

for (int i = 0; i < 3; i++) {
std::cout << "i=" << i << "; copying..." << std::endl;
auto a = new A(b[i].unpacked);
std::cout << "copied value = " << a->c << std::endl;
}
}
=



If I change the `alignas(16)` on the member in `struct A` to `alignas(8)` or
`alignas(4)` there is no segfault; there also is no segfault under -O0 or -O1,
or under g++ 6.

(The `alignas(16) char` was a `long double` in the original code, which has
alignof == 16).

The alignas(16) on the array in main is just there to force alignment on the
first element of `b`: with that alignment, the *first* copy succeeds because
the `unpacked` member happens to be correctly aligned; the call in the second
iteration of the loop (when the member isn't aligned) triggers the segfault.

[Bug fortran/80304] [7 Regression] Wrong result with do concurrent

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||edlinger at gcc dot gnu.org

--- Comment #15 from Thomas Koenig  ---
Also fails on powerpc64-unknown-linux-gnu.

r239317 works, r239326 fails, and also appears to be the only
patch in the vicinity that does anything about loops.

Could this be the cause?

Author: edlinger
Date: Fri Aug 12 19:30:39 2016
New Revision: 239426

URL: https://gcc.gnu.org/viewcvs?rev=239426=gcc=rev
Log:
2016-08-12  Bernd Edlinger  

PR tree-optimization/71083
* tree-predcom.c (ref_at_iteration): Use a COMPONENT_REF for the
bitfield access when possible.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-predcom.c

[Bug rtl-optimization/70478] [LRA] S/390: Performance regression - superfluous stack frame

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
(In reply to Andreas Krebbel from comment #6)
> The only solution we found caused other regressions.

I'll try to change the sensitive LRA code to solve it.  It will need to test a
few targets.  So, if everything is ok, the patch will be probably ready at the
end of the week or on the next week.

[Bug c++/70413] Class template names in anonymous namespaces are not globally unique

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-05
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.2.0, 7.0

--- Comment #2 from Markus Trippelsdorf  ---
Confirmed.

The problem is that _Z12invoke_printIN12_GLOBAL__N_11sEEvv is wrongly marked as
comdat.

[Bug fortran/80304] [7 Regression] Wrong result with do concurrent

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #14 from Harald Anlauf  ---
Further reduction:

module test_mod
  implicit none
contains
  pure real function add(i)
integer ,intent(in) :: i
add = i
  end function

  pure real function add2(i,j)
integer ,intent(in) :: i,j
add2 = i+j
  end function
end module test_mod

program test 
  use test_mod
  implicit none
  integer :: i ,j
  real:: a(0:1,0:1) ,b(0:1,0:1)
  call sub ()
  call sub ()
  call sub ()
contains
  subroutine sub ()
a = 0.
b = 0.
DO CONCURRENT( i=0:1 ,j=0:1)
   a(i,j) = add(i)
   b(i,j) = add2(i,j)
END DO
print*,sum(a),sum(b)
  end subroutine sub
end program test

On i686-pc-linux-gnu:

% gfc-trunk -O1 -finline pr80304b.f90 && ./a.out
   2.   4.
   2.   4.
   2.   4.
% gfc-trunk -O1 -fno-inline pr80304b.f90 && ./a.out
  -4.86805248E+09  -4.86805248E+09
  -4.86805248E+09  -4.86805248E+09
  -4.86805248E+09  -4.86805248E+09
% gfc-trunk -O2 -fno-inline pr80304b.f90 && ./a.out
  -4.86695731E+09  -4.86695731E+09
  -3.25031117E+09  -3.25031117E+09
  -3.27110272E+09  -3.27110272E+09
% gfc-trunk -O3 -fno-inline pr80304b.f90 && ./a.out
   2.   4.
   2.   4.
   2.   4.

[Bug c++/70413] Class template names in anonymous namespaces are not globally unique

[ethortsen at itg dot com]

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

ethortsen at itg dot com changed:

   What|Removed |Added

 CC||ethortsen at itg dot com

--- Comment #1 from ethortsen at itg dot com ---
Bumping this.

We ran into a similar issue in GCC 6.3.0 on x86_64.

We've ran the example provided by Fabian under GCC 6.3.0 on x86_64 and see the
same unexpected result.

[Bug c++/80309] [7 Regression] ICE: canonical types differ for identical types _Args2 and _Args2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/80309] [7 Regression] ICE: canonical types differ for identical types _Args2 and _Args2

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr  5 19:10:17 2017
New Revision: 246717

URL: https://gcc.gnu.org/viewcvs?rev=246717=gcc=rev
Log:
PR c++/80309
* pt.c (canonical_type_parameter): Use vec_safe_grow_cleared instead
of a loop doing vec_safe_push of NULL.  Formatting fixes.
(rewrite_template_parm): Copy TEMPLATE_PARM_PARAMETER_PACK from oldidx
to newidx before calling canonical_type_parameter on newtype.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/80244] [6/7 Regression] ICE with attribute in template alias

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/80178] Class with deleted copy and move constructors uses wrong argument passing ABI

[jason at gcc dot gnu.org]

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

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

Here's a fix.  I'm nervous about applying it at this point in GCC 7, though.

[Bug c++/80332] Warning is issued for deprecated "using" type alias of deprecated type

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-05
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||5.3.0, 6.3.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  Same with C++ attribute [[deprecated].

[Bug c++/78104] optimizer doesn't grok C++ new/delete yet

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

[Bug libstdc++/80331] unused const std::string not optimized away

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #5 from Markus Trippelsdorf  ---
Lets close as dup.

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

[Bug c++/78104] optimizer doesn't grok C++ new/delete yet

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||hiraditya at msn dot com

--- Comment #5 from Markus Trippelsdorf  ---
*** Bug 80331 has been marked as a duplicate of this bug. ***

[Bug fortran/80333] New: Namelist dtio write of array of class does not traverse the array

[jvdelisle at gcc dot gnu.org]

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

Bug ID: 80333
   Summary: Namelist dtio write of array of class does not
traverse the array
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jvdelisle at gcc dot gnu.org
  Target Milestone: ---

The following test case shows the wrong behavior. I am pretty sure this is
frontend related. Notice that derived types work OK, but class does not.  This
is because the array specification for an array of class is stored differently
and needs to be  pulled out in trans_io.c (transfer_namelist_element). I have
found the array spec in the component structure, but am not certain how to
handle it.

module m
  implicit none
  type :: t
character :: c
  contains
procedure :: read_formatted
generic :: read(formatted) => read_formatted
procedure :: write_formatted
generic :: write(formatted) => write_formatted
  end type t
contains
  subroutine read_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
class(t), intent(inout) :: dtv
integer, intent(in) :: unit
character(*), intent(in) :: iotype
integer, intent(in) :: v_list(:)
integer, intent(out) :: iostat
character(*), intent(inout) :: iomsg
read(unit,'(a1)', iostat=iostat, iomsg=iomsg) dtv%c
  end subroutine read_formatted

  subroutine write_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
class(t), intent(in) :: dtv
integer, intent(in) :: unit
character(*), intent(in) :: iotype
integer, intent(in) :: v_list(:)
integer, intent(out) :: iostat
character(*), intent(inout) :: iomsg
write(unit,'(a1)', iostat=iostat, iomsg=iomsg) dtv%c
  end subroutine write_formatted
end module m

program p
  use m
  implicit none
  class(t), dimension(:), allocatable :: w
  type(t), dimension(:), allocatable :: x
  namelist /nml/  w, x
  integer :: unit, iostatus

  allocate(w(10), x(10))
  w = t('j')
  w(5:7)%c='k'
  x = t('p')
  x(4:8)%c='s'
  print *, w
  print *, x
  write(*, nml)
end program p

$ ./a.out 
 j j j j k k k j j j
 p p p s s s s s p p

 W=j
 X=pppspp
 /

[Bug libstdc++/80331] unused const std::string not optimized away

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||23383

--- Comment #4 from Andrew Pinski  ---
23383


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23383
[Bug 23383] builtin array operator new is not marked with malloc attribute

[Bug tree-optimization/80318] GCC takes too much RAM and time compiling a template file

[benjamin.redelings at gmail dot com]

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

--- Comment #2 from benjamin.redelings at gmail dot com ---
Created attachment 41137
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41137=edit
preprocessed source

[Bug libstdc++/80331] unused const std::string not optimized away

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
(In reply to Marc Glisse from comment #2)
> I didn't check if those are the only blockers in this case...

Looks like they are indeed the only blockers, since we optimize the below just
fine. So, known issue (which doesn't mean we shouldn't do something about it).
(with 2 dead strings instead of 1, we need -O3, -O2 is not sufficient)

#include 
#undef _GLIBCXX_EXTERN_TEMPLATE
#define _GLIBCXX_EXTERN_TEMPLATE 0
#include 
#include 
inline void operator delete(void*p){__builtin_free(p);}
inline void* operator new(size_t n){return __builtin_malloc(n);}
int main() {
  const std::string s("");
}

[Bug c++/80332] New: Warning is issued for deprecated "using" type alias of deprecated type

[freddie_chopin at op dot pl]

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

Bug ID: 80332
   Summary: Warning is issued for deprecated "using" type alias of
deprecated type
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: freddie_chopin at op dot pl
  Target Milestone: ---

There is a base type with "__attribute__ ((deprecated))". If I create an alias
with "typedef", which also has "__attribute__ ((deprecated))", no warning is
issued, which matches the official docs:

https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attributes

However if I create a C++11 type alias with "using" keyword, which also has
"__attribute__ ((deprecated))", then the warning is issued for the line with
type alias.

I would expect that it would work the same way as deprecated "typedef", so no
warning.

Code:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

typedef int Integer __attribute__ ((deprecated));
using Using __attribute__ ((deprecated)) = Integer;
typedef Integer Typedef __attribute__ ((deprecated));

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

Test:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ g++ -c depr.cpp 
depr.cpp:2:44: warning: ‘Integer’ is deprecated [-Wdeprecated-declarations]
 using Using __attribute__ ((deprecated)) = Integer;
^~~
depr.cpp:1:13: note: declared here
 typedef int Integer __attribute__ ((deprecated));
 ^~~

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

[Bug libstdc++/80331] unused const std::string not optimized away

[glisse at gcc dot gnu.org]

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

--- Comment #2 from Marc Glisse  ---
If you replace "a" with something longer (size>16 when counting the last '\0'),
it does reproduce. I'd say this is a dup of 2 known issues:
- the compiled part of libstdc++ prevents optimization (maybe eventually with
LTO?),
- gcc knows about malloc and free but not about new and delete.

I didn't check if those are the only blockers in this case...

[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Even gcc 3.2 ICEs on this.

[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
if ((int128_t) p >= -9223372036854775808 - (int128_t) (signed char) g)

That looks just wrong, I thought with -m32 we don't support int128_t, so there
should be no computations in that type, even when we have too large constant.

void bar (void);
void
foo (long long int p, long long int q)
{
  if (p >= 1234567891234567891234567891234567812 + q)
bar ();
}

Apparently we emit int128 arithmetics though, it works even with
-fsanitize=undefined, or with -fwrapv, but not -ftrapv.

[Bug libstdc++/80331] unused const std::string not optimized away

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
Cannot reproduce. Try a more recent snapshot?

[Bug libstdc++/80331] New: unused const std::string not optimized away

[hiraditya at msn dot com]

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

Bug ID: 80331
   Summary: unused const std::string not optimized away
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hiraditya at msn dot com
  Target Milestone: ---

$ cat t.cpp
#include
int sain() {
  const std::string s("a");
  return 0;
}

# gcc version 7.0.0 20170118 (experimental) (GCC)
$ g++ -S -o t.s t.cpp -O2 -fno-exceptions -std=c++11

$ cat t.s
.type   _Z4sainv, @function
_Z4sainv:
.LFB940:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl$.LC0+1, %esi
subq$32, %rsp
.cfi_def_cfa_offset 48
leaq16(%rsp), %rbx
movq%rsp, %rdi
movq%rbx, (%rsp)
call   
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEE12_M_constructIPKcEEvT_S8_St20forward_iterator_tag.isra.16.constprop.20
movq(%rsp), %rdi
cmpq%rbx, %rdi
je  .L13
call_ZdlPv
.L13:
addq$32, %rsp
.cfi_def_cfa_offset 16
xorl%eax, %eax
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE940:
.size   _Z4sainv, .-_Z4sainv


clang++, on the other hand, completely optimizes the const string.

.type   _Z4sainv,@function
_Z4sainv:   # @_Z4sainv
.cfi_startproc
# BB#0:
xorl%eax, %eax
retq
.Lfunc_end0:
.size   _Z4sainv, .Lfunc_end0-_Z4sainv

[Bug middle-end/77486] ubsan detects runtime error: left shift of negative value -3 at real_hash in real.c:2890

[zeccav at gmail dot com]

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

--- Comment #7 from Vittorio Zecca  ---
(In reply to Jakub Jelinek from comment #5)
> Even r246252 is more than 2 weeks old.  Why not latest trunk?

Because I have no time to download and check every trunk.

[Bug middle-end/77486] ubsan detects runtime error: left shift of negative value -3 at real_hash in real.c:2890

[zeccav at gmail dot com]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #6 from Vittorio Zecca  ---
Fixed in trunk level 246252.
Closing as Resolved Fixed.

[Bug middle-end/77486] ubsan detects runtime error: left shift of negative value -3 at real_hash in real.c:2890

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Even r246252 is more than 2 weeks old.  Why not latest trunk?

[Bug fortran/80330] New: OpenACC: Unexpected data mapping instead of implicit firstprivate

[tschwinge at gcc dot gnu.org]

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

Bug ID: 80330
   Summary: OpenACC: Unexpected data mapping instead of implicit
firstprivate
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: cesar at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41136
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41136=edit
implicit-firstprivate-1.f90

Compile the attached "implicit-firstprivate-1.f90" (lifted from
"libgomp.oacc-fortran/pr70643.f90") with "-fdump-tree-gimple", and observe
that:

!$acc data
!$acc parallel loop
  do k=y_min,y_max
!$acc loop
 do j=x_min,x_max

... gets translated into:

  #pragma omp target oacc_data
{
  try
{
  {
integer(kind=4) D.3517;
integer(kind=4) D.3518;

D.3517 = y_min;
D.3518 = y_max;
#pragma omp target oacc_parallel map(tofrom:D.3518 [len: 4])
map(tofrom:D.3517 [len: 4]) firstprivate(x_min) firstprivate(x_max)

In particular, notice "firstprivate(x_min) firstprivate(x_max)" as expected,
but why are "y_min" and "y_max" put into temporaries first, and then
transmitted via "tofrom" mappings?

I have not yet spent enough time to construct a test case where this causes a
correctness problem, but it seems wrong as-is.

This only seems to happen for a combined "parallel loop" construct, and only if
there is an outer "data" construct.

In fact, it's the code in "gcc/gimplify.c" ,"omp_notice_variable", below "Look
in outer OpenACC contexts, to see if there's a data attribute for this
variable", that is then setting "GOVD_MAP", which translates to "tofrom".  (I
stumbled over this issue when changing said code to set "force_present" instead
of "tofrom"; "libgomp.oacc-fortran/pr70643.f90" was the only testsuite
regression.)

Said OpenACC-specific code looks similar to what is being done for OpenMP in
"omp_default_clause", but it's not the same.  In particular, for OpenACC, we
don't consider (as many cases of?) "omp_predetermined_sharing (decl)" (some of
them seem to be implemented in an ad-hoc way?) -- but I don't know if that or
something else in the gimplifier is actually the problem, or if it is something
in the Fortran front end?

[Bug middle-end/77486] ubsan detects runtime error: left shift of negative value -3 at real_hash in real.c:2890

[zeccav at gmail dot com]

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

--- Comment #4 from Vittorio Zecca  ---
This is on trunk level 239276.
Going to check on newer level 246252.

[Bug tree-optimization/80318] GCC takes too much RAM and time compiling a template file

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
(In reply to benjamin.redelings from comment #0)
> Hi,
> 
> When compiling the attached file

[...snip...]

> I've attached the preprocessed source below.

[...snip...]

Looks like this is missing the source code; I don't see any attachments to this
bug.

[Bug rtl-optimization/70703] [6/7 regression] Regression in register usage on x86

[vmakarov at gcc dot gnu.org]

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

--- Comment #13 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Apr  5 16:14:28 2017
New Revision: 246711

URL: https://gcc.gnu.org/viewcvs?rev=246711=gcc=rev
Log:
2017-04-05  Vladimir Makarov  

PR rtl-optimization/70703
* ira-color.c (update_conflict_hard_regno_costs): Use
HOST_WIDE_INT instead of long.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-color.c

[Bug middle-end/77486] ubsan detects runtime error: left shift of negative value -3 at real_hash in real.c:2890

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I don't believe that, because the code now reads:
case rvc_normal:
  h |= (unsigned int)REAL_EXP (r) << 3;
  break;
That has changed already in November: r243012.

[Bug c++/80329] New: Poor location for array bounds warning

[redi at gcc dot gnu.org]

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

Bug ID: 80329
   Summary: Poor location for array bounds warning
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

#include 

int main()
{
  std::string s("", 2);
}

With -O2 -Wsystem-headers there's a valid warning, but with a useless location:

In file included from
/home/jwakely/gcc/7/include/c++/7.0.1/bits/stl_algobase.h:66:0,
 from
/home/jwakely/gcc/7/include/c++/7.0.1/bits/char_traits.h:39,
 from /home/jwakely/gcc/7/include/c++/7.0.1/string:40,
 from s.cc:1:
/home/jwakely/gcc/7/include/c++/7.0.1/bits/stl_iterator_base_funcs.h: In
function ‘int main()’:
/home/jwakely/gcc/7/include/c++/7.0.1/bits/stl_iterator_base_funcs.h:104:21:
warning: array subscript is above array bounds [-Warray-bounds]
   return __last - __first;
  ~~~^

gcc-6-branch doesn't warn, but I hesitate to call this a regression because the
warning is pointing out a real problem (we try to copy 2 bytes from the array
"").

[Bug middle-end/77486] ubsan detects runtime error: left shift of negative value -3 at real_hash in real.c:2890

[zeccav at gmail dot com]

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

--- Comment #2 from Vittorio Zecca  ---
Still in trunk

/home/vitti/1tb/vitti/test/gcc-trunk-239276/gcc/real.c:2889:25: runtime error:
left shift of negative value -3

[Bug c++/80328] New: With -ffloat-store std::array operator[] no longer cost-free

[pavel.celba at ricardo dot com]

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

Bug ID: 80328
   Summary: With -ffloat-store std::array operator[] no longer
cost-free
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pavel.celba at ricardo dot com
  Target Milestone: ---

Following code:

#include 
#include 
#include 
#include 

int main()
{
  static const size_t numIters = 1u;

  srand(static_cast(time(nullptr)));  

  // Simple type timing
  float vec[3];
  for (int i = 0; i < 3; ++i)
vec[i] = static_cast(rand());

  clock_t simpleBegin = clock();

  for (size_t iter = 0u; iter < numIters; ++iter)
for (int i = 0; i < 3; ++i)
  vec[i] += vec[i];

  clock_t simpleEnd = clock(); 

  // Simple type timing
  std::array vec2;
  for (int i = 0; i < 3; ++i)
vec2[i] = static_cast(rand());

  clock_t arrayBegin = clock();

  for (size_t iter = 0u; iter < numIters; ++iter)
for (int i = 0; i < 3; ++i)
  vec2[i] += vec2[i];

  clock_t arrayEnd = clock();  

  // Suppress optimizing out whole computation
  volatile float suppressOptimizingOut[3];
  for (int i = 0; i < 3; ++i)
  {
suppressOptimizingOut[i] = vec[i];
suppressOptimizingOut[i] = vec2[i];
  }
  (void)suppressOptimizingOut; // Must use the value to suppress unused warning


  std::cout << "Simple case time: " << double(simpleEnd - simpleBegin) /
CLOCKS_PER_SEC << std::endl;
  std::cout << "Array case time: " << double(arrayEnd - arrayBegin) /
CLOCKS_PER_SEC << std::endl;
}

Compile options: -Wall -std=c++11 -ffloat-store -O2 -o a.out source_file.cpp

There is really no reason too - shouldn't do any additional operations compared
to simple case after all optimizations.

[Bug target/80298] incompatible with -mno-sse

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Apr  5 15:33:49 2017
New Revision: 246708

URL: https://gcc.gnu.org/viewcvs?rev=246708=gcc=rev
Log:
PR target/80298
* config/i386/mmintrin.h: Add -msse target option when __SSE__ is
not defined for x86_64 target.  Add -mmmx target option when __SSE2__
is not defined.
* config/i386/mm3dnow.h: Add -msse target when __SSE__ is not defined
for x86_64 target.  Handle -m3dnowa option.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/mm3dnow.h
trunk/gcc/config/i386/mmintrin.h

[Bug rtl-optimization/70703] [6/7 regression] Regression in register usage on x86

[vmakarov at gcc dot gnu.org]

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

--- Comment #12 from Vladimir Makarov  ---
Author: vmakarov
Date: Wed Apr  5 15:07:51 2017
New Revision: 246707

URL: https://gcc.gnu.org/viewcvs?rev=246707=gcc=rev
Log:
2017-04-05  Vladimir Makarov  

PR rtl-optimization/70703
* ira-color.c (update_costs_from_allocno): Use the smallest mode.
(update_conflict_hard_regno_costs): Use long instead of unsigned
arithmetic for cost calculation.

2017-04-05  Vladimir Makarov  

PR rtl-optimization/70703
* gcc.target/i386/pr70703.c: New.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr70703.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira-color.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/79265] [7 regression] -fsanitize=undefined inserts unnecessary null pointer tests

[sirl at gcc dot gnu.org]

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

--- Comment #6 from Franz Sirl  ---
(In reply to Jakub Jelinek from comment #4)
> This is a new warning, the fact that we didn't warn on some code and now
> warn with a new warning is not necessarily a regression.

Well, I wasn't so sure either if it counts as a regression, that's why I asked
on IRC first and then changed it. If you feel otherwise, you can remove the
marker again.

I guess it is kind of a "usability regression":

- "gcc-6 -Wall -Werror": compiles
- "gcc-6 -Wall -Werror -fsanitize=undefined": compiles
- "gcc-7 -Wall -Werror": compiles
- "gcc-7 -Wall -Werror -fsanitize=undefined": doesn't compile because of false
warning

So it's no longer enough to "just add -fsanitize=undefined" and recompile, now
you have to adjust warnings as well.

If it can't be reasonably solved within the GCC-7 timeframe, I would be fine
with a stop-gap measure like removing -Wformat-overflow from -Wall when UBSAN
is active (for example).

[Bug tree-optimization/80281] [5/6 Regression] Wrong constant folding

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Can be reproduced on x86_64-linux with -O2 -mfma -ffast-math.
Comparing pre and post r246674 differences, the first one I see in forwprop3:
@@ -3,6 +3,7 @@

 foo (unsigned int x, unsigned int y, unsigned int z)
 {
+  unsigned int _1;
   unsigned int _3;
   unsigned int _7;
   unsigned int _9;
@@ -12,8 +13,9 @@ foo (unsigned int x, unsigned int y, uns
   _9 = z_5(D) * z_5(D);
   _10 = y_4(D) * _9;
   _3 = -_10;
-  _7 = x_6(D) - _10;
-  return _7;
+  _1 = x_6(D) - _10;
+  _7 = _1;
+  return _1;

 }

@@ -23,6 +25,7 @@ foo (unsigned int x, unsigned int y, uns

 bar (float x, float y, float z)
 {
+  float _1;
   float _3;
   float _7;
   float reassocpow_9;
@@ -32,8 +35,9 @@ bar (float x, float y, float z)
   reassocpow_9 = __builtin_powif (z_5(D), 2);
   _10 = y_4(D) * reassocpow_9;
   _3 = -_10;
-  _7 = x_6(D) - _10;
-  return _7;
+  _1 = x_6(D) - _10;
+  _7 = _1;
+  return _1;

 }

Wonder why anything changed for the float types or unsigned types.
And in bar, where the failure appears, the difference between -mfma vs.
-mno-fma appears in widening_mul pass:
   powmult_7 = z_5(D) * z_5(D);
-  _10 = y_4(D) * powmult_7;
-  _1 = x_6(D) - _10;
+  _3 = -y_4(D);
+  _1 = _3 * powmult_7 + x_6(D);

On the other side, with -mfma the actual difference for -O2 -ffast-math -mfma
before/after this commit is:
-  powmult_1 = z_5(D) * z_5(D);
-  _3 = -powmult_1;
-  _7 = _3 * y_4(D) + x_6(D);
-  return _7;
+  powmult_7 = z_5(D) * z_5(D);
+  _3 = -y_4(D);
+  _1 = _3 * powmult_7 + x_6(D);
+  return _1;
so not an actual functional change, no idea why negating the pow2 vs. the other
operand would have any advantages/disadvantages, the difference is:
-   vfnmadd231ss%xmm2, %xmm1, %xmm0
+   vfnmadd231ss%xmm1, %xmm2, %xmm0

[Bug tree-optimization/80281] [5/6 Regression] Wrong constant folding

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
I've seen it fail on powerpc64-linux too.

[Bug tree-optimization/80281] [5/6 Regression] Wrong constant folding

[vogt at linux dot vnet.ibm.com]

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

--- Comment #14 from Dominik Vogt  ---
Created attachment 41135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41135=edit
dumpfile

[Bug tree-optimization/80281] [5/6 Regression] Wrong constant folding

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu.org,
   ||vogt at linux dot vnet.ibm.com

--- Comment #13 from Dominik Vogt  ---
This commit breaks tree-ssa/pr40921.c on s390x (-m31 and -m64) and s390:

.../build/gcc/xgcc -B.../build/gcc/ .../testsuite/gcc.dg/tree-ssa/pr40921.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -fdump-tree-optimized
-ffast-math -S -m64 -o pr40921.s
PASS: gcc.dg/tree-ssa/pr40921.c (test for excess errors) 
FAIL: gcc.dg/tree-ssa/pr40921.c scan-tree-dump-times optimized "_* = -y_" 0

[Bug sanitizer/79265] [7 regression] -fsanitize=undefined inserts unnecessary null pointer tests

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
What we could do is disable jump threading basic blocks that contain the cold
sanitizer builtins, i.e. in between BEGIN_SANITIZER_BUILTINS and
END_SANITIZER_BUILTINS if they have cold attribute (which is really undesirable
in any case, such jump threading only grows the cold section unnecessarily).

Or move the warning earlier such that it doesn't warn on code after threading,
though that is likely not GCC7 material.

[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557

[aivchenk at gmail dot com]

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

Alexander Ivchenko  changed:

   What|Removed |Added

 CC||aivchenk at gmail dot com

--- Comment #4 from Alexander Ivchenko  ---
This is not a CHKP issue as we ICE without it as well:

>gcc-7 /export/users/aivchenk/gnu_ws/gcc/gcc/testsuite/gcc.dg/pr38934.c -m32 
>-ftrapv

/export/users/aivchenk/gnu_ws/gcc/gcc/testsuite/gcc.dg/pr38934.c:14:35:
internal compiler error: in expand_expr_real_2, at expr.c:9569
   if (p >= -9223372036854775808LL - (signed char) g)
~~~^
0xa5e6a3 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
../../gcc/gcc/expr.c:9569
0x8fa8c6 expand_gimple_stmt_1
../../gcc/gcc/cfgexpand.c:3677
0x8fab10 expand_gimple_stmt
../../gcc/gcc/cfgexpand.c:3737
0x901bf4 expand_gimple_basic_block
../../gcc/gcc/cfgexpand.c:5744
0x903656 execute


gcc-4.8.3 works though. So it's a regression

[Bug sanitizer/79265] [7 regression] -fsanitize=undefined inserts unnecessary null pointer tests

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
This is a new warning, the fact that we didn't warn on some code and now warn
with a new warning is not necessarily a regression.

[Bug sanitizer/79265] [7 regression] -fsanitize=undefined inserts unnecessary null pointer tests

[sirl at gcc dot gnu.org]

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

Franz Sirl  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-05
Summary|-fsanitize=undefined|[7 regression]
   |inserts unnecessary null|-fsanitize=undefined
   |pointer tests   |inserts unnecessary null
   ||pointer tests
 Ever confirmed|0   |1

--- Comment #3 from Franz Sirl  ---
Code that used to compile warning-free with "gcc-6 -Wall -fsanitize=undefined"
now throws a warning with current gcc-7.0.1.

[Bug sanitizer/80308] [7 Regression] asan crash on big-endian powerpc-linux target

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #15 from Jakub Jelinek  ---
Fixed.

[Bug sanitizer/80308] [7 Regression] asan crash on big-endian powerpc-linux target

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr  5 13:17:15 2017
New Revision: 246703

URL: https://gcc.gnu.org/viewcvs?rev=246703=gcc=rev
Log:
PR sanitizer/80308
* asan.c (asan_store_shadow_bytes): Fix location of last_chunk_value
for big endian.

* c-c++-common/asan/pr80308.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/asan/pr80308.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/80322] convert intrinsics missing

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#expand=371,370,1707,1708=_mm512_cvtsd_f64

[Bug c++/80325] _mm512_undefined intrinsic missing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
For all your requests, can you back them up with details on what compiler
provides them etc.?
We do have in avx512fintrin.h
_mm512_undefined_ps (void)
_mm512_undefined_pd (void)
_mm512_undefined_epi32 (void)
_mm_undefined* and _mm256_undefined* are named similarly (except for epi32 vs.
si128/si256).  The SDM doesn't mention any of these.

[Bug c++/80322] convert intrinsics missing

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf  ---
Looks like LLVM only: https://reviews.llvm.org/D31155

[Bug c++/80322] convert intrinsics missing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||kyukhin at gcc dot gnu.org,
   ||uros at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Can't find it even in ICC 17.0 documentation.

[Bug c++/80322] convert intrinsics missing

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Where they are documented and where they come from?
Can't find them in 325462-sdm-vol-1-2abcd-3abcd.pdf

[Bug middle-end/80262] address space gets lost in memory access

[stefan at reservoir dot com]

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

--- Comment #6 from Stefan M Freudenberger  ---
Created attachment 41134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41134=edit
Modified source program that shows issue on x86_64.

I've modified my example (attached) to show the issue in x86_64, and tried it
on ToT, with the following results:

GNU C11 (GCC) version 7.0.1 20170330 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 7.0.1 20170330 (experimental), GMP version
6.1.2, MPFR version 3.1.5, MPC version 1.0.3, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: a526ee0d3a9f89b7e918be755c2fadee
bug5.c: In function ‘clearS2’:
bug5.c:23:1: internal compiler error: tree check: expected integer_cst, have
addr_space_convert_expr in decompose, at tree.h:5256
}
^
0xdebe6c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../src/gcc-trunk/gcc/tree.c:9817
0x57b864 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../src/gcc-trunk/gcc/tree.h:3320
0x57b864 wi::int_traits::decompose(long*, unsigned int,
tree_node const*)
../../src/gcc-trunk/gcc/tree.h:5256
0xdf41aa wi::int_traits::decompose(long*, unsigned int,
tree_node const*)
../../src/gcc-trunk/gcc/tree.h:3254
0xdf41aa wide_int_ref_storage::wide_int_ref_storage(tree_node const* const&)
../../src/gcc-trunk/gcc/wide-int.h:967
0xdf41aa generic_wide_int::generic_wide_int(tree_node* const&)
../../src/gcc-trunk/gcc/wide-int.h:745
0xdf41aa mem_ref_offset(tree_node const*)
../../src/gcc-trunk/gcc/tree.c:4645
0xc4f131 indirect_refs_may_alias_p
../../src/gcc-trunk/gcc/tree-ssa-alias.c:1319
0xc519bc refs_may_alias_p_1(ao_ref*, ao_ref*, bool)
../../src/gcc-trunk/gcc/tree-ssa-alias.c:1536
0xd0cca5 vn_reference_lookup_3
../../src/gcc-trunk/gcc/tree-ssa-sccvn.c:1821
0xc54689 maybe_skip_until
../../src/gcc-trunk/gcc/tree-ssa-alias.c:2645
0xc54b64 get_continuation_for_phi_1
../../src/gcc-trunk/gcc/tree-ssa-alias.c:2686
0xc54b64 get_continuation_for_phi(gimple*, ao_ref*, unsigned int*,
bitmap_head**, bool, void* (*)(ao_ref*, tree_node*, void*, bool*), void*)
../../src/gcc-trunk/gcc/tree-ssa-alias.c:2777
0xc54e05 walk_non_aliased_vuses(ao_ref*, tree_node*, void* (*)(ao_ref*,
tree_node*, unsigned int, void*), void* (*)(ao_ref*, tree_node*, void*, bool*),
tree_node* (*)(tree_node*), void*)
../../src/gcc-trunk/gcc/tree-ssa-alias.c:2849
0xd0c189 vn_reference_lookup(tree_node*, tree_node*, vn_lookup_kind,
vn_reference_s**, bool)
../../src/gcc-trunk/gcc/tree-ssa-sccvn.c:2448
0xce15ab eliminate_dom_walker::before_dom_children(basic_block_def*)
../../src/gcc-trunk/gcc/tree-ssa-pre.c:4500
0x1244eca dom_walker::walk(basic_block_def*)
../../src/gcc-trunk/gcc/domwalk.c:265
0xce0181 eliminate
../../src/gcc-trunk/gcc/tree-ssa-pre.c:4773
0xce04c4 execute
../../src/gcc-trunk/gcc/tree-ssa-pre.c:5207
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/80327] New: _mm512_abs_ps intrinsic missing

[m...@sven-woop.de]

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

Bug ID: 80327
   Summary: _mm512_abs_ps intrinsic missing
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m...@sven-woop.de
  Target Milestone: ---

The _mm512_abs_ps intrinsic is missing in GCC 6.3 and trunk version.

[Bug c++/80326] New: _mm512_trunc_ps intrinsic missing

[m...@sven-woop.de]

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

Bug ID: 80326
   Summary: _mm512_trunc_ps intrinsic missing
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m...@sven-woop.de
  Target Milestone: ---

The _mm512_trunc_ps intrinsic is missing in GCC 6.3 and trunk version.

[Bug c++/80325] New: _mm512_undefined intrinsic missing

[m...@sven-woop.de]

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

Bug ID: 80325
   Summary: _mm512_undefined intrinsic missing
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m...@sven-woop.de
  Target Milestone: ---

The _mm512_undefined intrinsic is missing in GCC 6.3 and also in the trunk
version.

[Bug c++/80324] New: _mm512_reduce_xxx type instrinsics are missing

[m...@sven-woop.de]

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

Bug ID: 80324
   Summary: _mm512_reduce_xxx type instrinsics are missing
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m...@sven-woop.de
  Target Milestone: ---

The following intrinsics are missing in GCC 6.3 (and also in trunk):

_mm512_reduce_add_epi32
_mm512_reduce_add_epi64
_mm512_reduce_add_pd
_mm512_reduce_add_ps
_mm512_reduce_and_epi32
_mm512_reduce_and_epi64
_mm512_reduce_max_epi32
_mm512_reduce_max_epi64
_mm512_reduce_max_epu32
_mm512_reduce_max_pd
_mm512_reduce_max_ps
_mm512_reduce_min_epi32
_mm512_reduce_min_epi64
_mm512_reduce_min_epu32
_mm512_reduce_min_pd
_mm512_reduce_min_ps
_mm512_reduce_mul_epi32
_mm512_reduce_mul_ps
_mm512_reduce_or_epi64

There are likely some others too, but these are the ones for which compilation
of our project fails.

[Bug c++/80309] [7 Regression] ICE: canonical types differ for identical types _Args2 and _Args2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.  Only the rewrite_template_parm are actually needed, the rest is
just what I found while debugging.

[Bug c++/80323] New: _mm512_int2mask and _mm512_mask2int intrinsics are missing

[m...@sven-woop.de]

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

Bug ID: 80323
   Summary: _mm512_int2mask and _mm512_mask2int intrinsics are
missing
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m...@sven-woop.de
  Target Milestone: ---

The following intrinsics are missing in GCC 6.3 (and also in trunk).

_mm512_int2mask
_mm512_mask2int

[Bug c++/80322] New: convert intrinsics missing

[m...@sven-woop.de]

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

Bug ID: 80322
   Summary: convert intrinsics missing
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m...@sven-woop.de
  Target Milestone: ---

The following intrinsics are missing in GCC 6.3 (and also in trunk).

_mm512_cvtsd_f64
_mm512_cvtss_f32
_mm256_cvtsd_f64
_mm256_cvtss_f32

[Bug target/78002] gcc.target/aarch64/stack-checking.c ICEs with -mabi=ilp32

[ebotcazou at gcc dot gnu.org]

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

--- Comment #12 from Eric Botcazou  ---
Author: ebotcazou
Date: Wed Apr  5 11:48:02 2017
New Revision: 246702

URL: https://gcc.gnu.org/viewcvs?rev=246702=gcc=rev
Log:
PR target/78002
* config/aarch64/aarch64.c (aarch64_emit_probe_stack_range): Replace
ptr_mode with Pmode throughout.
* config/aarch64/aarch64.md (probe_stack_range_

[Bug sanitizer/80308] [7 Regression] asan crash on big-endian powerpc-linux target

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug c++/80294] [5/6/7 Regression] ICE with constexpr and inheritance

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
It can be context-specific, NULL elts valid only in some CONSTRUCTORs, e.g.
during constexpr processing or whatever.  In any case it would be good to
understand if it is intentional and what it means.

[Bug c++/80294] [5/6/7 Regression] ICE with constexpr and inheritance

[trippels at gcc dot gnu.org]

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

--- Comment #15 from Markus Trippelsdorf  ---
I only looked at a small random sample. So yes, you are right and I retract my
patch, because the majority doesn't expect a NULL elt.

[Bug c++/80294] [5/6/7 Regression] ICE with constexpr and inheritance

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
I don't know what it means to have NULL elt and it looks weird to me, but I'm
not a C++ FE maintainer, I assume Jason and/or Nathan will review your patch
and know what it means.
Just grepping through FOR_EACH_CONSTRUCTOR_VALUE reveals that many don't really
accept NULL elements (e.g. use TREE_TYPE on the elements), while some others
could cope with it (e.g. when value_dependent_expression_p or
type_dependent_expression_p is called on it).

[Bug c++/80294] [5/6/7 Regression] ICE with constexpr and inheritance

[trippels at gcc dot gnu.org]

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

--- Comment #13 from Markus Trippelsdorf  ---
(In reply to Jakub Jelinek from comment #12)
> r234636 just moved that, the constructor_elt ce = { index, NULL_TREE };
> being pushed had there been before Nathan's patch too.

But checking for valid elt when using FOR_EACH_CONSTRUCTOR_VALUE (*, *, elt) is
used elsewhere, too. I don't see why it shouldn't be used here.

[Bug c++/80294] [5/6/7 Regression] ICE with constexpr and inheritance

[jakub at gcc dot gnu.org]

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

--- Comment #12 from Jakub Jelinek  ---
r234636 just moved that, the constructor_elt ce = { index, NULL_TREE }; being
pushed had there been before Nathan's patch too.

[Bug fortran/80304] [7 Regression] Wrong result with do concurrent

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres  ---
> Can you narrow it down further?

Not trivial!-(

[Bug fortran/80305] [7 Regression] print statement inside do-concurrent

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-05
Summary|print statement inside  |[7 Regression] print
   |do-concurrent   |statement inside
   ||do-concurrent
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
I get the following run time error

Fortran runtime error: Missing format for FORMATTED data transfer

The change occurred in the same range as for pr80304.

[Bug fortran/69498] ICE on disjunct cases with displaced or incomplete embedded statement

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #9 from Dominique d'Humieres  ---
The test in comment 2 (z7.f90) still gives an ICE at revision r246695

pr69498_3.f90:2:16:

 submodule (m) sm
1
Error: Unexpected SUBMODULE statement at (1)
f951: internal compiler error: in gfc_match_submodule, at fortran/module.c:745

[Bug c++/80320] Constructor executed twice for the same static member when using -fno-implicit-templates

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-05
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
(In reply to James Abbatiello from comment #0)
> I don't know exactly what's supposed to happen with -fno-implicit-templates
> and static members.  I initially expected that main.o would not try to
> construct any static members since they were not explicitly instantiated. 
> If that were the case then the static would only be constructed by foo.o and
> things would work correctly.

I think that's what should happen.


> I've tested this on various versions of GCC and it occurs on 4.4.7, 4.9.2,
> 6.3.0 and a copy of 7.0.1 built from trunk so this does not seem like a
> recent regression.

And also 4.3.6

[Bug target/80307] [7 regression] MUL generated for small multiplier cores

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||7.0
 Resolution|--- |FIXED
  Known to fail|7.0 |

--- Comment #3 from Thomas Preud'homme  ---
Fixed in r246682

[Bug debug/80321] New: [7 regression] infinite recursion with inlining of nested function and debug info

[ebotcazou at gcc dot gnu.org]

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

Bug ID: 80321
   Summary: [7 regression] infinite recursion with inlining of
nested function and debug info
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: major
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ebotcazou at gcc dot gnu.org
Blocks: 79255
  Target Milestone: ---

Created attachment 41132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41132=edit
Self-contained testcase

This is a very annoying regression for Ada introduced by:

2017-03-31  Jakub Jelinek  

PR debug/79255
* dwarf2out.c (decls_for_scope): If BLOCK_NONLOCALIZED_VAR is
a FUNCTION_DECL, pass it as decl instead of origin to
process_scope_var.

in the form of an infinite recursion at -O2 -g between process_scope_var and
decls_for_scope in dwarf2out.c.

To reproduce:

eric@polaris:~/build/gcc/native> gnatchop debug10.txt 
splitting debug10.txt into:
   debug10.adb
   debug10_pkg.ads
eric@polaris:~/build/gcc/native> gcc/gnat1 -quiet debug10.adb -O2 -g

raised STORAGE_ERROR : stack overflow or erroneous memory access

The testcase can be added to the gnat.dg testsuite as-is.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79255
[Bug 79255] [6 Regression] PGO bootstrap fails on x86_64/ppc64le building Ada

[Bug tree-optimization/80198] [6/7 Regression] does not vectorize generic inplace integer operation

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
How would building equivalences help?
Looking at the gcc.dg/tree-ssa/20030922-2.c testcase, the reason it works with
Jeff's patch is that we are lucky enough on that exact testcase starting with:
  if (_6 != _11)
goto ; [69.50%]
  else
goto ; [30.50%]

   [69.50%]:
  target_bb.3_12 = target_bb;
  if (_11 == target_bb.3_12)
goto ; [37.68%]
  else
goto ; [62.32%]

   [26.19%]:
  if (_6 != target_bb.3_12)
and first replace the target_bb.3_12 due to the extra added SSA_NAME_VALUE to
_11 in the last GIMPLE_COND above during cprop_operand and then
eliminate_redundant_computations do
avail_exprs_stack->lookup_avail_expr (stmt, insert, true);
on that if (_6 != _11) and find it.  If we are unlucky enough and say have
  if (_6 != _11)
in the bb4 and replace that with if (_6 != target_bb.3_12), then we won't find
it.  Consider say -O1 -fno-tree-fre:
struct rtx_def;
typedef struct rtx_def *rtx;
struct rtx_def
{
  int bb;
};
int *block_to_bb;
int target_bb;

int
rgn_rank (rtx insn1, rtx insn2)
{
  int a = block_to_bb[insn1->bb];
  int b = block_to_bb[insn2->bb];
  if (a != b)
if (b == target_bb && a != b)
  return 1;
}
Here dom2 with the r233207 change reverted is optimized into just two
GIMPLE_CONDs, while current trunk does not (manages to do it only during dom3).
As the first if (_6 != _11) is entered before we have any equivalences recorded
(and the equivalences are only temporary anyway, might not be in effect in all
the places where the if (_6 != _11) is in effect), I think there is no hope for
some canonicalization of the stmt we want to look up at the place we have some
equivalences for it temporarily recorded can help in doing just a single hash
table lookup.
Perhaps we should revert r233207 and in addition to the SSA_NAME_VALUE record
the temporary equivalences some way in another data structure (e.g. forward and
backward chains to other SSA_NAME versions, chains could be just unsigned int
SSA_NAME_VERSIONs or whatever).  Then e.g.
avail_exprs_stack::lookup_avail_expr
if it detects one or both arguments of the stmt have temporary equivalences
recorded could just loop through all the equivalence combinations (perhaps with
some upper bound), trying to (!insert) find the available expression.  And if
everything else fails do the insert lookup (if requested) on the SSA_NAMEs as
in the stmt last.  Thoughts on this?

[Bug target/79890] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

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

--- Comment #7 from Andreas Krebbel  ---
Fixed with patch from comment 6

[Bug target/79890] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430

[krebbel at gcc dot gnu.org]

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

--- Comment #6 from Andreas Krebbel  ---
Author: krebbel
Date: Wed Apr  5 08:28:18 2017
New Revision: 246701

URL: https://gcc.gnu.org/viewcvs?rev=246701=gcc=rev
Log:
PR target/79890: S/390: Fix crash.

builtin_eh_return requires the return address to be saved on the
stack.  The patch prevents using an FPR for that.

gcc/ChangeLog:

2017-04-05  Dominik Vogt  

PR target/79890
* config/s390/s390.c (s390_register_info_gprtofpr): Return if
call_eh_return is true.

gcc/testsuite/ChangeLog:

2017-04-05  Dominik Vogt  

PR target/79890
* gcc.target/s390/pr79890.c: New test case.


Added:
trunk/gcc/testsuite/gcc.target/s390/pr79890.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.c
trunk/gcc/testsuite/ChangeLog

[Bug sanitizer/80308] [7 Regression] asan crash on big-endian powerpc-linux target

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|marxin at gcc dot gnu.org  |unassigned at gcc dot 
gnu.org

--- Comment #13 from Martin Liška  ---
Thanks Jakub!

[Bug sanitizer/80308] [7 Regression] asan crash on big-endian powerpc-linux target

[bernd.edlinger at hotmail dot de]

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

--- Comment #12 from Bernd Edlinger  ---
(In reply to Bernd Edlinger from comment #11)
> (In reply to Jakub Jelinek from comment #10)
> > Created attachment 41131 [details]
> > gcc7-pr80308.patch
> > 
> > Full patch (untested so far).
> 
> Thanks!
> I will give it a real-world test.

I can confirm, that the test works on the original target:
crash is there with unpatched gcc and fixed with above patch.

[Bug c++/80309] [7 Regression] ICE: canonical types differ for identical types _Args2 and _Args2

[trippels at gcc dot gnu.org]

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

--- Comment #4 from Markus Trippelsdorf  ---
--param ggc-min-expand=0 --param ggc-min-heapsize=3000 triggers the ICE,
--param ggc-min-expand=0 --param ggc-min-heapsize=2000 doesn't.

[Bug sanitizer/80308] [7 Regression] asan crash on big-endian powerpc-linux target

[bernd.edlinger at hotmail dot de]

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

--- Comment #11 from Bernd Edlinger  ---
(In reply to Jakub Jelinek from comment #10)
> Created attachment 41131 [details]
> gcc7-pr80308.patch
> 
> Full patch (untested so far).

Thanks!
I will give it a real-world test.

[Bug sanitizer/80308] [7 Regression] asan crash on big-endian powerpc-linux target

[jakub at gcc dot gnu.org]

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

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

Full patch (untested so far).

[Bug c++/80320] New: Constructor executed twice for the same static member when using -fno-implicit-templates

[abbeyj+gcc at gmail dot com]

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

Bug ID: 80320
   Summary: Constructor executed twice for the same static member
when using -fno-implicit-templates
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: abbeyj+gcc at gmail dot com
  Target Milestone: ---

Created attachment 41130
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41130=edit
Testcase

With the attached testcase, the constructor for Foo::bar is run twice in a
row with the same `this` pointer both times.  bar is a static member of
Foo.  At exit the destructor is run twice as well.  This only happens when
using -fno-implicit-templates.  

$ make
g++ -Wall -fno-implicit-templates   -c -o main.o main.cpp
g++ -Wall -fno-implicit-templates   -c -o foo.o foo.cpp
g++ main.o foo.o -o double
$ ./double 
Bar  this=0x601041
Bar  this=0x601041
frob this=0x601041
~Bar this=0x601041
~Bar this=0x601041


I would have expected the output to look instead like:
$ ./double
Bar  this=0x601041
frob this=0x601041
~Bar this=0x601041


foo.cpp explicitly instantiates Foo so I'd expect foo.o to have a call to
the constructor.  There is one there in
__static_initialization_and_destruction_0.  Before the call there is a check
against "guard variable for Foo::bar".

main.cpp only references Foo::bar.  Like in foo.o, main.o also calls
Bar::Bar() from its __static_initialization_and_destruction_0.  Unlike in
foo.o, there is no check against "guard variable for Foo::bar".

I don't know exactly what's supposed to happen with -fno-implicit-templates and
static members.  I initially expected that main.o would not try to construct
any static members since they were not explicitly instantiated.  If that were
the case then the static would only be constructed by foo.o and things would
work correctly.

Possibly that's not the desired behavior and static members are intended to be
instantiated implicitly even with -fno-implicit-templates in effect.  If that
is the case then the generated code seems buggy since it doesn't include the
check against the guard variable.

I've tested this on various versions of GCC and it occurs on 4.4.7, 4.9.2,
6.3.0 and a copy of 7.0.1 built from trunk so this does not seem like a recent
regression.

[Bug sanitizer/80308] [7 Regression] asan crash on big-endian powerpc-linux target

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
Summary|asan crash on big-endian|[7 Regression] asan crash
   |powerpc-linux target|on big-endian powerpc-linux
   ||target

[Bug sanitizer/80308] asan crash on big-endian powerpc-linux target

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Short testcase (meant for c-c++-common/asan/pr80308.c (or
gcc.dg/asan/pr80308.c):
/* PR sanitizer/80308 */
/* { dg-do run } */

__attribute__((noinline, noclone)) int
foo (char *a)
{
  int i, j = 0;
  asm volatile ("" : "+r" (a) : : "memory");
  for (i = 0; i < 12; i++)
j += a[i];
  return j;
}

int
main ()
{
  int i, j = 0;
  for (i = 0; i < 4; i++)
{
  char a[12];
  __builtin_memset (a, 0, sizeof (a));
  j += foo (a);
}
  return j;
}

==34168==ERROR: AddressSanitizer: unknown-crash on address 0x3fffd50849b4 at pc
0x3fff7c76c028 bp 0x3fffd5084020 sp 0x3fffd5084090
WRITE of size 12 at 0x3fffd50849b4 thread T0
#0 0x3fff7c76c024 in __interceptor_memset
../../../../libsanitizer/asan/asan_interceptors.cc:471
...
=>0x09fffaa10930: 00 00 f1 f1 f1 f1[04]00 f2 f2 f3 f3 f3 f3 00 00

with unpatched gcc on ppc64 (-m64).