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

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
The other way to get rid of those errors would be wrap the MMX/3dNOW headers
into additional #pragma GCC target("sse") for 64-bit, but then you wouldn't be
able to use the MMX intrinsics with -mno-sse -mmmx -m64 (of course, nobody
really should be using those, but that is a different matter), while with the
proposed patch you can use them, you just can't have your own non-inlined
functions that have __m64 etc. as arguments or return values, because that
requires -msse.  As long as all functions pass __m64 by reference or take it
only from memory or deal with it only internally, -mmmx -mno-sse -m64 should be
fine.

[Bug target/80310] [7 Regression] Bogus -Wpsabi warning with -fsanitize=signed-integer-overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/80310] [7 Regression] Bogus -Wpsabi warning with -fsanitize=signed-integer-overflow

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Wed Apr  5 05:25:18 2017
New Revision: 246699

URL: https://gcc.gnu.org/viewcvs?rev=246699=gcc=rev
Log:
PR target/80310
* tree-nvr.c: Include internal-fn.h.
(pass_return_slot::execute): Ignore internal calls without
direct optab.

* c-c++-common/ubsan/pr80310.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/ubsan/pr80310.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-nrv.c

[Bug libgcc/80319] New: Support for floatundidf and floatundisf

[sbansal at ciena dot com]

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

Bug ID: 80319
   Summary: Support for floatundidf and floatundisf
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbansal at ciena dot com
  Target Milestone: ---

While migrating to a newer tool chain, corresponding to float and double data
types, __floatundisf and __floatundidf are being generated in assembly
respectively.

Checking the GCC code, these functions are defined in libgcc2.c.

Do I need to pass on certain flags while compiling libgcc? Please suggest.

Thanks.
Sumit

[Bug tree-optimization/80213] [7 Regression] ICE in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:704

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #1 from Arseny Solokha  ---
Maybe the following snippet can help in refining the culprit revision?

int zp, uj, rb;

static int
ip (int *mh, int ot)
{
  unsigned int cf;

  if (zp == 0 || uj == 0 || rb == 0)
return 0;

  for (uj = 0; uj < 2; ++uj)
{
  int w2;

  for (w2 = 0; w2 < ot; ++w2)
{
  cf = mh[w2];
  continue;
}
}

  return cf;
}

int
main (void)
{
  int d3[2] = { 0 };

  return ip (d3, 2);
}

% gcc-7.0.0-alpha20170402 -O1 -floop-parallelize-all -c xzddkrbs.c  
xzddkrbs.c: In function 'main':
xzddkrbs.c:26:1: internal compiler error: in check_loop_closed_ssa_use, at
tree-ssa-loop-manip.c:704
 main (void)
 ^~~~

After a slight modification I'm also able to make gcc ICE w/
-floop-nest-optimize instead of -floop-parallelize-all.

[Bug libgcc/80314] Undefined reference to __dso_handle & __cxa_atexit

[sbansal at ciena dot com]

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

