[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[nyh at math dot technion.ac.il]

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

--- Comment #5 from Nadav Har'El  ---
Some replies to Andrew's comments above:

1. As the number of cores continue to grow, libraries will also fix malloc
scalability issues, so concurrent malloc will no longer present a problem. The
code which led me to this report (http://www.seastar-project.org/) already
replaces malloc() by a lock-free implementation (Seastar has per-thread memory
allocation), so malloc() was never a problem there. 

2. With the phrase "global lock" I just meant that there is just one lock that
all the unrelated threads which try to throw any exception of any type need to
take.

3. As far as I can tell, the C++ standard doesn't say anything exceptions
necessarily being very slow. Conventional wisdom indeed has it that exceptions
are slower than normal function returns. But nothing suggests that C++
exceptions are not scalable, in the sense that throwing unrelated exceptions in
unrelated threads at the same time is not possible, or is orders of magnitude
slower than just the normal costs of exceptions on one thread. That is nothing
more than an implementation bug. It can be argued how urgent fixing this bug
is, but as the number of cores continue to grow, and performance of C++
software continues to improve (e.g., http://www.seastar-project.org/),
"exception storms" of the type I outlined in my original report will become a
very real risk.

Fixing this bug completely might require fixes in glibc too (dl_iterate_phdr,
and as you said malloc). But I think it definitely needs fixing.

[Bug c++/71010] error: 'begin' was not declared in this scope

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|FIXED   |INVALID

--- Comment #4 from Andrew Pinski  ---
(In reply to Ubikovich from comment #3)
> But since C++14 cbegin invoke std::begin:
> 
> // http://en.cppreference.com/w/cpp/iterator/begin
> template< class C >
> constexpr auto cbegin( const C& c ) -> decltype(std::begin(c));
> (3)   (since C++14)
> 
> Then in what namespace should be user-defined begin/end?

In the same as the class so ADR (argument dependent resolution) can find it.

[Bug inline-asm/71086] [4.9 Only] miscompiled inline-asm + alternative constraints + __builtin_expect + always_inline

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-04
  Known to work||5.0, 6.0, 7.0
   Target Milestone|--- |4.9.4
Summary|miscompiled inline-asm +|[4.9 Only] miscompiled
   |alternative constraints +   |inline-asm + alternative
   |__builtin_expect +  |constraints +
   |always_inline   |__builtin_expect +
   ||always_inline
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
.

[Bug bootstrap/71134] GCC fails to build with in-tree dependencies: missing libopcodes

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Bootstrap does not work with a combined tree.  Cross compiler works though.

[Bug tree-optimization/71079] ICE on valid code at -O1 and above on x86_64-linux-gnu: verify_gimple failed

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |7.0

[Bug target/71191] aarch64 and others: __atomic_load;arithmetic;__atomic_compare_exchange loops should be able to generate better code with LL/SC-type constructs than a CAS loop

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
> On AArch64 there are restrictions on what kind of instructions can go into
> these LL/SC loops using the exclusive instructions i.e. the LDAXR / STLXR
> instructions. 

MIPS has a similar restriction.  I know one of AARCH64 (and MIPS) processor
which shows issues when some of those restrictions are violated (either load or
stores in-between the LL/SC).  I have seen now issues in LLVM and valgrind due
to that :).  So anything that makes LL and SC builtins I would to reject out
right.

[Bug c++/71748] ICE on valid (?) C++ template code invoking a base destructor: in build_base_path, at cp/class.c:304

[su at cs dot ucdavis.edu]

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

--- Comment #1 from Zhendong Su  ---
If we remove the template from the code, it'll be accepted: 

$ g++-trunk -c -Wall -Wextra -std=c++11 good.cpp
$ 
$ cat good.cpp
struct A 
{
  virtual ~A () {}
};

struct B : public A 
{
  virtual ~B () {} 
};

void foo ()
{
  B *b = new B;
  b->~A (); 
  // also accepted: b->A::~A(); 
}

int main ()
{
  foo (); 
  return 0;
}

[Bug c/71746] Scope Variable Address (Stack) Mismatch

[mfurkanuslu at openmailbox dot org]

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

Furkan USLU  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #2 from Furkan USLU  ---
--

[Bug c++/71748] New: ICE on valid (?) C++ template code invoking a base destructor: in build_base_path, at cp/class.c:304

[su at cs dot ucdavis.edu]

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

Bug ID: 71748
   Summary: ICE on valid (?) C++ template code invoking a base
destructor: in build_base_path, at cp/class.c:304
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++ code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

It also affects all versions since 4.7.x, but is accepted without any warnings
by 4.6.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160703 (experimental) [trunk revision 237949] (GCC)
$
$ g++-4.6 -c -Wall -Wextra -pedantic -std=c++0x small.cpp
$
$ g++-trunk -c small.cpp
small.cpp: In instantiation of ‘void foo() [with int  = 0]’:
small.cpp:19:14:   required from here
small.cpp:14:9: internal compiler error: in build_base_path, at cp/class.c:304
   b->~A ();
   ~~^~
0x7533e9 build_base_path(tree_code, tree_node*, tree_node*, int, int)
../../gcc-source-trunk/gcc/cp/class.c:304
0x66a1b1 build_over_call
../../gcc-source-trunk/gcc/cp/call.c:7489
0x6763d1 build_new_method_call_1
../../gcc-source-trunk/gcc/cp/call.c:8521
0x6763d1 build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
../../gcc-source-trunk/gcc/cp/call.c:8591
0x6e687f tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc-source-trunk/gcc/cp/pt.c:16690
0x6d6cff tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15868
0x6d739a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15180
0x6d66f3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15166
0x6d8230 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc-source-trunk/gcc/cp/pt.c:15351
0x6d4c35 instantiate_decl(tree_node*, int, bool)
../../gcc-source-trunk/gcc/cp/pt.c:22095
0x721912 instantiate_pending_templates(int)
../../gcc-source-trunk/gcc/cp/pt.c:22214
0x764a45 c_parse_final_cleanups()
../../gcc-source-trunk/gcc/cp/decl2.c:4600
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
$


-


struct A
{ 
  virtual ~A () {}
};

struct B : public A
{ 
  virtual ~B () {}
};

template < int > void foo ()
{ 
  B *b = new B;
  b->~A ();
}

int main ()
{ 
  foo < 0 > ();
  return 0;
}

[Bug c++/71747] New: ICE on invalid C++11 code with misuse of overloaded operator '()': Segmentation fault (program cc1plus)

[su at cs dot ucdavis.edu]

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

Bug ID: 71747
   Summary: ICE on invalid C++11 code with misuse of overloaded
operator '()': Segmentation fault (program cc1plus)
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++11 code causes an ICE (without any proper error diagnostics
before the ICE) when compiled with the current GCC trunk on x86_64-linux-gnu in
both 32-bit and 64-bit modes.  

It also affects all versions since at least as early as 4.6.x. 


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160703 (experimental) [trunk revision 237949] (GCC) 
$ 
$ g++-trunk -c -std=c++11 small.cpp
g++-trunk: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ 


-


template < bool > struct A
{
  typedef int type; 
  constexpr bool operator() () const 
  { 
return true; 
  }
}; 

template < bool, typename = int > struct F; 
template < bool X > 
// should be: struct F < X, typename A < A < X > {} () >::type > 
struct F < X, typename A < F < X > {} () >::type > 
{
};

F < true > f;

[Bug c/71746] Scope Variable Address (Stack) Mismatch

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
svar leaves the scope so the address of it becomes invalid.  Any access to that
address is undefined.

[Bug c/71746] New: Scope Variable Address (Stack) Mismatch

[mfurkanuslu at openmailbox dot org]

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

Bug ID: 71746
   Summary: Scope Variable Address (Stack) Mismatch
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mfurkanuslu at openmailbox dot org
  Target Milestone: ---

int main()
{
int* ptr;
{
int svar = 13;
ptr = 
}
int mvar = 144;
printf("%d\n", *ptr);

output is 13 but if i add this line (after or before printf)

int* p = 

output is 144.

[Bug bootstrap/70835] internal compiler error on libiberty/floatformat.c when bootstrapping 5.3.0 with 5.3.0

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
.

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

[Bug bootstrap/70838] internal compiler error on libiberty/floatformat.c when bootstrapping 5.3.0 with 5.3.0

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
*** Bug 70835 has been marked as a duplicate of this bug. ***

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Also if you are using C++ features you need to understand scalibility issues
might not be under your control so you should stop using those features.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
This cache:
/* The unseen_objects list contains objects that have been registered
   but not yet categorized in any way.  The seen_objects list has had
   its pc_begin and count fields initialized at minimum, and is sorted
   by decreasing value of pc_begin.  */
static struct object *unseen_objects;
static struct object *seen_objects

In "unwind-dw2-fde.c".

So there is no global lock by the way, just around the area which accesses the
above two objects.

[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|libstdc++   |libgcc

--- Comment #2 from Andrew Pinski  ---
Also there is a cache in the unwidng code.  This cache is where the lock is
really located.  Changing this cache to lockless might be harder to do.

[Bug libstdc++/71744] Concurrently throwing exceptions is not scalable

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
unwind uses malloc which does have a lock too.

[Bug fortran/71745] upper array bound huge(i) on 32-bit systems

[tkoenig at gcc dot gnu.org]

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

--- Comment #1 from Thomas Koenig  ---
Just checked with recent trunk, same error.

Dump looks interesting, the assignment statement is
converted to an endless loop:

  {
integer(kind=4) S.0;

S.0 = 2147483645;
while (1)
  {
a[S.0 + -2147483645] = 2;
S.0 = S.0 + 1;
  }
L.1:;
  }

[Bug fortran/71745] New: upper array bound huge(i) on 32-bit systems

[tkoenig at gcc dot gnu.org]

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

Bug ID: 71745
   Summary: upper array bound huge(i) on 32-bit systems
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

This is with a 4.8 compiler (I don't have a working -m32 around
for trunk at the moment), but I think the error applies as well.

ig25@linux-fd1f:/tmp> /usr/bin/gfortran -m32 foo.f90
ig25@linux-fd1f:/tmp> ./a.out

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Backtrace for this error:
#0  0xF76A224E
#1  0xF76A135E
#2  0xF779AE4F
#3  0x80485A1 in MAIN__ at foo.f90:?
Speicherzugriffsfehler
ig25@linux-fd1f:/tmp> cat foo.f90
program main
  integer :: i
  integer, dimension(huge(i)-2:huge(i)) :: a
  a = 2
  print *,a, size(a)
end program main

[Bug libstdc++/71744] New: Concurrently throwing exceptions is not scalable

[nyh at math dot technion.ac.il]

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

Bug ID: 71744
   Summary: Concurrently throwing exceptions is not scalable
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nyh at math dot technion.ac.il
  Target Milestone: ---

Multiple threads on multiple cores should be able to concurrently throw
exceptions without bothering one another. But unfortunately, it appears that in
the current implementation of libstdc++ and/or glibc, the stack unwinding
process takes a global lock (while getting the list of shared objects, and
perhaps other things) which serializes these parallel exception-throwing and
can dramatically slow down the program.

This problem has been reported in the past by users - see for example 

http://stackoverflow.com/questions/26257343/does-stack-unwinding-really-require-locks
https://blogs.oracle.com/dave/entry/synchronization_horror_story_of_the

Some might dismiss this inefficiency with the standard "exceptions should be
rare" excuse. They should be rare. But sometimes they are not, leading do a
catastrophic collapse in performance.

We saw an illustrative example of an "exception storm" in a Seastar
(http://www.seastar-project.org/) application. This application can handle over
a million requests per second on many cores. Some unexpected circumstance
caused the application to slow down somewhat, which led to some of the requests
timing out. The timeout was implemented as an exception, so now we had
thousands of exceptions being thrown in all cores in parallel. This led to the
applications threads starting to hang, once in a while, on the lock(s) inside
"throw". This in turn made the application even slower, and created even more
timeouts, which in turn resulted in even more exceptions. In this way the
number of exceptions per second escalated, until the point where most of the
work the application was doing was fighting over the "throw" locks, and no
useful work was being done.

[Bug c/71743] return with no value cannot be ignored [Possible regression or undocumented change on https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/Warning-Options.html#Warning-Options]

[bastien.penavayre at epitech dot eu]

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

--- Comment #3 from bastien penavayre  ---
Created attachment 38826
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38826=edit
source file as example

[Bug c/71743] return with no value cannot be ignored [Possible regression or undocumented change on https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/Warning-Options.html#Warning-Options]

[bastien.penavayre at epitech dot eu]

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

--- Comment #2 from bastien penavayre  ---
Created attachment 38825
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38825=edit
gcc-6 -v test.c -c

[Bug c/71743] return with no value cannot be ignored [Possible regression or undocumented change on https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/Warning-Options.html#Warning-Options]

[bastien.penavayre at epitech dot eu]

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

--- Comment #1 from bastien penavayre  ---
Created attachment 38824
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38824=edit
gcc-5 -v test.c -c

[Bug c/71743] New: return with no value cannot be ignored [Possible regression or undocumented change on https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/Warning-Options.html#Warning-Options]

[bastien.penavayre at epitech dot eu]

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

Bug ID: 71743
   Summary: return with no value cannot be ignored [Possible
regression or undocumented change on
https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/Warning-O
ptions.html#Warning-Options]
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bastien.penavayre at epitech dot eu
  Target Milestone: ---

Created attachment 38823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38823=edit
gcc-4.9 -v -c test.c

Hi,

So since gcc-5, in manual at the warning section:
https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc/Warning-Options.html#Warning-Options
and
https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Warning-Options.html#Warning-Options

It's stated that:
"-Wreturn-type
  ... Also warn about any return statement with no return value in a function
whose return type is not void ... , and about a return statement with an
expression in a function whose return type is void."

The issue here is that this is not true as the following code still warns:

int func()
{
#pragma GCC diagnostic ignored "-Wreturn-type"
   return ;
}

This one also :

void func()
{
#pragma GCC diagnostic ignored "-Wreturn-type"
   return 42;
}

The only case where ignoring -Wreturn-type works is when :
"falling off the end of the function body is considered returning without a
value".

The first test worked as expected before gcc-5 and warns since then.

Before gcc-5 the second test warns as expected as the "a return statement with
an expression in a function whose return type is void" wasn't yet part of the
manual.

[Bug c++/71741] The program works 3 times slower compiled with g++ 5.3.1 than the same program compiled with g++ 4.8.4 with the same command (i7-5820 Haswell)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #1 from Martin Liška  ---
I've just tried to reproduce the problem, however using the attached Makefile
does not work for me:

find: ‘./src’: No such file or directory
find: ‘./src’: No such file or directory
g++ -std=c++11 -Wall -O3 -save-temps main.cpp  -iquote. -o bin/inclined -lgsl
-lgslcblas -lm -ltinyxml -L/usr/local/lib
make: *** No rule to make target 'test/perf/openmp_test.o', needed by
'bin/openmp_test'.  Stop.
make: *** Waiting for unfinished jobs
g++: error: main.cpp: No such file or directory

I'm also to assemble the final binary with:
$ g++ -std=c++11 -Wall -O3 -save-temps main.ii Well.ii WellFlow.ii
InclinedSum.ii  -iquote. -o inclined -lgsl -lgslcblas -lm -ltinyxml
-L/usr/local/lib

but I'm unable to execute the binary as I'm probably missing input or an
argument?

$ ./inclined 
terminate called after throwing an instance of 'char const*'
Aborted (core dumped)

[Bug c++/71739] ICE on valid C++11 code: tree check: expected identifier_node, have tree_list in private_is_attribute_p, at tree.c:6080

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-03
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug tree-optimization/71609] [7 regression] test case gfortran.dg/vect/vect-8.f90 fails starting with r237549

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c++/71738] ICE on valid C++ code: tree check: expected record_type or union_type or qual_union_type, have template_decl in lookup_template_class_1, at cp/pt.c:8619

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-03
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, starting from 4.5.0 (oldest release I have).

[Bug tree-optimization/71736] [7 Regression] ICE in verify_ssa

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug target/71276] frndint generation should not depend on flag_unsafe_math_optimizations

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug c++/71737] ICE following 2x pack expansion in non-pack with template alias

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-03
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed on trunk, release branches look good.

[Bug target/71278] Inline nearbyint for SSE4.1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug target/71277] SSE4.1 rounding generation should not depend on flag_trapping_math

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/71736] ICE in verify_ssa

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-07-03
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Martin Liška  ---
Confirmed, it's a GCC 7 Regression.

[Bug c++/71541] destructor of condition_variable_any crashes with static linkage

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
.

Weak symbols at play here :)

[Bug rtl-optimization/71591] SIGSEGV in test_uncond_jump (rtl-tests.c:90) with -E -fself-test

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug libstdc++/71562] Changing the hard coded size of _S_local_capacity in sso_string_base.h

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Allowing a different ABI is just going to be confusing to users.  In fact it
does not allow people to use shared libraries any more unless you recompile the
whole distro to make sure they are all using the ABI.

[Bug c/71600] [7 regression] test case gcc.dg/gnu89-const-expr-1.c fails starting with r237581

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c/63484] misleading/obsolete -fdelete-null-pointer-checks documentation

[bugfeed at online dot de]

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

Leif Leonhardy  changed:

   What|Removed |Added

 CC||bugfeed at online dot de

--- Comment #1 from Leif Leonhardy  ---
As of GCC 6.1.0, the documentation has slightly changed:

  -fdelete-null-pointer-checks

Assume that programs cannot safely dereference null pointers, and that no
code or data element resides at address zero. This option enables simple
constant folding optimizations at all optimization levels. In addition,
other
optimization passes in GCC use this flag to control global dataflow
analyses
that eliminate useless checks for null pointers; these assume that a memory
access to address zero always results in a trap, so that if a pointer is
checked after it has already been dereferenced, it cannot be null.

Note however that in some environments this assumption is not true. Use
-fno-delete-null-pointer-checks to disable this optimization for programs
that depend on that behavior.

This option is enabled by default on most targets. On Nios II ELF, it
defaults to off. On AVR and CR16, this option is completely disabled.

Passes that use the dataflow information are enabled independently at
different optimization levels.

[Bug tree-optimization/61502] == comparison on "one-past" pointer gives wrong result

[pinskia at gcc dot gnu.org]

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

--- Comment #20 from Andrew Pinski  ---
(In reply to Alexander Cherepanov from comment #19)
> (In reply to jos...@codesourcery.com from comment #3)
> > Except within a larger object, I'm not aware of any reason the cases of 
> > two objects following or not following each other in memory must be 
> > mutually exclusive.
> 
> Apparently some folks use linker scripts to get a specific arrangement of
> objects.
> 
> A fresh example is a problem in Linux -- https://lkml.org/lkml/2016/6/25/77
> . A simplified example from http://pastebin.com/4Qc6pUAA :
> 
> extern int __start[];
> extern int __end[];
>  
> extern void bar(int *);
>  
> void foo()
> {
> for (int *x = __start; x != __end; ++x)
> bar(x);
> }


To get around the above example:
extern int __start[];
extern int __end[];

extern void bar(int *);

void foo()
{
int *x = __start;
int *y = __end;
asm("":"+r"(x));
asm("":"+r"(y));
for (; x != y; ++x)
bar(x);
}

> 
> This is optimized into an infinite loop by gcc 7 at -O.

[Bug middle-end/71734] [7 Regression] FAIL: libgomp.fortran/simd4.f90 -O3 -g execution test

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Sun Jul  3 16:40:22 2016
New Revision: 237950

URL: https://gcc.gnu.org/viewcvs?rev=237950=gcc=rev
Log:
Add 2 tests for PR middle-end/71734

simd3.f90 and simd4.f90 fail only with -msse2.  But they are compiled
with -mavx on AVX machines.  Add 2 tests to compile simd3.f90 and
simd4.f90 with -msse2 on AVX machines.

PR middle-end/71734
* testsuite/libgomp.fortran/pr71734-1.f90: New test.
* testsuite/libgomp.fortran/pr71734-2.f90: Likewise.

Added:
trunk/libgomp/testsuite/libgomp.fortran/pr71734-1.f90
trunk/libgomp/testsuite/libgomp.fortran/pr71734-2.f90
Modified:
trunk/libgomp/ChangeLog

[Bug c/71742] New: Wrong formulation of "error: flexible array member in otherwise empty struct"

[ch3root at openwall dot com]

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

Bug ID: 71742
   Summary: Wrong formulation of "error: flexible array member in
otherwise empty struct"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ch3root at openwall dot com
  Target Milestone: ---

Source code:

--
int main()
{
  struct s {
int :1;
int a[];
  };
}
--

Results:

--
$ gcc -std=c11 -pedantic -Wall -Wextra -O3 test.c && ./a.out
test.c: In function ‘main’:
test.c:5:9: error: flexible array member in otherwise empty struct
 int a[];
 ^
--

gcc version: gcc (GCC) 7.0.0 20160627 (experimental)

gcc is right in detecting an error in this testcase but the message is wrong
because the struct is not otherwise empty. The problem is absence of named
members.

The relevant rule:

C11, 6.7.2.1p18: "As a special case, the last element of a structure with more
than one named member may have an incomplete array type; this is called a
flexible array member."

libiberty - Segmentation fault when attempting to delete a non-existent element in a hash table

[rocco]

Hello people,
the attached C-program can be used to reproduce a segmentation fault
found in libliberty/hashtab.c

I am using a libiberty tar-gzipped source version found in a recent Debian
Archive File (libiberty_20160215.tar.xz) where the first entry in ChangeLog is:
 * 2016-01-27  Iain Buclaw  

This is the output of the execution of my program before patching the
library:

ro...@nuc.carbo.net 1221> ./bug-remove
Hello world!

  This program creates a hash table with htab_create().
Then:
  * inserts 2 objects with htab_find_slot(INSERT).
  * delete 1 existent with htab_remove_elt().
  * attempt to delete 1 non existent with htab_remove_elt().
Boom !!!

Inserting [Hello - 1] ... Ok
Inserting [World! - 2] ... Ok
Searching for [Hello] ... Ok
Searching for [World!] ... Ok
Deleting [Hello] ... Ok
Segmentation fault


And this was the patch I applied in libiberty/libiberty:
ro...@nuc.carbo.net 1222> diff hashtab.c hashtab.c.ORG 
729c729
<   if (!slot || *slot == HTAB_EMPTY_ENTRY)
---
>   if (*slot == HTAB_EMPTY_ENTRY)


Maybe the same error could be also in other different points for
different API functions but I did not check.


/rocco



bug-remove.c
Description: Binary data

[Bug middle-end/71734] [7 Regression] FAIL: libgomp.fortran/simd4.f90 -O3 -g execution test

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
Created attachment 38822
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38822=edit
Testcases

[Bug c++/71741] New: The program works 3 times slower compiled with g++ 5.3.1 than the same program compiled with g++ 4.8.4 with the same command (i7-5820 Haswell)

[cranon at yandex dot ru]

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

Bug ID: 71741
   Summary: The program works 3 times slower compiled with g++
5.3.1 than the same program compiled with g++ 4.8.4
with the same command (i7-5820 Haswell)
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cranon at yandex dot ru
  Target Milestone: ---

Created attachment 38821
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38821=edit
All data (Makefile, compile_log, *.ii, *.s files) are in attach.7z

I have a some code that contains many cycles (for) where it calls some maths
(sin, cos, exp). 
Previously, I built it with g++ 4.8.4 (Ubuntu 14.04.3, libm-2.19)with flags:
-std=c++11 -Wall -O3

Now, I have g++ 5.3.1 (Ubuntu 16.04, libm-2.23), and I compile it with the same
command.
It become 3 times slower (program time).

I've tried to compile with different optimization flags (O0, O1, O2, O3,
Ofast), but in all cases the problem is reproduced (with Ofast both variants
works faster, but the second works 3 times slower than the first)

I use in my program libtinyxml-dev, libgslcblas. But they have the same
versions in both cases and don't take any significant part in the program
(according to code and callgrind profiling) in terms of performance.

My proc is i7-5820 Haswell.
All data (Makefile, compile_log, *.ii, *.s files) are in attach.7z

[Bug ada/67836] Exceptions with tracebacks in task rendezvous cause STORAGE_ERROR

[nicolas.boulenguez at free dot fr]

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

--- Comment #2 from nicolas.boulenguez at free dot fr ---
The Debian URL above provides a shorter instance of (probably) the same bug
within a single task.

[Bug c++/71740] ICE when defining a pointer to the `memcpy()` function with namespace scope using `auto` targeting i686

[lh_mouse at 126 dot com]

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

--- Comment #1 from lh_mouse  ---
Explicitly specifying __cdecl or __attribute__((__cdecl__)) causes an ICE.
Specifying __stdcall or __fastcall, or not specifying one, does not produce an
ICE.

[Bug c++/71740] New: ICE when defining a pointer to the `memcpy()` function with namespace scope using `auto` targeting i686

[lh_mouse at 126 dot com]

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

Bug ID: 71740
   Summary: ICE when defining a pointer to the `memcpy()` function
with namespace scope using `auto` targeting i686
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lh_mouse at 126 dot com
  Target Milestone: ---

The following code generates an ICE with i686-w64-mingw32-gcc:

** Note: the function `memcpy` is declared manually to avoid
#include'ing any system headers. The prototype MUST match
the one in the standard library. Renaming it or changing its
parameters is not allowed in order to reproduce the ICE. **
```
D:\Desktop>cat test.cpp
extern "C" void *__attribute__((__cdecl__)) memcpy(void *, const void *,
unsigned);
auto p = 

D:\Desktop>i686-w64-mingw32-gcc test.cpp
test.cpp:2:11: internal compiler error: Segmentation fault
 auto p = 
   ^~

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

test.cpp:2:11: internal compiler error: Aborted

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
i686-w64-mingw32-gcc: internal compiler error: Aborted (program cc1plus)
```

Changing `memcpy` to something like `foo` or changing the type of the last
parameter to `unsigned long` causes the ICE to vanish.

Replacing `auto p =` with `void *(*p)(void *, const void *, unsigned) =` works
around the problem.

[Bug target/71695] m68k: long long multiplication broken

[martin at netbsd dot org]

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

Martin Husemann  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |---

--- Comment #3 from Martin Husemann  ---
Chuck Silvers has looked a bit closer and found that while it does not happen
with an unmodified gcc 5.4 configured for --target=m68k-linux, it is
reproducable when configuring for --target=m68k-netbsdelf.

One of the differences in the config is the override to BIGGEST_ALIGNEMENT in
netbsd-elf.h:

For m68k/SVR4, some types (doubles for example) are aligned on 8 byte
boundaries */

 #undef BIGGEST_ALIGNMENT
 #define BIGGEST_ALIGNMENT 64

while Linux uses:

Most published ABIs say that ints should be aligned on 16-bit
boundaries, but CPUs with 32-bit busses get better performance
aligned on 32-bit boundaries.  */
 #define BIGGEST_ALIGNMENT (TARGET_ALIGN_INT ? 32 : 16)


This seems to have been there since prehistoric times. Removing this override
makes gcc generate the same code as shown by Andreas.

More interesting though is that adding BIGGEST_ALIGNMENT 64 to the linux
configuration does NOT make gcc emit the bad code, so there must be another
factor involved. Any hints appreciated!

[Bug c++/71739] New: ICE on valid C++11 code: tree check: expected identifier_node, have tree_list in private_is_attribute_p, at tree.c:6080

[su at cs dot ucdavis.edu]

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

Bug ID: 71739
   Summary: ICE on valid C++11 code: tree check: expected
identifier_node, have tree_list in
private_is_attribute_p, at tree.c:6080
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++11 code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

It is a regression from 6.1.x.


$ g++-trunk -v
Using built-in specs.
COLLECT_GCC=g++-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto
--prefix=/usr/local/gcc-trunk --disable-bootstrap
Thread model: posix
gcc version 7.0.0 20160702 (experimental) [trunk revision 237945] (GCC) 
$ 
$ g++-6.1 -c small.cpp
$ clang++-3.8 -c -std=c++11 small.cpp
$ 
$ g++-trunk -c small.cpp
small.cpp:2:38: internal compiler error: tree check: expected identifier_node,
have tree_list in private_is_attribute_p, at tree.c:6080
 template < int N > struct alignas(N) A {};
  ^
0x105eccc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-source-trunk/gcc/tree.c:9751
0x105f074 tree_check
../../gcc-source-trunk/gcc/tree.h:3286
0x105f074 private_is_attribute_p(char const*, unsigned long, tree_node const*)
../../gcc-source-trunk/gcc/tree.c:6080
0x1075cc2 is_attribute_p
../../gcc-source-trunk/gcc/tree.h:4164
0x1075cc2 attribute_value_equal(tree_node const*, tree_node const*)
../../gcc-source-trunk/gcc/tree.c:5012
0x10763ad attribute_list_contained(tree_node const*, tree_node const*)
../../gcc-source-trunk/gcc/tree.c:7225
0x107e4d8 merge_attributes(tree_node*, tree_node*)
../../gcc-source-trunk/gcc/tree.c:6241
0x75be4a save_template_attributes
../../gcc-source-trunk/gcc/cp/decl2.c:1289
0x75be4a cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc-source-trunk/gcc/cp/decl2.c:1475
0x78b9ff cp_parser_class_head
../../gcc-source-trunk/gcc/cp/parser.c:22028
0x78b9ff cp_parser_class_specifier_1
../../gcc-source-trunk/gcc/cp/parser.c:21305
0x78b9ff cp_parser_class_specifier
../../gcc-source-trunk/gcc/cp/parser.c:21601
0x78b9ff cp_parser_type_specifier
../../gcc-source-trunk/gcc/cp/parser.c:15841
0x7a4653 cp_parser_decl_specifier_seq
../../gcc-source-trunk/gcc/cp/parser.c:12763
0x7aebc5 cp_parser_single_declaration
../../gcc-source-trunk/gcc/cp/parser.c:25786
0x7aef3c cp_parser_template_declaration_after_parameters
../../gcc-source-trunk/gcc/cp/parser.c:25485
0x7af948 cp_parser_explicit_template_declaration
../../gcc-source-trunk/gcc/cp/parser.c:25713
0x7af948 cp_parser_template_declaration_after_export
../../gcc-source-trunk/gcc/cp/parser.c:25731
0x7b6e29 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12097
0x7b5804 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12027
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ 


-


template < int N > struct alignas(N) A;
template < int N > struct alignas(N) A {};

[Bug c++/71738] New: ICE on valid C++ code: tree check: expected record_type or union_type or qual_union_type, have template_decl in lookup_template_class_1, at cp/pt.c:8619

[su at cs dot ucdavis.edu]

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

Bug ID: 71738
   Summary: ICE on valid C++ code: tree check: expected
record_type or union_type or qual_union_type, have
template_decl in lookup_template_class_1, at
cp/pt.c:8619
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following C++ code causes an ICE when compiled with the current GCC trunk
on x86_64-linux-gnu in both 32-bit and 64-bit modes.  

It seems to affect all versions since at least as early as 4.6.x. 


$ g++-trunk -c small.cpp
small.cpp: In instantiation of ‘struct S’:
small.cpp:14:11:   required from here
small.cpp:11:15: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_decl in lookup_template_class_1,
at cp/pt.c:8619
   friend void A < X >::B < Y >::operator= (Z);
   ^~~
0x105eccc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc-source-trunk/gcc/tree.c:9751
0x67f4c9 tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
../../gcc-source-trunk/gcc/tree.h:3070
0x700615 lookup_template_class_1
../../gcc-source-trunk/gcc/cp/pt.c:8619
0x700615 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc-source-trunk/gcc/cp/pt.c:8672
0x70106b tsubst_aggr_type
../../gcc-source-trunk/gcc/cp/pt.c:11482
0x6f29fc tsubst_decl
../../gcc-source-trunk/gcc/cp/pt.c:11847
0x6ea75e tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:12874
0x6f166e tsubst_decl
../../gcc-source-trunk/gcc/cp/pt.c:11708
0x6ea75e tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:12874
0x71df81 tsubst_friend_function
../../gcc-source-trunk/gcc/cp/pt.c:9257
0x71df81 instantiate_class_template_1
../../gcc-source-trunk/gcc/cp/pt.c:10318
0x71df81 instantiate_class_template(tree_node*)
../../gcc-source-trunk/gcc/cp/pt.c:10417
0x7c09a3 complete_type(tree_node*)
../../gcc-source-trunk/gcc/cp/typeck.c:133
0x685ee8 start_decl_1(tree_node*, bool)
../../gcc-source-trunk/gcc/cp/decl.c:5084
0x6acead start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc-source-trunk/gcc/cp/decl.c:5047
0x7ad262 cp_parser_init_declarator
../../gcc-source-trunk/gcc/cp/parser.c:18571
0x7addb9 cp_parser_simple_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12383
0x7ae0c1 cp_parser_block_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12251
0x7b6d30 cp_parser_declaration
../../gcc-source-trunk/gcc/cp/parser.c:12148
0x7b5804 cp_parser_declaration_seq_opt
../../gcc-source-trunk/gcc/cp/parser.c:12027
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$


--


template < class > struct S
{ 
  template < class > struct A
  { 
template < class > struct B;
  };

  template < class X >
  template < class Y >
  template < class Z >
  friend void A < X >::B < Y >::operator= (Z);
};

S < int > s;

[Bug fortran/69860] ICE on missing end apostrophe with character(kind=4)

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Index: expr.c
===
--- expr.c  (revision 237945)
+++ expr.c  (working copy)
@@ -970,8 +970,14 @@ gfc_is_constant_expr (gfc_expr *e)


 default:
-  gfc_internal_error ("gfc_is_constant_expr(): Unknown expression type");
-  return 0;
+  {
+   int e, w;
+   gfc_get_errors (, );
+   if (e < 1)
+ gfc_internal_error ("gfc_is_constant_expr(): Unknown "
+   "expression type");
+   return 0;
+  }
 }
 }

[Bug fortran/69867] ICE on initializing character in type with array of incompatible data

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
Index: decl.c
===
--- decl.c  (revision 237945)
+++ decl.c  (working copy)
@@ -1912,8 +1916,10 @@ build_struct (const char *name, gfc_char

   if (c->initializer->expr_type == EXPR_CONSTANT)
gfc_set_constant_character_len (len, c->initializer, -1);
-  else if (mpz_cmp (c->ts.u.cl->length->value.integer,
-   c->initializer->ts.u.cl->length->value.integer))
+  else if (c->initializer
+   && c->initializer->ts.u.cl
+   && mpz_cmp (c->ts.u.cl->length->value.integer,
+   c->initializer->ts.u.cl->length->value.integer))
{
  gfc_constructor *ctor;
  ctor = gfc_constructor_first (c->initializer->value.constructor);