[Bug c++/71154] Attributes for an explicit template instantiation are ignored

[abbeyj+gcc at gmail dot com]

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

--- Comment #3 from James Abbatiello  ---
Andrew Pinsky, I'm not sure I understand your comment.  Why would the
visibility of D be affected by the visibility of C?  If I change your test
case so that C is declared as hidden before the definition of D then I get
this warning:

warning: ‘D’ declared with greater visibility than the type of its field ‘D::a’
[-Wattributes]

But it is just a warning and it does not cause D to have hidden visibility. 
Did you have some different test in mind?

I've also tried your testcase with clang++ and it acts as I would expect (D is
visible, C is hidden).  So it seems that it is possible to support this
behavior even if it might be difficult within g++ for some reason.

Can you please unresolve this bug?  Limit it just the visibility attribute if
you need to but I still want this change.

[Bug c++/71774] [4.9/5/6/7 regression] Bogus "is protected" error when list-initializing a base class with a defaulted protected constructor and a virtual function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/71561] [5/6/7 Regression] ICE with -Wall on valid C++ code on x86_64-linux-gnu: in potential_constant_expression_1, at cp/constexpr.c:5249

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Dup.

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

[Bug c++/71728] [5 Regression] ICE with goto in statement-expression inside a condition

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||su at cs dot ucdavis.edu

--- Comment #7 from Jason Merrill  ---
*** Bug 71561 has been marked as a duplicate of this bug. ***

[Bug c++/69223] [5/6/7 regression] ICE with polymorphic lambda

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Fri Jul 22 03:57:43 2016
New Revision: 238631

URL: https://gcc.gnu.org/viewcvs?rev=238631=gcc=rev
Log:
PR c++/69223 - ICE with deduced template return type.

* semantics.c (apply_deduced_return_type): Call
complete_type_or_else before building the new RESULT_DECL.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-deduce3.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/semantics.c

[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.5 |4.9.5

--- Comment #8 from Jason Merrill  ---
Fixed.

[Bug c++/71630] [5/6/7 Regression] ICE on valid C++14 code with variable templates: in get, at cgraph.h:395

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/69223] [5/6/7 regression] ICE with polymorphic lambda

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.5 |4.9.5

--- Comment #7 from Jason Merrill  ---
Fixed.

[Bug c++/71274] [5/6 Regression] deprecated static const member of struct raises warning without use

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

Summary|[5/6/7 Regression]  |[5/6 Regression] deprecated
   |deprecated static const |static const member of
   |member of struct raises |struct raises warning
   |warning without use |without use

--- Comment #3 from Jason Merrill  ---
Fixed on trunk so far.

[Bug c++/69223] [5/6/7 regression] ICE with polymorphic lambda

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Fri Jul 22 03:51:22 2016
New Revision: 238630

URL: https://gcc.gnu.org/viewcvs?rev=238630=gcc=rev
Log:
PR c++/69223 - ICE with deduced template return type.

* semantics.c (apply_deduced_return_type): Call
complete_type_or_else before building the new RESULT_DECL.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-deduce3.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/semantics.c

[Bug c++/71630] [5/6/7 Regression] ICE on valid C++14 code with variable templates: in get, at cgraph.h:395

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Jul 22 03:51:15 2016
New Revision: 238629

URL: https://gcc.gnu.org/viewcvs?rev=238629=gcc=rev
Log:
PR c++/71630 - extern variable template

* pt.c (instantiate_decl): Fix pattern_defined for namespace scope
variable templates.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ53.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/pt.c