--- Comment #3 from Sumit  ---
(In reply to Jonathan Wakely from comment #1)
> I think these both need to come from either libc or libgcc.

Is it something that I have missed while compiling the tool chain? Please
suggest.

[Bug libgcc/80314] Undefined reference to __dso_handle & __cxa_atexit

[sbansal at ciena dot com]

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

--- Comment #2 from Sumit  ---
(In reply to Jonathan Wakely from comment #1)
> I think these both need to come from either libc or libgcc.

I have checked my libgcc and it does not have that either.


onx-sbansal-01|

[Bug tree-optimization/80318] New: 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

Bug ID: 80318
   Summary: GCC takes too much RAM and time compiling a template
file
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: benjamin.redelings at gmail dot com
  Target Milestone: ---

Hi,

When compiling the attached file, GCC takes 2 minutes and about 6 gigs of RAM. 
This is large compared to clang, which takes about 55 second and about 1.8 gigs
of RAM.

Here's the exactly compilation command:

g++-7 -std=c++14 -DHAVE_CONFIG_H -I. -I../../../master/src -I.. 
-I../../../master/include -I../../../master/src  -isystem
../../../master/boost/include -ffast-math -DNDEBUG -DNDEBUG_DP -funroll-loops 
-Wall -Wextra -Wno-sign-compare -Woverloaded-virtual -Wstrict-aliasing -pipe
-O3 -pedantic -I/usr/include/cairo -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng16 -g -Wmisleading-indentation
-Wlogical-op -MT parser/parse.o -MD -MP -MF $depbase.Tpo -c -o parser/parse.o
../../../master/src/parser/parse.C

I've attached the preprocessed source below.

GCC version is.

$ g++-7 -v
Using built-in specs.
COLLECT_GCC=g++-7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 7-20170316-1'
--with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-7
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 7.0.1 20170316 (experimental) [trunk revision 246203] (Debian
7-20170316-1)

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

[roland at gnu dot org]

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

--- Comment #4 from roland at gnu dot org ---
I'd assumed it would be fixed just with more #pragma push_options,
target("sse"), pop_options, sequences.

It seems like a separate issue about automagically allowing things in
always_inline cases, and I'm not at all sure that is a general case that ought
to be fixed.

[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

--- Comment #12 from Thomas Koenig  ---
(In reply to Dominique d'Humieres from comment #3)


> The change occurred between revisions r239317 (2016-08-10, OK) and r239423
> (2016-08-12, wrong).

Can you narrow it down further?

I don't see anything relevant for Fortran here, I think
this was a middle-end change which affected Fortran.

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

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
The error message is bogus. I get an entirely different error.  It seems to
work for me with no optimization and fails with -O1. I suspect the internal dtp
structure is getting corrupted. Maybe a similar problem to 80304.

[Bug target/61837] missed loop invariant expression optimization

[wschmidt at gcc dot gnu.org]

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

--- Comment #2 from Bill Schmidt  ---
Also needs to hoist the "addi 8,4,-1" out to permit this.  That instruction is
also invariant.

[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

   Keywords||diagnostic
   Priority|P3  |P5

[Bug target/79883] avr i18n: untranslated "interrupt" or "signal"

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #6 from Georg-Johann Lay  ---
We could just turn signal into __signal__ and interrupt into __interrupt__ to
be more clear.

[Bug c++/79580] [5/6 Regression] ICE in nested_anon_class_index, at cp/mangle.c:1604

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

 CC||reichelt at gcc dot gnu.org

--- Comment #3 from Volker Reichelt  ---
*** Bug 58634 has been marked as a duplicate of this bug. ***

[Bug c++/58634] [c++11] ICE initializing static class member via an anonymous class

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

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

--- Comment #1 from Volker Reichelt  ---
Fixed with the patch for PR79580.

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

[Bug sanitizer/80308] 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 #8 from Bernd Edlinger  ---
Yeah, the patched asan.c works!

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #1 from Jonathan Wakely  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2017-04/

[Bug go/80302] FAIL: time on systems with tzdata2017b installed

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #2 from Ian Lance Taylor  ---
Thanks.  Should be fixed now.

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

[koenigni at gcc dot gnu.org]

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

koenigni at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from koenigni at gcc dot gnu.org ---
Fixed on trunk, closing.

[Bug ipa/80317] New: Missed optimization for common standard library case

[antoshkka at gmail dot com]

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

Bug ID: 80317
   Summary: Missed optimization for common standard library case
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoshkka at gmail dot com
  Target Milestone: ---

It's a common case in standard library and in user code to move objects to new
location and then destroy object at the old location. For example GCC's
std::vector::reserve has the following code:

  pointer __tmp = _M_allocate_and_copy(__n,
_GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(this->_M_impl._M_start),
_GLIBCXX_MAKE_MOVE_IF_NOEXCEPT_ITERATOR(this->_M_impl._M_finish));
  std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish,
_M_get_Tp_allocator()); 


The problem is that traversing exactly the same data twice is not well
optimized. Minimal example:

///

#include 

template 
struct shared_ptr_like {
T* ptr;
shared_ptr_like(shared_ptr_like&& v) noexcept : ptr(v.ptr) { v.ptr = 0; }
~shared_ptr_like() { if (ptr) { delete ptr; } }
};

typedef shared_ptr_like test_type;
void relocate(test_type* new_buffer, test_type* old_buffer, std::size_t size) {
for (std::size_t i = 0; i != size; ++i) {
new (new_buffer + i) test_type{ static_cast(old_buffer[i])
};
}
for (std::size_t i = 0; i != size; ++i) {
old_buffer[i].~test_type();
}
}

///

Produces assembly that traverses the loop twice, writes zeros to memory and
compares memory with zeros:

relocate(shared_ptr_like*, shared_ptr_like*, unsigned long):
testrdx, rdx
je  .L15
pushrbp
sal rdx, 3
pushrbx
lea r8, [rdi+rdx]
mov rbx, rsi
mov rax, rsi
sub rsp, 8
.L3:
mov rcx, QWORD PTR [rax]
add rdi, 8
add rax, 8
mov QWORD PTR [rdi-8], rcx
mov QWORD PTR [rax-8], 0
cmp rdi, r8
jne .L3
lea rbp, [rsi+rdx]
.L5:
mov rdi, QWORD PTR [rbx]
testrdi, rdi
je  .L4
mov esi, 4
calloperator delete(void*, unsigned long)
.L4:
add rbx, 8
cmp rbp, rbx
jne .L5
add rsp, 8
pop rbx
pop rbp
ret
.L15:
rep ret



Meanwhile optimal assembly for that function would be


relocate(shared_ptr_like*, shared_ptr_like*, unsigned long):
testrdx, rdx
je  .L1
lea rdx, [rdi+rdx*8]
.L3:
mov rax, QWORD PTR [rsi]
add rdi, 8
add rsi, 8
mov QWORD PTR [rdi-8], rax
cmp rdi, rdx
jne .L3
.L1:
rep ret


Note: Compiling the following code produces the optimal assembly from above:

#include 

template 
struct shared_ptr_like {
T* ptr;
shared_ptr_like(shared_ptr_like&& v) noexcept : ptr(v.ptr) { v.ptr = 0; }
~shared_ptr_like() { if (ptr) { delete ptr; } }
};

typedef shared_ptr_like test_type;
void relocate(test_type* new_buffer, test_type* old_buffer, std::size_t size) {
for (std::size_t i = 0; i != size; ++i) {
new (new_buffer + i) test_type{ static_cast(old_buffer[i])
};
old_buffer[i].~test_type();
}
}


Checked on GCC 7.0.1 20170330 with flags -std=c++17 -O2

[Bug c++/80297] [6 Regression] Compiler time crash: type mismatch in binary expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[6/7 Regression] Compiler   |[6 Regression] Compiler
   |time crash: type mismatch   |time crash: type mismatch
   |in binary expression|in binary expression

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug go/80302] FAIL: time on systems with tzdata2017b installed

[ian at gcc dot gnu.org]

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

--- Comment #1 from ian at gcc dot gnu.org  ---
Author: ian
Date: Tue Apr  4 19:37:22 2017
New Revision: 246695

URL: https://gcc.gnu.org/viewcvs?rev=246695=gcc=rev
Log:
PR go/80302
time: make the ParseInLocation test more robust

This is a backport of https://golang.org/cl/37964 from the gc toolchain.

Original description:

The tzdata 2017a update (2017-02-28) changed the abbreviation of the
Asia/Baghdad time zone (used in TestParseInLocation) from 'AST' to the
numeric '+03'.

Update the test so that it skips the checks if we're using a recent
tzdata release.

Updates golang/go#19457
Fixes GCC PR 80302.

Reviewed-on: https://go-review.googlesource.com/39470

Modified:
trunk/libgo/go/time/format_test.go

[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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
(In reply to Bernd Edlinger from comment #6)
> this looks suspicious:
> 
> --- asan.c.jj   2017-03-27 10:25:01.0 +0200
> +++ asan.c  2017-04-04 21:15:31.444941816 +0200
> @@ -2762,7 +2762,8 @@ asan_store_shadow_bytes (gimple_stmt_ite
>unsigned char shadow_c = c;
>if (i == size - 1 && last_chunk_size && !is_clobber)
> shadow_c = last_chunk_size;
> -  val |= (unsigned HOST_WIDE_INT) shadow_c << (BITS_PER_UNIT * i);
> +  val |= (unsigned HOST_WIDE_INT) shadow_c
> +<< (BITS_PER_UNIT * (BYTES_BIG_ENDIAN ? size - 1 - i : i));
>  }
> 
>/* Handle last chunk in unpoisoning.  */

Indeed, though perhaps it might be more readable to:
  for (unsigned i = 0; i < size; ++i)
{
  unsigned char shadow_c = c;
  if (i == (BYTES_BIG_ENDIAN ? 0 : size - 1)
  && last_chunk_size
  && !is_clobber)
shadow_c = last_chunk_size;
  val |= (unsigned HOST_WIDE_INT) shadow_c << (BITS_PER_UNIT * i);
}

But we really want a testcase for the testsuite here.
It needs to be something simple that with (the default
-fsanitize-use-after-scope) unpoisons and later poisons a variable with size
that is not a multiple of 32 bytes, such as that size of 12.

[Bug sanitizer/80308] 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 #6 from Bernd Edlinger  ---
this looks suspicious:

--- asan.c.jj   2017-03-27 10:25:01.0 +0200
+++ asan.c  2017-04-04 21:15:31.444941816 +0200
@@ -2762,7 +2762,8 @@ asan_store_shadow_bytes (gimple_stmt_ite
   unsigned char shadow_c = c;
   if (i == size - 1 && last_chunk_size && !is_clobber)
shadow_c = last_chunk_size;
-  val |= (unsigned HOST_WIDE_INT) shadow_c << (BITS_PER_UNIT * i);
+  val |= (unsigned HOST_WIDE_INT) shadow_c
+<< (BITS_PER_UNIT * (BYTES_BIG_ENDIAN ? size - 1 - i : i));
 }

   /* Handle last chunk in unpoisoning.  */

[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

   Keywords|diagnostic  |wrong-code
Summary|Warn about variable |[7 Regression] Wrong result
   |redefinition in |with do concurrent
   |do-concurrent   |
   Severity|enhancement |normal

--- Comment #11 from Thomas Koenig  ---
(In reply to Chinoune from comment #10)

> 1- Why 'b' has been calculated correctly while 'a' hasn't ?! .the only
> difference between the two functions is ( +1. )

The behavior is undefined, this may work, or it may not.

> 2- I attached a new modified test and it fails.

OK... this one is indeed a wrong-code bug.  Setting regression
marker and adding wrong-code bug again.

I suspect a middle end problem, let's see if I can also
make this into a C test case.

[Bug c++/80297] [6/7 Regression] Compiler time crash: type mismatch in binary expression

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  4 19:14:47 2017
New Revision: 246693

URL: https://gcc.gnu.org/viewcvs?rev=246693=gcc=rev
Log:
PR c++/80297
* genmatch.c (capture::gen_transform): For GENERIC unshare_expr
captures used multiple times, except for the last use.
* generic-match-head.c: Include gimplify.h.

* g++.dg/torture/pr80297.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr80297.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/generic-match-head.c
trunk/gcc/genmatch.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/80304] Warn about variable redefinition in do-concurrent

[chinoune.mehdi at hotmail dot com]

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

Chinoune  changed:

   What|Removed |Added

  Attachment #41117|0   |1
is obsolete||

--- Comment #10 from Chinoune  ---
Created attachment 41129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41129=edit
modified test-program

(In reply to Thomas Koenig from comment #9)
> What you are doing is
> 
>   DO CONCURRENT( i=0:1 ,j=0:1)
> a = a + add(i,j,abs(i-j))
> b = b + add2(i,j,abs(i-j))
>   END DO
> 
> This causes the variables a and b to be defined multiple
> times in the loop.
> 
> In the standard, this is given in 8.1.6.7 of J3/10-007:
> 
>  A variable that is referenced in an iteration shall either be previously
> defined during that iteration, or
> shall not be defined or become undefined during any other iteration. A
> variable that is defined or becomes
> undefined by more than one iteration becomes undefined when the loop
> terminates.
> 
> Conceptually, when parallelizing, you cannot depend on a having
> any specific value during the loop execution, so the program
> might read a in one thread, have it changed by another thread,
> then add the value to it and store it back, losing what
> was done by the other thread.
> 
> You cannot do a sum like this with DO CONCURRENT.  In OpenMP terms,
> what you are attempting a reduction.
> 
> It would be nice to warn about this, though.

1- Why 'b' has been calculated correctly while 'a' hasn't ?! .the only
difference between the two functions is ( +1. )
2- I attached a new modified test and it fails.
3- The test-program works well with gfortran-5 gfortran-6 and Intel Fortran
2017.

[Bug middle-end/80283] [5/6/7 Regression] bad SIMD register allocation

[already5chosen at yahoo dot com]

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

--- Comment #11 from Michael_S  ---
Created attachment 41128
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41128=edit
ARMv7 case

ARMv7 - very similar to x64

[Bug middle-end/80283] [5/6/7 Regression] bad SIMD register allocation

[already5chosen at yahoo dot com]

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

--- Comment #10 from Michael_S  ---
Created attachment 41127
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41127=edit
bad reg allocation despite no-tree-ter

No problems

[Bug fortran/80304] Warn about variable redefinition in do-concurrent

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

   Keywords|wrong-code  |diagnostic
   Target Milestone|7.0 |---
Summary|[7 Regression]  |Warn about variable
   |do-concurrent dosn't work   |redefinition in
   |well with gfortran 7.   |do-concurrent
   Severity|normal  |enhancement

--- Comment #9 from Thomas Koenig  ---
What you are doing is

  DO CONCURRENT( i=0:1 ,j=0:1)
a = a + add(i,j,abs(i-j))
b = b + add2(i,j,abs(i-j))
  END DO

This causes the variables a and b to be defined multiple
times in the loop.

In the standard, this is given in 8.1.6.7 of J3/10-007:

 A variable that is referenced in an iteration shall either be previously
defined during that iteration, or
shall not be defined or become undefined during any other iteration. A variable
that is defined or becomes
undefined by more than one iteration becomes undefined when the loop
terminates.

Conceptually, when parallelizing, you cannot depend on a having
any specific value during the loop execution, so the program
might read a in one thread, have it changed by another thread,
then add the value to it and store it back, losing what
was done by the other thread.

You cannot do a sum like this with DO CONCURRENT.  In OpenMP terms,
what you are attempting a reduction.

It would be nice to warn about this, though.

[Bug middle-end/80283] [5/6/7 Regression] bad SIMD register allocation

[bernds at gcc dot gnu.org]

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

--- Comment #9 from Bernd Schmidt  ---
Cou(In reply to Michael_S from comment #8)
> Here is a variant that makes an issue to show on x64 with -fno-tree-ter.
> https://godbolt.org/g/mSLiRZ

Could you attach this here as well? I've been trying to get the testcase out of
godbolt, but there seems not to be a save option and copy & paste doesn't work
either.

In general, the problem is that ter makes pessimal scheduling decisions,
increasing register pressure. The patch I have adds a little mini-scheduler
into the expand stage to try to prevent this. In theory that should also work
for testcases where the bad scheduling was done manually, but I'd like to
check.

[Bug fortran/80304] [7 Regression] do-concurrent dosn't work well with gfortran 7.

[chinoune.mehdi at hotmail dot com]

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

--- Comment #8 from Chinoune  ---
(In reply to Thomas Koenig from comment #7)
> Fun fact: -flto also fixes it.

It fixes the first test not the second (comment #5)

[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 #5 from Jakub Jelinek  ---
(In reply to Bernd Edlinger from comment #4)
> weird, in function OTServerBaseNode::addReference
> the shadow ram is initialize correctly, and it
> is overwritten in line 671 immediately before the crash:
> 
> => 0x129fc870  rlwinm  r9,r29,29,3,31
> 2: x/i 0x37f7569c
>0x37f7569c:  .long 0x4f2f2
> => 0x129fc874  lwz r4,80(r31)
> 2: x/i 0x37f7569c
>0x37f7569c:  .long 0x4f2f2
> => 0x129fc878 addis   r9,r9,8192
> 2: x/i 0x37f7569c
>0x37f7569c:  .long 0x4f2f2
> => 0x129fc87c mr  r3,r29
> 2: x/i 0x37f7569c
>0x37f7569c:  .long 0x4f2f2
> => 0x129fc880 sth r10,0(r9)
> 2: x/i 0x37f7569c
>0x37f7569c:  .long 0x400f2f2
> => 0x129fc884bl  0x11e9cd64  const&)>

Can we have preprocessed source and g++ options for that?

[Bug sanitizer/80308] 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 #4 from Bernd Edlinger  ---
weird, in function OTServerBaseNode::addReference
the shadow ram is initialize correctly, and it
is overwritten in line 671 immediately before the crash:

=> 0x129fc870  rlwinm  r9,r29,29,3,31
2: x/i 0x37f7569c
   0x37f7569c:  .long 0x4f2f2
=> 0x129fc874  lwz r4,80(r31)
2: x/i 0x37f7569c
   0x37f7569c:  .long 0x4f2f2
=> 0x129fc878 addis   r9,r9,8192
2: x/i 0x37f7569c
   0x37f7569c:  .long 0x4f2f2
=> 0x129fc87c mr  r3,r29
2: x/i 0x37f7569c
   0x37f7569c:  .long 0x4f2f2
=> 0x129fc880 sth r10,0(r9)
2: x/i 0x37f7569c
   0x37f7569c:  .long 0x400f2f2
=> 0x129fc884bl  0x11e9cd64 

[Bug fortran/80304] [7 Regression] do-concurrent dosn't work well with gfortran 7.

[tkoenig at gcc dot gnu.org]

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

--- Comment #7 from Thomas Koenig  ---
Fun fact: -flto also fixes it.

[Bug middle-end/80283] [5/6/7 Regression] bad SIMD register allocation

[already5chosen at yahoo dot com]

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

Michael_S  changed:

   What|Removed |Added

 CC||already5chosen at yahoo dot com

--- Comment #8 from Michael_S  ---
Hi
I am person that originated the issue. I didn't want to take part in the
discussion, but Markus convinced me.

I want to add a couple of point:
1. It seems to me that the issue is not specific to x64. It is more general and
could happen on any machine with 16 SIMD registers.

2. Here is a demonstration of the issue on ARMv7 Neon.
https://godbolt.org/g/e9A5Yi
As an example of proper code generation you can look (on the same Godbolt) at
code, generated by Visual C.

3. Markus argues that ARMv7 Neon issue differs from x64. He appears to think
so, because x64 issue is cured by -fno-tree-ter and ARMv7 issue is not.
I disagree. According to my understanding tree-ter processing is just a trigger
of the problem, not the cause of it. The cause has to be a broken optimizer
heuristics.

4. To prove my point that relationship between the problem and the tree-ter on
x64 is incidental, I reformatted an original code in slightly different manner
(was I imitating tree-ter ? May be. But I didn't look at  tree-ter source
code).
Here is a variant that makes an issue to show on x64 with -fno-tree-ter.
https://godbolt.org/g/mSLiRZ

Best regards,
Michael

[Bug fortran/80304] [7 Regression] do-concurrent dosn't work well with gfortran 7.

[tkoenig at gcc dot gnu.org]

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

--- Comment #6 from Thomas Koenig  ---
The *.original dump shows ANNOTATE_EXPRs:

  if (ANNOTATE_EXPR ) goto L.3;
  i.0 = 0;
  count.2 = 2;
  while (1)
{
  if (ANNOTATE_EXPR ) goto L.2;

These were added in r204023, three years ago, so this is
not a recent change.

gcc 6 does not show this behavior, so it is very likely that
a recent change made this a bug (or exposed a latent bug).

Hmm... changing INTENT(IN) to VALUE makes the bug go away.
Something to do with inlining functions which pass index
variables of DO CONCURRENT by reference?

[Bug tree-optimization/79390] [7 Regression] 10% performance drop in SciMark2 LU after r242550

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  4 17:52:27 2017
New Revision: 246686

URL: https://gcc.gnu.org/viewcvs?rev=246686=gcc=rev
Log:
PR tree-optimization/79390
* target.h (struct noce_if_info): Declare.
* targhooks.h (default_noce_conversion_profitable_p): Declare.
* target.def (noce_conversion_profitable_p): New target hook.
* ifcvt.h (struct noce_if_info): New type, moved from ...
* ifcvt.c (struct noce_if_info): ... here.
(noce_conversion_profitable_p): Renamed to ...
(default_noce_conversion_profitable_p): ... this.  No longer
static nor inline.
(noce_try_store_flag_constants, noce_try_addcc,
noce_try_store_flag_mask, noce_try_cmove, noce_try_cmove_arith,
noce_convert_multiple_sets): Use targetm.noce_conversion_profitable_p
instead of noce_conversion_profitable_p.
* config/i386/i386.c: Include ifcvt.h.
(ix86_option_override_internal): Don't override
PARAM_MAX_RTL_IF_CONVERSION_INSNS default.
(ix86_noce_conversion_profitable_p): New function.
(TARGET_NOCE_CONVERSION_PROFITABLE_P): Redefine.
* config/i386/x86-tune.def (X86_TUNE_ONE_IF_CONV_INSN): Adjust comment.
* doc/tm.texi.in (TARGET_NOCE_CONVERSION_PROFITABLE_P): Add.
* doc/tm.texi: Regenerated.

* gcc.target/i386/pr79390.c: New test.
* gcc.dg/ifcvt-4.c: Use -mtune-ctrl=^one_if_conv_insn for i?86/x86_64.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr79390.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/x86-tune.def
trunk/gcc/doc/tm.texi
trunk/gcc/doc/tm.texi.in
trunk/gcc/ifcvt.c
trunk/gcc/ifcvt.h
trunk/gcc/target.def
trunk/gcc/target.h
trunk/gcc/targhooks.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/ifcvt-4.c

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

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

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

[redi at gcc dot gnu.org]

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

Bug ID: 80316
   Summary: std::promise treats no shared state as undefined
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This segfaults:

#include 
int main()
{
  std::promise p;
  std::promise q(std::move(p));
  p.set_exception_at_thread_exit(std::make_exception_ptr(1));
}

The spec for set_exception_at_thread_exit is clear:

Throws: future_error if an error condition occurs.
Error conditions:
 — promise_already_satisfied if its shared state already has a stored value or
exception.
 — no_state if *this has no shared state.

We also segfault for any of:

  p.set_value(1);
  p.set_value_at_thread_exit(1);
  p.set_exception(std::make_exception_ptr(1));

It's not clear whether these are undefined, but I'll create a DR for that.

[Bug libgcc/80314] Undefined reference to __dso_handle & __cxa_atexit

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|c++ |libgcc

--- Comment #1 from Jonathan Wakely  ---
I think these both need to come from either libc or libgcc.

[Bug target/80286] [5/6 Regression] AVX2 _mm_cvtsi128_si32 doesn't return a proper 32bits int

[gregory.hainaut at gmail dot com]

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

--- Comment #8 from gregory hainaut  ---
(In reply to Jakub Jelinek from comment #7)
> wrong-code fixed on the trunk so far, optimizations still not.

Thanks you for the quick fix :)

[Bug c/80315] New: Calling __builtin_crypto_vshasigmaw with argument 3 out of range creates an unrecognizable insn

[gcc at svenkoehler dot de]

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

Bug ID: 80315
   Summary: Calling __builtin_crypto_vshasigmaw with argument 3
out of range creates an unrecognizable insn
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at svenkoehler dot de
  Target Milestone: ---

Created attachment 41126
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41126=edit
Intermediate file of the source in question

Using the power8 crypto builtin with an argument 3 out of range 0..15 (thus
more that 4 bits) generates a further unrecognizable instruction:

res = __builtin_crypto_vshasigmaw(test, 1, 0xff);

results in:

breaking_sha.c: In function ‘main’:
breaking_sha.c:14:1: error: unrecognizable insn:
 }
 ^
(insn 10 9 11 2 (set (reg:V4SI 158)
(unspec:V4SI [
(reg:V4SI 159)
(const_int 1 [0x1])
(reg:SI 161)
] UNSPEC_VSHASIGMA)) breaking_sha.c:12 -1
 (nil))
breaking_sha.c:14:1: internal compiler error: in extract_insn, at
recog.c:2287
0x1067e9b3 _fatal_insn(char const*, rtx_def const*, char const*, int,
char const*)
../../src/gcc/rtl-error.c:108
0x1067ea17 _fatal_insn_not_found(rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:116
0x10644fe7 extract_insn(rtx_insn*)
../../src/gcc/recog.c:2287
0x10420567 instantiate_virtual_regs_in_insn
../../src/gcc/function.c:1582
0x10420567 instantiate_virtual_regs
../../src/gcc/function.c:1950
0x10420567 execute
../../src/gcc/function.c:1999
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Trace as of: gcc version 6.2.0 20160901 (Ubuntu 6.2.0-3ubuntu11~16.04)
Likewise with: gcc version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4)

[Bug c++/80296] Broken diagnostic 'unary_plus_expr' not supported by expression

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

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

--- Comment #4 from Volker Reichelt  ---
Fixed on trunk.

[Bug c++/80296] Broken diagnostic 'unary_plus_expr' not supported by expression

[reichelt at gcc dot gnu.org]

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

--- Comment #3 from Volker Reichelt  ---
Author: reichelt
Date: Tue Apr  4 16:30:44 2017
New Revision: 246683

URL: https://gcc.gnu.org/viewcvs?rev=246683=gcc=rev
Log:
PR c++/80296
* cxx-pretty-print.c (cxx_pretty_printer::expression): Add
UNARY_PLUS_EXPR case.

* g++.dg/cpp0x/alias-decl-80296.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-80296.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cxx-pretty-print.c
trunk/gcc/testsuite/ChangeLog

[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 #11 from Markus Trippelsdorf  ---
(In reply to Markus Trippelsdorf from comment #9)
> This was added as an PR79141 fix. CCing Nathan.

Sorry, wrong PR (too many tabs open).
I meant PR70393.

[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

--- Comment #2 from Thomas Preud'homme  ---
Author: thopre01
Date: Tue Apr  4 16:24:18 2017
New Revision: 246682

URL: https://gcc.gnu.org/viewcvs?rev=246682=gcc=rev
Log:
[ARM] Fix small multiply feature

2017-04-03  Thomas Preud'homme  

gcc/
PR target/80307
* config/arm/arm.c (thumb1_rtx_costs): Give a cost of 32
instructions for small multiply cores.

gcc/testsuite/
PR target/80307
* gcc.target/arm/small-multiply-m0-1.c: Do not skip test if not
targeting any CPU or architecture.
* gcc.target/arm/small-multiply-m0-2.c: Likewise.
* gcc.target/arm/small-multiply-m0-3.c: Likewise.
* gcc.target/arm/small-multiply-m0plus-1.c: Likewise.
* gcc.target/arm/small-multiply-m0plus-2.c: Likewise.
* gcc.target/arm/small-multiply-m0plus-3.c: Likewise.
* gcc.target/arm/small-multiply-m1-1.c: Likewise.
* gcc.target/arm/small-multiply-m1-2.c: Likewise.
* gcc.target/arm/small-multiply-m1-3.c: Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/arm/small-multiply-m0-1.c
trunk/gcc/testsuite/gcc.target/arm/small-multiply-m0-2.c
trunk/gcc/testsuite/gcc.target/arm/small-multiply-m0-3.c
trunk/gcc/testsuite/gcc.target/arm/small-multiply-m0plus-1.c
trunk/gcc/testsuite/gcc.target/arm/small-multiply-m0plus-2.c
trunk/gcc/testsuite/gcc.target/arm/small-multiply-m0plus-3.c
trunk/gcc/testsuite/gcc.target/arm/small-multiply-m1-1.c
trunk/gcc/testsuite/gcc.target/arm/small-multiply-m1-2.c
trunk/gcc/testsuite/gcc.target/arm/small-multiply-m1-3.c

[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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/80314] New: Undefined reference to __dso_handle & __cxa_atexit

[sbansal at ciena dot com]

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

Bug ID: 80314
   Summary: Undefined reference to __dso_handle & __cxa_atexit
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbansal at ciena dot com
  Target Milestone: ---

I am seeing undefined reference to __dso_handle and __cxa_texit during linking
stage.

BinUtils version : 2.23.52.20130219

What could be the possible problem?

hax-dgera-1|

[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 #10 from Markus Trippelsdorf  ---
I've posted the simple patch here:
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00132.html

[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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #9 from Markus Trippelsdorf  ---
This was added as an PR79141 fix. CCing Nathan.

[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 #8 from Jakub Jelinek  ---
ICE started with r218220.

[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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
{.value_=}
looks broken to me.
It has been added by
  /* We fell off the end of the CONSTRUCTOR, so insert a new
 entry at the end.  */
insert:
  {
constructor_elt ce = { index, NULL_TREE };

vec_safe_insert (CONSTRUCTOR_ELTS (*valp), idx, ce);
cep = CONSTRUCTOR_ELT (*valp, idx);

[Bug translation/80280] Missing closing quote (%>) c/semantics.c and c/c-typeck.c

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Looks like these were all fixed on trunk in r237843.

[Bug target/80313] New: -march=znver1 produce worse code than -march=haswell

[vincenzo.innocente at cern dot ch]

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

Bug ID: 80313
   Summary: -march=znver1 produce worse code than -march=haswell
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincenzo.innocente at cern dot ch
  Target Milestone: ---

Created attachment 41125
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41125=edit
sef contained scimark2 MC benchmark

just got hold of a AMD Ryzen 7 1800X Eight-Core Processor and was surprised by
the results running with -march=native
the point is that the results can be reproduced on a haswell or broadwell as
well!

I used full scimark2,

just the MC benchmark shows at least one problem

this is on intel
[innocent@vinavx3 fullMC]$ gcc -march=znver1 -O3 fullMC.c -g ; time ./a.out
1.245u 0.000s 0:01.24 100.0%0+0k 0+0io 0pf+0w
[innocent@vinavx3 fullMC]$ gcc -O3 fullMC.c -g ; time ./a.out
0.327u 0.000s 0:00.32 100.0%0+0k 0+0io 0pf+0w
[innocent@vinavx3 fullMC]$ gcc -march=broadwell -O3 fullMC.c -g ; time ./a.out
0.308u 0.000s 0:00.30 100.0%0+0k 0+0io 0pf+0w

this is on ryzen
[innocent@vinzen0 fullMC]$ gcc -march=znver1 -O3 fullMC.c -g ; time ./a.out
1.354u 0.001s 0:01.35 100.0%0+0k 0+0io 0pf+0w
[innocent@vinzen0 fullMC]$ gcc -O3 fullMC.c -g ; time ./a.out
0.315u 0.000s 0:00.31 100.0%0+0k 0+0io 0pf+0w
[innocent@vinzen0 fullMC]$ gcc -march=broadwell -O3 fullMC.c -g ; time ./a.out
0.313u 0.001s 0:00.31 100.0%0+0k 0+0io 0pf+0w

[Bug other/80312] New: libatomic: add -fasynchronous-unwind-tables option for building

[tony.reix at atos dot net]

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

Bug ID: 80312
   Summary: libatomic: add -fasynchronous-unwind-tables option for
building
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tony.reix at atos dot net
  Target Milestone: ---

Build libatomic with -fasynchronous-unwind-tables .
It is required on AIX, at least, for Go.
(suggestion in a discussion with Ian Lance Taylor)

[Bug fortran/80304] [7 Regression] do-concurrent dosn't work well with gfortran 7.

[chinoune.mehdi at hotmail dot com]

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

--- Comment #5 from Chinoune  ---
Created attachment 41124
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41124=edit
the second test program

This is another test which fails with all the optimizations directives (except
-Og).

[Bug other/65530] [meta-bug] -mmpx -fcheck-pointer-bounds failures

[marxin at gcc dot gnu.org]

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

Bug 78631 Summary: [Intel MPX] libmpxwrappers shared library leads to a 
non-bounds-preserving memcpy()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78631

   What|Removed |Added

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

[Bug target/78631] [Intel MPX] libmpxwrappers shared library leads to a non-bounds-preserving memcpy()

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #16 from Martin Liška  ---
No reply, closing as resolved.

[Bug gcov-profile/35591] value profiling tuning

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Sounds interesting. I'm planning to switch default counter type for string
routines to Top N. That would allow such transformations. Do you have any
interesting benchmark where one can see a speed gap benefiting from the
optimization?

[Bug gcov-profile/35543] Add more strOp for value profiling

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
> 
> Yes, looks like it is done for memcpy, memset, bzero, etc, but not strncmp,
> memcmp, memmove, strncpy etc.
> 
> 

Hi David.

Do you have any interesting benchmarks where optimization of such function
would be beneficial and makes a speed gap?

Thanks,
Martin

[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

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

--- Comment #14 from Martin Liška  ---
One remaining file is parameterregistry.cpp.gcno file.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug target/80310] [7 Regression] Bogus -Wpsabi warning with -fsanitize=signed-integer-overflow

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug c++/80311] New: Bound member functions extension allows bogus conversions

[redi at gcc dot gnu.org]

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

Bug ID: 80311
   Summary: Bound member functions extension allows bogus
conversions
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

struct X {
  int i = 0;
  int f() { return i; }
};

int main() {
  X x;
  using fp = int (*)();
  auto f = (fp)(::f);
  return f();
}

This bogus attempt to use
https://gcc.gnu.org/onlinedocs/gcc/Bound-member-functions.html fails, because
there is no 'this' pointer provided for the call to the bound function.

G++ should notice this and give a diagnostic, even with -Wno-pmf-conversions.

The diagnostic should be given when converting to a function pointer that
doesn't match the arguments that would be needed for the bound function.

i.e. for (fp)(::f) or (fp)(x.*pmf) where that resovles to a pointer to:

  R Y::f(Args...)

we should warn if fp is not R (*)(Y*, Args...).

This should simply be an error, not a warning. I see no reason to allow the
extension to form invalid function pointers. Code that really really wants to
do so can always perform a conversion after forming the bound function pointer:

struct X {
  int i = 0;
  int f() { return i; }
};

int main() {
  X x;
  using wrong_type = int(*)();
  using right_type = int(*)(X*);
  auto f = (wrong_type)(right_type)(::f);
  return ((right_type)f)();
}

Maybe -fpermissive could cause it to be allowed without the extra conversion,
for legacy code misusing the feature.

[Bug target/80306] ICE in cfgexpand.c during cross-compilation for mips target

[niva at niisi dot msk.ru]

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

niva at niisi dot msk.ru changed:

   What|Removed |Added

  Known to fail||4.7.4

--- Comment #1 from niva at niisi dot msk.ru ---
The bug is also reproduced with gcc-7.0.0 20160510 (experimental)

[Bug target/80310] [7 Regression] Bogus -Wpsabi warning with -fsanitize=signed-integer-overflow

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-04-04
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

[Bug target/80310] New: [7 Regression] Bogus -Wpsabi warning with -fsanitize=signed-integer-overflow

[jakub at gcc dot gnu.org]

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

Bug ID: 80310
   Summary: [7 Regression] Bogus -Wpsabi warning with
-fsanitize=signed-integer-overflow
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

/* { dg-do compile } */
/* { dg-options "-O2 -fsanitize=signed-integer-overflow" } */
/* { dg-additional-options "-mno-avx" { target i?86-*-* x86_64-*-* } } */

typedef int V __attribute__((vector_size (32)));

void
foo (V *a, V *b, V *c)
{
  *a = *b + *c; /* { dg-bogus "AVX vector return without AVX enabled
changes the ABI" "" { target i?86-*-* x86_64-*-* } } */
}

gets warning in 7+, even when there is no actual function that returns in AVX
registers.

[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 #3 from Markus Trippelsdorf  ---
Ugh, looks like a garbage collector issue.

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

[koenigni at gcc dot gnu.org]

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

--- Comment #7 from koenigni at gcc dot gnu.org ---
Author: koenigni
Date: Tue Apr  4 13:41:41 2017
New Revision: 246679

URL: https://gcc.gnu.org/viewcvs?rev=246679=gcc=rev
Log:

2017-03-18  Nicolas Koenig   
PR fortran/69498
* symbol.c (gfc_delete_symtree): If there is a period in the
name, ignore
everything before it.

2017-03-18  Nicolas Koenig  
PR fortran/69498
* gfortran.dg/submodule_unexp.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/submodule_unexp.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/symbol.c
trunk/gcc/testsuite/ChangeLog

[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 #2 from Markus Trippelsdorf  ---
Started with r246653.

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
Confirmed.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Priority|P3  |P1
   Target Milestone|--- |7.0

[Bug c++/80309] New: [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

Bug ID: 80309
   Summary: [7 Regression] ICE: canonical types differ for
identical types _Args2 and _Args2
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---

A very recent regression:

markus@x4 gcc % g++ -c -std=gnu++17 -mavx2
./libstdc++-v3/testsuite/20_util/pair/cons/deduction.cc
./libstdc++-v3/testsuite/20_util/pair/cons/deduction.cc: In function ‘void
test01()’:
./libstdc++-v3/testsuite/20_util/pair/cons/deduction.cc:50:30: internal
compiler error: canonical types differ for identical types _Args2 and _Args2
   std::pair mo{MoveOnly(), 2l};
  ^
0x7331ea comptypes(tree_node*, tree_node*, int)
/home/markus/gcc/gcc/cp/typeck.c:1433
0x629005 template_args_equal(tree_node*, tree_node*, bool)
/home/markus/gcc/gcc/cp/pt.c:8300
0x628f62 template_args_equal(tree_node*, tree_node*, bool)
/home/markus/gcc/gcc/cp/pt.c:8257
0x62909a template_args_equal(tree_node*, tree_node*, bool)
/home/markus/gcc/gcc/cp/pt.c:8275
0x628caf comp_template_args(tree_node*, tree_node*, tree_node**, tree_node**,
bool)
/home/markus/gcc/gcc/cp/pt.c:8348
0x6357a9 spec_hasher::equal(spec_entry*, spec_entry*)
/home/markus/gcc/gcc/cp/pt.c:1660
0x68def6 hash_table::find_with_hash(spec_entry*
const&, unsigned int)
/home/markus/gcc/gcc/hash-table.h:856
0x66e9dd lookup_template_class_1
/home/markus/gcc/gcc/cp/pt.c:8696
0x66e9dd lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/home/markus/gcc/gcc/cp/pt.c:9009
0x671f48 tsubst_aggr_type
/home/markus/gcc/gcc/cp/pt.c:11905
0x643e03 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/markus/gcc/gcc/cp/pt.c:13405
0x644188 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/markus/gcc/gcc/cp/pt.c:13395
0x65bb67 tsubst_arg_types
/home/markus/gcc/gcc/cp/pt.c:13007
0x65ba45 tsubst_arg_types
/home/markus/gcc/gcc/cp/pt.c:12976
0x65e512 build_deduction_guide
/home/markus/gcc/gcc/cp/pt.c:25133
0x63c031 do_class_deduction
/home/markus/gcc/gcc/cp/pt.c:25225
0x63c031 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
/home/markus/gcc/gcc/cp/pt.c:25331
0x615ca7 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
/home/markus/gcc/gcc/cp/decl.c:6835
0x6f860d cp_parser_init_declarator
/home/markus/gcc/gcc/cp/parser.c:19380
0x71dc18 cp_parser_simple_declaration
/home/markus/gcc/gcc/cp/parser.c:12777

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

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Ok, looks there's just ppc64 in the compile farm. Running on gcc110, asan.exp
works all fine except c-c++-common/asan/swapcontext-test-1.c.

I also verified that w/ -m32, shadow memory in properly prepared:

=>0x3ff758e0: 00 00 f1 f1 f1 f1 00[04]f2 f2 f3 f3 f3 f3 00 00

If you have a reduced test-case, I can help.

[Bug c++/80290] [6/7 Regression] g++ uses unreasonable amount of memory compiling nested string maps

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener  ---
(In reply to Richard Biener from comment #13)
> typedef std::pair > > FruMap;
> extern const FruMap frus[] = {
> { 1, { "", { "", {"",""}, }, }, },
> };
> 
> is twice as fast as
> 
> typedef std::pair > > > FruMap;
> 
> extern const FruMap frus[] = {
> { 1, { "", { "", { "", {"",""}, }, } }, },
> };
> 
> the latter with 70713 implicit_conversion calls while the former with "only"
> 14331 implicit_conversion calls.  Removing another std::pair<> level reduces
> it to 4389 calls (still 10689 tsubst_copy_and_build calls(!)).

Similar amount of cxx_eval_call_expression so it boils down to constexpr
handling...

[Bug c++/80290] [6/7 Regression] g++ uses unreasonable amount of memory compiling nested string maps

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener  ---
typedef std::pair > > FruMap;
extern const FruMap frus[] = {
{ 1, { "", { "", {"",""}, }, }, },
};

is twice as fast as

typedef std::pair > > > FruMap;

extern const FruMap frus[] = {
{ 1, { "", { "", { "", {"",""}, }, } }, },
};

the latter with 70713 implicit_conversion calls while the former with "only"
14331 implicit_conversion calls.  Removing another std::pair<> level reduces
it to 4389 calls (still 10689 tsubst_copy_and_build calls(!)).

typedef std::pair > FruMap;
extern const FruMap frus[] = {
{ 1, { "", {"",""}, }, },
};  

constexpr evaluation seems to cause quite some bits of it.  The constexpr hash
is quite big and we arrive with following exprs to evaluate/cache:

{}
0 || 0
std::_PCC::_ConstructiblePair ()
!std::_PCC::_ImplicitlyConvertiblePair ()
std::_PCC::_ConstructiblePair () && !std::_PCC::_ImplicitlyConvertiblePair ()

and for the && we don't use the cached LHS we computed above because
we don't use maybe_constant_value for example in cxx_eval_logical_expression
but we recurse into cxx_eval_constant_expression!

A simple patch like

Index: gcc/cp/constexpr.c
===
--- gcc/cp/constexpr.c  (revision 246678)
+++ gcc/cp/constexpr.c  (working copy)
@@ -3860,6 +3860,9 @@ lookup_placeholder (const constexpr_ctx
   return ob;
 }

+static GTY((deletable)) hash_map *cv_cache;
+
+
 /* Attempt to reduce the expression T to a constant value.
On failure, issue diagnostic and return error_mark_node.  */
 /* FIXME unify with c_fully_fold */
@@ -3874,6 +3877,11 @@ cxx_eval_constant_expression (const cons
   constexpr_ctx new_ctx;
   tree r = t;

+  tree *cached;
+  if (cv_cache
+  && (cached = cv_cache->get (t)))
+return *cached;
+
   if (jump_target && *jump_target)
 {
   /* If we are jumping, ignore all statements/expressions except those
@@ -4824,8 +4832,6 @@ fold_simple (tree t)
Otherwise, if T does not have TREE_CONSTANT set, returns T.
Otherwise, returns a version of T without TREE_CONSTANT.  */

-static GTY((deletable)) hash_map *cv_cache;
-
 tree
 maybe_constant_value (tree t, tree decl)
 {

should improve this, but while it catches some cases it doesn't result in
an overall improvement.  The patch is likely incorrect anyway.

But I think it shows the issue (and likely the patch doesn't help because
"equivalent" calls are not detected as such by the cv_cache map which
ends up with pointer equivalence AFAICS).

Oh, and there are constexpr evaluations that do not go through the cache
anyway (potential_constant_expression, cxx_constant_value)

[Bug c++/71577] [6/7 regression] ICE on invalid C++11 code (with extra struct initializer) on x86_64-linux-gnu: in digest_init_r, at cp/typeck2.c:1117

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com

--- Comment #7 from Paolo Carlini  ---
Mine.

[Bug sanitizer/80308] 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 #2 from Bernd Edlinger  ---
(In reply to Martin Liška from comment #1)
> I'll take a look. Can I reproduce it on a machine we have in compile farm?

No, idea, if I find time, I will try to get a smaller test case.

[Bug c++/80290] [6/7 Regression] g++ uses unreasonable amount of memory compiling nested string maps

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #12 from Richard Biener  ---
switching offender to the C++ FE

[Bug c++/80297] [6/7 Regression] Compiler time crash: type mismatch in binary expression

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On Tue, 4 Apr 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80297
> 
> --- Comment #8 from Jakub Jelinek  ---
> Created attachment 41121
>   --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41121=edit
> gcc7-pr80297.patch
> 
> Patch I'm going to test.

LGTM.

[Bug c++/80297] [6/7 Regression] Compiler time crash: type mismatch in binary expression

[jakub at gcc dot gnu.org]

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

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

Patch I'm going to test.

[Bug c++/80038] [6/7 Regression] Random segfault using local vectors in Cilk function

[ryxi at stu dot xidian.edu.cn]

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

--- Comment #29 from Xi Ruoyao  ---
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg01563.html

Patch proposal

[Bug sanitizer/80308] 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

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

--- Comment #1 from Martin Liška  ---
I'll take a look. Can I reproduce it on a machine we have in compile farm?

[Bug rtl-optimization/77919] [5 Regression] ICE converting DC to V2DF mode

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

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

--- Comment #13 from Andreas Krebbel  ---
Fixed by Jakub's patches.

[Bug target/79893] ICE in s390_adjust_builtin_arglist in gcc/config/s390/s390-c.c:679

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

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

--- Comment #5 from Andreas Krebbel  ---
Fixed with patch from comment 4

[Bug target/79904] ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

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

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

[Bug libstdc++/80290] [6/7 Regression] g++ uses unreasonable amount of memory compiling nested string maps

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
With gcc-6 every extra member of the init-list increases memory usage
dramatically:

 TOTAL :   0.64 0.17 0.82 126289 kB
 TOTAL :   0.76 0.23 1.00 147632 kB
 TOTAL :   0.88 0.26 1.15 168975 kB

but with gcc-5:

 TOTAL:   0.03 0.01 0.06   8390 kB
 TOTAL:   0.03 0.01 0.05   8727 kB
 TOTAL:   0.05 0.02 0.08   9064 kB

[Bug libstdc++/80290] [6/7 Regression] g++ uses unreasonable amount of memory compiling nested string maps

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Or even just:

#include 

typedef std::pair > > > FruMap;

#define INIT { 1, { "", { "", { "", {"",""}, }, } }, }

extern const FruMap frus[] = {
INIT,
INIT,
INIT,
INIT,
INIT,
};

All the time is spent in implicit_conversion().

[Bug libstdc++/80290] [6/7 Regression] g++ uses unreasonable amount of memory compiling nested string maps

[redi at gcc dot gnu.org]

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

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

#include 

typedef std::pair > > > FruMap;

#define INIT { 1, \
  { "/system/chassis/motherboard/cpu0", \
{ "xyz.openbmc_project.Inventory.Decorator.Asset", \
  { "PartNumber", \
{"IPMIFruSection","Board"}, \
  }, \
} \
  }, \
}

extern const FruMap frus[] = {
INIT,
INIT,
INIT,
INIT,
INIT,
};


GCC 5:

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 (17%) wall 
  1323 kB (15%) ggc
 phase parsing   :   0.04 (100%) usr   0.01 (100%) sys   0.05 (83%)
wall7520 kB (84%) ggc
 |name lookup:   0.01 (25%) usr   0.00 ( 0%) sys   0.03 (50%) wall 
   581 kB ( 7%) ggc
 |overload resolution:   0.01 (25%) usr   0.00 ( 0%) sys   0.01 (17%) wall 
  1867 kB (21%) ggc
 parser (global) :   0.02 (50%) usr   0.00 ( 0%) sys   0.02 (33%) wall 
  2692 kB (30%) ggc
 parser struct body  :   0.01 (25%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
   911 kB (10%) ggc
 template instantiation  :   0.01 (25%) usr   0.01 (100%) sys   0.03 (50%) wall
   3239 kB (36%) ggc
 TOTAL :   0.04 0.01 0.06  
8941 kB


GCC 6:

Execution times (seconds)
 phase setup :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 1%) wall 
  1397 kB ( 1%) ggc
 phase parsing   :   0.62 (98%) usr   0.19 (100%) sys   0.81 (96%) wall
 125355 kB (99%) ggc
 phase opt and generate  :   0.01 ( 2%) usr   0.00 ( 0%) sys   0.02 ( 2%) wall 
   231 kB ( 0%) ggc
 |name lookup:   0.01 ( 2%) usr   0.01 ( 5%) sys   0.00 ( 0%) wall 
  1155 kB ( 1%) ggc
 |overload resolution:   0.24 (38%) usr   0.04 (21%) sys   0.27 (32%) wall 
 68949 kB (54%) ggc
 callgraph construction  :   0.01 ( 2%) usr   0.00 ( 0%) sys   0.01 ( 1%) wall 
   231 kB ( 0%) ggc
 callgraph optimization  :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 1%) wall 
 0 kB ( 0%) ggc
 preprocessing   :   0.01 ( 2%) usr   0.00 ( 0%) sys   0.01 ( 1%) wall 
   187 kB ( 0%) ggc
 parser (global) :   0.36 (57%) usr   0.10 (53%) sys   0.55 (65%) wall 
103307 kB (81%) ggc
 parser struct body  :   0.01 ( 2%) usr   0.00 ( 0%) sys   0.01 ( 1%) wall 
  1227 kB ( 1%) ggc
 parser inl. meth. body  :   0.01 ( 2%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
95 kB ( 0%) ggc
 template instantiation  :   0.21 (33%) usr   0.09 (47%) sys   0.24 (29%) wall 
 19154 kB (15%) ggc
 symout  :   0.02 ( 3%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
  1387 kB ( 1%) ggc
 TOTAL :   0.63 0.19 0.84
127016 kB

[Bug libstdc++/80290] [6/7 Regression] g++ uses unreasonable amount of memory compiling nested string maps

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
The drastic slowdown started with r225189

We can't realistically revert that, so we'll have to find a way to make the FE
faster. I don't really know what I'm talking about, but I like this idea:

(In reply to Richard Biener from comment #3)
> I wonder if some trivial caching of "last elements overload set" during
> initializer processing could speed up things dramatically and avoid
> generating so much garbage
> (we don't GC during a single check_initializer call).

[Bug target/80286] [5/6 Regression] AVX2 _mm_cvtsi128_si32 doesn't return a proper 32bits int

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[5/6/7 Regression] AVX2 |[5/6 Regression] AVX2
   |_mm_cvtsi128_si32 doesn't   |_mm_cvtsi128_si32 doesn't
   |return a proper 32bits int  |return a proper 32bits int

--- Comment #7 from Jakub Jelinek  ---
wrong-code fixed on the trunk so far, optimizations still not.

[Bug libgomp/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug target/80286] [5/6/7 Regression] AVX2 _mm_cvtsi128_si32 doesn't return a proper 32bits int

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  4 10:45:55 2017
New Revision: 246676

URL: https://gcc.gnu.org/viewcvs?rev=246676=gcc=rev
Log:
PR target/80286
* config/i386/i386.c (ix86_expand_args_builtin): If op has scalar
int mode, convert_modes it to mode as unsigned, otherwise use
lowpart_subreg to mode rather than SImode.
* config/i386/sse.md (ashr3,
ashr3, ashr3, 3):
Use DImode instead of SImode for the shift count operand.
* config/i386/mmx.md (mmx_ashr3, mmx_3):
Likewise.
testsuite/
* gcc.target/i386/avx-pr80286.c: New test.
* gcc.dg/pr80286.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr80286.c
trunk/gcc/testsuite/gcc.target/i386/avx-pr80286.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/config/i386/mmx.md
trunk/gcc/config/i386/sse.md
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/80290] [6/7 Regression] g++ uses unreasonable amount of memory compiling nested string maps

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

[Bug libgomp/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16

[jakub at gcc dot gnu.org]

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

--- Comment #16 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr  4 10:41:33 2017
New Revision: 246675

URL: https://gcc.gnu.org/viewcvs?rev=246675=gcc=rev
Log:
PR libgomp/79876
* config/posix/thread-stacksize.h: New file.
* config/darwin/thread-stacksize.h: New file.
* config/nvptx/thread-stacksize.h: New file.
* env.c: Include thread-stacksize.h.
(initialize_env): Initialize stacksize to GOMP_DEFAULT_STACKSIZE
instead of 0.  Call pthread_attr_setstacksize even if
GOMP_DEFAULT_STACKSIZE is non-zero.

Added:
trunk/libgomp/config/darwin/thread-stacksize.h
trunk/libgomp/config/nvptx/thread-stacksize.h
trunk/libgomp/config/posix/thread-stacksize.h
Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/env.c

[Bug c++/80297] [6/7 Regression] Compiler time crash: type mismatch in binary expression

[rguenther at suse dot de]

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

--- Comment #7 from rguenther at suse dot de  ---
On Tue, 4 Apr 2017, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80297
> 
> --- Comment #6 from Jakub Jelinek  ---
> (In reply to Richard Biener from comment #5)
> > We can experiment with adding unshare_exprs to genmatch and see in how many
> > patterns that triggers.  But as said, the general issue looks latent to me.
> > Folding during gimplification is dangerous.
> 
> It isn't just folding during gimplification, we have hundreds of fold_build*
> calls in tons of GIMPLE passes too, and at that point unsharing is also 
> needed.

Well, any GENERIC created there needs to go through force_gimple_operand
again.  Hmm, but that doesn't unshare either.

> I'll try to implement the unsharing and we can see how many patterns it 
> affects
> and based on that decide if we want some cfun flag to control the unsharing or
> not, ok?

Ok.  But given the above we have no choice..

What are the exact rules for GENERIC?  ISTR it was that 
sub-expression sharing is allowed, right?  Or is that just for
frontend GENERIC?  OTOH it would mean that fold-const.c has to cope
with tree sharing but may not generate "new" sharing?  That would be
quite a difficult thing to verify with a verifier...

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

[bernd.edlinger at hotmail dot de]

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

Bug ID: 80308
   Summary: asan crash on big-endian powerpc-linux target
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

I use gcc-7 from snapshot, and glibc-2.19 and linux-2.6.29

I have crashes with an object of size 12,
in the constructor is a memset(this, 0, sizeof(*this));

asan crashes: note the impossible shadow bytes
look like little-bigendian issue, bytes should be
f2 f2 00 04 f2 f2  but are actually  f2 f2 04 00 f2 f2


=
==8369==ERROR: AddressSanitizer: unknown-crash on address 0xbfa184e4 at pc
0x0fa67dbc bp 0xbfa17520 sp 0xbfa17528
WRITE of size 8 at 0xbfa184e4 thread T0
#0 0xfa67db8 in __interceptor_memset
../../../../gcc-7-20170402/libsanitizer/asan/asan_interceptors.cc:471
#1 0x11e9cdb0 in NodeIdStruct::NodeIdStruct(NodeIdStruct const&)
../../../../Core/OT/NodeIdStruct.cpp:23
#2 0x129fc884 in std::pair
>::pair(NodeIdStruct&,
SOCmnPointer&)
/home/ed/gnu/powerpc-linux-new/powerpc-linux/include/c++/7.0.1/bits/stl_pair.h:324
#3 0x129fc884 in OTServerBaseNode::addReference(OTServerBaseNode*,
NodeIdStruct const*, bool) ../../../../Core/OT/OTServerBaseNode.cpp:671
#4 0x128ba1e4 in SOCmnPointer
OTServerAddressSpaceRoot::addObjectT(OTServerBaseNode*, char
const*, tagEnumNumericNodeId, tagEnumNumericNodeId, tagEnumNumericNodeId)
../../../../Core/OT/OTServerAddressSpaceRoot.cpp:2266
#5 0x1281d438 in OTServerAddressSpaceRoot::initialize(bool)
../../../../Core/OT/OTServerAddressSpaceRoot.cpp:886
#6 0x11f3a90c in
OTApplication::initialize_API(ApplicationDescriptionStruct*)
../../../../Core/OT/OTApplication.cpp:1389
#7 0x112ab07c in TestEnvironment::startApplication()
/home/ed/OPCToolboxV5/Source/Apps/Test/UnitTests/OT/TestEnvironment.cpp:52
#8 0x112ab07c in TestEnvironment::SetUp()
/home/ed/OPCToolboxV5/Source/Apps/Test/UnitTests/OT/TestEnvironment.cpp:10
#9 0x113a59a8 in SetUpEnvironment ../gmock-1.6.0/gtest/src/gtest.cc:4133
#10 0x113a59a8 in void
(*std::for_each<__gnu_cxx::__normal_iterator > >,
void
(*)(testing::Environment*)>(__gnu_cxx::__normal_iterator > >,
__gnu_cxx::__normal_iterator > >,
void (*)(testing::Environment*)))(testing::Environment*)
/home/ed/gnu/powerpc-linux-new/powerpc-linux/include/c++/7.0.1/bits/stl_algo.h:3884
#11 0x113a59a8 in void
testing::internal::ForEach >, void
(*)(testing::Environment*)>(std::vector > const&, void
(*)(testing::Environment*)) ../gmock-1.6.0/gtest/src/gtest-internal-inl.h:287
#12 0x113a59a8 in testing::internal::UnitTestImpl::RunAllTests()
../gmock-1.6.0/gtest/src/gtest.cc:4229
#13 0x113aa6a0 in bool
testing::internal::HandleSehExceptionsInMethodIfSupported(testing::internal::UnitTestImpl*, bool
(testing::internal::UnitTestImpl::*)(), char const*)
../gmock-1.6.0/gtest/src/gtest.cc:2090
#14 0x113aa6a0 in bool
testing::internal::HandleExceptionsInMethodIfSupported(testing::internal::UnitTestImpl*, bool
(testing::internal::UnitTestImpl::*)(), char const*)
../gmock-1.6.0/gtest/src/gtest.cc:2126
#15 0x113aa6a0 in testing::UnitTest::Run()
../gmock-1.6.0/gtest/src/gtest.cc:3871
#16 0x1003b9e8 in main
/home/ed/OPCToolboxV5/Source/Apps/Test/UnitTests/OT/main.cpp:44
#17 0xeff0300 in generic_start_main ../csu/libc-start.c:285

Address 0xbfa184e4 is located in stack of thread T0 at offset 2724 in frame
#0 0x129f7c30 in OTServerBaseNode::addReference(OTServerBaseNode*,
NodeIdStruct const*, bool) ../../../../Core/OT/OTServerBaseNode.cpp:404

  This frame has 112 object(s):
[32, 33) ''
[96, 97) ''
[160, 161) ''
[224, 225) ''
[288, 289) ''
[352, 353) ''
[416, 417) ''
[480, 481) ''
[544, 545) ''
[608, 609) ''
[672, 673) ''
[736, 737) ''
[800, 801) ''
[864, 868) ''
[928, 932) 'it'
[992, 996) ''
[1056, 1060) ''
[1120, 1124) ''
[1184, 1188) ''
[1248, 1252) ''
[1312, 1316) ''
[1376, 1380) ''
[1440, 1444) 'it'
[1504, 1508) ''
[1568, 1572) ''
[1632,