[Bug c++/39270] New: Explicit instantiation rejected
Hello.
The following does not compile:
-
class A
{
public:
class B {};
template void x(X a) {}
template void x(int a);
};
template
void A::x (int a)
{ }
template void A::x (int a);
--
Namely, the explicit instantiation on the last line is rejected with the error:
test.cc:13: error: ambiguous template specialization x for void
A::x(int)
i.e. not even recognized as an explicit instantiation.
Implicit instantiation seems to work fine.
cheers
gcc config:
Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local
--infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64
--libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/
--with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64
--with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --program-suffix=-4.3
--enable-version-specific-runtime-libs --enable-linux-futex
--without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE
Linux)
--
Summary: Explicit instantiation rejected
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: highegg at gmail dot com
GCC target triplet: Target: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39270
[Bug c++/39340] New: unnecessarily strict std::norm implementation
g++ 4.3.1 implements std::norm(x) as std::abs(x) squared for built-in floating
point types. I believe this is taking the standard too literally. It says
std::norm should return "magnitude of x squared" in the mathematical sense
(i.e. a floating-point approximation thereof), which is not necessarily
equivalent to "the result of std::abs(x) squared". I think the intent of
std::norm was clearly to avoid doing a square root if the magnitude is to be
squared immediatelly.
--
Summary: unnecessarily strict std::norm implementation
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: highegg at gmail dot com
GCC host triplet: x86_64-suse-linux
GCC target triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39340
[Bug libstdc++/39340] unnecessarily strict std::norm implementation
--- Comment #1 from highegg at gmail dot com 2009-03-03 11:49 --- I kindly request to remove this bug report. I've just learned that there are indeed numerical issues that I just failed to see. I'll try to supply a patch eventually. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39340
[Bug libfortran/31760] New: missing elemental applicability
The gfortran intrinsics ERF,BESXX cannot be used as elemental. -- Summary: missing elemental applicability Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: highegg at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31760
[Bug libfortran/31760] missing elemental applicability
--- Comment #2 from highegg at gmail dot com 2007-04-29 18:03 --- (In reply to comment #1) > Why is this a bug in your opinion? ERF and the Bessel functions are MIL/GNU > extensions. I don't think there's a standard that requires these functions to > be elemental. Do you think this is a bug because the functions are treated as > elemental by other compilers you use? Some other reason? > Several reasons: 1. It's kind of systematic to make all simple (i.e. no scalar+vector) math functions as elemental. 2. Others compilers (g95,Intel) do so. 3. The draft F2008 standard contains elemental ERF,ERFC as well as Bessel functions (though with slightly different naming). But you're right, there is no standard enforcing this. I just thought that perhaps this is an unintentional ommitment. I'll change this to enhancement if this is possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31760
[Bug libfortran/31760] missing elemental applicability
-- highegg at gmail dot com changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31760
[Bug fortran/32217] New: gfortran segfaults on UNPACK with zero-sized arrays
The following valid program ends up in a segfault at the UNPACK function call
with gfortran 4.3.0 20070605 (experimental binaries from gcc site):
program bug_report
implicit none
integer,parameter:: rp = kind(1.d0),na = 6
real(rp),allocatable:: hhe(:,:,:),hhc(:,:,:),dv(:)
integer:: nhh,ndv
nhh = 0
allocate(hhe(nhh,2,2))
ndv = 2*na + count(hhe /= 0)
allocate(hhc(nhh,2,2),dv(ndv))
print *,'OK'
hhc = unpack(dv(2*na+1:),hhe /= 0._rp,0._rp)
print *,'OK'
end program
Also reproducible with gfortran 4.2.0 on x86_64 and IA64.
Although the F2003 standard does not explicitly cover zero-sized arguments to
UNPACK; however, I think that from the text it follows logically that the
result should be zero-sized array. With nhh > 0, the program is working fine.
cheers to all gfortran developers,
Jaroslav Hajek
--
Summary: gfortran segfaults on UNPACK with zero-sized arrays
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: highegg at gmail dot com
GCC host triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32217
[Bug fortran/32512] New: efficiency of RESHAPE and SPREAD
gfortran currently implements the TRANSPOSE intrinsic by simply rearranging the
array descriptor, which can save considerable time when passed to an
assumed-shape argument. Two more intrinsics can be implemented in this way:
RESHAPE can check for contiguity of its argument and if so, only construct a
new descriptor sharing the data.
If, as I assume, the array element reference a(i1,i2,i3) is computed
equivalently to:
*((type *)(offset + i1*dim[0].stride + i2*dim[1].stride + i3*dim[2].stride)
then one can also implement a fast version of SPREAD by using zero strides
in the array descriptor
(thus the array reference will ignore some of the indices). This also covers
broadcasting a scalar to an array (all zero strides).
For code using whole array manipulation intensively, I'd expect significant
savings of both time and memory. Can't find at this moment how to attach a file
in this form, so I'll post a test case afterwards.
cheers to all gfortran developers,
Jaroslav Hajek
--
Summary: efficiency of RESHAPE and SPREAD
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: highegg at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32512
[Bug fortran/32512] efficiency of RESHAPE and SPREAD
--- Comment #1 from highegg at gmail dot com 2007-06-26 06:36 --- Created an attachment (id=13790) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13790&action=view) speedtester of TRANSPOSE, RESHAPE and SPREAD this testcase tests speed of constructing an array via TRANSPOSE, RESHAPE and SPREAD, by passing the result to a computationally non-intensive subroutine (involving only one row and column of the matrix). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32512
[Bug fortran/32512] efficiency of RESHAPE and SPREAD
--- Comment #2 from highegg at gmail dot com 2007-06-26 10:56 --- Just an informal note: Apparently (using the testcase), EkoPath 3.0 has a fast RESHAPE but not fast SPREAD, while Intel 9.1 and current g95 have neither. -- highegg at gmail dot com changed: What|Removed |Added CC||highegg at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32512