[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Fri Jul 22 03:51:07 2016
New Revision: 238628

URL: https://gcc.gnu.org/viewcvs?rev=238628=gcc=rev
Log:
PR c++/71913 - missing copy elision with new.

* call.c (unsafe_copy_elision_p): It's OK to elide when
initializing an unknown object.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/init/elide5.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/call.c

[Bug c++/69223] [5/6/7 regression] ICE with polymorphic lambda

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Fri Jul 22 03:46:54 2016
New Revision: 238627

URL: https://gcc.gnu.org/viewcvs?rev=238627=gcc=rev
Log:
PR c++/69223 - ICE with deduced template return type.

* semantics.c (apply_deduced_return_type): Call
complete_type_or_else before building the new RESULT_DECL.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-deduce3.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/semantics.c

[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Fri Jul 22 03:46:41 2016
New Revision: 238625

URL: https://gcc.gnu.org/viewcvs?rev=238625=gcc=rev
Log:
PR c++/71913 - missing copy elision with new.

* call.c (unsafe_copy_elision_p): It's OK to elide when
initializing an unknown object.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/init/elide5.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/call.c

[Bug c++/69223] [5/6/7 regression] ICE with polymorphic lambda

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Jul 22 03:45:54 2016
New Revision: 238624

URL: https://gcc.gnu.org/viewcvs?rev=238624=gcc=rev
Log:
PR c++/69223 - ICE with deduced template return type.

* semantics.c (apply_deduced_return_type): Call
complete_type_or_else before building the new RESULT_DECL.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-deduce3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c

[Bug c++/71630] [5/6/7 Regression] ICE on valid C++14 code with variable templates: in get, at cgraph.h:395

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Fri Jul 22 03:46:49 2016
New Revision: 238626

URL: https://gcc.gnu.org/viewcvs?rev=238626=gcc=rev
Log:
PR c++/71630 - extern variable template

* pt.c (instantiate_decl): Fix pattern_defined for namespace scope
variable templates.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp1y/var-templ53.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/pt.c

[Bug c++/71630] [5/6/7 Regression] ICE on valid C++14 code with variable templates: in get, at cgraph.h:395

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Fri Jul 22 03:45:43 2016
New Revision: 238622

URL: https://gcc.gnu.org/viewcvs?rev=238622=gcc=rev
Log:
PR c++/71630 - extern variable template

* pt.c (instantiate_decl): Fix pattern_defined for namespace scope
variable templates.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ53.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Fri Jul 22 03:45:37 2016
New Revision: 238621

URL: https://gcc.gnu.org/viewcvs?rev=238621=gcc=rev
Log:
PR c++/71913 - missing copy elision with new.

* call.c (unsafe_copy_elision_p): It's OK to elide when
initializing an unknown object.

Added:
trunk/gcc/testsuite/g++.dg/init/elide5.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/71274] [5/6/7 Regression] deprecated static const member of struct raises warning without use

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Fri Jul 22 03:45:48 2016
New Revision: 238623

URL: https://gcc.gnu.org/viewcvs?rev=238623=gcc=rev
Log:
PR c++/71274 - deprecated warning without use.

* decl2.c (maybe_instantiate_decl): Split out from mark_used.
(decl_constant_var_p): Use it instead.

Added:
trunk/gcc/testsuite/g++.dg/warn/deprecated-11.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c

[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Jul 22 03:41:44 2016
New Revision: 238619

URL: https://gcc.gnu.org/viewcvs?rev=238619=gcc=rev
Log:
PR c++/71913 - missing copy elision with new.

* call.c (unsafe_copy_elision_p): It's OK to elide when
initializing an unknown object.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/init/elide5.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/call.c

[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library

[norm.jacobs at oracle dot com]

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

Norm Jacobs  changed:

   What|Removed |Added

 CC||norm.jacobs at oracle dot com

--- Comment #29 from Norm Jacobs  ---
Created attachment 38948
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38948=edit
proposed fix to link values-*.o

Unfortunately, due to the way support for behavioral differences in conflicting
standards interfaces is implemented in Solaris libc and libm, there really
isn't a perfect answer here.  An offline discussion of this led to the
conclusion that "the application dictates the xpg'ness and any library that
thinks it has control from the compilation options it uses, is fooling itself."

The current builds of GCC that are delivered with Solaris 11 and later include
a patch very similar to the one that I have attached.  The one that I have
attached should only link in appropriate values-*.o files when GCC calls the
linker to generate an executable program.  This seems consistent with what the
Studio compilers do.

[Bug c++/71964] New: Move constructor of std::set does not move allocator

[rbd at debian dot org]

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

Bug ID: 71964
   Summary: Move constructor of std::set does not move allocator
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rbd at debian dot org
  Target Milestone: ---

My understanding of allocator aware containers (of which std::set is one) is
that moving the container should move the allocator.  However the following
code shows that std::set copies the allocator:

$ cat a.cpp
#include 
#include 
#include 
#include 

template
struct my_allocator : public std::allocator
{
typedef std::true_type propagate_on_container_move_assignment;

typedef size_t size_type;
typedef T * pointer;
typedef const T * const_pointer;

template
struct rebind
{
typedef my_allocator<_Tp1> other;
};

my_allocator() : std::allocator() { }

my_allocator(const my_allocator & a) noexcept : std::allocator(a)
{
fprintf(stderr, "copy constructor called\n");
}

my_allocator(const my_allocator && a) noexcept :
std::allocator(std::move(a))
{
fprintf(stderr, "move constructor called\n");
}
};

int main(int argc, char *argv[])
{
std::set x;
std::set y{ std::move(x) };

return 0;
}

$ g++ --std=c++11 -v a.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.1' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --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 --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.1) 
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/5/cc1plus -quiet -v -imultiarch x86_64-linux-gnu
-D_GNU_SOURCE a.cpp -quiet -dumpbase a.cpp -mtune=generic -march=x86-64
-auxbase a -std=c++11 -version -fstack-protector-strong -Wformat
-Wformat-security -o /tmp/ccxdEpTy.s
GNU C++11 (Ubuntu 5.4.0-6ubuntu1~16.04.1) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/5"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/5/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/5
 /usr/include/x86_64-linux-gnu/c++/5
 /usr/include/c++/5/backward
 /usr/lib/gcc/x86_64-linux-gnu/5/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++11 (Ubuntu 5.4.0-6ubuntu1~16.04.1) version 5.4.0 20160609
(x86_64-linux-gnu)
compiled by GNU C version 5.4.0 20160609, GMP version 6.1.0, MPFR
version 3.1.4, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 54c46ecad36e047174be4f497c131a62
COLLECT_GCC_OPTIONS='-std=c++11' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 as -v --64 -o /tmp/cc9xwjYg.o /tmp/ccxdEpTy.s
GNU assembler version 2.26.1 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.26.1
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/5/:/usr/lib/gcc/x86_64-linux-gnu/

[Bug lto/60779] -fcx-fortran-rules ignored when using -flto

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
Hasn't this been fixed by using the optimize attribute infrastructure for LTO
now?

[Bug c++/69223] [5/6/7 regression] ICE with polymorphic lambda

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/71274] [5/6/7 Regression] deprecated static const member of struct raises warning without use

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/71630] [5/6/7 Regression] ICE on valid C++14 code with variable templates: in get, at cgraph.h:395

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/71756] [5/6/7 Regression] internal compiler error: in ~saved_token_sentinel, at cp/parser.c:1228

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|5.5 |6.2

--- Comment #4 from Jason Merrill  ---
Fixed by the patch for bug 70781.

[Bug fortran/71730] [5/6/7 Regression] ICE when character length specification uses an undefined variable

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug c++/71913] [5/6/7 Regression] Missing copy elision with operator new

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Yes, I think that change was too conservative; it avoids copy elision when we
*might* be initializing a base subobject, but here if ptr were pointing to a
base subobject we'd be calling the wrong constructor anyway, so copy elision
doesn't make it worse.

[Bug c/71963] New: Showing incompatible type when types are same.

[sinu.nayak2001 at gmail dot com]

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

Bug ID: 71963
   Summary: Showing incompatible type when types are same.
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sinu.nayak2001 at gmail dot com
  Target Milestone: ---

#include 
int main()
{
int k[3][3] = {{1,2,3},{4,5,6},{7,8,9}};
int (*c)[3];
int (*d)[3];
c = k+1;
d = k+2;
*c = *d; //error: incompatible types when assigning to type 'int[3]'
from type 'int *'
k[0] = k[1]; //error: incompatible types when assigning to type
'int[3]' from type 'int *'
printf("%d\n", (*c)[0]);
printf("%d\n", (*d)[0]);

return 0;
}


In the above code, errors are shown as commented.
No doubt, it is a tricky attempt to assign an array to another array.
However, aren't the types of both left hand side and right hand side same?


Sincerely,
Srinivas Nayak

[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding

[edlinger at gcc dot gnu.org]

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

--- Comment #12 from Bernd Edlinger  ---
Author: edlinger
Date: Thu Jul 21 19:06:02 2016
New Revision: 238605

URL: https://gcc.gnu.org/viewcvs?rev=238605=gcc=rev
Log:
016-07-21  Bernd Edlinger  

PR middle-end/71876
* calls.c (gimple_maybe_alloca_call_p): New function.  Return true
if STMT may be an alloca call.
(gimple_alloca_call_p, alloca_call_p): Return only true for the
builtin alloca call.
* calls.h (gimple_maybe_alloca_call_p): New function.
* tree-inline.c (inline_forbidden_p_stmt): Use
gimple_maybe_alloca_call_p here.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/calls.c
trunk/gcc/calls.h
trunk/gcc/tree-inline.c

[Bug middle-end/71876] longjmp is miscompiled with -ffreestanding

[edlinger at gcc dot gnu.org]

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

--- Comment #13 from Bernd Edlinger  ---
Author: edlinger
Date: Thu Jul 21 19:11:26 2016
New Revision: 238606

URL: https://gcc.gnu.org/viewcvs?rev=238606=gcc=rev
Log:
016-07-21  Bernd Edlinger  

PR middle-end/71876
* builtin-attrs.def (ATTR_RT_NOTHROW_LEAF_LIST): New return twice
attribute.
* builtins.def (BUILT_IN_SETJMP): Use ATTR_RT_NOTHROW_LEAF_LIST here.
* calls.c (special_function_p): Remove the special handling of the
"__builtin_" prefix.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/builtin-attrs.def
trunk/gcc/builtins.def
trunk/gcc/calls.c

[Bug fortran/71883] [5/6/7 Regression] ICE in identical_array_ref, at fortran/dependency.c:104

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.5

[Bug tree-optimization/50417] [4.9/5/6/7 regression]: memcpy with known alignment

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4
Summary|regression: memcpy with |[4.9/5/6/7 regression]:
   |known alignment |memcpy with known alignment

[Bug c++/71848] [7 Regression] libstdc++ testsuite error on AIX

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c++/71728] [5 Regression] ICE with goto in statement-expression inside a condition

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

  Known to work||6.2.0, 7.0
