[Bug fortran/57141] New: Cannot change attributes of USE-associated intrinsic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57141 Bug #: 57141 Summary: Cannot change attributes of USE-associated intrinsic Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: roger.fer...@bsc.es Hi, gfortran-4.8 (and 4.7 as well and possibly earlier versions too) complain with this snippet. The error message is not emitted if the declaration of R is uncommented. ! -- test.f90 MODULE M INTRINSIC :: NULL !! Uncommenting the following statement !! causes the error go away ! REAL, POINTER :: R(:) => NULL() END MODULE M MODULE M_INTERN USE M IMPLICIT NONE REAL, POINTER :: ARR(:) => NULL() END MODULE M_INTERN ! -- end of test.f90 $ gfortran -c test.f90 test.f90:12.37: REAL, POINTER :: ARR(:) => NULL() 1 Error: Cannot change attributes of USE-associated symbol null at (1) Kind regards,
[Bug fortran/54223] New: Statement function statement with dummy arguments that are also OPTIONAL may crash in wrong calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54223 Bug #: 54223 Summary: Statement function statement with dummy arguments that are also OPTIONAL may crash in wrong calls Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: roger.fer...@bsc.es Hi, in the following non-conformant Fortran snippet SUBROUTINE S(X) IMPLICIT NONE INTEGER, OPTIONAL :: X INTEGER :: F, Y ! Statement function statement F(X) = X + 1 ! This call to F is wrong, it requires an actual argument here ! despite the X being OPTIONAL Y = F() END SUBROUTINE S causes gfortran 4.7.1 to crash $ gfortran -c test.f90 test.f90: In function 's': test.f90:11:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. I think that the OPTIONAL attribute is confusing gfortran when it checks the (wrong) call to F. Removing the OPTIONAL attribute results in gfortran properly diagnosing the missing actual argument. Kind regards,
[Bug fortran/54822] New: OpenMP - Firstprivate optional dummy arguments crash if not present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54822 Bug #: 54822 Summary: OpenMP - Firstprivate optional dummy arguments crash if not present Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: roger.fer...@bsc.es The following program SUBROUTINE S(X) IMPLICIT NONE INTEGER, OPTIONAL :: X !$OMP TASK FIRSTPRIVATE(X) IF (PRESENT(X)) THEN X = X + 1 END IF !$OMP END TASK END SUBROUTINE S PROGRAM MAIN IMPLICIT NONE INTERFACE SUBROUTINE S(X) IMPLICIT NONE INTEGER, OPTIONAL :: X END SUBROUTINE S END INTERFACE CALL S() END PROGRAM MAIN crashes at runtime using gfortran 4.7.1 $ gfortran -o bug bug.f90 -fopenmp $ ./bug Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7FC7C9245667 #1 0x7FC7C9245C34 #2 0x7FC7C83DE4EF #3 0x4007B2 in s_._omp_cpyfn.1 at bug.f90:0 #4 0x7FC7C8DA2875 #5 0x40074D in s_ #6 0x40075D in MAIN__ at bug.f90:0 Violació de segment I think that the initialization of the firstprivate X using the non-present dummy argument X is causing the crash.
[Bug fortran/54822] OpenMP - Firstprivate optional dummy arguments crash if not present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54822 --- Comment #2 from Roger Ferrer Ibanez 2012-10-05 09:53:36 UTC --- > The OpenMP standard says that the firstprivate private copy of the var is > initialized (for non-pointers) using intrinsic assignment, Oops. I tried also with Intel Fortran and it worked and I wrongly assumed this was OK. The wording of the standard clearly states that this is a problem in the code. Sorry for the fuss.
[Bug fortran/47359] New: Recursive functions of intrinsic names generates invalid assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47359
Summary: Recursive functions of intrinsic names generates
invalid assembler
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: roger.fer...@bsc.es
I know this is sort of a contrived case but seems that gfortran is getting
confused in this case leading to syntactically invalid assembler.
RECURSIVE FUNCTION MAX(A, B) RESULT(K)
IF (B >= 0) THEN
K = MAX(A+1, B-1)
ELSE
K = A
END IF
END
$ gfortran -c test.f90 -save-temps
test.s:11: Error: junk at end of line, first unrecognized character is `('
test.s:12: Error: unrecognized symbol type ""
test.s:12: Error: junk at end of line, first unrecognized character is `('
test.s:13: Error: Unrecognized opcode: `__(intrinsic)__max:'
test.s:73: Error: expected comma after name `__' in .size directive
$ cat -n test.s
...
11.globl __(intrinsic)__max
12.type__(intrinsic)__max, @function
13__(intrinsic)__max:
...
73.size__(intrinsic)__max,.-__(intrinsic)__max
My guess is that gfortran is picking the intrinsic 'max' function symbol
instead of the one being currently defined (which is recursive and thus is
eligible to be called in its same body, isn't it?)
I don't know how much conformant this is to Fortran standard but Intel Fortran
and IBM XL Fortran did not complain and successfully generated an object file.
If this is not valid Fortran, an error message is better than a cryptic
assembler syntax error :)
[Bug c++/57614] New: Friend declaration and qualified class member access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57614
Bug ID: 57614
Summary: Friend declaration and qualified class member access
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
In the snippet below, a weird interaction happens between two overloaded friend
declarations and a class member access using a qualified id-expression.
// -- test.cc
class A
{
protected:
int s;
public:
A();
};
class B : public A
{
protected:
public:
B();
// By reversing the order of these two declarations
// you can change the location of the error
friend void foo(B &, int);
friend void foo(B &, B& b);
};
void foo(B& a, int)
{
// This is only fine if this function was the first "friend" declared
a.A::s = 3;
// Always fine
a.s = 3;
}
void foo(B& a, B& b)
{
// This is only fine if this function was the first "friend" declared
a.A::s = 3;
// Always fine
a.s = 3;
}
// -- end of test.cc
g++ is 4.7.3
$ g++ -c test.cc
test.cc: In function ‘void foo(B&, B&)’:
test.cc:4:7: error: ‘int A::s’ is protected
test.cc:32:7: error: within this context
If we reverse the order of the friend declarations we can change the error
location.
$ g++ -c test.cc
test.cc: In function ‘void foo(B&, int)’:
test.cc:4:7: error: ‘int A::s’ is protected
test.cc:24:7: error: within this context
The error seems to happen with the second overloaded friend declaration.
This problem can be worked around if the id-expression of the class member
access is unqualified.
[Bug c++/53836] New: ICE: unexpected expression of kind template_parm_index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53836
Bug #: 53836
Summary: ICE: unexpected expression of kind template_parm_index
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: roger.fer...@bsc.es
Created attachment 27733
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27733
Preprocessed source
Hello,
the following testcase fails to compile in g++ 4.7.1
// -- test.cc
template
struct A { };
template
void g()
{
const int M ( Q );
A a;
}
void h()
{
g<3>();
}
$ g++ -c test.cc
test.cc: In function ‘void g()’:
test.cc:9:8: internal compiler error: unexpected expression ‘Q’ of kind
template_parm_index
Please submit a full bug report,
with preprocessed source if appropriate.
Preprocessed source stored into /tmp/cc7IeEc0.out file, please attach this to
your bugreport.
Using 'const int M = Q;' instead works fine.
g++ 4.4 and g++ 4.5 fail (without an ICE), but g++ 4.6.3 works fine so it looks
to me as a 4.7 regression.
Kind regards,
[Bug c++/53836] ICE: unexpected expression of kind template_parm_index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53836
--- Comment #1 from Roger Ferrer Ibanez 2012-07-03
08:28:59 UTC ---
A similar problem happens when template-type parameters are involved.
// -- test2.cc
template
struct A { };
template
void g2()
{
const int M ( sizeof(Q) );
A a;
}
void h()
{
g2();
}
$ g++ -c test2.cc
test2.cc: In function ‘void g2()’:
test2.cc:8:8: error: the value of ‘M’ is not usable in a constant expression
test2.cc:7:15: note: ‘M’ was not initialized with a constant expression
test2.cc:8:8: note: in template argument for type ‘int’
test2.cc:8:11: error: invalid type in declaration before ‘;’ token
Should I open another PR for that one?
[Bug fortran/52452] New: INTRINSIC cannot be applied to gfortran's ETIME
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52452 Bug #: 52452 Summary: INTRINSIC cannot be applied to gfortran's ETIME Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: roger.fer...@bsc.es [Note for a possible duplicate: This bug may be related to #52333, but in that one EXTERNAL and explicit INTERFACEs are involved (which is not the case in the current bug).] gfortran's ETIME can be used either as a FUNCTION or as a SUBROUTINE. Explicitly specifying that it is an INTRINSIC name (using an intrinsic-statement) works fine if the function version is used. But when using the subroutine version, gfortran 4.6.2 complains: Consider the following testcase PROGRAM test_etime IMPLICIT NONE INTRINSIC :: etime REAL(4) :: tarray(1:2) REAL(4) :: result CALL etime(tarray, result) END PROGRAM test_etime results in $ gfortran -c test_etime.f90 test_etime.f90:3.22: INTRINSIC :: etime 1 Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'etime' at (1) Removing that line the compilation succeeds (and gfortran appropiately emits a call to _gfortran_etime_sub). Using the function version works too with or without an INTRINSIC statement. [Note: I'm aware, as the documentation clearly states, that both forms cannot be used in a single program unit. I'm just using one of them at a time] Maybe it is my fault assuming too liberally the meaning of the INTRINSIC statement/attribute. Kind regards,
[Bug c++/58878] New: Template parameter name can be hidden in a template member function defined inside the class specifier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58878
Bug ID: 58878
Summary: Template parameter name can be hidden in a template
member function defined inside the class specifier
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
g++ allows declarations to hide a template-parameter name in template member
functions defined inside the class-specifier.
I have not been able to find whether this was expected behaviour in g++ so
I'm inclined to believe this is an error in g++.
Following is a testcase where several declarations attempt to hide
template-parameter names 't' and 's' in the scope.
g++ accepts cases 1, 5 and 6 and (I think) it should not allow them. The
remaining cases seem to be correctly diagnosed.
This fails both in g++ 4.8.1 and g++ 4.9.0 20131015 (experimental).
-- test.c
// Template-members of non-template class
struct A
{
template
void f()
{
int t = 1; // Error. g++ does NOT complain
}
template
void g();
};
template
void A::g()
{
int t = 2; // OK. g++ DOES complain
}
// (Non-template) Members of template class
template
struct B
{
void f()
{
int t = 3; // OK. g++ DOES complain
}
void g();
};
template
void B::g()
{
int t = 4; // OK. g++ DOES complain
}
// Template members of template class
template
struct C
{
template
void f()
{
int t = 5; // Error. g++ does NOT complain
int s = 6; // Error. g++ does NOT complain
}
template
void g();
};
template
template
void C::g()
{
int t = 7; // OK. g++ DOES complain
int s = 8; // OK. g++ DOES complain
}
-- end of test.cc
$ g++ -c test.cc
test.cc: In member function ‘void A::g()’:
test.cc:17:9: error: declaration of ‘int t’
int t = 2; // OK. g++ DOES complain
^
test.cc:14:11: error: shadows template parm ‘class t’
template
^
test.cc: In member function ‘void B::f()’:
test.cc:26:13: error: declaration of ‘int t’
int t = 3; // OK. g++ DOES complain
^
test.cc:21:11: error: shadows template parm ‘class t’
template
^
test.cc: In member function ‘void B::g()’:
test.cc:35:9: error: declaration of ‘int t’
int t = 4; // OK. g++ DOES complain
^
test.cc:32:11: error: shadows template parm ‘class t’
template
^
test.cc: In member function ‘void C::g()’:
test.cc:58:9: error: declaration of ‘int t’
int t = 7; // OK. g++ DOES complain
^
test.cc:54:11: error: shadows template parm ‘class t’
template
^
test.cc:59:9: error: declaration of ‘int s’
int s = 8; // OK. g++ DOES complain
^
test.cc:55:11: error: shadows template parm ‘class s’
template
I'd expect error messages for 1, 5 and 6 to appear as well.
Kind regards,
[Bug fortran/65825] New: Cannot change attributes intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65825 Bug ID: 65825 Summary: Cannot change attributes intrinsic Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roger.ferrer at bsc dot es Hi, a problem similar to PR57141 happens with the code below. Fails both with gfortran 4.9.2 and 5.0.1 20150412 (prerelease). Both Intel Fortran 14.0.2 and XL Fortran 15.01 accept this code (both print 3 of course). -- t.f90 MODULE moo IMPLICIT NONE INTEGER(4), PUBLIC :: c(3, 3) !! uncomment the following statement !! as a workaround ! PRIVATE :: ubound DATA c(3, 1:ubound(c, 2)) / 1, 2, 3 / END MODULE moo PROGRAM main USE moo IMPLICIT NONE INTEGER(4) :: x INTRINSIC :: ubound ! gfortran rejects this x = ubound(c, 2) ! should print 3 PRINT *, x END PROGRAM main -- end of t.f90 Leaving the upper bound of the subscript-triplet can be used as a workaround. Another workaround involves explicitly stating that ubound name is private. I assume that the code is OK since in both cases ubound does not change its "intrinsic" meaning. Kind regards,
[Bug fortran/65825] Cannot change attributes intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65825 --- Comment #2 from Roger Ferrer Ibanez --- > Well, if so, why are you do you want to declare ubound as intrinsic besides > pushing gfortran to its limit? I did not intend to push gfortran anywhere. It actually happened by chance. Kind regards,
[Bug c++/60265] New: [C++11] using-declarator of enumerator fails if fully qualified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60265
Bug ID: 60265
Summary: [C++11] using-declarator of enumerator fails if fully
qualified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
a using-declarator the nested-name of which includes an enumerator-name fails,
as g++ seems to expect only namespace-names at this point.
This seems a specific lookup problem of the using-declarator. Other
qualified-ids, seem to work, as shown in the snippet below.
// -- enum.cc
namespace A
{
enum E { V };
}
namespace B
{
void f1()
{
int x;
x = A::E::V; // OK
x = A::V;// OK
}
void f2()
{
using A::V; // OK
int x;
x = V;
}
void f3()
{
using A::E::V; // ERR (but should be OK)
int x;
x = V;
}
}
// -- end of enum.cc
$ ~/soft/gcc-experiment/gcc-install/bin/g++ -std=c++11 --version
g++ (GCC) 4.9.0 20140218 (experimental)
$ g++ -std=c++11 -c enum.cc
enum.cc: In function ‘void B::f3()’:
enum.cc:24:21: error: ‘A::E’ is not a namespace
using A::E::V; // ERR
^
enum.cc:26:13: error: ‘V’ was not declared in this scope
x = V;
^
enum.cc:26:13: note: suggested alternative:
enum.cc:3:14: note: ‘V’
enum E { V };
Kind regards,
[Bug fortran/60522] New: WHERE construct causes an ICE in gfc_trans_where_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60522 Bug ID: 60522 Summary: WHERE construct causes an ICE in gfc_trans_where_2 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roger.ferrer at bsc dot es Hi, the following code ! -- test.f90 subroutine foo(a, b) implicit none integer, dimension(:), intent(inout) :: a integer, dimension(:), intent(in) :: b where (b(:) > 0) a(lbound(a, 1):ubound(a, 1)) = b(lbound(b, 1):ubound(b, 1)) * b(lbound(b, 1):ubound(b, 1)) end where end subroutine foo ! -- end of test.f90 causes an ICE if optimization is enabled: $ gfortran -c test.f90 -O test.f90: In function ‘foo’: test.f90:6:0: internal compiler error: in gfc_trans_where_2, at fortran/trans-stmt.c:4550 where (B(:) > 0) ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. The problem goes away if the assignment is of the (equivalent) form: a(:) = b(:) * b(:) or a = b * b or if optimization is disabled. Kind regards,
[Bug c++/67746] New: Mangled name is accepted for variables in namespace-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67746
Bug ID: 67746
Summary: Mangled name is accepted for variables in
namespace-scope
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Target Milestone: ---
Hi,
this was discovered by accident.
g++ 5.2.0 accepts this
namespace N
{
int x;
}
void f(void)
{
_ZN1N1xE = 1; // somehow this is an alias to N::x at the eyes of the C++FE
}
but rejects other cases that have the same mangling (according to "nm") like
struct N
{
static int x;
};
void f(void)
{
_ZN1N1xE = 1; // rejected
}
The following case is not allowed either, which suggests that the mangled name
is added into some scope after the declarator has been processed.
namespace N
{
int x = _ZN1N1xE; // rejected
}
Next case is accepted, again suggesting that after the init-declarator 'x = 3'
has been consumed, the mangled name is added into some scope.
namespace N
{
int x = 3, y = _ZN1N1xE; // accepted
}
I understand that underscore-prefixed names may belong to the implementation,
but given that other similar cases are rejected, perhaps this one can be
rejected as well.
Kind regards,
[Bug c++/67746] Mangled name is accepted for variables in namespace-scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67746 --- Comment #2 from Roger Ferrer Ibanez --- (In reply to Jonathan Wakely from comment #1) > Your examples are undefined due to the use of reserved names, and the > libstdc++ implementation actually relies on this in places, so I think > changing it would break things. Ah ok, I didn't know this was used in the libstdc++. Thanks,
[Bug target/67896] New: Inconsistent behaviour between C and C++ for types poly8x8_t and poly16x8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67896
Bug ID: 67896
Summary: Inconsistent behaviour between C and C++ for types
poly8x8_t and poly16x8_t
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Target Milestone: ---
Target: aarch64-linux-gnu
Hi,
aarch64-linux-gnu-gcc is able to distinguish Neon poly types "poly8x8_t" and
"poly16x8_t" but aarch64-linux-gnu-g++ seems it can't.
The following snippet
-- test.c
#include
void f(poly8x8_t *a, poly16x8_t *b)
{
a = b;
}
-- end of test.c
triggers a warning in C
$ aarch64-linux-gnu-gcc -Wall -c test.c
test.c: In function ‘f’:
test.c:5:7: warning: assignment from incompatible pointer type
[-Wincompatible-pointer-types]
a = b;
^
but is accepted without complaints in C++
$ aarch64-linux-gnu-g++ -x c++ -Wall -c test.c
A more elaborated C++11 testcase reveals that these two types are mostly equal
except for sizeof.
-- testcxx11.cc
#include
typedef poly8x8_t T;
typedef poly16x8_t T; // this is OK in C++ if they are the same type
template
struct Equal;
template
struct Equal
{
typedef int X;
};
Equal::X x;
static_assert(sizeof(poly8x8_t) == sizeof(poly16x8_t), "");
-- end of testcxx11.cc
In this example, g++ only complains about their sizeof being different (8 and
16 respectively)
$ aarch64-linux-gnu-g++ -Wall -std=c++11 -c testcxx11.cc
testcxx11.cc:17:1: error: static assertion failed:
static_assert(sizeof(poly8x8_t) == sizeof(poly16x8_t), "");
^
Kind regards,
[Bug target/67896] Inconsistent behaviour between C and C++ for types poly8x8_t and poly16x8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67896
--- Comment #1 from Roger Ferrer Ibanez ---
Hi,
after some debugging I think I understand what happens but I'm not sure I can
provide an acceptable fix for that.
When comparing __Poly8x8_t and __Poly16x8_t types (these are the builtin types
for poly8x8_t and poly16x8_t respectively) in the C++ FE, the sequence involves
"comptypes" and then "structural_comptypes".
Since both types are vectors, the number of elements is the same (i.e.
TYPE_VECTOR_SUBPARTS is 8 for the two vector types), so it only remains to
check the element type (i.e. the TREE_TYPE) of the vector (these are __Poly8_t
and __Poly16_t). At this point "structural_comptypes" sees that both types are
INTEGER_TYPE and then proceeds to compare them using TYPE_CANONICAL but at this
point for both types the canonical type is NULL, so the structural comparison
trivially succeeds.
Types __Poly8x8_t and __Poly16x8_t are initialized in
"aarch64_init_simd_builtin_types" in "gcc/config/aarch64/aarch64-builtins.c".
There is an array of structs, called aarch64_simd_types, with two fields, among
others, eltype (element type) and itype (internal type).
At some point the code initializes the several __PolyS_t (where S = {8, 16, 64,
128}) with a distinct type of integer type {QI, HI, DI, TI} (note that itype is
also initialized)
aarch64_simd_types[Poly8_t].eltype = aarch64_simd_types[Poly8_t].itype =
build_distinct_type_copy (unsigned_intQI_type_node);
aarch64_simd_types[Poly16_t].eltype = aarch64_simd_types[Poly16_t].itype =
build_distinct_type_copy (unsigned_intHI_type_node);
...
and a bit later it makes sure __PolySxN_t have their element type to their
respective __PolyS_t.
aarch64_simd_types[Poly8x8_t].eltype = aarch64_simd_types[Poly8_t].itype;
...
aarch64_simd_types[Poly16x8_t].eltype = aarch64_simd_types[Poly16_t].itype;
And it finally proceeds to build the vector types except if the itype is not
null. Only the nonvector __PolyS_t types have a non-null itype (it was assigned
above) so they are not set a vector type.
for (i = 0; i < nelts; i++)
{
tree eltype = aarch64_simd_types[i].eltype;
enum machine_mode mode = aarch64_simd_types[i].mode;
if (aarch64_simd_types[i].itype == NULL)
aarch64_simd_types[i].itype =
build_distinct_type_copy
(build_vector_type (eltype, GET_MODE_NUNITS (mode)));
tdecl = add_builtin_type (aarch64_simd_types[i].name,
aarch64_simd_types[i].itype);
TYPE_NAME (aarch64_simd_types[i].itype) = tdecl;
SET_TYPE_STRUCTURAL_EQUALITY (aarch64_simd_types[i].itype);
}
The last statement in the loop ensures that the type is compared using
structural equality. This effectively sets the canonical type to zero,
according to the macro in tree.h
#define SET_TYPE_STRUCTURAL_EQUALITY(NODE) (TYPE_CANONICAL (NODE) = NULL_TREE)
My knowledge of the internals of GCC is too limited at this point to state
whether setting structural equality for all these types is OK. I think, though,
that setting structural equality for the non-vector types (thus nullifying
their canonical type) may be wrong: it makes two __PolyS_N_t types (where N is
the same) identical at the eyes of the C++ FE.
The following crude patch seems to let the C++ FE distinguish the two types.
--- /home/roger/soft/gcc/src/gcc-5.2.0/gcc/config/aarch64/aarch64-builtins.c
2015-04-01 13:18:03.0 +0200
+++ config/aarch64/aarch64-builtins.c 2015-10-11 23:51:05.315828614 +0200
@@ -628,15 +628,20 @@
tree eltype = aarch64_simd_types[i].eltype;
enum machine_mode mode = aarch64_simd_types[i].mode;
+ bool is_vector = false;
if (aarch64_simd_types[i].itype == NULL)
- aarch64_simd_types[i].itype =
- build_distinct_type_copy
+ {
+ aarch64_simd_types[i].itype =
+ build_distinct_type_copy
(build_vector_type (eltype, GET_MODE_NUNITS (mode)));
+ is_vector = true;
+ }
tdecl = add_builtin_type (aarch64_simd_types[i].name,
aarch64_simd_types[i].itype);
TYPE_NAME (aarch64_simd_types[i].itype) = tdecl;
- SET_TYPE_STRUCTURAL_EQUALITY (aarch64_simd_types[i].itype);
+ if (is_vector)
+ SET_TYPE_STRUCTURAL_EQUALITY (aarch64_simd_types[i].itype);
}
#define AARCH64_BUILD_SIGNED_TYPE(mode) \
With this change, g++ is able to tell the two types apart.
$ cat test.cc
typedef __Poly8x8_t A;
typedef __Poly16x8_t A;
$ aarch64-linux-gnu-g++ -fsyntax-only test.cc -Wall
test.cc:2:22: error: conflicting declaration ‘typedef __vector(8) __Poly16_t A’
typedef __Poly16x8_t A;
^
test.cc:1:21: note: previous declaration as ‘typedef __vector(8) __Poly8_t A’
typedef __Poly8x8_t A;
Caveat: I debugged this problem in a cross-compiler without real hardware so I
do not know if this is OK or not.
Hope this helps.
Kind regards,
[Bug c++/68087] New: ICE with constexpr in array with negative index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68087
Bug ID: 68087
Summary: ICE with constexpr in array with negative index
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Target Milestone: ---
Hi,
GCC 6.0.0 20151025 and 5.2 crash with an ICE with the following code:
-- ice.cc
constexpr char c[] = "hello";
constexpr const char *p = c;
void f()
{
static_assert(*(p-1) == 'h', "");
}
-- end of ice.cc
$ g++ --version
g++ (GCC) 6.0.0 20151025 (experimental)
$ g++ -std=c++11 -c ice.cc
ice.cc: In function ‘void f()’:
ice.cc:6:37: internal compiler error: in tree_to_shwi, at tree.c:7304
static_assert(*(p-1) == 'h', "");
^
0xf2fec2 tree_to_shwi(tree_node const*)
../../gcc-git/gcc/tree.c:7304
0x7fc084 cxx_eval_array_reference
../../gcc-git/gcc/cp/constexpr.c:1785
0x7fc084 cxx_eval_constant_expression
../../gcc-git/gcc/cp/constexpr.c:3485
0x7fb18c cxx_eval_indirect_ref
../../gcc-git/gcc/cp/constexpr.c:2588
0x7fb18c cxx_eval_constant_expression
../../gcc-git/gcc/cp/constexpr.c:3340
0x7fe63e cxx_eval_binary_expression
../../gcc-git/gcc/cp/constexpr.c:1601
0x7fa994 cxx_eval_constant_expression
../../gcc-git/gcc/cp/constexpr.c:3462
0x7fff0b cxx_eval_outermost_constant_expr
../../gcc-git/gcc/cp/constexpr.c:3746
0x801980 maybe_constant_value(tree_node*, tree_node*)
../../gcc-git/gcc/cp/constexpr.c:3859
0x772f15 finish_static_assert(tree_node*, tree_node*, unsigned int, bool)
../../gcc-git/gcc/cp/semantics.c:8291
0x6f47a2 cp_parser_static_assert
../../gcc-git/gcc/cp/parser.c:12662
0x70b099 cp_parser_block_declaration
../../gcc-git/gcc/cp/parser.c:11880
0x70bed1 cp_parser_declaration_statement
../../gcc-git/gcc/cp/parser.c:11496
0x70804a cp_parser_statement
../../gcc-git/gcc/cp/parser.c:10162
0x708971 cp_parser_statement_seq_opt
../../gcc-git/gcc/cp/parser.c:10440
0x708a73 cp_parser_compound_statement
../../gcc-git/gcc/cp/parser.c:10394
0x708c00 cp_parser_function_body
../../gcc-git/gcc/cp/parser.c:20216
0x708c00 cp_parser_ctor_initializer_opt_and_function_body
../../gcc-git/gcc/cp/parser.c:20252
0x709929 cp_parser_function_definition_after_declarator
../../gcc-git/gcc/cp/parser.c:24856
0x70a82b cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-git/gcc/cp/parser.c:24768
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.
GCC 5.1 and earlier emit a diagnostic instead:
$ g++-5.1 -std=c++11 -c ice.cc
ice.cc: In function ‘void f()’:
ice.cc:6:5: error: non-constant condition for static assertion
static_assert(*(p-1) == 'h', "");
^
ice.cc:6:5: error: array subscript out of bound
Kind regards,
[Bug jit/68370] New: Pointer arithmetic in libgccjit seems to require an extra cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68370
Bug ID: 68370
Summary: Pointer arithmetic in libgccjit seems to require an
extra cast
Product: gcc
Version: 5.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Target Milestone: ---
Hi,
maybe I'm doing something wrong, but libgccjit rejects an assignment of pointer
arithmetic where the types (according to the diagnostic) are OK.
This is not a blocker as it can be worked around using an explicit cast.
I am using GCC 5.2.0.
I have a function "int test(const char* text)" with a single block.
gcc_jit_type *int_type = gcc_jit_context_get_type (ctx, GCC_JIT_TYPE_INT);
gcc_jit_type *const_char_ptr_type =
gcc_jit_context_get_type (ctx, GCC_JIT_TYPE_CONST_CHAR_PTR);
// param: const char* text;
gcc_jit_param *param_text =
gcc_jit_context_new_param (ctx, /* loc */ NULL, const_char_ptr_type,
"text");
gcc_jit_rvalue *rval_text = gcc_jit_param_as_rvalue (param_text);
// int test(const char* text);
gcc_jit_param *params[] = { param_text };
gcc_jit_function *test_fun =
gcc_jit_context_new_function (ctx, /* loc */ NULL,
GCC_JIT_FUNCTION_EXPORTED, int_type, "test",
1, params, /* is_variadic */ 0);
gcc_jit_block *block = gcc_jit_function_new_block (test_fun, "test-block");
and then I want to compute
text++;
According to the documentation this has to be done like this.
text = &text[1];
But if I write
// text = &text[1]; // does not work
gcc_jit_block_add_assignment (block, /* loc */ NULL,
gcc_jit_param_as_lvalue (param_text),
gcc_jit_lvalue_get_address(
gcc_jit_context_new_array_access(ctx, /* loc */ NULL,
rval_text,
gcc_jit_context_one (ctx, int_type)),
/* loc */ NULL));
libgccjit rejects it with
libgccjit.so: error: gcc_jit_block_add_assignment: mismatching types:
assignment to text (type: const char *) from &text[(int)1] (type: const char *)
This can be worked around using a cast:
gcc_jit_block_add_assignment (block, /* loc */ NULL,
gcc_jit_param_as_lvalue (param_text),
gcc_jit_context_new_cast (ctx, /* loc */ NULL,
gcc_jit_lvalue_get_address(
gcc_jit_context_new_array_access(ctx, /* loc */ NULL,
rval_text,
gcc_jit_context_one (ctx, int_type)),
/* loc */ NULL),
const_char_type));
Kind regards,
[Bug jit/68370] Pointer arithmetic in libgccjit seems to require an extra cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68370 --- Comment #3 from Roger Ferrer Ibanez --- Created attachment 36729 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36729&action=edit Small reproducer
[Bug fortran/63744] New: Duplicate use-statement causes error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63744 Bug ID: 63744 Summary: Duplicate use-statement causes error Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: roger.ferrer at bsc dot es Hi, (I guess this is related to PR34657) The following snippet is accepted by gfortran -- test-ok.f90 MODULE MOO INTEGER :: S END MODULE MOO SUBROUTINE S1 USE MOO, ONLY: X => S, X => S X = 1 END SUBROUTINE S1 -- end of test-ok.f90 but it is rejected if the program unit SUBROUTINE S1 is renamed to SUBROUTINE S, as shown below -- test.f90 MODULE MOO INTEGER :: S END MODULE MOO SUBROUTINE S USE MOO, ONLY: X => S, X => S X = 1 END SUBROUTINE S -- end of test.f90 $ gfortran -c test.f90 test.f90:6.8: USE MOO, ONLY: X => S, X => S 1 Error: 's' of module 'moo', imported at (1), is also the name of the current program unit test.f90:8.5: X = 1 1 Error: Name 'x' at (1) is an ambiguous reference to 's' from module 'moo' Removing the second rename lets the code be accepted. USE MOO, ONLY: X => S A similar behaviour is observed if we have two repeated USE-statements rather than two repeated rename's in the rename-list USE MOO, ONLY: X => S USE MOO, ONLY: X => S Kind regards,
[Bug c++/64002] New: Braced initialization of unknown bound array of nondependent type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64002
Bug ID: 64002
Summary: Braced initialization of unknown bound array of
nondependent type
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
during an initialization of an array of unknown bound of
non-dependent type using a braced initializer which contains
type-dependent expressions, g++ does not "postpone" the computation
of the array size at instantiation time and seems to use the number
of elements inside the braced-initializer.
In all cases the code compiles fine.
#include
struct A
{
int x, y;
};
template
int f1(T t1, T t2)
{
A a[] = { t1, t2 };
return sizeof(a) / sizeof(a[0]);
}
void test1()
{
assert(f1(A(), A()) == 2); // OK
assert(f1(1, 2) == 1); // ERROR: this assert fails at runtime
}
That said, in the context of C++2011 a parameter pack expansion seems to work
correctly.
template
int f2(T ...n)
{
A a[] = { n... };
return sizeof(a) / sizeof(a[0]);
}
void test2()
{
assert(f2(A(), A()) == 2); // OK
assert(f2(1, 2) == 1); // OK
}
All asserts pass correctly both in clang-3.5 and icc 14.0.2
Kind regards,
[Bug c++/64002] Braced initialization of unknown bound array of nondependent type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64002 --- Comment #1 from Roger Ferrer Ibanez --- Created attachment 34055 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34055&action=edit Small testcase
[Bug target/64358] New: Wrong code for __int128 operations in powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64358
Bug ID: 64358
Summary: Wrong code for __int128 operations in powerpc64le
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
I'm observing a weird behaviour in PowerPC64 Little Endian that does not seem
to occur on other architectures supporting __int128. The following code, when
compiled with -O1 generates wrong output in gcc 4.9.1.
-- test.c
#include
typedef unsigned __int128 uint128_t;
#define PRINT(value) \
{ union u { uint128_t i; unsigned long long l[2]; } _t = { .i = value }; \
fprintf(stderr, "%s => <%016llx, %016llx>\n", #value, _t.l[1],
_t.l[0]); }
__attribute__((noinline))
uint128_t get_int(uint128_t value, unsigned int num_bytes)
{
uint128_t mask = ~(uint128_t)0;
mask <<= (uint128_t)(8 * num_bytes); /* assuming 1 byte = 8 bits */
mask = ~mask;
value &= mask;
return value;
}
int main(int argc, char* argv[])
{
uint128_t x = 0;
x = get_int(10, /* num_bytes */ 1);
PRINT(x);
return 0;
}
-- end of test.c
The problem is still present in a recent version from the svn:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/home/Computational/rferrer/gcc/install/bin/gcc
COLLECT_LTO_WRAPPER=/home/Computational/rferrer/gcc/install/libexec/gcc/powerpc64le-unknown-linux-gnu/5.0.0/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: ../gcc-src/configure
--prefix=/home/Computational/rferrer/gcc/install
--enable-languages=c,c++,fortran
--with-gmp=/home/Computational/rferrer/gcc/install
--with-mpfr=/home/Computational/rferrer/gcc/install
--with-mpc=/home/Computational/rferrer/gcc/install --enable-multiarch
--disable-multilib
Thread model: posix
gcc version 5.0.0 20141218 (experimental) (GCC)
$ make
gcc -O0 -o test.O0 test.c
./test.O0
x => <, 000a>
gcc -O1 -o test.O1 test.c
./test.O1
x =>
Kind regards,
[Bug target/64358] Wrong code for __int128 operations in powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64358 --- Comment #2 from Roger Ferrer Ibanez --- (In reply to Pat Haugen from comment #1) > This occurs on powerpc64 Big Endian too and is fixed by a patch I just > submitted yesterday. Talk about timing... Fantastic > > https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01585.html I applied the patch in my tree and it fixes this issue. Thanks a lot!
[Bug c++/62064] New: Private inheritance and conversion function id in class member access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62064
Bug ID: 62064
Summary: Private inheritance and conversion function id in
class member access
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
the snippet below causes an access error in g++ 4.9.1 if the
conversion-function-id is referenced in a class-member access.
Intel C++ 14.0.2 and clang 3.3 accept it.
This problem can be worked around with -fno-access-control
(There is also some weirdness like 'struct A A::A' in the diagnostic messages
themselves, but I guess this would belong to another bug)
Should the code be ill-formed, then the "OK" case should be rejected as well.
// -- test.cc
struct A
{
typedef int some_type;
operator some_type();
};
struct B : private A
{
typedef bool some_type;
void foo(B &r)
{
B *p;
B o;
A::operator A::some_type(); // OK
o.A::operator A::some_type(); // ERR
r.A::operator A::some_type(); // ERR
p->A::operator A::some_type(); // ERR
(*this).A::operator A::some_type(); // ERR
}
};
// -- end of test.cc
$ g++ --version
g++ (Debian 4.9.1-1) 4.9.1
$ g++ -c test.cc
test.cc: In member function ‘void B::foo(B&)’:
test.cc:3:1: error: ‘struct A A::A’ is inaccessible
{
^
test.cc:18:23: error: within this context
o.A::operator A::some_type(); // ERR
^
test.cc:4:17: error: ‘typedef int A::some_type’ is inaccessible
typedef int some_type;
^
test.cc:18:26: error: within this context
o.A::operator A::some_type(); // ERR
^
test.cc:3:1: error: ‘struct A A::A’ is inaccessible
{
^
test.cc:19:23: error: within this context
r.A::operator A::some_type(); // ERR
^
test.cc:4:17: error: ‘typedef int A::some_type’ is inaccessible
typedef int some_type;
^
test.cc:19:26: error: within this context
r.A::operator A::some_type(); // ERR
^
test.cc:3:1: error: ‘struct A A::A’ is inaccessible
{
^
test.cc:20:24: error: within this context
p->A::operator A::some_type(); // ERR
^
test.cc:4:17: error: ‘typedef int A::some_type’ is inaccessible
typedef int some_type;
^
test.cc:20:27: error: within this context
p->A::operator A::some_type(); // ERR
^
test.cc:3:1: error: ‘struct A A::A’ is inaccessible
{
^
test.cc:21:29: error: within this context
(*this).A::operator A::some_type(); // ERR
^
test.cc:4:17: error: ‘typedef int A::some_type’ is inaccessible
typedef int some_type;
^
test.cc:21:32: error: within this context
(*this).A::operator A::some_type(); // ERR
^
Kind regards,
[Bug c++/58734] [C++11] Template template parameter pack instantiation problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58734 --- Comment #2 from Roger Ferrer Ibanez --- Hi, g++ 4.9.1. does not fail anymore with this one. I guess it was already been fixed. Kind regards,
[Bug c++/63378] New: decltype and access control issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63378
Bug ID: 63378
Summary: decltype and access control issues
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
the following testcase fails to compile with g++ 4.9.1 and 5.0.0 (20140925).
-- test.cc
template
struct B { };
template
struct A
{
private:
template
static B bar();
public:
template
auto foo1() -> decltype(bar());
};
// (*)
template<>
template<>
auto A::foo1() -> B;
-- end of test.cc
$ g++ --version
g++ (GCC) 5.0.0 20140925 (experimental)
$ g++ -c -std=c++11 -c test.cc
test.cc:18:6: error: template-id ‘foo1’ for ‘B
A::foo1()’ does not match any template declaration
auto A::foo1() -> B;
^
but making 'A::bar' public or using '-fno-access-control' g++ accepts the
code OK.
Explicitly using a manually substituted decltype gives a clue of what is going
on
-- test.cc
// Declarations of B and A above
// (*)
template<>
template<>
auto A::foo1() -> decltype(A::bar());
-- end of test.cc
$ g++ -c -std=c++11 -c test.cc
test.cc:22:6: error: template-id ‘foo1’ for ‘B
A::foo1()’ does not match any template declaration
auto A::foo1() -> decltype(A::bar());
^
test.cc:9:26: error: ‘static B A::bar() [with T2 = int; S2 = float;
T1 = int]’ is private
static B bar();
^
test.cc:22:64: error: within this context
auto A::foo1() -> decltype(A::bar());
Both clang-3.5 and icc 14.0.2 accept this code.
Kind regards,
[Bug c++/63378] decltype and access control issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63378 --- Comment #1 from Roger Ferrer Ibanez --- Created attachment 33578 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33578&action=edit Testcase
[Bug c++/67339] New: Segfault when parsing a typename involving a template-alias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67339
Bug ID: 67339
Summary: Segfault when parsing a typename involving a
template-alias
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Target Milestone: ---
Created attachment 36250
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36250&action=edit
Small testcase
Hi,
the following snippet crashes in trunk (6.0.0 20150824).
-- test.ii
template < typename T>
struct A
{
void foo();
template < typename S, typename W >
using N = void (T::*)(S, W) const ;
};
template < typename T>
void A::foo()
{
typename A::template N fun = &T::out;
}
-- end of test.ii
$ g++ --version
g++ (GCC) 6.0.0 20150824 (experimental)
$ g++ -c test.ii
test.ii: In member function 'void A::foo()':
test.ii:12:29: internal compiler error: Segmentation fault
typename A::template N fun = &T::out;
^
0xc7cf1f crash_signal
../../gcc-svn/gcc/toplev.c:352
0x6efffd cp_parser_elaborated_type_specifier
../../gcc-svn/gcc/cp/parser.c:16189
0x6de047 cp_parser_type_specifier
../../gcc-svn/gcc/cp/parser.c:15104
0x6edf01 cp_parser_decl_specifier_seq
../../gcc-svn/gcc/cp/parser.c:12042
0x7025a1 cp_parser_simple_declaration
../../gcc-svn/gcc/cp/parser.c:11608
0x6fbf54 cp_parser_block_declaration
../../gcc-svn/gcc/cp/parser.c:11555
0x6fcd61 cp_parser_declaration_statement
../../gcc-svn/gcc/cp/parser.c:11174
0x6fdb8c cp_parser_statement
../../gcc-svn/gcc/cp/parser.c:9894
0x6fe162 cp_parser_statement_seq_opt
../../gcc-svn/gcc/cp/parser.c:10172
0x6fe2bb cp_parser_compound_statement
../../gcc-svn/gcc/cp/parser.c:10126
0x6fe4eb cp_parser_function_body
../../gcc-svn/gcc/cp/parser.c:19783
0x6fe4eb cp_parser_ctor_initializer_opt_and_function_body
../../gcc-svn/gcc/cp/parser.c:19819
0x6ff369 cp_parser_function_definition_after_declarator
../../gcc-svn/gcc/cp/parser.c:24426
0x70022c cp_parser_function_definition_from_specifiers_and_declarator
../../gcc-svn/gcc/cp/parser.c:24338
0x70022c cp_parser_init_declarator
../../gcc-svn/gcc/cp/parser.c:17619
0x7005ae cp_parser_single_declaration
../../gcc-svn/gcc/cp/parser.c:24868
0x70074b cp_parser_template_declaration_after_parameters
../../gcc-svn/gcc/cp/parser.c:24487
0x701334 cp_parser_explicit_template_declaration
../../gcc-svn/gcc/cp/parser.c:24722
0x701334 cp_parser_template_declaration_after_export
../../gcc-svn/gcc/cp/parser.c:24740
0x708109 cp_parser_declaration
../../gcc-svn/gcc/cp/parser.c:11412
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.
It looks like a regression introduced in 5.1: both GCC 5.1.0 and GCC 5.2.0
crash while 4.9.3 works fine.
Best regards,
