[Bug libstdc++/71856] [6/7 Regression] _GLIBCXX_DEBUG-mode breaks GNU parallel extension

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
Fixed for 6.2, but the gcc-6 branch still uses only _GLIBCXX_ASSERTIONS and not
_GLIBCXX_PARALLEL_ASSERTIONS (but parallel mode will no longer enable it by
mistake).

[Bug middle-end/71898] [7 Regression] [graphite] ICE: verify_ssa failed

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Created attachment 38939
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38939&action=edit
Candidate patch

[Bug c++/69560] x86_64: alignof(uint64_t) produces incorrect results with -m32

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

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

--- Comment #13 from Andreas Schwab  ---
alignof(long long) "type of a complete object"
alignof(foo) "type of a subobject"

[Bug libgomp/71941] New: ICE with OpenMP tasks and queue

[thakkinen at gmail dot com]

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

Bug ID: 71941
   Summary: ICE with OpenMP tasks and queue
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thakkinen at gmail dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 38940
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38940&action=edit
ICE with OpenMP tasks and queue, .ii file

Hi, following dummy code causes ICE with gcc 6.1.0:

#include 
#include 
#include 
#include 

using namespace std;

int main(void){
int loops=10;
int end_flag=0;
queue testq;
#pragma omp single
{
#pragma omp task
{
#pragma omp parallel for
for(int i=0;i0){
cout << "Testq size: " << testq.size() << endl;
}
}
}
}
return 0;
}

Compiler command and output:

$ g++ -Wall -Wextra -save-temps -fopenmp omp_task_queue.cpp
In file included from
/home/xx/gcc_61/gcc-6.1.0/include/c++/6.1.0/queue:64:0,
 from omp_task_queue.cpp:3:
/home/xx/gcc_61/gcc-6.1.0/include/c++/6.1.0/bits/stl_queue.h: In copy
constructor ‘std::queue >::queue(const
std::queue >&)’:
/home/xx/gcc_61/gcc-6.1.0/include/c++/6.1.0/bits/stl_queue.h:96:11:
internal compiler error: in cp_genericize, at cp/cp-gimplify.c:1568
 class queue
   ^
0x6de96a cp_genericize(tree_node*)
../.././gcc/cp/cp-gimplify.c:1568
0x5e82d9 finish_function(int)
../.././gcc/cp/decl.c:14820
0x69338e synthesize_method(tree_node*)
../.././gcc/cp/method.c:817
0x632cc0 mark_used(tree_node*, int)
../.././gcc/cp/decl2.c:5251
0x5c990a build_over_call
../.././gcc/cp/call.c:7608
0x5c812f build_new_method_call_1
../.././gcc/cp/call.c:8419
0x5c812f build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../.././gcc/cp/call.c:8489
0x693f5e locate_fn_flags
../.././gcc/cp/method.c:900
0x694126 get_copy_ctor(tree_node*, int)
../.././gcc/cp/method.c:958
0x6db3bb omp_cxx_notice_variable
../.././gcc/cp/cp-gimplify.c:908
0x6db301 omp_cxx_notice_variable
../.././gcc/cp/cp-gimplify.c:876
0x6dcc64 cp_genericize_r
../.././gcc/cp/cp-gimplify.c:1018
0xcb7713 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../.././gcc/tree.c:11531
0xcb7903 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../.././gcc/tree.c:11848
0xcb7903 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../.././gcc/tree.c:11848
0x6dbe4e genericize_omp_for_stmt
../.././gcc/cp/cp-gimplify.c:388
0x6dd438 cp_genericize_r
../.././gcc/cp/cp-gimplify.c:1385
0xcb7713 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../.././gcc/tree.c:11531
0x6dd24c cp_genericize_r
../.././gcc/cp/cp-gimplify.c:1222
0xcb7713 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set >*))
../.././gcc/tree.c:11531
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Gcc and system specs:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/xx/gcc_61/gcc-6.1.0/libexec/gcc/x86_64-pc-linux-gnu/6.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ./configure --disable-multilib
--prefix=/home/xx/gcc_61/gcc-6.1.0 --with-gmp=/home/xx/gcc_61/gmp-6.1.0
--with-mpfr=/home/xx/gcc_61/mpfr-3.1.4
--with-mpc=/home/xx/gcc_61/mpc-1.0.3
Thread model: posix
gcc version 6.1.0 (GCC)

$ uname -a
Linux abcd.efg.hi 2.6.32-642.3.1.el6.x86_64 #1 SMP Sun Jun 26 18:16:44 EDT 2016
x86_64 x86_64 x86_64 GNU/Linux

[Bug target/59833] ARM soft-float extendsfdf2 fails to quiet signaling NaN

[aurelien at aurel32 dot net]

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

--- Comment #10 from Aurelien Jarno  ---
I have just posted a new version of the patch:

https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01198.html

[Bug middle-end/71898] [7 Regression] [graphite] ICE: verify_ssa failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

  Attachment #38939|0   |1
is obsolete||

--- Comment #3 from Martin Liška  ---
Created attachment 38941
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38941&action=edit
Candidate patch v2

[Bug c++/69560] x86_64: alignof(uint64_t) produces incorrect results with -m32

[mh+gcc at glandium dot org]

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