Summary|[5/6/7 Regression] ICE with |[5 Regression] ICE with
   |goto in |goto in
   |statement-expression inside |statement-expression inside
   |a condition |a condition
  Known to fail|7.0 |

--- Comment #6 from Jakub Jelinek  ---
Fixed for 6.2+.  For 5.x would need also PR68206 backported.

[Bug c++/71728] [5/6/7 Regression] ICE with goto in statement-expression inside a condition

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul 21 18:24:48 2016
New Revision: 238602

URL: https://gcc.gnu.org/viewcvs?rev=238602=gcc=rev
Log:
PR c++/71728
* constexpr.c (potential_constant_expression_1) :
Replace assert with test, return false if the goto isn't break
or continue.  Formatting fix.

* g++.dg/other/pr71728.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/other/pr71728.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/constexpr.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug c++/71728] [5/6/7 Regression] ICE with goto in statement-expression inside a condition

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul 21 18:22:32 2016
New Revision: 238601

URL: https://gcc.gnu.org/viewcvs?rev=238601=gcc=rev
Log:
PR c++/71728
* constexpr.c (potential_constant_expression_1) :
Replace assert with test, return false if the goto isn't break
or continue.  Formatting fix.

* g++.dg/other/pr71728.C: New test.

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

[Bug sanitizer/71953] ICE using address sanitizers with PCH

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
This fixes the v3 testsuite with asan, thanks.

[Bug fortran/71961] [7 Regression] 178.galgel in SPEC CPU 2000 is miscompiled

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2016-07-21
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
Reduced test case?

[Bug sanitizer/71962] New: error: ‘((& x) != 0u)’ is not a constant expression

[redi at gcc dot gnu.org]

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

Bug ID: 71962
   Summary: error: ‘((& x) != 0u)’ is not a constant expression
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
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: ---

struct P {
  constexpr P(const int* p) : p(p) { }
  const int* p;
  explicit constexpr operator bool() const { return (bool)p; }
};

int main() {
  static constexpr int x{1};
  constexpr P p{};
  static_assert((bool)p, "");
}

This valid program is rejected when ubsan is used:

$ g++ ubsan.cc -fsanitize=undefined
ubsan.cc: In function ‘int main()’:
ubsan.cc:10:3: error: non-constant condition for static assertion
   static_assert((bool)p, "");
   ^
ubsan.cc:4:53: error: ‘((& x) != 0u)’ is not a constant expression
   explicit constexpr operator bool() const { return (bool)p; }
 ^~~

[Bug fortran/71961] New: [7 Regression] 178.galgel in SPEC CPU 2000 is miscompiled

[hjl.tools at gmail dot com]

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

Bug ID: 71961
   Summary: [7 Regression] 178.galgel in SPEC CPU 2000 is
miscompiled
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: tkoenig at gcc dot gnu.org
  Target Milestone: ---

On x86-64, r238497 miscompiled 178.galgel in SPEC CPU 2000:

[hjl@gnu-ivb-1 0002]$ cat galgel.out.mis 
0203: C1 = (  -0.3411,  0.2388)
  C1 = (  -0.3475,  0.2414)
^
0268:  Parameter Mu=  0.1048E+05
   Parameter Mu=  0.1068E+05
   ^
0269:  Parameter Tau   = -0.1024E-01
   Parameter Tau   = -0.1041E-01
   ^
0270:  Floquet exponent= -0.6821
   Floquet exponent= -0.6950
   ^
[hjl@gnu-ivb-1 0002]$

[Bug libstdc++/71945] Integer overflow in use counter of shared pointers

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
You also get undefined behaviour at 2bn objects when the signed _Atomic_word
overflows, and the weak count can also be forced to overflow. Doing so requires
allocating tens of GB of shared_ptr objects though.

[Bug fortran/31190] minimum field width list-directed output

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #11 from Dominique d'Humieres  ---
Closing as WONTFIX.

[Bug libstdc++/71960] __glibcxx_assert and Debug Mode checks can't be used in constexpr functions

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Alternatively, compiler magic which allows the checks to be skipped when used
in a constant expression would allow us to support all valid code, at the
expense of not diagnosing misuses in constant expressions.

[Bug libstdc++/71960] New: __glibcxx_assert and Debug Mode checks can't be used in constexpr functions

[redi at gcc dot gnu.org]

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

Bug ID: 71960
   Summary: __glibcxx_assert and Debug Mode checks can't be used
in constexpr functions
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: minor
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This affects clamp, min_element, max_element and minmax_element, at least.

For the simple __glibcxx_assert uses it would be nice to have a constexpr
replacement for __replacement_assert which could be used in those places.

In more complex cases we could drop the 'constexpr' specifier but that would
mean some valid code wouldn't compile in Debug Mode.

[Bug c++/62096] unexpected warning overflow in implicit constant conversion

[travis.vitek at roguewave dot com]

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

--- Comment #4 from Travis Vitek  ---
I believe the underlying type of the unscoped enumeration `E' should be `int'.
According to 7.2 paragraph 7, the underlying type is

  .. implementation-defined which integral type is used
  as the underlying type except that the underlying
  type shall not be larger than int unless the value
  of an enumerator cannot fit in an int or unsigned int.

I've modified my test case slightly to verify that it is `int'.

[vitek@sidewinder] 71 % cat t.cpp
#include 

enum E {
E_val  = 1,
};

enum U {
U_val  = 4294967295,
};

inline constexpr E operator~(E e)
{
return E(~static_cast(e));
}

#define DEFINE_DETECT(T) const char* detect(T) { return #T; }
DEFINE_DETECT(bool)

DEFINE_DETECT(char)
DEFINE_DETECT(signed char)
DEFINE_DETECT(unsigned char)

DEFINE_DETECT(wchar_t)

DEFINE_DETECT(short)
DEFINE_DETECT(int)
DEFINE_DETECT(long)
DEFINE_DETECT(long long)

DEFINE_DETECT(unsigned int)
DEFINE_DETECT(unsigned short)
DEFINE_DETECT(unsigned long)
DEFINE_DETECT(unsigned long long)


int main()
{
printf ("%s\n", detect(E_val));
printf ("%s\n", detect(U_val));

int eval = ~E_val;
int uval = ~U_val;

(void) eval;
(void) uval;
}
[vitek@sidewinder] 72 % g++ --pedantic -std=c++11 t.cpp
t.cpp: In function 'int main()':
t.cpp:41:17: warning: overflow in implicit constant conversion [-Woverflow]
 int eval = ~E_val;
 ^
[vitek@sidewinder] 73 % ./a.out
int
unsigned int


