[Bug c++/31378] New: "too few template-parameter-lists" when initializing static template member
When compiling the following program the g++ 4.1.0 gives the error message:
"testtemplstatic.cpp:22: error: too few template-parameter-lists". Which I
interprete as a complaint, that a "template<>" is missing.
If I uncomment the "template<>" in line 21 g++ prints the error message:
"testtemplstatic.cpp:22: error: template header not allowed in member
definition of explicitly specialized class", which I interprete as having a
"template<>" too much.
One of the both versions (presumably the first) should be correct.
My configuration:
> g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.0/configure
--prefix=/flc/flc03/data/samson/soft/gcc/4.1.0 --enable-languages=c,c++
Thread model: posix
gcc version 4.1.0
Regretfully I cannot check the bug with an 4.1.2 version of g++, as the
compilation of gcc 4.1.2 fails with an linker error on a Scientific Linux
(RHEL3) machine.
Cheers, T.
#include
using namespace std;
template< class T >
struct foo
{
struct bar;
};
template<>
struct foo::bar
{
const static char* blubb;
};
template struct foo;
//template<>
const char* foo::bar::blubb = "huhu";
int main()
{
cout << foo::bar::blubb
[Bug c++/31378] "too few template-parameter-lists" when initializing static template member
--- Comment #2 from trumsko at yahoo dot com 2007-03-27 20:56 --- Finally I managed to compile the 4.1.2 version of gcc and the error does not occur any more. -- trumsko at yahoo dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31378
[Bug fortran/31964] New: ishftc fails with certain thrid argument
If the third argument of ishftc equals BIT_SIZE of the first argument, the result shall be the same as if the last argument was omitted. program main implicit none integer aint aint=1 write(*,*) BIT_SIZE(aint) write(*,*) ishftc(aint,1) write(*,*) ishftc(aint,1,32) write(*,*) ishftc(aint,1,BIT_SIZE(aint)) end program main Produces the following wrong output: 32 2 2 2 /tmp/forttest3 $ gfortran -v Using built-in specs. Target: i386-pc-linux-gnu Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure --prefix=/home/fxcoudert/gfortran_nightbuild/irun-20070426 --enable-languages=c,fortran --disable-decimal-float --build=i386-pc-linux-gnu --enable-checking=release --with-gmp=/home/fxcoudert/gfortran_nightbuild/software Thread model: posix gcc version 4.3.0 20070426 (experimental) -- Summary: ishftc fails with certain thrid argument Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: trumsko at yahoo dot com GCC build triplet: i686-redhat-linux-gnu GCC host triplet: i686-redhat-linux-gnu GCC target triplet: i686-redhat-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31964
[Bug libstdc++/26907] New: Two times filebuf::sungetc() at beginning of file gives undefined result
If I use filebuf::sungetc() at the beginning of a file, the result of the next
sbumc() call is not
allways the first character in the file:
#include
#include
using namespace std;
int main()
{
ifstream infile("test.dat");
filebuf* inbuf=infile.rdbuf();
int res;
//at beginning of file
res=inbuf->sungetc();
res=inbuf->sungetc();
res = inbuf->sbumpc();
if ( res == EOF )
cout << "x" << endl;
else
cout <<(char) res << endl;
res=inbuf->sungetc();
//at beginning on file
res=inbuf->sungetc();
res=inbuf->sungetc();
res = inbuf->sbumpc();
if ( res == EOF )
cout << "x" << endl;
else
cout <<(char) res <<"-"
[Bug libstdc++/26907] Two times filebuf::sungetc() at beginning of file gives undefined result
--- Comment #2 from trumsko at yahoo dot com 2006-03-28 20:58 --- o.k. I read the comments to libstdc++/9439 and browsed through section 27.5.2 of the ISO standtard again. Unfortunatly I didn't find the proof, that the example program realy behaves contrary to the standard, as I only found the statement in section 27.5.2.4.4 that the postconditions for pbackfail() are the same as for underflow() but I didn't find the exact postconditions for underflow(). I'm not complaining about the return value of sungetc() (acutally I fully agree), but I complain, that two failing calls of sungetc() at the beginning of a file influence the next call of sbumpc() and even worse depending on the state of the buffer. My oppinion is, that an abitrary number of sungetc() at the beginning of a file should not have the effect, that the next sbumpc() returns the first character of the file. Independent to the state of the buffer. This is not the case. The example code proves, that under certain cirumstances a sbumpc() does _not_ return the first character of the file. Cheers Troban. -- trumsko at yahoo dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26907
[Bug fortran/30034] New: pure subroutine requires intent for procedure argument
The following declaration
pure subroutine s_one ( anum, afun )
integer, intent(in) :: anum
interface
pure function afun (k) result (l)
implicit none
integer, intent(in) :: k
integer :: l
end function afun
end interface
results in the error (using lates build of gfortran-4.3):
Error: Argument 'afun' of pure subroutine 's_one' at (1) must have its INTENT
specified
The section 12.6 of ISO/IEC 1539-1 says:
Constraint: The specification-part of a pure function subprogram shall specify
that all dummy arguments have INTENT (IN) except procedure arguments and
arguments with the POINTER attribute.
which as far I understand means theat the code above is corrent (without intent
statement for 'afun'.
Cheers, T.
--
Summary: pure subroutine requires intent for procedure argument
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trumsko at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30034
[Bug fortran/30084] New: segmentation falut when compiling certain code
gfortran crashes when compiling teh attached code (the same segmentation fault occures when compiling with 4.2.0 version of gfortran) [EMAIL PROTECTED] /tmp/gfortcrash $ gfortran -c kinds.f90 vamp_bundle.f90 vamp_bundle.f90:3166: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. [EMAIL PROTECTED] /tmp/gfortcrash $ gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure --prefix=/home/fxcoudert/gfortran_nightbuild/irun-20061130 --enable-languages=c,fortran --with-gmp=/home/fxcoudert/gfortran_nightbuild/software Thread model: posix gcc version 4.3.0 20061130 (experimental) -- Summary: segmentation falut when compiling certain code Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: trumsko at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30084
[Bug fortran/30084] segmentation falut when compiling certain code
--- Comment #1 from trumsko at yahoo dot com 2006-12-06 14:36 --- Created an attachment (id=12754) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12754&action=view) source files to crash gfortran unpack and execute gfortran -c kinds.f90 vamp_bundle.f90 to reproduce segmentation violation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30084
[Bug fortran/30224] New: segmentation falut when compiling certain code
gfortran crashes when compiling the attached code
[EMAIL PROTECTED] /tmp/gfortcrash $ gfortran -c kinds.f90 constants.f90
lorentz.f90
lorentz.f90: In function rotation_generic_cs:
lorentz.f90:775: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
[EMAIL PROTECTED] /tmp/gfortcrash $ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /home/fxcoudert/gfortran_nightbuild/trunk/configure
--prefix=/home/fxcoudert/gfortran_nightbuild/irun-20061130
--enable-languages=c,fortran
--with-gmp=/home/fxcoudert/gfortran_nightbuild/software
Thread model: posix
gcc version 4.3.0 20061130 (experimental)
Reduced testcase:
== lorentz_red.f90 =
module lorentz
implicit none
public :: rotation
integer, dimension(3,3,3), parameter :: epsilon_three = &
& reshape( source = (/ 0, 0,0, 0,0,-1, 0,1,0,&
& 0, 0,1, 0,0, 0, -1,0,0,&
& 0,-1,0, 1,0, 0, 0,0,0 /),&
& shape = (/3,3,3/) )
interface rotation
module procedure rotation_generic_cs
end interface
contains
function rotation_generic_cs(cp, sp, n) result(a)
real :: a
real, intent(in) :: cp, sp
real, dimension(3), intent(in) :: n
integer :: i,j
a=cp*cp + (1-cp)*n(i)*n(j) &
& - sp*dot_product(epsilon_three(i,j,:), n)
end function rotation_generic_cs
end module lorentz
=
[EMAIL PROTECTED] /tmp/gfortcrash2 $ gfortran -c lorentz_red.f90
lorentz.f90: In function rotation_generic_cs:
lorentz.f90:18: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Note that changing the order of the calculation produces an "internal compiler
error" instead of a segmentation fault:
= lorentz_red2.f90 ==
module lorentz
implicit none
public :: rotation
integer, dimension(3,3,3), parameter :: epsilon_three = &
& reshape( source = (/ 0, 0,0, 0,0,-1, 0,1,0,&
& 0, 0,1, 0,0, 0, -1,0,0,&
& 0,-1,0, 1,0, 0, 0,0,0 /),&
& shape = (/3,3,3/) )
interface rotation
module procedure rotation_generic_cs
end interface
contains
function rotation_generic_cs(cp, sp, n) result(a)
real :: a
real, intent(in) :: cp, sp
real, dimension(3), intent(in) :: n
integer :: i,j
a= - sp*dot_product(epsilon_three(i,j,:), n) &
& + cp*cp + (1-cp)*n(i)*n(j)
end function rotation_generic_cs
end module lorentz
===
[EMAIL PROTECTED] /tmp/gfortcrash2 $ gfortran -c lorentz_red2.f90
lorentz.f90: In function rotation_generic_cs:
lorentz.f90:17: internal compiler error: in gfc_conv_expr_op, at
fortran/trans-expr.c:1109
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: segmentation falut when compiling certain code
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: trumsko at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30224
[Bug fortran/30224] segmentation falut when compiling certain code
--- Comment #1 from trumsko at yahoo dot com 2006-12-15 18:04 --- Created an attachment (id=12815) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12815&action=view) full 'real life' code producing segfault unpack and execute gfortran -c kinds.f90 constants.f90 lorentz.f90 to reproduce segmentation violation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30224