--- Comment #14 from Mike Hommey  ---
(In reply to Andreas Schwab from comment #13)
> alignof(long long) "type of a complete object"
> alignof(foo) "type of a subobject"

But that doesn't tell why the alignment of a long long is 8 as a complete
object, but 4 as a subobject (the offset of l in foo is 4, not 8).

[Bug middle-end/71898] [7 Regression] [graphite] ICE: verify_ssa failed

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #4 from Joost VandeVondele  
---
(In reply to Martin Liška from comment #2)
> Created attachment 38939 [details]
> Candidate patch

Since this is a graphite fix, it might also fix PR71351 ?

[Bug c++/69560] x86_64: alignof(uint64_t) produces incorrect results with -m32

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

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

--- Comment #15 from Andreas Schwab  ---
Because the ABI says so.

[Bug middle-end/71898] [7 Regression] [graphite] ICE: verify_ssa failed

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
(In reply to Joost VandeVondele from comment #4)
> (In reply to Martin Liška from comment #2)
> > Created attachment 38939 [details]
> > Candidate patch
> 
> Since this is a graphite fix, it might also fix PR71351 ?

Unfortunately, it's a different issue.

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

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed Jul 20 08:31:35 2016
New Revision: 238512

URL: https://gcc.gnu.org/viewcvs?rev=238512&root=gcc&view=rev
Log:
PR tree-optimization/71503
PR tree-optimization/71683
* tree-if-conv.c (gen_phi_arg_condition): Record true predicate
and break.

gcc/testsuite
PR tree-optimization/71503
PR tree-optimization/71683
* gcc.dg/tree-ssa/ifc-pr71503.c: New test.
* gcc.dg/tree-ssa/ifc-pr71683.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ifc-pr71503.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ifc-pr71683.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

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

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
Author: amker
Date: Wed Jul 20 08:31:35 2016
New Revision: 238512

URL: https://gcc.gnu.org/viewcvs?rev=238512&root=gcc&view=rev
Log:
PR tree-optimization/71503
PR tree-optimization/71683
* tree-if-conv.c (gen_phi_arg_condition): Record true predicate
and break.

gcc/testsuite
PR tree-optimization/71503
PR tree-optimization/71683
* gcc.dg/tree-ssa/ifc-pr71503.c: New test.
* gcc.dg/tree-ssa/ifc-pr71683.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/ifc-pr71503.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/ifc-pr71683.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-if-conv.c

[Bug c++/71942] New: [ARM] Zero-extending whats allready zero-extended even when -O3

[albrecht.guendel at web dot de]

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

Bug ID: 71942
   Summary: [ARM] Zero-extending whats allready zero-extended even
when -O3
   Product: gcc
   Version: 5.4.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: albrecht.guendel at web dot de
  Target Milestone: ---

Hi, 
i came across the insertion of an redundant instruction while toggleing a pin
on an ARM-Microcontroller: 

while(1) GPIOA->ODR = (GPIOA->ODR ^ static_cast(1u

[Bug gcov-profile/57165] ICE when using -fprofile-use in cgraph.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
Is the bug still valid?
To reproduce the problem, we need a whole project, which can be instrumented,
run and eventually rebuilt with -fprofile-use.

[Bug c++/71942] [ARM] Zero-extending whats allready zero-extended even when -O3

[albrecht.guendel at web dot de]

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

--- Comment #1 from Albi  ---
To give a minimum case:

int main(void)
{
volatile unsigned short foo = 0;
while(1) foo ^= 1;
}

creates:
ldrh.w  r3, [sp, #6]
uxthr3, r3<< again no reason for this
eor.w   r3, r3, #1
strh.w  r3, [sp, #6]

[Bug libgomp/71941] [6/7 Regression] ICE with OpenMP tasks and queue

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-20
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |6.2
Summary|ICE with OpenMP tasks and   |[6/7 Regression] ICE with
   |queue   |OpenMP tasks and queue
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed.

[Bug c++/71943] New: Wreturn-type when combining destructor + return + __noreturn__ function

[sigmaepsilon92 at gmail dot com]

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

Bug ID: 71943
   Summary: Wreturn-type when combining destructor + return +
__noreturn__ function
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sigmaepsilon92 at gmail dot com
  Target Milestone: ---

The following code gives me a Wreturn-type warning:

extern void die(void) __attribute__((__noreturn__));

struct AutoDec{
~AutoDec() { }
};

bool testfn(void)
{
AutoDec ad;
return false;
((0) ? (void)0 : die());
}

I'm not sure how these three lines are related but if I remove any of it(the
struct, the return which causes unreachable code, or the condition around
die()) the warning goes away.

this happens on both ARM and x86/x64, using the following g++ options:
g++ -Wall -c -o /tmp/test.o /tmp/test.cpp

[Bug c++/71942] [ARM] Zero-extending whats allready zero-extended even when -O3

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||arm
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-20
 Ever confirmed|0   |1

--- Comment #2 from Richard Earnshaw  ---
This is a well known problem.  When a data object is marked volatile the
compiler is ultra-conservative about optimizing around it.  The result is that
the load and the zero-extend get separated and then never merged back together
again.

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

[gcc-bugzilla at chwress dot at]

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

Bug ID: 71945
   Summary: Integer overflow in use counter of shared pointers
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugzilla at chwress dot at
  Target Milestone: ---

Created attachment 38942
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38942&action=edit
A small program demonstrating the issue

We (Fabian Yamaguchi, Christian Wressnegger, and Alwin Maier) would like
to report an integer overflow of the use counter in the `share_pointer`
object of the Standard C++ Libraries version 5.4, 6.1 and before.
Exploiting the flaw requires some very specific prerequisites to be met,
a successful attempt however allows an attacker to execute code.
Consequently, this might be worth addressing.

The following conditions must hold true in order to trigger the
overflow:

(1) The target is compiled and runs on an architecture where
sizeof(size_t) is larger than sizeof(int), e.g. 64 bit systems with the
LP64 (Linux/ BSD) or LLP64 (Windows) data model in order to allocate
more UINT_MAX Objects.

(2) The attacker is capable of triggering the creation of a multitude of
shared objects.

(3) The attacker can make one of these shared pointers go out of scope,
e.g., by instructing the system to remove a state object.

The following short program (shared_ptr_overflow.cpp) demonstrates the
bug: First, we create a shared pointer referencing a minimal class
`MyClass`. Second, 0x more references are created which results
in the use counter to flip over to 0 again. Finally, we add one more
reference (use counter is incremented to 1) and make one of the shared
pointers go out of scope. As a result the use counter is decremented to
0 and the contained object is freed, leaving 0x shared pointer
object behind, that still reference that memory region.
Subsequently, an attacker may allocate memory containing arbitrary data
such as executable code to take the place of the freed object and make
all references left behind point to that piece of data.


--- snip (shared_ptr_overflow.cpp) 

//#define HAS_ENOUGH_MEMORY

int main()
{
std::cout << "1) Create an object and pass it over to a shared pointer..."
<< std::endl;
// We initialize the object on the heap and set x to 10.
shared_ptr ptr(new MyClass(10));
std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 1

const size_t numPtrs = (size_t) 0x;
#ifdef HAS_ENOUGH_MEMORY
std::cout << "2) Create 0x" << std::hex << numPtrs << " more references to
that object..." << std::endl;
std::vector> v(numPtrs);

for (size_t i = 0; i < numPtrs; i++)
{
v[i] = ptr;
}
std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 0


std::cout << "3) Create one more reference..." << std::endl;
{
shared_ptr ptr2 = ptr;
std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 1

std::cout << "4) That last reference goes out of scope again now..." <<
std::endl;
}
#else
{
std::cout << "2) Create an extra reference to that object..." <<
std::endl;
shared_ptr ptr2 = ptr;
std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 2

std::cout << "3) Emulate 0x" << std::hex << numPtrs << " more
references to that object..." << std::endl;
for(size_t i = 0; i < numPtrs; i++){
memset(&ptr, '\0', sizeof(shared_ptr));
ptr = ptr2;
}
std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 1

std::cout << "4) One reference goes out of scope again now..." <<
std::endl;
}
#endif
std::cout << "   ptr.use_count() -> " << ptr.use_count() << std::endl;
// use-count is 0

std::cout << "5) We now spray the heap with 'A's to overwrite the freed
memory" << std::endl;
for(int i = 0; i < 1000; i++){
char *foo = new char[4];
memset(foo, 'A', 4);
}

// The address stored in ptr is still that of the free'd object
std::cout << "   ptr: " << (void *) ptr.get() << std::endl;

// ptr->x is now 0x41414141
std::cout << "   value: " << std::hex << ptr->x << std::endl;


std::cout << "*) Bye!" << std::endl;

#ifdef HAS_ENOUGH_MEMORY
v.clear();
std::cout << std::endl;
std::cout << "Destroying the last reference causes a double-free of the
object..." << std::endl;
#endif
return 0;
}

--- /snip ---


For testing purposes the program can be compiled and run with the
HAS_ENOUGH_MEMORY definition commented out, in order to reduce the
hardware prerequisites. To test this, build the demo application using
the provided make file, an

[Bug middle-end/71942] [ARM] Zero-extending whats allready zero-extended even when -O3

[albrecht.guendel at web dot de]

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

--- Comment #3 from Albi  ---
Agreed, after way more google research a lot of people complain about this.

Never the less this poses a big problem since it halves the performance of
every load on a sub-32-bit datatype.

Imho the problem issnt in the optimizer... i think the fundamental problem is
that the instruction-set is not aware of the implicit unsigned zero-extention
thats allready done by the load-instruction.

With that knowledge the idea of inserting the (redundant) zero-extending
instruction like "uxth" wouldnt even come up even without optimization.

This is at least true for every unsigned short or unsigned char.
Signed types need the sign extension of course.

In other words: there is actually no reason the instruction should be issued in
the first place and therefore the optimizer should not really need to remove it
afterwards.  Its fundamentally redundant.

[Bug c++/71946] New: FD_ZERO macro parsing error in lambda function.

[ruanbeihong at gmail dot com]

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

Bug ID: 71946
   Summary: FD_ZERO macro parsing error in lambda function.
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ruanbeihong at gmail dot com
  Target Milestone: ---

#include 
#include 

std::function test = []{
fd_set set;
FD_ZERO(&set);
};

g++ -std=c++11 a.cpp

In file included from /usr/include/x86_64-linux-gnu/sys/select.h:30:0,
 from a.cpp:1:
a.cpp: In lambda function:
a.cpp:6:2: error: expected ‘)’ before ‘:’ token
  FD_ZERO(&set);
  ^

[Bug libgomp/71941] [6/7 Regression] ICE with OpenMP tasks and queue

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from Jakub Jelinek  ---
Reduced testcase:
struct A { A (); A (A &); ~A (); };

template 
struct B
{
  struct C { A a; C () : a () {} };
  C c;
  void foo ();
};

void
bar ()
{
  B<0> b;
#pragma omp task
  for (int i = 0; i < 2; i++)
b.foo ();
}

Caused by r234436.

[Bug libgomp/71941] [6/7 Regression] ICE with OpenMP tasks and queue

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug c++/71943] Wreturn-type when combining destructor + return + __noreturn__ function

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I think it is fine to warn, -Wreturn* warning is done early before
optimizations (intentionally), so unreachable code that might not be yet
optimized away yet may confuse it.  Don't put unreachable code after return and
the warning will go away.

[Bug c++/71946] FD_ZERO macro parsing error in lambda function.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-20
 CC||marxin at gcc dot gnu.org
   Target Milestone|--- |4.9.4
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, all GCC releases supporting -std=c++ are affected.
ICC and clang++ accept the code snippet.

[Bug c++/71937] out of memory on very large fuction

[trippels at gcc dot gnu.org]

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

--- Comment #7 from Markus Trippelsdorf  ---
Execution times (seconds)
 phase setup :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall 
  1629 kB ( 0%) ggc
 phase parsing   :   1.32 ( 0%) usr   0.24 ( 2%) sys   1.56 ( 0%) wall 
137733 kB (11%) ggc
 phase opt and generate  : 393.97 (100%) usr  13.22 (98%) sys 407.22 (100%)
wall 1067477 kB (88%) ggc
 |name lookup:   0.12 ( 0%) usr   0.02 ( 0%) sys   0.12 ( 0%) wall 
  5015 kB ( 0%) ggc
 |overload resolution:   0.83 ( 0%) usr   0.03 ( 0%) sys   0.89 ( 0%) wall 
 84696 kB ( 7%) ggc
 garbage collection  :   0.41 ( 0%) usr   0.01 ( 0%) sys   0.42 ( 0%) wall 
 0 kB ( 0%) ggc
 callgraph construction  :   0.19 ( 0%) usr   0.01 ( 0%) sys   0.19 ( 0%) wall 
  7035 kB ( 1%) ggc
 callgraph optimization  :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall 
   182 kB ( 0%) ggc
 ipa inlining heuristics :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 cfg construction:   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
  1072 kB ( 0%) ggc
 cfg cleanup :   0.03 ( 0%) usr   0.01 ( 0%) sys   0.04 ( 0%) wall 
13 kB ( 0%) ggc
 trivially dead code :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall 
 0 kB ( 0%) ggc
 df scan insns   :   0.11 ( 0%) usr   0.01 ( 0%) sys   0.13 ( 0%) wall 
17 kB ( 0%) ggc
 df live regs:   0.06 ( 0%) usr   0.00 ( 0%) sys   0.06 ( 0%) wall 
 0 kB ( 0%) ggc
 df reg dead/unused notes:   0.08 ( 0%) usr   0.00 ( 0%) sys   0.08 ( 0%) wall 
  2713 kB ( 0%) ggc
 register information:   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
 0 kB ( 0%) ggc
 alias analysis  :   0.04 ( 0%) usr   0.01 ( 0%) sys   0.04 ( 0%) wall 
  2400 kB ( 0%) ggc
 rebuild jump labels :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
 0 kB ( 0%) ggc
 preprocessing   :   0.06 ( 0%) usr   0.09 ( 1%) sys   0.14 ( 0%) wall 
  1326 kB ( 0%) ggc
 parser (global) :   0.14 ( 0%) usr   0.05 ( 0%) sys   0.21 ( 0%) wall 
 25190 kB ( 2%) ggc
 parser struct body  :   0.00 ( 0%) usr   0.01 ( 0%) sys   0.01 ( 0%) wall 
  4525 kB ( 0%) ggc
 parser function body:   1.04 ( 0%) usr   0.06 ( 0%) sys   1.10 ( 0%) wall 
 97874 kB ( 8%) ggc
 parser inl. func. body  :   0.02 ( 0%) usr   0.01 ( 0%) sys   0.02 ( 0%) wall 
  2864 kB ( 0%) ggc
 parser inl. meth. body  :   0.04 ( 0%) usr   0.01 ( 0%) sys   0.06 ( 0%) wall 
  2189 kB ( 0%) ggc
 template instantiation  :   0.02 ( 0%) usr   0.01 ( 0%) sys   0.02 ( 0%) wall 
  3835 kB ( 0%) ggc
 inline parameters   :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.02 ( 0%) wall 
  1176 kB ( 0%) ggc
 tree gimplify   :   0.07 ( 0%) usr   0.01 ( 0%) sys   0.08 ( 0%) wall 
 13487 kB ( 1%) ggc
 tree eh :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
  5681 kB ( 0%) ggc
 tree CFG construction   :   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
  9974 kB ( 1%) ggc
 tree CFG cleanup:   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
17 kB ( 0%) ggc
 tree PHI insertion  :   1.79 ( 0%) usr   0.09 ( 1%) sys   1.87 ( 0%) wall 
924596 kB (77%) ggc
 tree SSA rewrite:   2.13 ( 1%) usr   0.08 ( 1%) sys   2.21 ( 1%) wall 
  4486 kB ( 0%) ggc
 tree SSA other  :   0.03 ( 0%) usr   0.01 ( 0%) sys   0.06 ( 0%) wall 
17 kB ( 0%) ggc
 tree SSA incremental:   0.11 ( 0%) usr   0.01 ( 0%) sys   0.11 ( 0%) wall 
 0 kB ( 0%) ggc
 tree operand scan   :   0.03 ( 0%) usr   0.01 ( 0%) sys   0.03 ( 0%) wall 
  3108 kB ( 0%) ggc
 dominance frontiers :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
 0 kB ( 0%) ggc
 dominance computation   :   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall 
 0 kB ( 0%) ggc
 out of ssa  : 386.85 (98%) usr  12.92 (96%) sys 399.80 (98%) wall 
   168 kB ( 0%) ggc
 expand vars :   0.00 ( 0%) usr   0.00 ( 0%) sys   0.00 ( 0%) wall 
  2194 kB ( 0%) ggc
 expand  :   0.27 ( 0%) usr   0.01 ( 0%) sys   0.28 ( 0%) wall 
 35591 kB ( 3%) ggc
 post expand cleanups:   0.03 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
  3643 kB ( 0%) ggc
 loop init   :   0.02 ( 0%) usr   0.00 ( 0%) sys   0.03 ( 0%) wall 
97 kB ( 0%) ggc
 integrated RA   :   0.61 ( 0%) usr   0.01 ( 0%) sys   0.62 ( 0%) wall 
 19175 kB ( 2%) ggc
 reload  :   0.34 ( 0%) usr   0.01 ( 0%) sys   0.35 ( 0%) wall 
  3658 kB ( 0%) ggc
 thread pro- & epilogue  :   0.07 ( 0%) usr   0.00 ( 0%) sys   0.07 ( 0%) wall 
   361 kB ( 0%) ggc
 shorten branches:   0.04 ( 0%) usr   0.00 ( 0%) sys   0.04 ( 0%) wall 
 0 kB ( 0%) ggc
 final   :   0.23 ( 0%) usr   0.01 ( 0%) sys   0.24 ( 0%) wall 
 17991 kB ( 1%) ggc
 initialize rtl  :   0.01 ( 0%) usr   0.00 ( 0%) sys   0.01 ( 0%) wall 
21 kB ( 0%) ggc
 rest of compilation :   0.12 ( 0%) usr   0.00 ( 0%) sys   0.13 ( 0%) 

[Bug c++/71937] out of memory on very large fuction

[trippels at gcc dot gnu.org]

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

--- Comment #8 from Markus Trippelsdorf  ---
  Frame: Ir Backtrace for Thread 1
   [ 0]  85,518 brk (9503 x)
   [ 1] 645,718 sbrk (9502 x)
   [ 2] 787,930 __default_morecore (9498 x)
   [ 3] 345,696,969 _int_malloc (1634374 x)
   [ 4] 429,049,064 malloc (1634371 x)
   [ 5] 424,601,116 0x10174d90 (1573948 x)
   [ 6]  40,785,111 xmalloc (141360 x)
   [ 7]  43,846,513 mempool_obstack_chunk_alloc(unsigned long) (160495 x)
   [ 8]  56,593,460 _obstack_newchunk (145510 x)
   [ 9]  10,642,493,461 bitmap_set_bit(bitmap_head*, int) (107039144 x)
   [10]  40,631,180,636 coalesce_ssa_name() (122 x)
   [11]  40,967,370,411 rewrite_out_of_ssa(ssaexpand*) (122 x)
   [12]  41,081,413,163 (anonymous namespace)::pass_expand::execute(function*)
(122 x)
   [13]  41,820,088,098 execute_one_pass(opt_pass*) (4536 x)
   [14]  42,589,456,759 execute_pass_list(function*, opt_pass*) (122 x)
   [15]  42,664,521,643 cgraph_node::expand() (122 x)
   [16]  42,672,880,045 output_in_order(bool) (1 x)
   [17]  55,222,713,798 symbol_table::compile() (1 x)
   [18]  55,860,373,675 symbol_table::finalize_compilation_unit() (1 x)
   [19]  62,683,937,902 compile_file() (1 x)
   [20]  62,699,127,487 toplev::main(int, char**) (1 x)
   [21]  62,699,127,511 main (1 x)

[Bug testsuite/71931] build sysroot flags are not passed to target lib tests

[nsz at gcc dot gnu.org]

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

--- Comment #1 from nsz at gcc dot gnu.org ---
a workaround is passing EXTRA_DEJAGNU_SITE_CONFIG=foo.exp to make, where
foo.exp has

set GCC_UNDER_TEST "build-dir/gcc/xgcc -Bbuild-dir/gcc --sysroot build-sysroot"

[Bug c++/71937] out of memory on very large fuction

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
So does -fno-tree-coalesce-vars help the compile time/memory here?

[Bug c++/71937] out of memory on very large fuction

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
(In reply to Jakub Jelinek from comment #9)
> So does -fno-tree-coalesce-vars help the compile time/memory here?

No. Even:

diff --git a/gcc/tree-ssa-coalesce.c b/gcc/tree-ssa-coalesce.c
index 34c3fa1..c5fddd0 100644
--- a/gcc/tree-ssa-coalesce.c
+++ b/gcc/tree-ssa-coalesce.c
@@ -1813,7 +1813,7 @@ coalesce_ssa_name (void)
   /* If this optimization is disabled, we need to coalesce all the
  names originating from the same SSA_NAME_VAR so debug info
  remains undisturbed.  */
-  if (!flag_tree_coalesce_vars)
+  if (false)
 {
   hash_table ssa_name_hash (10);

doesn't help.

[Bug middle-end/71898] [7 Regression] [graphite] ICE: verify_ssa failed

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
Author: marxin
Date: Wed Jul 20 11:16:47 2016
New Revision: 238513

URL: https://gcc.gnu.org/viewcvs?rev=238513&root=gcc&view=rev
Log:
Properly handly PHI stmts in later_of_the_two (PR

PR middle-end/71898
* graphite-isl-ast-to-gimple.c (later_of_the_two):
Properly handly PHI stmts.
* gfortran.dg/graphite/pr71898.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/graphite/pr71898.f90
Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/71898] [7 Regression] [graphite] ICE: verify_ssa failed

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug c++/59281] attribute((constructor)) accepts enum class as integer constant

[nyh at math dot technion.ac.il]

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

Nadav Har'El  changed:

   What|Removed |Added

 CC||nyh at math dot technion.ac.il

--- Comment #3 from Nadav Har'El  ---
Sad, this "fix" removed a useful feature... For example, the OSv project has:


enum class init_prio : int {
dtb = 101,
console,
sort,
cpus,
fpranges,
...
}

To automatically create numbers for these priorities. This trick no longer
works.

[Bug fortran/71623] [5/6/7 Regression] Segfault when allocating deferred-length characters to size of a pointer

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from vehre at gcc dot gnu.org ---
No regressions reported, closing.

[Bug fortran/68241] [meta-bug] Deferred-length character

[vehre at gcc dot gnu.org]

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

Bug 71623 Summary: [5/6/7 Regression] Segfault when allocating deferred-length 
characters to size of a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71623

   What|Removed |Added

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

[Bug middle-end/71947] New: x ^ y not folded to 0 if x == y

[prathamesh3492 at gcc dot gnu.org]

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

Bug ID: 71947
   Summary: x ^ y not folded to 0 if x == y
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

Hi,
For the following case:
int f(int x, int y)
{
  int ret;
  if (x == y)
ret = x ^ y;
  else
ret = 1;

  return ret;
}

x ^ y does not get folded to 0.

From the discussion in:
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00385.html
r233207 must have regressed this test-case.

Thanks,
Prathamesh

[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

   Last reconfirmed|2016-02-19 00:00:00 |2016-7-20
 CC||thopre01 at gcc dot gnu.org

--- Comment #5 from Thomas Preud'homme  ---
I can indeed reproduce that bug with latest gcc-5-branch either by compiling
the below testcase, or by building ChibiOS 3.0.4 as described in
https://answers.launchpad.net/gcc-arm-embedded/+question/280242

Best regards.

(In reply to acrsofter from comment #3)
> reproduce steps:
> 
> [foo.c]
> 
> int _umh(int i)
> {
>   return i+1;
> }
> 
> int weaks(int i) __attribute__((weak, alias("_umh")));
> 
> int main()
> {
>  return weaks(10);
> }
> 
> 
> [bar.c]
> 
> int weaks(int i)
> {
>   return i+1;
> }
> 
> 
> now compile:
> 
> gcc -c bar.c
> 
> gcc -flto -c foo.c
> 
> gcc -flto -o elf bar.o foo.o
> 
> 
> note:
> 
> bar compiled without flt
> but rest with flt
> 
> 
> now at linking stage booms
> at line
> 
>  gcc_assert (c != SYMBOL_EXTERNAL
>   && (c == SYMBOL_DUPLICATE || !symbol_partitioned_p (node)));
> 
> in lto/lto-partition.c
> 
> ===
> 
> same code compiled without lto ok
> 
> gcc 4.9.3 not affected
> but 5.3.0 affected and latest (gcc-6-20160214) affected

[Bug fortran/71688] [4.9/5/6/7 Regression] ICE in analyze, at cgraphunit.c:632 with -fcoarray=lib

[jamborm at gcc dot gnu.org]

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

--- Comment #9 from Martin Jambor  ---
Author: jamborm
Date: Wed Jul 20 13:24:19 2016
New Revision: 238515

URL: https://gcc.gnu.org/viewcvs?rev=238515&root=gcc&view=rev
Log:
Fix PR fortran/71688

2016-07-20  Martin Jambor  

PR fortran/71688
* trans-decl.c (gfc_generate_function_code): Use get_create rather
than create to get a call graph node.

testsuite/
gfortran.dg/pr71688.f90: New test.


Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/pr71688.f90
Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/fortran/trans-decl.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug middle-end/71315] missing strlen optimization on a POINTER_PLUS expression

[prathamesh3492 at gcc dot gnu.org]

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

 CC||prathamesh3492 at gcc dot 
gnu.org

--- Comment #3 from prathamesh3492 at gcc dot gnu.org ---
Hi,
As of r238513, gcc folds call to strlen into constant.
void f(unsigned x)

void g()
{
  char s[] = "hello";
  f (__builtin_strlen (s + 1));
}

optimized dump shows:
;; Function g (g, funcdef_no=0, decl_uid=1753, cgraph_uid=0, symbol_order=0)

Optimizing: _1 = __builtin_strlen (&MEM[(void *)&s + 1B]);
into: _1 = 4;
g ()
{
  char s[6];
  long unsigned int _1;
  unsigned int _2;

  :
  s = "hello";
  _1 = 4;
  _2 = (unsigned int) _1;
  f (_2);
  s ={v} {CLOBBER};
  return;

}

However there seems to be another issue, if there are repeated
calls to strlen() with same arg, only the first call is folded.
For example consider following case:

void f (unsigned);

void g (void)
{
char s[] = "hello";
f (__builtin_strlen (s));
f (__builtin_strlen (s));
}

Only the first call to __builtin_strlen() is folded to 5,
the second one isn't.
Optimized dump shows:
;; Function g (g, funcdef_no=0, decl_uid=1753, cgraph_uid=0, symbol_order=0)

Optimizing: _1 = __builtin_strlen (&s);
into: _1 = 5;
g ()
{
  char s[6];
  long unsigned int _1;
  unsigned int _2;
  long unsigned int _3;
  unsigned int _4;

  :
  s = "hello";
  _1 = 5;
  _2 = (unsigned int) _1;
  f (_2);
  _3 = __builtin_strlen (&s);
  _4 = (unsigned int) _3;
  f (_4);
  s ={v} {CLOBBER};
  return;

}

clang seems to fold both the calls to 5.

Thanks,
Prathamesh

[Bug fortran/71688] [4.9/5/6/7 Regression] ICE in analyze, at cgraphunit.c:632 with -fcoarray=lib

[jamborm at gcc dot gnu.org]

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

--- Comment #10 from Martin Jambor  ---
Author: jamborm
Date: Wed Jul 20 13:31:19 2016
New Revision: 238516

URL: https://gcc.gnu.org/viewcvs?rev=238516&root=gcc&view=rev
Log:
Fix PR fortran/71688

2016-07-20  Martin Jambor  

PR fortran/71688
* trans-decl.c (gfc_generate_function_code): Use get_create rather
than create to get a call graph node.

testsuite/
* gfortran.dg/pr71688.f90: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr71688.f90
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-decl.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug middle-end/71315] missing strlen optimization on a POINTER_PLUS expression

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
This is alias analysis deficiency.  It considers s escaped, because &s[0] is
passed to a function (strlen), but __builtin_strlen really is not allowed to
save the argument into some global var that e.g. the following call to f
function could then use to modify it.

The strlen pass just uses the alias oracle to query if it needs to invalidate
remembered string lengths, in particular on the f () call.  As the alias oracle
considers s to be escaped, it returns that the f () call might change it (which
it indeed could if instead of __builtin_strlen one used some function with the
same prototype, but on which the compiler can't make any assumptions).

[Bug middle-end/50060] intrinsics not folded by the middle-end

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jul 20 14:00:02 2016
New Revision: 238520

URL: https://gcc.gnu.org/viewcvs?rev=238520&root=gcc&view=rev
Log:
PR c++/50060
* constexpr.c (cxx_eval_builtin_function_call): Pass false as lval
when evaluating call arguments.  Use fold_builtin_call_array instead
of fold_build_call_array_loc, return t if it returns NULL.  Otherwise
check the result with potential_constant_expression and call
cxx_eval_constant_expression on it.

* g++.dg/cpp0x/constexpr-50060.C: New test.
* g++.dg/cpp1y/constexpr-50060.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-50060.C
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-50060.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog

[Bug target/71948] New: [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

Bug ID: 71948
   Summary: [avr] Make progmem work on reduced Tiny cores by
adding 0x4000 to symbols
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

The reduced tiny cores feature reading from flash:  The flash memory can be
seen in the RAM address range at an offset starting at 0x4000.

Hence progmem can be used to put data into flash and to generate the correct
accesses without the need of special functions (like pgm_read_* which is needed
on generic core).  This can easily be achieved by adding 0x4000 to the value of
symbols.

[Bug c++/71909] [4.9/5/6/7 Regression] g++ accepts an unreachable function catch block that lacks a corresponding try

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jul 20 14:01:30 2016
New Revision: 238521

URL: https://gcc.gnu.org/viewcvs?rev=238521&root=gcc&view=rev
Log:
PR c++/71909
* parser.c (cp_parser_save_member_function_body): Consume
__transaction_relaxed or __transaction_atomic with optional
attribute.  Only skip catch with block if try keyword is seen.

* g++.dg/parse/pr71909.C: New test.
* g++.dg/tm/pr71909.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/parse/pr71909.C
trunk/gcc/testsuite/g++.dg/tm/pr71909.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/testsuite/ChangeLog

[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

 Target||avr
   Priority|P3  |P5
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-07-20
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

[Bug c++/71909] [4.9/5/6/7 Regression] g++ accepts an unreachable function catch block that lacks a corresponding try

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jul 20 14:05:00 2016
New Revision: 238523

URL: https://gcc.gnu.org/viewcvs?rev=238523&root=gcc&view=rev
Log:
PR c++/71909
* parser.c (cp_parser_save_member_function_body): Consume
__transaction_relaxed or __transaction_atomic with optional
attribute.  Only skip catch with block if try keyword is seen.

* g++.dg/parse/pr71909.C: New test.
* g++.dg/tm/pr71909.C: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/g++.dg/parse/pr71909.C
branches/gcc-6-branch/gcc/testsuite/g++.dg/tm/pr71909.C
Modified:
branches/gcc-6-branch/gcc/cp/ChangeLog
branches/gcc-6-branch/gcc/cp/parser.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

  Known to fail||5.4.1, 6.1.1, 7.0

--- Comment #6 from Thomas Preud'homme  ---
I can also reproduce both bugs with trunk GCC.

[Bug c++/71909] [4.9/5/6/7 Regression] g++ accepts an unreachable function catch block that lacks a corresponding try

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jul 20 14:16:40 2016
New Revision: 238526

URL: https://gcc.gnu.org/viewcvs?rev=238526&root=gcc&view=rev
Log:
PR c++/71909
* parser.c (cp_parser_save_member_function_body): Consume
__transaction_relaxed or __transaction_atomic with optional
attribute.  Only skip catch with block if try keyword is seen.

* g++.dg/parse/pr71909.C: New test.
* g++.dg/tm/pr71909.C: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/parse/pr71909.C
branches/gcc-5-branch/gcc/testsuite/g++.dg/tm/pr71909.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/parser.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[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

--- Comment #1 from Georg-Johann Lay  ---
Author: gjl
Date: Wed Jul 20 14:12:16 2016
New Revision: 238525

URL: https://gcc.gnu.org/viewcvs?rev=238525&root=gcc&view=rev
Log:
gcc/
Implement attribute progmem on reduced Tiny cores by adding
flash offset 0x4000 to respective symbols.

PR target/71948
* doc/extend.texi (AVR Variable Attributes) [progmem]: Add
documentation how it works on reduced Tiny cores.
(AVR Named Address Spaces): No support for reduced Tiny.
* config/avr/avr.c (AVR_SYMBOL_FLAG_TINY_PM): New macro.
(avr_address_tiny_pm_p): New static function.
(avr_print_operand_address) [AVR_TINY]: Add AVR_TINY_PM_OFFSET
if the address is in progmem.
(avr_assemble_integer): Same.
(avr_encode_section_info) [AVR_TINY]: Set AVR_SYMBOL_FLAG_TINY_PM
for symbol_ref in progmem.
* config/avr/avr.h (AVR_TINY_PM_OFFSET): New macro.
* config/avr/avr-c.c (avr_cpu_cpp_builtins): Use it instead of
magic 0x4000 when built-in def'ing __AVR_TINY_PM_BASE_ADDRESS__.
gcc/testsuite/
PR target/71948
* gcc.target/avr/torture/tiny-progmem.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/avr/torture/tiny-progmem.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/avr/avr-c.c
trunk/gcc/config/avr/avr.c
trunk/gcc/config/avr/avr.h
trunk/gcc/doc/extend.texi
trunk/gcc/testsuite/ChangeLog

[Bug c++/71909] [4.9/5/6/7 Regression] g++ accepts an unreachable function catch block that lacks a corresponding try

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Wed Jul 20 14:32:46 2016
New Revision: 238527

URL: https://gcc.gnu.org/viewcvs?rev=238527&root=gcc&view=rev
Log:
PR c++/71909
* parser.c (cp_parser_save_member_function_body): Consume
__transaction_relaxed or __transaction_atomic with optional
attribute.  Only skip catch with block if try keyword is seen.

* g++.dg/parse/pr71909.C: New test.
* g++.dg/tm/pr71909.C: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/parse/pr71909.C
branches/gcc-4_9-branch/gcc/testsuite/g++.dg/tm/pr71909.C
Modified:
branches/gcc-4_9-branch/gcc/cp/ChangeLog
branches/gcc-4_9-branch/gcc/cp/parser.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug c++/71909] [4.9/5/6/7 Regression] g++ accepts an unreachable function catch block that lacks a corresponding try

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/50060] intrinsics not folded by the middle-end

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #10 from Jakub Jelinek  ---
Should be fixed on the trunk (for C++14/C++17 and later).

[Bug middle-end/50060] intrinsics not folded by the middle-end

[pbristow at hetp dot u-net.com]

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

--- Comment #11 from Paul A. Bristow  ---
Thanks for all this, which looks helpful, but I am not able to use unreleased
compiler versions, so meanwhile I am working to use a workaround (to allow me
to see what other pitfalls lie ahead for the novice ;-).  FWIW my proof of
concept is 

// Version that returns both mantissa and exponent as a tuple.
// Proof of concept only, ignoring sign, overflow, denorm, infinite and NaNs.
constexpr std::tuple frexp(float f)
{
  int e = 0;

  if (f >= 1.f)
  {
f /= 2 ;
e++;
  }
  else if (f <= 0.1f)
  {
f *= 2;
e--;
  }
  return  std::make_tuple(f, e);
 }

allowing

constexpr std::tuple ee = frexp(1.f);

(I can confirm by checking that debugging will not step into the function, and
also I can assign the tuple or the elements to a constexpr variable.)

Of course, this isn't a 'drop-in' for std::frexp, nor templated on other
floating-point types, like Boost.Multiprecision types, but it will help for
now.

I hope that this can be resolved somehow eventually, though I fear the pointer
update will always be a nono for constexpr, preventing a truely 'drop-in'
solution thus preventing any function that uses frexp from being constexpr.

[Bug rtl-optimization/65698] Non-optimal code for simple compare function for x86 32-bit target

[ysrumyan at gmail dot com]

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

--- Comment #3 from Yuri Rumyantsev  ---
I see that this bug was no considered for a while.
Here is my additional comment.
First of all, this test was extracted from bzip2 benchmark, mainGTU function.
The problem is that (1) tree optimizer collects cse for i1 * 2 and i2 * 2;
(2) Forward propagation pass do not substitute it back to address computation
since use_killed_between is very simplified it handles only simple basic block
or semi-hammock:
  /* Finally, if DEF_BB is the sole predecessor of TARGET_BB.  */
  if (single_pred_p (target_bb)
  && single_pred (target_bb) == def_bb)
This function must be enhanced to handle arbitrary cfg.

Note that this deficiency increases register pressure on 2 and we have more
spills/fills for x86 32-bit target.

[Bug tree-optimization/56688] Fortran save statement prevents loop vectorization.

[ysrumyan at gmail dot com]

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

--- Comment #7 from Yuri Rumyantsev  ---
I checked that GCC 7 compiler still does not vectorize loops in thin6d function
which is the only hottest function in 200.sixtrack benchmark.

[Bug pch/71934] pch cannot be disabled so gcc cannot be position independent

[bugdal at aerifal dot cx]

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

Rich Felker  changed:

   What|Removed |Added

 CC||bugdal at aerifal dot cx

--- Comment #4 from Rich Felker  ---
Note that some hosts are PIC/PIE only, or require relocating the program text
at runtime (textrels). This includes anything without an MMU. GCC 5.x and
presumably 6.x works fine on the NOMMU target I've tested with ELF/FDPIC ABI,
but of course would blow up if somebody tried using a precompiled header file.

There should really be a build-time option to make gcc completely ignore the
existence of .gch files and fallback to the normal headers as if they didn't
exist. Even better would be just removing PCH support completely.

[Bug c++/71937] out of memory on very large fuction

[trippels at gcc dot gnu.org]

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

--- Comment #11 from Markus Trippelsdorf  ---
The excessive memory usage only happens when compiling without optimizations.
Using -O1 it stays below 2 GB, but takes minutes to finish.

[Bug fortran/71688] [4.9/5/6/7 Regression] ICE in analyze, at cgraphunit.c:632 with -fcoarray=lib

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Jambor  ---
Fixed on all active branches.

[Bug c++/71513] [6/7 Regression] ICE on valid C++11 code (with alignas specifier) on x86_64-linux-gnu: Segmentation fault

[jason at gcc dot gnu.org]

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

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 lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

Version|5.3.0   |7.0

--- Comment #7 from Thomas Preud'homme  ---
Update version accordingly.

[Bug fortran/71839] undefined reference to `_gfortran_caf_stop_str'

[mexas at bristol dot ac.uk]

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

Anton Shterenlikht  changed:

   What|Removed |Added

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

--- Comment #8 from Anton Shterenlikht  ---
OpenCoarrays folk cannot reproduce it.
I found a workaround.
In any case, this seems nothing to do with GCC.
Please close this PR.

Thanks


Anton

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||5.4.0
   Keywords||missed-optimization
   Last reconfirmed||2016-07-20
  Component|middle-end  |tree-optimization
 CC||law at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|x ^ y not folded to 0 if x  |[6/7 Regression] x ^ y not
   |== y|folded to 0 if x == y
   Target Milestone|--- |6.2

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug c/71949] New: ATOMIC_FLAG_INIT definition in stdatomic.h

[patrick.pelissier at gmail dot com]

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

Bug ID: 71949
   Summary: ATOMIC_FLAG_INIT definition in stdatomic.h
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick.pelissier at gmail dot com
  Target Milestone: ---

Compiling the following program, I get one error for one kind of affectation to
ATOMIC_FLAG_INIT :

#include 
void f(void) {
  atomic_flag f1 = ATOMIC_FLAG_INIT;
  atomic_flag f2;
  f2 =  ATOMIC_FLAG_INIT;
}

$ /opt/gcc/bin/gcc -c flag.c
In file included from flag.c:1:0:
flag.c: In function 'f':
flag.c:6:9: error: expected expression before '{' token
   f2 =  ATOMIC_FLAG_INIT;
 ^

$ /opt/gcc/bin/gcc --version
gcc (GCC) 6.1.0

I expected both construction to be valid.

Proposed solution: fix definition of ATOMIC_FLAG_INIT in stdatomic.h into:

#define ATOMIC_FLAG_INIT ((atomic_flag) { 0 })

instead of 

#define ATOMIC_FLAG_INIT{ 0 }

[Bug gcov-profile/69004] Building t-engine on ARM fails during -fprofile-use stage

[tulipawn at gmail dot com]

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

--- Comment #16 from PeteVine  ---
I've just read 4.9.4 is to be released soon - any chance of landing a fix for
this issue?

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

[sytelus at gmail dot com]

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

Bug ID: 71950
   Summary: std::ios_base::failure.what() returns irrelevant error
message
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sytelus at gmail dot com
  Target Milestone: ---

The what() method of exception class std::ios_base::failure should return
helpful error messages indicating why IO operation failed. At present it
returns irrelevant and unhelpful message such as "basic_ios::clear".

Below is the code to reproduce this bug:

#include 
#include 

int main() {
try {
std::ofstream flog;
flog.exceptions(flog.exceptions() | std::ios::failbit |
std::ifstream::badbit);
flog.open("~/bad/path/xyz.tsv", std::ios::trunc);
}
catch (const std::ios_base::failure &ex) {
std::cout << ex.what();
}
}

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

[sytelus at gmail dot com]

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

Shital Shah  changed:

   What|Removed |Added

 CC||sytelus at gmail dot com

--- Comment #22 from Shital Shah  ---
This bug just bit me and I came to know about this regression via thread on
StackOverflow.com. I've also filed related bug where what() method on exception
returns irrelevant message: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71950


Hope this gets fixed soon.

Stackoverflow disucssion:

http://stackoverflow.com/questions/38471518/how-to-get-io-error-messages-when-creating-a-file-in-c/

[Bug libgcc/71951] New: libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[timo.teras at iki dot fi]

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

Bug ID: 71951
   Summary: libgcc_s built with -fomit-frame-pointer on aarch64 is
broken
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: timo.teras at iki dot fi
  Target Milestone: ---

On gcc 6.1.0 if CFLAGS contains -fomit-frame-pointer it is used to build
libgcc_s. On Aarch64 this creates non-working libgcc_s and it crashes when
unwinding.

I suppose the unwinding code needs frame pointers always. This probably worked
until https://gcc.gnu.org/ml/gcc-patches/2013-03/msg01228.html made
omit-frame-pointer skip it for leaf functions. I guess the unwinding leaf
functions should have attributes for no-omit-frame-pointer, or just add
-fno-omit-frame-pointer for the relevant files.

[Bug libgcc/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Unwind code in lib gcc does uses the dwarf2 unwinding tables. So omit frame
pointer should not change anything.

[Bug libgcc/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Do you have an example? Because I ran with omit frame pointer all the time.

[Bug libgcc/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[timo.teras at iki dot fi]

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

--- Comment #3 from Timo Teräs  ---
$ cat a.cpp <

int foo()
{
 throw "Foo!";
}

int main ()
{
   try {
 foo();
   }catch (const char* msg) {
 std::cerr << msg << std::endl;
   }
   return 0;
}
EOF

$ gdb a
GNU gdb (GDB) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "aarch64-alpine-linux-musl".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from a...done.
(gdb) run
Starting program: a 

Program received signal SIGSEGV, Segmentation fault.
0x03ffb7db9780 in _Unwind_GetGR () from /usr/lib/libgcc_s.so.1
(gdb) where
#0  0x03ffb7db9780 in _Unwind_GetGR () from /usr/lib/libgcc_s.so.1
#1  0x03ffb7dba938 in ?? () from /usr/lib/libgcc_s.so.1
#2  0x03ffb7dbab88 in ?? () from /usr/lib/libgcc_s.so.1
#3  0x03ffb7dbaed4 in _Unwind_RaiseException () from /usr/lib/libgcc_s.so.1
#4  0x03ffb7e74d28 in __cxa_throw () from /usr/lib/libstdc++.so.6
#5  0x02aa0e34 in foo() ()
#6  0x02aa0e44 in main ()
(gdb) info registers
x0 0x8  8
x1 0x1d 29
x2 0x0  0
x3 0x4000   4611686018427387904
x4 0x0  0
x5 0x0  0
x6 0x3b0944
x7 0x3ffed404398046506304
x8 0x2aa0fa82932030967720
x9 0x3ffecc04398046506176
x100xa42a4  672420
x110xa42a4  672420
x120xb66b4978   3060484472
x130x18 24
x140x10072057594037927936
x150xb66b4978   3060484472
x160x3ffb7dcee904396836253328
x170x3ffb7f7a5284396838004008
x180x2aa06c92932030965449
x190x3fff1e04398046507488
x200x3fff1e04398046507488
x210x3ffe9804398046505344
x220x3fff5a04398046508448
x230x190400
x240x3ffb80050004396838572032
x250x3fff5a04398046508448
x260x3ffb80030004396838563840
x270x0  0
x280x0  0
x290x3fffc504398046510160
x300x3ffb7dba9384396836170040
sp 0x3ffe9100x3ffe910
pc 0x3ffb7db97800x3ffb7db9780 <_Unwind_GetGR+72>
cpsr   0x6000   1610612736
fpsr   0x0  0
fpcr   0x0  0
(gdb) disas
Dump of assembler code for function _Unwind_GetGR:
   0x03ffb7db9738 <+0>: cmp w1, #0x61
   0x03ffb7db973c <+4>: b.le0x3ffb7db9748 <_Unwind_GetGR+16>
   0x03ffb7db9740 <+8>: str x30, [sp,#-16]!
   0x03ffb7db9744 <+12>:bl  0x3ffb7db2670 
   0x03ffb7db9748 <+16>:ldr x3, [x0,#832]
   0x03ffb7db974c <+20>:sxtwx1, w1
   0x03ffb7db9750 <+24>:ldr x2, [x0,x1,lsl #3]
   0x03ffb7db9754 <+28>:tbz x3, #62, 0x3ffb7db976c
<_Unwind_GetGR+52>
   0x03ffb7db9758 <+32>:add x0, x0, x1
   0x03ffb7db975c <+36>:ldrbw0, [x0,#856]
   0x03ffb7db9760 <+40>:cbz w0, 0x3ffb7db976c <_Unwind_GetGR+52>
   0x03ffb7db9764 <+44>:mov x0, x2
   0x03ffb7db9768 <+48>:ret
   0x03ffb7db976c <+52>:adrpx0, 0x3ffb7dcf000
   0x03ffb7db9770 <+56>:add x0, x0, #0x70
   0x03ffb7db9774 <+60>:ldrbw0, [x0,x1]
   0x03ffb7db9778 <+64>:cmp w0, #0x8
   0x03ffb7db977c <+68>:b.ne0x3ffb7db9740 <_Unwind_GetGR+8>
=> 0x03ffb7db9780 <+72>:ldr x0, [x2]
   0x03ffb7db9784 <+76>:b   0x3ffb7db9768 <_Unwind_GetGR+48>
End of assembler dump.
(gdb) quit
A debugging session is active.

Inferior 1 [process 13752] will be killed.


This got fixed when removing -fomit-frame-pointer from libgcc_s build.

[Bug libgcc/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Can you try this on a glibc instead musl?

[Bug libgcc/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[timo.teras at iki dot fi]

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

--- Comment #5 from Timo Teräs  ---
Not easily. It's musl, and using iterate phdr. Same build script works on x86,
x86_64 and armhf. It's only aarch64 misbehaving like this with omit frame
pointer. Any other suggestions what to try/how to debug further?

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

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #8 from Jeffrey A. Law  ---
Light searching doesn't find anything useful for setjmp_syscall.

savectx however still shows up in a variety of solaris searches.  In fact, you
can find references to it in Solaris 10.  So I'd say that's not dead.

qsetjmp was used by the 4.3 BSD m68k port and its derivatives. It was removed
sometime after 2011.   I don't work on the m68k or BSD bits anymore and I'd be
amazed if anyone ever noticed if support was removed.  I won't object if it's
removed.

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

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
 Resolution|FIXED   |INVALID

--- Comment #3 from Jason Merrill  ---
I don't think this is a false positive: the initialization of val is in fact
implicitly converting from a value outside the range of int (but inside the
range of long long).  We are able to compute the constant value because the
function is constexpr.

The warning goes away if you make E signed by giving it a negative enumerator.

[Bug libgcc/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Timo Teräs from comment #5)
> Not easily. It's musl, and using iterate phdr. Same build script works on
> x86, x86_64 and armhf. It's only aarch64 misbehaving like this with omit
> frame pointer. Any other suggestions what to try/how to debug further?

So check the unwind information to see if it is correct.


   0x03ffb7db974c <+20>:sxtwx1, w1
   0x03ffb7db9750 <+24>:ldr x2, [x0,x1,lsl #3]

So x0 + ((long long)(int)w1) << 3
Or rather contex + index

And it is looking into x29 because of x1 is 29.

So it does look like the unwind information is messed up for the frame being
looked at.

[Bug c/71858] Surprising suggestions for misspellings

[dmalcolm at gcc dot gnu.org]

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

--- Comment #7 from David Malcolm  ---
Author: dmalcolm
Date: Wed Jul 20 18:42:11 2016
New Revision: 238538

URL: https://gcc.gnu.org/viewcvs?rev=238538&root=gcc&view=rev
Log:
C++ FE: handle misspelled identifiers and typenames

gcc/cp/ChangeLog:
PR c/70339
PR c/71858
* name-lookup.c: Include gcc-rich-location.h, spellcheck-tree.h,
and parser.h.
(suggest_alternatives_for): If no candidates are found, try
lookup_name_fuzzy and report if if finds a suggestion.
(consider_binding_level): New function.
(lookup_name_fuzzy) New function.
* parser.c: Include gcc-rich-location.h.
(cp_lexer_next_token_is_decl_specifier_keyword): Move most of
logic into...
(cp_keyword_starts_decl_specifier_p): ...this new function.
(cp_parser_diagnose_invalid_type_name): When issuing
"does not name a type" errors, attempt to make a suggestion using
lookup_name_fuzzy.
* parser.h (cp_keyword_starts_decl_specifier_p): New prototype.
* search.c (lookup_field_fuzzy_info::fuzzy_lookup_field): Reject
types that are not CLASS_TYPE_P, rather than rejecting individual
tree codes.

gcc/testsuite/ChangeLog:
PR c/70339
PR c/71858
* g++.dg/spellcheck-identifiers.C: New test case, based on
gcc.dg/spellcheck-identifiers.c.
* g++.dg/spellcheck-identifiers-2.C: New test case, based on
gcc.dg/spellcheck-identifiers-2.c.
* g++.dg/spellcheck-typenames.C: New test case, based on
gcc.dg/spellcheck-typenames.c


Added:
trunk/gcc/testsuite/g++.dg/spellcheck-identifiers-2.C
trunk/gcc/testsuite/g++.dg/spellcheck-identifiers.C
trunk/gcc/testsuite/g++.dg/spellcheck-typenames.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/parser.h
trunk/gcc/cp/search.c
trunk/gcc/testsuite/ChangeLog

[Bug c/70339] Poor message for "singed" vs "signed" typo

[dmalcolm at gcc dot gnu.org]

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

--- Comment #5 from David Malcolm  ---
Author: dmalcolm
Date: Wed Jul 20 18:42:11 2016
New Revision: 238538

URL: https://gcc.gnu.org/viewcvs?rev=238538&root=gcc&view=rev
Log:
C++ FE: handle misspelled identifiers and typenames

gcc/cp/ChangeLog:
PR c/70339
PR c/71858
* name-lookup.c: Include gcc-rich-location.h, spellcheck-tree.h,
and parser.h.
(suggest_alternatives_for): If no candidates are found, try
lookup_name_fuzzy and report if if finds a suggestion.
(consider_binding_level): New function.
(lookup_name_fuzzy) New function.
* parser.c: Include gcc-rich-location.h.
(cp_lexer_next_token_is_decl_specifier_keyword): Move most of
logic into...
(cp_keyword_starts_decl_specifier_p): ...this new function.
(cp_parser_diagnose_invalid_type_name): When issuing
"does not name a type" errors, attempt to make a suggestion using
lookup_name_fuzzy.
* parser.h (cp_keyword_starts_decl_specifier_p): New prototype.
* search.c (lookup_field_fuzzy_info::fuzzy_lookup_field): Reject
types that are not CLASS_TYPE_P, rather than rejecting individual
tree codes.

gcc/testsuite/ChangeLog:
PR c/70339
PR c/71858
* g++.dg/spellcheck-identifiers.C: New test case, based on
gcc.dg/spellcheck-identifiers.c.
* g++.dg/spellcheck-identifiers-2.C: New test case, based on
gcc.dg/spellcheck-identifiers-2.c.
* g++.dg/spellcheck-typenames.C: New test case, based on
gcc.dg/spellcheck-typenames.c


Added:
trunk/gcc/testsuite/g++.dg/spellcheck-identifiers-2.C
trunk/gcc/testsuite/g++.dg/spellcheck-identifiers.C
trunk/gcc/testsuite/g++.dg/spellcheck-typenames.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/name-lookup.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/parser.h
trunk/gcc/cp/search.c
trunk/gcc/testsuite/ChangeLog

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

[bernd.edlinger at hotmail dot de]

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

--- Comment #9 from Bernd Edlinger  ---
(In reply to Jeffrey A. Law from comment #8)
> Light searching doesn't find anything useful for setjmp_syscall.
> 
> savectx however still shows up in a variety of solaris searches.  In fact,
> you can find references to it in Solaris 10.  So I'd say that's not dead.
> 
> qsetjmp was used by the 4.3 BSD m68k port and its derivatives. It was
> removed sometime after 2011.   I don't work on the m68k or BSD bits anymore
> and I'd be amazed if anyone ever noticed if support was removed.  I won't
> object if it's removed.

OK. Thanks.  Have you any opinion about the "__x" prefix?

The problem with the savectx, and getcontext is this:

If you ask ordinary people, who use gcc every day, if they have ever heard
about a function, that is called savectx or getcontext, then the answer
will be no.  That means that they could choose that name for a function
that they may use for their daily work.

Now GCC does silently add the equivalent of __attribute__((returns_twice,
leaf)) to a user function by that name, and that creates no warning at all.

leaf is likely to cause invalid code in a scenario as comment#2
so I would like to at least remove the leaf here.

But also the returns_twice will cause confusion.

This will eventually trigger a Wclobbered warning,
and the bad thing here is the warning complains about
"variable %q+D might be clobbered by % or %"
(I think there are still many unclear BZ about Wclobbered)

How should they know that the reason is the unfortunate coosing
of getcontext or savectx as a function name?

To mitigate that we should make savectx a builtin so you can
get at least a warning about the builtin parameter mismatch.

I know what getcontext is supposed to look like,
but what is the correct function header for savectx ?

[Bug libgcc/71951] libgcc_s built with -fomit-frame-pointer on aarch64 is broken

[timo.teras at iki dot fi]

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

--- Comment #7 from Timo Teräs  ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Timo Teräs from comment #5)
> > Not easily. It's musl, and using iterate phdr. Same build script works on
> > x86, x86_64 and armhf. It's only aarch64 misbehaving like this with omit
> > frame pointer. Any other suggestions what to try/how to debug further?
> 
> So check the unwind information to see if it is correct.
> 
> 
>0x03ffb7db974c <+20>:  sxtwx1, w1
>0x03ffb7db9750 <+24>:  ldr x2, [x0,x1,lsl #3]
> 
> So x0 + ((long long)(int)w1) << 3
> Or rather contex + index
> 
> And it is looking into x29 because of x1 is 29.
> 
> So it does look like the unwind information is messed up for the frame being
> looked at.

I'm not too familiar with dwarf, but I assume the section relevant from objdump
--dwarf output is:

0120 001c 0124 FDE cie=
pc=9738..9788
  DW_CFA_advance_loc: 12 to 9744
  DW_CFA_def_cfa_offset: 16
  DW_CFA_offset: r30 (x30) at cfa-16
  DW_CFA_advance_loc: 4 to 9748
  DW_CFA_def_cfa_offset: 0
  DW_CFA_restore: r30 (x30)
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop

I can also attach the broken libgcc_s here if it helps.

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

[law at redhat dot com]

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

--- Comment #10 from Jeffrey A. Law  ---
No opinion on the "x" prefix.  I think that was already in place when that code
was updated to support qsetjmp and savectx in the early 90s.  I've never seen
the "x" versions in practice.

ANd yes, you're raising real issues (you can find instances in the real world
where this has bitten folks).

Unfortunately, I don't know a signature for savectx.  I haven't used a solaris
system in eons.

[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 #23 from Jonathan Wakely  ---
(In reply to Boris Kolpackov from comment #21)
> Speaking of possible fixes, I had this crazy idea, not sure if it is
> technically possible though: what if libstdc++ throws some custom exception
> that derives from both version of ios::failure? This way both old and new
> ABI users will be able to catch it via the respective bases.

Apart from the difficulty of deriving from both types when they can't both be
declared at the same time (which could be solved) that solution would mean you
couldn't catch it with a handler of type const std::exception&, because the
base class would be ambiguous (it's not a virtual base).

Ideally I'd like it to be caught by handlers for std::ios_base::failure and
std::ios_base::failure[abi-tag:__cxx11] but I'm not sure that's possible.

Another option is to decide which to throw based on an environment variable, so
applications can choose whether they want the types thrown by the library to be
catchable by new code or old code.

But we might end up just throwing the new type, and saying old code needs to be
recompiled, or just to catch it as std::exception not std::ios_base::failure.

[Bug libstdc++/37475] [DR 382] codecvt::do_in/do_out functions return "ok" when the output sequence has zero length

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Oops, I meant 382 is NAD
http://cplusplus.github.io/LWG/lwg-closed.html#382

I'm not sure what (if anything) we need to do here though, someone needs to
re-analyze.

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

[bernd.edlinger at hotmail dot de]

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

--- Comment #11 from Bernd Edlinger  ---
(In reply to Jeffrey A. Law from comment #10)
> No opinion on the "x" prefix.  I think that was already in place when that
> code was updated to support qsetjmp and savectx in the early 90s.  I've
> never seen the "x" versions in practice.
> 

I would like to get rid of the 25 year old ballast, that is likely good for
nothing.

> ANd yes, you're raising real issues (you can find instances in the real
> world where this has bitten folks).
> 
> Unfortunately, I don't know a signature for savectx.  I haven't used a
> solaris system in eons.

Maybe it would be a better option to add the returns_twice it to the
fixinclude machinery?

[Bug fortran/71952] New: [Coarray, F2008] Rejects valid coarray access with array partref

[damian at sourceryinstitute dot org]

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

Bug ID: 71952
   Summary: [Coarray, F2008] Rejects valid coarray access with
array partref
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: damian at sourceryinstitute dot org
  Target Milestone: ---

I'm filing this just to keep track of a missing coarray feature and to mention
a minor typographical error.  I search on "partref" turns up nothing in the
draft Fortran 2015 standard.  After searching of the web, I realized it was
intended to be "part-ref". A bit more explanation might be helpful if
appropriate. 

$ cat coarray-access-with-array-partref.f90 
  implicit none
  type particles
real x(1)
  end type
  type(particles) outbox(1)[*],foo
  print *,outbox(1)[1]%x
end 

$ gfortran -fcoarray=lib coarray-access-with-array-partref.f90 
coarray-access-with-array-partref.f90:6:10:

   print *,outbox(1)[1]%x
  1
Error: Sorry, coindexed access at (1) to a scalar component with an array
partref is not yet supported

[Bug c++/71121] [6/7 Regression] Spurious warning: "the address of [...] will never be NULL [-Waddress]"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/54367] [meta-bug] lambda expressions

[jason at gcc dot gnu.org]

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

Bug 70942 Summary: [6/7 Regression] [c++14] Incorrect deduction of generic 
lambda `auto&&` parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70942

   What|Removed |Added

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

[Bug c++/70972] [6 Regression] Inheriting constructors taking parameters by value should move them, not copy

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||tuwwcn at gmail dot com

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

[Bug c++/70845] [6/7 Regression] inherited piecewise_construct_t constructor from std::pair by "using-declarations" is missing

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |DUPLICATE

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

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

[Bug c++/71117] [6/7 Regression] Overeager application of conversion to function pointer during overload resolution of call to function object

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||vittorio.romeo at outlook dot 
com

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

[Bug c++/70942] [6/7 Regression] [c++14] Incorrect deduction of generic lambda `auto&&` parameter

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Jason Merrill  ---
Fixed by the patch for 71117.

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

[Bug c++/70781] [6/7 Regression] ICE on invalid C++ code with lambda expressions on x86_64-linux-gnu in finish_expr_stmt, at cp/semantics.c:677

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/71896] [6/7 Regression] Constexpr function with pointer to member parameter doesn't return constexpr value

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug sanitizer/71953] New: ICE using sanitizers with PCH

[redi at gcc dot gnu.org]

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

Bug ID: 71953
   Summary: ICE using sanitizers with PCH
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  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: ---

This happens when I try to enable asan and/or ubsan in the libstdc++ testsuite.

Possibly component should be pch, but I want someone to actually look at it ;)

I can't reproduce it with preprocessed source, because I get an invalid-pch
error unless it's done in the build tree when the PCH file is present.

With suitable values of SRCDIR, OBJDIR and TARGET:

echo | $OBJDIR/gcc/xg++ -B$OBJDIR/gcc -fsanitize=address -g -O -c -nostdinc++
-I $OBJDIR/$TARGET/libstdc++-v3/include/$TARGET  -include bits/stdc++.h -x c++
-  
: In function ‘void __static_initialization_and_destruction_0(int,
int)’:
:1:0: internal compiler error: Segmentation fault
0xd273ef crash_signal
/home/jwakely/src/gcc/gcc/gcc/toplev.c:335
0xfbdce8 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/jwakely/src/gcc/gcc/gcc/tree.h:3136
0xfbdce8 build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**)
/home/jwakely/src/gcc/gcc/gcc/tree.c:11161
0xfbdf4d build_call_expr(tree_node*, int, ...)
/home/jwakely/src/gcc/gcc/gcc/tree.c:11211
0xd40ea6 asan_dynamic_init_call(bool)
/home/jwakely/src/gcc/gcc/gcc/asan.c:2178
0x6ebf38 do_static_initialization_or_destruction
/home/jwakely/src/gcc/gcc/gcc/cp/decl2.c:3848
0x6f0ee7 c_parse_final_cleanups()
/home/jwakely/src/gcc/gcc/gcc/cp/decl2.c:4676
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/71463] [6/7 regression] unexpected warning: ignoring function return attributes on template argument

[mail at milianw dot de]

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

--- Comment #8 from Milian Wolff  ---
As an interested bystander, may I ask: If the attribute is part of the type,
shouldn't it then be transferred via decltype() and then also used in the
template to trigger the warning there? To me, the example you gave shows a
defect in GCC (no warning inside the template), and not a nice feature. What am
I missing?

[Bug c++/71954] New: template partial specialization for constexpr error

[liweifriends at gmail dot com]

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

Bug ID: 71954
   Summary: template partial specialization for constexpr error
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: liweifriends at gmail dot com
  Target Milestone: ---

The code is as follows:

template  struct Container;

template 
struct Str1
{
template 
struct Helper1
{
constexpr static bool value = true;
};

template 
struct Helper1, T3...>
{
constexpr static bool value = false;
};

static_assert(Helper1::value, "Check");
};

template 
struct Str2
{
template 
static constexpr bool Helper2 = true;

// ERROR here:
template 
static constexpr bool Helper2, T3...> = false;

static_assert(Helper2, "Check");
};

When compile with --std=c++14, Str1 is OK but Str2 will cause an Error:
error: explicit template argument list not allowed

[Bug c++/71463] [6/7 regression] unexpected warning: ignoring function return attributes on template argument

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
(In reply to Milian Wolff from comment #8)
> As an interested bystander, may I ask: If the attribute is part of the type,
> shouldn't it then be transferred via decltype() and then also used in the
> template to trigger the warning there?

The attribute isn't properly part of the C++ type, so in the testcase below
A needs to be the same type as A, and so they share a member function.
 So we have to choose which type to use as the canonical type, and we choose
the type without the attribute.  And that's what the "ignoring attributes"
warning is telling you.

typedef int fn();
typedef int fna() __attribute ((warn_unused_result));

template 
struct A {
  T *p;
  void g() { p(); } // no warning   
};

int main()
{
  A().g();
  A().g();
}

[Bug c++/71946] FD_ZERO macro parsing error in lambda function.

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Works for me on aarch64-linux-gnu with:
GNU C++14 (GCC) version 7.0.0 20160717 (experimental)
(aarch64-unknown-linux-gnu)

Maybe provide a preprocessed source which fails.

For me it expands to:
# 6 "t.c" 3 4
   do { unsigned int __i; fd_set *__arr = (
# 6 "t.c"
   &set
# 6 "t.c" 3 4
   ); for (__i = 0; __i < sizeof (fd_set) / sizeof (__fd_mask); ++__i)
((__arr)->fds_bits)[__i] = 0; } while (0)
# 6 "t.c"
;

[Bug c++/71946] FD_ZERO macro parsing error in lambda function.

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
Looks like x86 has a special select.h in glibc :).

[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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu Jul 21 06:05:24 2016
New Revision: 238558

URL: https://gcc.gnu.org/viewcvs?rev=238558&root=gcc&view=rev
Log:
Improving concepts performance and diagnostics.

PR c++/67565
PR c++/67579
PR c++/71843
gcc/
* timevar.def (TV_CONSTRAINT_SAT, TV_CONSTRAINT_SUB): New time vars
for constraint satisfaction and subsumption.
* timevar.h (auto_timevar): New constructor that matches the push/pop
pattern of usage in pt.c.
gcc/cp/
* cp-tree.def (CHECK_CONSTR): New.
* cp-tree.h (CHECK_CONSTR_CONCEPT): New.
(CHECK_CONSTR_ARGS): New.
* constraint.cc (make_predicate_constraint): Remove in favor of
normalize_expression.
(resolve_constraint_check): Actually return error_mark_node when
resolution fails.
(resolve_variable_concept_check): Perform coercion as if processing
a template. Also return errors on resolution failure.
(lift_*): Remove all of these functions. Don't unnecessarily inline
concepts.
(learn_*): Add facilities to memoize implications for subsumption
during normalization.
(expanding_concept): New.
(expand_concept): New. Return the inlined and normalized definition
of a concept when needed.
(transform_*, xform_*): Rename to normalize_* to better reflect the
responsibility of those functions.
(normalize_template_id_expression): Check for non-boolean operands
when possible. Generate check constraints instead of normal variable
references.
(normalize_call_expression): Report errors when resolution fails.
(check_for_logical_overloads): Rewrite this check to more accurately
report the error.
(normalize_atom): Check for overloaded calls and invalid types before
determining if the expression refers to a concept.
(build_constraints): Don't cache normalized constraints or decmposed
assumptions.
(finish_shorthand_constraint): Return a normalized expression instead
of a predicate constraint.
(finish_template_introduction): Same.
(placeholder_extract_concept_and_args): Rewrite this since we only
ever get check constraints here.
(equivalent_placeholder_constraints): Rewrite in terms of check
constraints, and handle error_mark_nodes correctly.
(tsubst_check_constraint, tsubst_expr_constr, tsubst_type_constr)
(tsubst_implicit_conversion_constr)
(tsubst_argument_deduction_constr, tsubst_exception_constr)
(tsubst_parameterized_constraint, tsubst_constraint): New.
(tsbust_conjunection): Replace with tsubst_logical_operator and
actually generate the right kind of constraint.
(tsubst_requirement_body): Reverse the order of substituted arguments
so that they appear in the order written (helps diagnostics).
(satisfy_check_constraint): New.
(satisfy_conjunction): Simplify.
(satisfy_disjunction): Same.
(satisfy_constraint_1): Handle check constraints.
(eval_constr): New (private) global state.
(evaluating_constraints_sentinel): New. Manages eval_constr.
(satisfy_constraint): Add timing variables.
(satisfy_associated_constraints): Add hooks for memoization.
(evaluate_function_concept): Build a check constraint instead of
normalizing its definition.
(evaluate_variable_concept): Same.
(evaluate_constraint_expression): Normalize, but in the current
declaration processing context.
(evaluating_constraints_p): New.
(elide_constraint_failure_p): Actually emit constraint_thresh errors.
(diagnose_*): Remove artificial indentation. Add a new parameter to
each that tracks the current (complete) constraint prior to any
substitutions.
(diagnose_expression): Removed.
(diagnose_call_expression): Same.
(diagnose_template_id): Same.
(diagnose_template_id): New.
(diagnose_logical_constraint): New.
(diagnose_expression_constraint): Show the original expression.
(diagnose_type_constraint): Show the original type.
(diagnose_implicit_conversion_constraint): Be specific about
failures, don't re-diagnose a known-to-be-failed substitutions,
and manage elisions properly.
(diagnose_argument_deduction_constraint): Same.
(diagnose_exception_constraint): Same.
(diagnose_parameterized_constraint): Same.
(constraint_p): Allow EXPR_PACK_EXPANSION.
* logic.cc (next_by_distance): Removed. No longer used.
(any_p): Renamed from any_of.
(term_entry, term_hasher): New.
(term_list): Rewrite to include a hash table for quick lookup.
Also, make less stateful.
(proof_sta

[Bug libgomp/71941] [6/7 Regression] ICE with OpenMP tasks and queue

[thakkinen at gmail dot com]

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

thakkinen at gmail dot com changed:

   What|Removed |Added

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

--- Comment #4 from thakkinen at gmail dot com ---
Hi, that was one lightning speed fix. Thank you, code compiles correctly.

On the side note, when recompiling gcc 6.1 w. patch with gcc 6.1 i had to set
--enable-werror=no for configure script; in line 46 of gcc/tree-object-size.c
there is narrowing conversion that halts compiling otherwise.