[vitek@sidewinder] 74 %


If the underlying type of `E' is `int', then there should be no overflow when
converting back from `E' to `int', right? What am I missing?

[Bug sanitizer/71953] ICE using address sanitizers with PCH

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul 21 16:18:46 2016
New Revision: 238597

URL: https://gcc.gnu.org/viewcvs?rev=238597=gcc=rev
Log:
PR sanitizer/71953
* asan.c (asan_dynamic_init_call): Call asan_init_shadow_ptr_types
before builtin_decl_implicit.

Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/asan.c

[Bug sanitizer/71953] ICE using address sanitizers with PCH

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Thu Jul 21 16:17:58 2016
New Revision: 238596

URL: https://gcc.gnu.org/viewcvs?rev=238596=gcc=rev
Log:
PR sanitizer/71953
* asan.c (asan_dynamic_init_call): Call asan_init_shadow_ptr_types
before builtin_decl_implicit.

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

[Bug libstdc++/71959] New: [OpenACC] #pragma acc parallel leads to segfault in x86_64-pc-linux-gnu-accel-nvptx-none-gcc

[christopher.guc...@torq-dev.de]

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

Bug ID: 71959
   Summary: [OpenACC] #pragma acc parallel leads to segfault in
x86_64-pc-linux-gnu-accel-nvptx-none-gcc
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christopher.guc...@torq-dev.de
  Target Milestone: ---

Created attachment 38947
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38947=edit
Source files and -save-temps files

I'm trying to modify libstdc++ by adding GPU offloaded code in omp_loop.h (my
version attached). I test the code using the attached measureParallel.cpp file.

Compiling the code using the following command:

> g++ -v -save-temps -Wall -Wextra measureParallel.cpp -D_GLIBCXX_PARALLEL 
> -lpthread -fopenacc -foffload=nvptx-none -foffload="-O3" -O3 -o 
> measureParallel.autotuned

gives me the following output:

> Using built-in specs.
> COLLECT_GCC=g++
> COLLECT_LTO_WRAPPER=/home/thonfeld.net/chris/git/gcc 
> offload/install/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.1.0/lto-wrapper
> OFFLOAD_TARGET_NAMES=nvptx-none
> Target: x86_64-pc-linux-gnu
> Configured with: 
> /home/thonfeld.net/chris/git/gcc-offload/source/gcc-6.1.0/configure --prefix= 
> --disable-bootstrap --enable-languages=c,c++,fortran,lto --disable-multilib 
> --enable-offload-targets=nvptx-none=/home/thonfeld.net/chris/git/gcc-offload/install
>  --with-cuda-driver-include=/include CC='gcc -m64' CXX='g++ -m64' 
> --with-sysroot= : (reconfigured) 
> /home/thonfeld.net/chris/git/gcc-offload/source/gcc-6.1.0/configure --prefix= 
> --disable-bootstrap --enable-languages=c,c++,fortran,lto --disable-multilib 
> --enable-offload-targets=nvptx-none=/home/thonfeld.net/chris/git/gcc-offload/install
>  --with-cuda-driver-include=/include CC='gcc -m64' CXX='g++ -m64' 
> --with-sysroot=
> Thread model: posix
> gcc version 6.1.0 (GCC) 
> COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-D' 
> '_GLIBCXX_PARALLEL' '-fopenacc' '-foffload=nvptx-none' '-foffload=-O3' '-O3' 
> '-o' 'measureParallel.autotuned' '-shared-libgcc' '-mtune=generic' 
> '-march=x86-64' '-pthread'
>  
> /home/thonfeld.net/chris/git/gcc-offload/install/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.1.0/cc1plus
>  -E -quiet -v -imultiarch x86_64-linux-gnu -iprefix 
> /home/thonfeld.net/chris/git/gcc-offload/install/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/
>  -D_GNU_SOURCE -D_REENTRANT -D_GLIBCXX_PARALLEL measureParallel.cpp 
> -mtune=generic -march=x86-64 -Wall -Wextra -fopenacc -foffload=nvptx-none 
> -foffload=-O3 -O3 -fpch-preprocess -o measureParallel.ii
> ignoring nonexistent directory 
> "/home/thonfeld.net/chris/git/gcc-offload/install/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../x86_64-pc-linux-gnu/include"
> ignoring nonexistent directory 
> "/lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0"
> ignoring nonexistent directory 
> "/lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/x86_64-pc-linux-gnu"
> ignoring nonexistent directory 
> "/lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../include/c++/6.1.0/backward"
> ignoring duplicate directory 
> "/home/thonfeld.net/chris/git/gcc-offload/install/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/include"
> ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
> ignoring duplicate directory 
> "/home/thonfeld.net/chris/git/gcc-offload/install/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/include-fixed"
> ignoring nonexistent directory 
> "/home/thonfeld.net/chris/git/gcc-offload/install/bin/../lib/gcc/../../lib/gcc/x86_64-pc-linux-gnu/6.1.0/../../../../x86_64-pc-linux-gnu/include"
> #include "..." search starts here:
> #include <...> search starts here:
>  
> /home/thonfeld.net/chris/git/masterarbeit-chris/code/submodules/libtuning/include
>  
> /home/thonfeld.net/chris/git/gcc-offload/install/include/c++/6.1.0/x86_64-pc-linux-gnu
>  /home/thonfeld.net/chris/git/gcc-offload/install/include/c++/6.1.0
>  .
>  
> /home/thonfeld.net/chris/git/gcc-offload/install/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/include
>  
> /home/thonfeld.net/chris/git/gcc-offload/install/bin/../lib/gcc/x86_64-pc-linux-gnu/6.1.0/include-fixed
>  /usr/local/include
>  /home/thonfeld.net/chris/git/gcc-offload/install/bin/../lib/gcc/../../include
>  /usr/include/x86_64-linux-gnu
>  /usr/include
> End of search list.
> COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-D' 
> '_GLIBCXX_PARALLEL' '-fopenacc' '-foffload=nvptx-none' '-foffload=-O3' '-O3' 
> '-o' 'measureParallel.autotuned' '-shared-libgcc' '-mtune=generic' 
> '-march=x86-64' '-pthread'
>  
> /home/thonfeld.net/chris/git/gcc-offload/install/bin/../libexec/gcc/x86_64-pc-linux-gnu/6.1.0/cc1plus
>  -fpreprocessed measureParallel.ii -quiet -dumpbase measureParallel.cpp 
> -mtune=generic -march=x86-64 -auxbase measureParallel 

[Bug c++/70932] flexible array member with non-trivial destructor

[junyer at google dot com]

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

--- Comment #7 from Paul Wankadia  ---
Ahh. Thank you for clarifying. I will continue to watch this bug then. :)

[Bug c++/70932] flexible array member with non-trivial destructor

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
To clarify/correct comment #5: the error in comment #4 is due to bug 71147, the
one in comment #3 ("unbekannte Feldgröße in »delete«") looks like it's the same
as in comment #0 and probably due to this bug.

[Bug c++/71147] [6 Regression] Flexible array member wrongly rejected in template

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
The test case from comment 4 on bug 70932 fails due to this bug.  But looking
at the error in comment 3 more closely I see "unbekannte Feldgröße in »delete«"
which with some help from Google Translate does look like the same error as in
bug 70932.  Sorry for the confusion!

[Bug c++/71694] store-data race with bitfields and tail-padding in C++

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
(In reply to Richard Biener from comment #3)
> The C++ FE identifies such types with
> 
>   CLASSTYPE_NON_LAYOUT_POD_P (t) || CLASSTYPE_EMPTY_P (t)
> 
> where only CLASSTYPE_NON_LAYOUT_POD_P is interesting to us.  Only available
> in struct lang_type.  Possibly able to expose that via a new langhook.

Perhaps a langhook that returns the size that is safe to access when we don't
know that we're dealing with a complete object of that type, i.e.
CLASSTYPE_SIZE for C++ classes.

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[boris at kolpackov dot net]

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

--- Comment #26 from Boris Kolpackov  ---
> If breaking the old ABI was an option we wouldn't be in this situation in the 
> first place.

By throwing the new version you are breaking the ABI. The point I was trying to
make is that maybe in this case we can allow the old code to still limp along
(and thus make this change more palatable).

[Bug c++/71147] [6 Regression] Flexible array member wrongly rejected in template

[junyer at google dot com]

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

Paul Wankadia  changed:

   What|Removed |Added

 CC||junyer at google dot com

--- Comment #8 from Paul Wankadia  ---
(In reply to Martin Sebor from comment #7)
> Fixed on trunk (r236664) and 6-branch (r236729).

https://github.com/google/re2/issues/102 reported this for g++ (GCC) 6.1.1
20160707. The 6-20160707 snapshot was taken at gcc-6-branch revision 238150, so
I guess that it would have included your fix. Is it possible that the bug is
not completely fixed yet? (My apologies in advance if I'm barking up the wrong
tree!)

P.S. Thank you for redirecting me here from bug 70932. :)

[Bug c++/70932] flexible array member with non-trivial destructor

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
(In reply to Paul Wankadia from comment #3)
> Is this likely to be the same issue even though std::atomic should have
> a trivial destructor for all T?

No, that's bug 71147, fixed in 7.0 and 6.x.

[Bug c++/67491] [meta-bug] concepts issues

[jason at gcc dot gnu.org]

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

Bug 67579 Summary: [concepts] Memoization for constraint expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67579

   What|Removed |Added

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

[Bug c++/67579] [concepts] Memoization for constraint expressions

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.2

--- Comment #3 from Jason Merrill  ---
Fixed for 6.2.

[Bug c++/67491] [meta-bug] concepts issues

[jason at gcc dot gnu.org]

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

Bug 67565 Summary: [concepts] Very slow compile time and high memory usage with 
complex concept definitions, even if unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67565

   What|Removed |Added

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

[Bug c++/67565] [concepts] Very slow compile time and high memory usage with complex concept definitions, even if unused

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |6.2

--- Comment #6 from Jason Merrill  ---
Fixed for 6.2.

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[boris at kolpackov dot net]

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

--- Comment #24 from Boris Kolpackov  ---
Some more speculation/crazy ideas about the potential fix:

If just throwing the new version and forgetting about the old one is an option,
then perhaps we could "de-inherit" old from std::exception and inherit new from
this modified variant of old (in addition to system_error). This will give us:

1. Old code will be able to catch it as old ios::failure.

2. Old code will be able to catch it as std::exception (via the new version's
inheritance chain).

3. typeid() will even report it as ios::failure (unlike in my previous
suggestion).

Regarding how to have two version at the same time, I may be wrong, but I
thought inline namespaces were used to implement this dual ABI.

[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

--- Comment #25 from Jonathan Wakely  ---
(In reply to Boris Kolpackov from comment #24)
> Some more speculation/crazy ideas about the potential fix:
> 
> If just throwing the new version and forgetting about the old one is an
> option, then perhaps we could "de-inherit" old from std::exception and
> inherit new from this modified variant of old (in addition to system_error).

That would be an ABI break for the old ABI. If breaking the old ABI was an
option we wouldn't be in this situation in the first place.

> Regarding how to have two version at the same time, I may be wrong, but I
> thought inline namespaces were used to implement this dual ABI.

No, maybe take a look at the code.

[Bug tree-optimization/71947] [6/7 Regression] x ^ y not folded to 0 if x == y by DOM

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Now the testcase is optimized at -O2 by VRP but still not at -O1.

[Bug c++/67565] [concepts] Very slow compile time and high memory usage with complex concept definitions, even if unused

[tom at honermann dot net]

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

--- Comment #5 from Tom Honermann  ---
Nice, thanks!

Using gcc r238587, I get the times below for the examples in this report.  All
cases are dramatically improved.  Unless there is some other known issue not
captured in the discussion here, it looks to me like this issue can be
resolved.

For the example in comment 0:

$ time g++ -std=c++1z -fconcepts main.cpp
real0m0.051s
user0m0.040s
sys 0m0.008s

For the example in comment 2:

$ time g++ -c -std=c++1z -fconcepts t.cpp
real0m0.009s
user0m0.004s
sys 0m0.000s

$ time g++ -c -std=c++1z -fconcepts t.cpp -DGO_FAST1
real0m0.009s
user0m0.004s
sys 0m0.000s

$ time g++ -c -std=c++1z -fconcepts t.cpp -DGO_FAST2
real0m0.009s
user0m0.000s
sys 0m0.004s

$ time g++ -c -std=c++1z -fconcepts t.cpp -DGO_SLOWER1
real0m0.009s
user0m0.000s
sys 0m0.004s

Additionally, my builds of Text View [1] now complete in 0m26.140s improved
from 1m35.837s.

[1]: https://github.com/tahonermann/text_view

[Bug tree-optimization/71947] [6/7 Regression] x ^ y not folded to 0 if x == y by DOM

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Jul 21 13:00:32 2016
New Revision: 238591

URL: https://gcc.gnu.org/viewcvs?rev=238591=gcc=rev
Log:
2016-07-21  Richard Biener  

PR tree-optimization/71947
* tree-vrp.c (extract_range_from_assert): Singleton symbolic
ranges have useful limit_vr information.

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

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp102.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug tree-optimization/71661] [7 Regression] wrong code at -O3

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
This to me looks like some transformation of a loop that doesn't properly
adjust the number of iterations.  During vrp1 loop2 is:
loop_2 (header = 11, latch = 13, niter = c_23 + 1 <= 3 ? 2 - c_23 : 0,
upper_bound = 3, likely_upper_bound = 3)
{
  bb_11 (preds = {bb_5 bb_13 }, succs = {bb_6 })
  {
:
# c_5 = PHI 
# d_7 = PHI 
# .MEM_11 = PHI <.MEM_25(5), .MEM_12(13)>
# .MEM_18 = VDEF <.MEM_11>
a = 2;
c_19 = c_5 + 1;

  }
  bb_6 (preds = {bb_11 }, succs = {bb_13 bb_7 })
  {
:
# c_6 = PHI 
# d_8 = PHI 
# .MEM_12 = PHI <.MEM_18(11)>
if (c_6 <= 2)
  goto ;
else
  goto ;

  }
  bb_13 (preds = {bb_6 }, succs = {bb_11 })
  {
:
c_29 = ASSERT_EXPR ;
goto ;

  }
}

after dce it is:
loop_2 (header = 6, latch = 6, niter = , upper_bound = 3, likely_upper_bound =
3)
{
  bb_6 (preds = {bb_5 bb_6 }, succs = {bb_6 bb_7 })
  {
:
# c_5 = PHI <0(5), c_19(6)>
# d_7 = PHI 
# .MEM_11 = PHI <.MEM_25(5), .MEM_18(6)>
# .MEM_18 = VDEF <.MEM_11>
a = 2;
c_19 = c_5 + 1;
if (c_19 <= 2)
  goto ;
else
  goto ;

  }
}
so again reasonable.
but ch pass turns this into:
loop_2 (header = 11, latch = 7, niter = , upper_bound = 3, likely_upper_bound =
3)
{
  bb_7 (preds = {bb_8 bb_11 }, succs = {bb_11 })
  {
:
# c_9 = PHI <0(8), c_19(11)>
# d_25 = PHI 
# .MEM_24 = PHI <.MEM_18(8), .MEM_18(11)>

  }
  bb_11 (preds = {bb_7 bb_2 bb_5 }, succs = {bb_7 bb_8 })
  {
:
# c_5 = PHI 
# d_7 = PHI 
# .MEM_11 = PHI <.MEM_24(7), .MEM_15(2), .MEM_10(5)>
# .MEM_18 = VDEF <.MEM_11>
a = 2;
c_19 = c_5 + 1;
if (c_19 <= 2)
  goto ;
else
  goto ;

  }
  bb_8 (preds = {bb_11 }, succs = {bb_7 bb_10 })
  {
:
d_20 = d_7 + 1;
if (d_20 <= 1)
  goto ;
else
  goto ;

  }
}

(basically collapses 2 loops into one), and the upper_bound/likely_upper_bound
is just wrong here, because the loop latch is executed exactly 5 times
if the loop is entered from bb 5 (that is the case at runtime), or 2 times + UB
(if entered from bb 2) - with c_19 being 1, 2, 3, 1, 2.

[Bug target/71958] x86_64-w64-mingw32, ICE when '-mx32' is used

[i.nixman at autistici dot org]

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

--- Comment #1 from niXman  ---
s/But compiled ok/The same error occurs/

[Bug tree-optimization/71957] [5/6/7 Regression] Invalid code generation with function static objects

[sebastian.hu...@embedded-brains.de]

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

--- Comment #4 from Sebastian Huber  ---
(In reply to Richard Biener from comment #3)
> On a second look the testcase looks invalid as it invokes a virtual function
> via C on an object of type C.  Why do you think doing this is valid?

I try to generate a new test case without the reinterpret cast.

[Bug target/71948] [avr] Make progmem work on reduced Tiny cores by adding 0x4000 to symbols

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

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

--- Comment #2 from Georg-Johann Lay  ---
Done, cf.

https://gcc.gnu.org/onlinedocs/gcc/AVR-Variable-Attributes.html

for an example.

[Bug c++/70932] flexible array member with non-trivial destructor

[junyer at google dot com]

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

--- Comment #4 from Paul Wankadia  ---
FWIW, using a simplified struct, Compiler Explorer (gcc.godbolt.org) with GCC
6.1 throws a different error:


#include 

struct State {
  int i;
  std::atomic next_[];
};


Compiler output — x86 gcc 6.1 (g++ (DRW-internal-build) 6.1.0)
5 : error: field 'next_' has incomplete type 'std::atomic []'
std::atomic next_[];
^
In file included from
/tmp/gcc-explorer-compiler116621-82-1gzc8bu/example.cpp:1:0:
/opt/gcc-6.1.0/include/c++/6.1.0/atomic:165:12: note: declaration of 'struct
std::atomic'

[Bug tree-optimization/71503] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu in "gen_phi_arg_condition"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #7 from Jakub Jelinek  ---
*** Bug 71683 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/71683] [7 Regression] ICE in gen_phi_arg_condition, at tree-if-conv.c:1705 w/ -ftree-vectorize -O2 (and above)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
.

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

[Bug tree-optimization/71503] [7 Regression] gcc ICE at -O3 on valid code on x86_64-linux-gnu in "gen_phi_arg_condition"

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/71854] [7 Regression] ICE at -O3 in both 32-bit and 64-bit modes on x86_64-linux-gnu (verify_gimple failed)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
--- tree-vect-stmts.c.jj4   2016-07-14 20:28:33.0 +0200
+++ tree-vect-stmts.c   2016-07-21 13:49:35.015011603 +0200
@@ -7763,7 +7763,17 @@ vectorizable_condition (gimple *stmt, gi
   vec_else_clause = vec_oprnds3[i];

  if (masked)
-   vec_compare = vec_cond_lhs;
+   {
+ if (slp_node
+ && !VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (vec_cond_lhs)))
+   {
+ tree zero = build_zero_cst (TREE_TYPE (vec_cond_lhs));
+ vec_compare = build2 (NE_EXPR, vec_cmp_type,
+   vec_cond_lhs, zero);
+   }
+ else
+   vec_compare = vec_cond_lhs;
+   }
  else
{
  vec_cond_rhs = vec_oprnds1[i];

didn't help, the bug has to be elsewhere, guess related to SLP pattern recog
and the VECTOR_BOOLEAN_P stuff.  Anyway, not working on this.

[Bug c++/70932] flexible array member with non-trivial destructor

[junyer at google dot com]

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

Paul Wankadia  changed:

   What|Removed |Added

 CC||junyer at google dot com

--- Comment #3 from Paul Wankadia  ---
https://github.com/google/re2/issues/102 reported the same error with GCC
6.1.1:


g++ -c -o obj/dbg/re2/dfa.o  -std=c++11 -pthread -Wall -Wextra
-Wno-unused-parameter -Wno-missing-field-initializers -I.   -O3 -g re2/dfa.cc
re2/dfa.cc: In Konstruktor »re2::DFA::State::State()«:
re2/dfa.cc:95:10: Fehler: unbekannte Feldgröße in »delete«
   struct State {
  ^
re2/dfa.cc: In Elementfunktion »re2::DFA::State* re2::DFA::CachedState(int*,
int, re2::uint)«:
re2/dfa.cc:703:9: Anmerkung: erzeugte Methode »re2::DFA::State::State()« zuerst
hier erfordert 
   State state;
 ^
make: *** [Makefile:190: obj/dbg/re2/dfa.o] Fehler 1


This is the flexible array member:

std::atomic next_[];

Is this likely to be the same issue even though std::atomic should have a
trivial destructor for all T?

[Bug tree-optimization/71957] [5/6/7 Regression] Invalid code generation with function static objects

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #3 from Richard Biener  ---
On a second look the testcase looks invalid as it invokes a virtual function
via C on an object of type C.  Why do you think doing this is valid?

[Bug tree-optimization/71957] [5/6/7 Regression] Invalid code generation with function static objects

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
  Component|c++ |tree-optimization

--- Comment #2 from Richard Biener  ---
t.C.086t.ccp2:  __builtin_unreachable ();

looks like devirt to me and things go downhill from there.  -fno-devirtualize
fixes it for me.

Honza?

  _9 = OBJ_TYPE_REF(_3;(struct B)[(void *)]->0) ([(void *)],
k_7(D));

is folded to unreachable () inside D::f.

  :
  _11 = __cxa_guard_acquire (&_ZGVZ1gvE1i);
  if (_11 != 0)
goto ;
  else
goto ;

  :
  _12 = f ();
  C::C (, _12);
  __cxa_guard_release (&_ZGVZ1gvE1i);

  :
  _2 = MEM[(struct B *)]._vptr.B;
  _3 = *_2;
  _9 = OBJ_TYPE_REF(_3;(struct B)[(void *)]->0) ([(void *)],
k_7(D));
  return _9;

[Bug c++/71957] [5/6/7 Regression] Invalid code generation with function static objects

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||i?86-*-*
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2016-07-21
 Ever confirmed|0   |1
Summary|Invalid code generation |[5/6/7 Regression] Invalid
   |with function static|code generation with
   |objects |function static objects
   Target Milestone|--- |5.5
  Known to fail||5.4.0, 7.0

--- Comment #1 from Richard Biener  ---
Confirmed on i?86.

[Bug target/71958] New: x86_64-w64-mingw32, ICE when '-mx32' is used

[i.nixman at autistici dot org]

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

Bug ID: 71958
   Summary: x86_64-w64-mingw32, ICE when '-mx32' is used
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: i.nixman at autistici dot org
  Target Milestone: ---

This code:

void
bar(int v)
{
short w[v];
}

produces the following error if compiled using gcc-6.1.0:
bar.c: In function 'bar':
bar.c:5:8: internal compiler error: in copy_to_mode_reg, at explow.c:601
  short w[v];
^

But compiled ok using this versions: 4.8.3, 4.9.2, 5.1.0, 5.2.0, 5.3.0, 5.4.0

[Bug libstdc++/70722] include_next in cmath skips user-defined wrapper

[redi at gcc dot gnu.org]

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

--- Comment #13 from Jonathan Wakely  ---
The C standard has equivalent wording in 7.1.2:

If a file with the same name as one of the above < and > delimited sequences,
not
provided as part of the implementation, is placed in any of the standard places
that are searched for included source files, the behavior is undefined.

[Bug libstdc++/70722] include_next in cmath skips user-defined wrapper

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Nadav Har'El from comment #10)
> There is nothing "holy" about glibc, and nothing "broken" about wanting to
> replace it (or, as Firefox did, only a part of it). Sure, the replacement
> needs to be 100% compatible with glibc, and if it isn't, the replacement
> needs to be fixed (e.g., I just fixed this
> https://github.com/cloudius-systems/osv/issues/770 and didn't come
> complaining to the libstdc++ project).
> 
> HOWEVER, in this case, the projects in question (Firefox, OSv, and probably
> more to come) did nothing incorrect or incompatible in their glibc
> replacement. Their only "sin" was the order of the header files.

Are you sure about that?

 17.6.4.4  Headers  [alt.headers]
 If a file with a name equivalent to the derived file name for one of the C++
 standard library headers is not provided as part of the implementation, and
 a file with that name is placed in any of the standard places for a source
 file to be included (16.2), the behavior is undefined.

> I still don't understand why the glibc header files could not have been
> improved to accommodate also the C++ standard (and I have no idea what the
> issues were) instead of needing to have copies of the same header file in
> both libstdc++ and glibc.

Not everybody uses glibc.

The change is documented at https://gcc.gnu.org/gcc-6/porting_to.html so if you
want to continue playing games with undefined behaviour then it's your job to
fix it.

[Bug c++/71957] New: Invalid code generation with function static objects

[sebastian.hu...@embedded-brains.de]

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

Bug ID: 71957
   Summary: Invalid code generation with function static objects
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sebastian.hu...@embedded-brains.de
  Target Milestone: ---

The following test case produces wrong code with GCC 6. The problem is at least
visible on x86, ARM, SPARC and PowerPC.

class A {
public:
  A(int);
};

template  class B {
public:
  virtual void* h(int) = 0;
};

template  class C : public B {
public:
  explicit C(int);
  void* h(int);
};

C& g(void);

class D : public A {
  static void* f(int);
};

void* D::f(int k) {
  B& j = (reinterpret_cast(g()));
  return j.h(k);
}

int f(void);

C& g(void) {
  static C i(f());
  return i;
}

g++ -Wfatal-errors -Wall -Wextra -S -O3 -fno-exceptions test.cc -o-
.file   "test.cc"
.text
.align 2
.p2align 4,,15
.globl  _ZN1D1fEi
.type   _ZN1D1fEi, @function
_ZN1D1fEi:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$_ZGVZ1gvE1i, %edi
movzbl  _ZGVZ1gvE1i(%rip), %eax
call__cxa_guard_acquire

<-- ERROR: It must check the return value of __cxa_guard_acquire()

call_Z1fv
movl$_ZZ1gvE1i, %edi
movl%eax, %esi
call_ZN1CI1AEC1Ei
movl$_ZGVZ1gvE1i, %edi
call__cxa_guard_release

<-- ERROR Invalid function return

.cfi_endproc
.LFE0:
.size   _ZN1D1fEi, .-_ZN1D1fEi
.p2align 4,,15
.globl  _Z1gv
.type   _Z1gv, @function
_Z1gv:
.LFB1:
.cfi_startproc
movzbl  _ZGVZ1gvE1i(%rip), %eax
testb   %al, %al
je  .L15
movl$_ZZ1gvE1i, %eax
ret
.p2align 4,,10
.p2align 3
.L15:
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$_ZGVZ1gvE1i, %edi
call__cxa_guard_acquire
testl   %eax, %eax
je  .L5
call_Z1fv
movl$_ZZ1gvE1i, %edi
movl%eax, %esi
call_ZN1CI1AEC1Ei
movl$_ZGVZ1gvE1i, %edi
call__cxa_guard_release
.L5:
movl$_ZZ1gvE1i, %eax
addq$8, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size   _Z1gv, .-_Z1gv
.local  _ZGVZ1gvE1i
.comm   _ZGVZ1gvE1i,8,8
.local  _ZZ1gvE1i
.comm   _ZZ1gvE1i,8,8
.ident  "GCC: (GNU) 6.1.1 20160705 [gcc-6-branch revision
fcd04db:3fed107:ebf5486fa49b6660091b549d17e945f63e698eac]"
.section.note.GNU-stack,"",@progbits

[Bug java/71917] [7 regression] libjava.jar/ReturnProxyTest.jar etc. FAIL

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

[Bug testsuite/71865] [7 regression] test case gcc.dg/diagnostic-token-ranges.c fails starting with r237714

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
.

[Bug tree-optimization/70964] [7 Regression] internal compiler error: in single_succ_edge, at basic-block.h:351

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/71728] [5/6/7 Regression] ICE with goto in statement-expression inside a condition

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

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

Untested fix.

[Bug rtl-optimization/71956] [7 Regression] 176.gcc fails on 32 bits when compiled with -march=core-avx2

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
The known regression caused with r235765 should have been fixed with r237503
though.

[Bug libstdc++/71950] std::ios_base::failure.what() returns irrelevant error message

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This isn't easy to do. The exception is thrown in basic_ios::clear() when
setting the error flags, but the cause of the error is not known there. We
could look at errno, but not all such errors are caused by C library functions
that set errno, so it would be misleading in many cases.

[Bug rtl-optimization/71956] [i686][7 Regression] 176.gcc fails on 32 bits when compiled with -march=core-avx2

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |7.0

[Bug rtl-optimization/71956] New: [i686][7 Regression] 176.gcc fails on 32 bits when compiled with -march=core-avx2

[izamyatin at gmail dot com]

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

Bug ID: 71956
   Summary: [i686][7 Regression] 176.gcc fails on 32 bits when
compiled with -march=core-avx2
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: izamyatin at gmail dot com
  Target Milestone: ---

Bisecting points on r235765. 
My exact options are -O3 -mfpmath=sse -march=core-avx2 -m32

Will try to bisect test sources

[Bug testsuite/70108] [5/6/7 Regression] FAIL: gcc.dg/simulate-thread/speculative-store-2.c -O0 -g thread simulation test

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
That looks like a gdb issue to me.  Have you tried more recent gdb?

[Bug c++/71955] Core dump and interesting behaviour while using reference class members

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Also p1 and p2 contain undefined behavior, that's reason why the program can't
be compiled w/ -fpermissive.

Running p1 with valgind shows:

==1728== Conditional jump or move depends on uninitialised value(s)
==1728==at 0x4F5D323: std::__cxx11::basic_string::_M_assign(std::__cxx11::basic_string const&) (in /usr/lib64/libstdc++.so.6.0.22)
==1728==by 0x4F5D6E8: std::__cxx11::basic_string::operator=(std::__cxx11::basic_string const&) (in /usr/lib64/libstdc++.so.6.0.22)
==1728==by 0x400D85:
SampleStringClass::SampleStringClass(std::__cxx11::basic_string const&) (in
/home/marxin/Downloads/gcc-question/a.out)
==1728==by 0x400CA5: main (in /home/marxin/Downloads/gcc-question/a.out)
==1728== 
==1728== Use of uninitialised value of size 8
==1728==at 0x4EF12C0: std::basic_ostream&
std::operator<< (std::basic_ostream&,
std::__cxx11::basic_string
const&) (in /usr/lib64/libstdc++.so.6.0.22)
==1728==by 0x400DA9: SampleStringClass::show() (in
/home/marxin/Downloads/gcc-question/a.out)
==1728==by 0x400CB1: main (in /home/marxin/Downloads/gcc-question/a.out)
==1728== 
Anand Apparao Kulkarni
==1728== Use of uninitialised value of size 8
==1728==at 0x4EF12C0: std::basic_ostream&
std::operator<< (std::basic_ostream&,
std::__cxx11::basic_string
const&) (in /usr/lib64/libstdc++.so.6.0.22)
==1728==by 0x400DA9: SampleStringClass::show() (in
/home/marxin/Downloads/gcc-question/a.out)
==1728==by 0x400CBD: main (in /home/marxin/Downloads/gcc-question/a.out)
==1728== 
Anand Apparao Kulkarni


Thus I would suggest following patch to your source code:

--- p1.backup   2016-07-21 11:22:20.651299644 +0200
+++ p1.cpp  2016-07-21 11:23:37.128793125 +0200
@@ -5,11 +5,10 @@

 class SampleStringClass {
private:
-   std::string& ref;
+   const std::string& ref;
public:
-   SampleStringClass(const std::string& arg)
+   SampleStringClass(const std::string& arg): ref (arg)
{
-   ref=arg;
}
void show()
{
@@ -19,11 +18,10 @@

 class SampleIntClass {
private:
-   int& ref;
+   const int& ref;
public:
-   SampleIntClass(const int& arg)
+   SampleIntClass(const int& arg): ref (arg)
{
-   ref=arg;
}
void show()
{

[Bug fortran/71935] [4.9/5/6/7 Regression] ICE is_c_interoperable(): gfc_simplify_expr failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug fortran/71936] [6/7 Regression] ICE in wide_int_to_tree, at tree.c:1487

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4

[Bug middle-end/71937] out of memory on very large function

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Component|c++ |middle-end

--- Comment #14 from Richard Biener  ---
It's a well-known issue in out-of-SSA as it computes liveness of SSA vars for
coalescing.  We _do_ perform some coalescing even with -fno-coalesce-vars.

The solution is to not compute liveness but use SSA to query liveness as
outlined in some paper.

At some point I tried to be "optimistic" in simply assuming no conflicts for
the must-coalesce cases (abnormals) and for -O0 same SSA_NAME_VAR SSA names
quite possibly should also always coalesce successfully.  So we could do
-fno-coalesce-vars a bit cheaper with the chance to eventually generate
wrong-code unnoticed.

[Bug c++/71955] Core dump and interesting behaviour while using reference class members

[anand312 at rediffmail dot com]

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

Anand Kulkarni  changed:

   What|Removed |Added

 CC||anand312 at rediffmail dot com

--- Comment #1 from Anand Kulkarni  ---
Created attachment 38945
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38945=edit
Attachment of the code.

code attached.

[Bug c++/71955] New: Core dump and interesting behaviour while using reference class members

[anand312 at rediffmail dot com]

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

Bug ID: 71955
   Summary: Core dump and interesting behaviour while using
reference class members
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: anand312 at rediffmail dot com
  Target Milestone: ---

I have 3 programs attached p1,p2 and p3.cpp. p3 seems to dump core where as p1
and p2 work fine. seems like some compiler optimization is blowing it away as
per stack trace. gcc version is below. All 3 programs are same esentially 
with just commented code sections [ which are entirely independent logically ]

g++ -fpermissive -o p1.out p1.cpp
g++ -fpermissive -o p2.out p2.cpp
g++ -fpermissive -o p3.out p3.cpp

[anand@ldnpsr2937 gcc-question]$ gcc --version
gcc (GCC) 6.1.1 20160621 (Red Hat 6.1.1-3)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug sanitizer/71953] ICE using address sanitizers with PCH

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug tree-optimization/71947] [6/7 Regression] x ^ y not folded to 0 if x == y by DOM

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[6/7 Regression] x ^ y not  |[6/7 Regression] x ^ y not
   |folded to 0 if x == y   |folded to 0 if x == y by
   ||DOM

--- Comment #2 from Richard Biener  ---
I have a fix that makes this folded at -O2 by VRP.  At -O1 we only have DOM
which
was optimizing this in GCC 5.