[Bug c++/21280] [4.0/4.1 Regression] #pragma interface, templates, and inline function used but never defined
--- Additional Comments From prw at ceiriog1 dot demon dot co dot uk 2005-05-05 17:23 --- Bug 21306 is not the same bug. The attached patch FIX1 fixes the test cases for this bug, but not for 21306 - you will need to look at the test case for that bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21280
[Bug libfortran/21376] New: libfortran E output format causes FPE
There's an obvious bug in libfortran/io/write.c which causes a failure
to print 1.0 in exp. format - here's the fix:
diff -U3 -r gcc-4.0.0-old/libgfortran/io/write.c
gcc-4.0.0/libgfortran/io/write.c
--- gcc-4.0.0-old/libgfortran/io/write.c2005-04-05 15:24:36.0
+0100
+++ gcc-4.0.0/libgfortran/io/write.c2005-05-04 07:55:12.0 +0100
@@ -316,9 +316,11 @@
edigits = 2;
else
{
- edigits = 1 + (int) log10 (fabs(log10 (value)));
- if (edigits 2)
+ double absexp = fabs(log10 (value));
+ if (absexp 100)
edigits = 2;
+ else
+ edigits = 1 + (int) log10 (absexp);
}
if (ft == FMT_F || ft == FMT_EN
--
Summary: libfortran E output format causes FPE
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: prw at ceiriog1 dot demon dot co dot uk
CC: gcc-bugs at gcc dot gnu dot org,prw at ceiriog1 dot
demon dot co dot uk
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21376
[Bug libfortran/21376] libfortran E output format causes FPE
--- Additional Comments From prw at ceiriog1 dot demon dot co dot uk
2005-05-04 17:28 ---
The problem occurred in a large finite element analysis code I developed.
The toplevel logic was written in C++, and this was linked to a venerable
public domain numerical analysis library in Fortran. My testcase consists
of the following two files. You only get a floating point exception
if IEEE floating point exceptions are enabled. I don't know if it is possible
to do this from a pure Fortran program, but it is certainly possible to
do from C, and I find it important to do this in numerical codes so that
I can see errors where they occur rather than just propagating NaN's through
the program.
File toplevel.c:
#include fenv.h
main()
{
feenableexcept(FE_DIVBYZERO | FE_INVALID | FE_OVERFLOW );
killer_();
}
File killer.f:
subroutine killer
write(6,'(x,e10.4)') 1.0
end
gcc -c toplevel.c
gfortran -c killer.f
gcc toplevel.o killer.o -lgfortran
./a.out
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21376
[Bug c++/21280] [4.0/4.1 Regression] #pragma interface, templates, and inline function used but never defined
--- Additional Comments From prw at ceiriog1 dot demon dot co dot uk
2005-04-30 07:37 ---
I may have a discovered a related bug with a large program using
STL (hash_set). I've tried to simplify somewhat, and I have some
comments arising from some hacking with gdb (ddd). As a previous
poster on duplicate Bug #20584 observed, it seems to be related
to #pragma interface. In this example the problem is with the
~hash_set destructor, which is never defined explicitly but needs
to be synthesized to destroy the _M_ht member. This destructor
is never instantiated anywhere.
This problem occurs with the 4.0.0 distribution.
Just do g++ bug-example.cc (if you can't reproduce the warning,
I will post the preprocessed source also).
FILE bug-example.h
#pragma interface
#include ext/hash_set
using __gnu_cxx::hash_set;
template class Value, class HashFcn, class EqualKey
class SetData:
public hash_setValue *, HashFcn, EqualKey
{
int i;
public:
SetData(void) {i = 1;}
int foo() {}
};
typedef int Loc;
struct Loc_hash {
size_t operator()(Loc *const loc) const
{
return *loc;
}
};
struct Loc_eq {
bool operator()(Loc *const loc1, Loc *const loc2) const
{
return (*loc1 == *loc2);
}
};
typedef SetDataLoc,Loc_hash,Loc_eq LocSet;
FILE bug-example.cc --
// If this is set we are OK.
// #pragma implementation
#include bug-example.h
/* ==
Compile with -DEG1: We are OK
Compile with -DEG2: We get a warning:
bug-example.h:13: warning: inline function $-1òø__gnu_cxx::hash_setLoc*,
Loc_hash, Loc_eq, std::allocatorLoc* ::~hash_set()òù used but never defined
~hash_set is not declared explicitly; but it is synthesized since one of
the members (_M_ht) has a non-trivial destructor.
Try setting the following breakpoint:
(gdb) info b 1
Num Type Disp Enb AddressWhat
1 breakpoint keep y 0x080d295f in lazily_declare_fn at
../../gcc/cp/method.c:1055
stop only if !({text variable, no debug info} 0x599b60 strncmp)
(type-type.name-decl.name-identifier.id.str, hash_set, 8)
breakpoint already hit 2 times
For EG1: Hit a breakpoint here:
(gdb) c
Breakpoint 1, lazily_declare_fn (sfk=sfk_destructor, type=0x41746bd0) at
../../gcc/cp/method.c:1055
(gdb) p type-type.name-decl.name-identifier.id.str
$10 = (const unsigned char *) 0x8e6706a
hash_setLoc*,Loc_hash,Loc_eq,std::allocatorLoc*
(gdb) p input_location
$11 = {
file = 0x8e2cc88 bug-example.cc,
line = xx (i.e. LocSet x;)
}
(If the SetData/LocSet constructor fails, then the superclass destructors
must be called to clean up - the compiler therefore needs to synthesize
~hash_set).
For EG2, ~hash_set is not declared until instantiate_pending_templates
(called from finish_file):
(gdb) c
Breakpoint 1, lazily_declare_fn (sfk=sfk_destructor, type=0x41746c3c) at
../../gcc/cp/method.c:1055
(gdb) p input_location
$13 = {
file = 0x8e5cc40 bug-example.h,
line = xx (i.e. SetData(void) {i = 1;})
}
Since bug-example.h contains #pragma interface this does not get
compiled. It should, since it really comes from the hash_set
header, which does not have #pragma interface.
I have a very comple example in which this warning actually leads to a
linker error, but in this small example I have not yet worked out how
to make a destructor call which does not cause ~hash_set to be
properly instantiated - but believe me, it can and does happen.
= */
main()
{
#if defined(EG1)
LocSet x;
int i=1;
x.insert(i);
#else
LocSet *x = new LocSet;
int i=1;
x-insert(i);
#endif
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21280
[Bug c++/21280] [4.0/4.1 Regression] #pragma interface, templates, and inline function used but never defined
--- Additional Comments From prw at ceiriog1 dot demon dot co dot uk 2005-04-30 17:29 --- Following up my earlier comment: It appears that some code, which is intended to improve the user diagnostics, can in fact break the template instantiation process, for the reason stated in the comment which you can find in the patch FIX1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21280
[Bug c++/21306] New: [4.0 Regression] Another way to generate inline function A::~A() used but never defined errors
The attached test case leads to this error: [EMAIL PROTECTED] Orfeo]$ g++ main.ii ../../Orfeo/A.h:3: warning: inline function A::~A() used but never defined /tmp/cc2W2kUK.o(.gnu.linkonce.t._ZN1BI1AED1Ev[BA::~B()]+0xf): In function `BA::~B()': : undefined reference to `A::~A()' collect2: ld returned 1 exit status This is a very simplified model of a bug which I have found when using the STL vector template, which explicitly invokes a destructor via p-~T(). The problem is that class A does not define an explicit destructor, but the class BA needs it. This is a regression since 3.4.2 (or at least the Fedora Core version gcc-3.4.2-6.fc3). Running that on the same code, no destructor call ~A() is generated in ~B(). Presumably the compiler deduces that the template class T(=A) has no nontrivial destructor in this case and so optimizes out the call t-~T(); [Presumably an empty stub could be generated, but where? In the present example it is not generated since the filename for the #pragma implementation (main.cc) does not match that for the #pragma interface (A.h). You might add an implementation file A.cc with a #pragma implementation, but this does not help unless it contains an explicit reference to ~A. Otherwise it doesn't know that any such destructor is needed. The destructor would have to be generated at the point of use, even though this may lead to some duplication between modules, since there seems to be no way of deducing the correct place to put it.] -- Summary: [4.0 Regression] Another way to generate inline function A::~A() used but never defined errors Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: prw at ceiriog1 dot demon dot co dot uk CC: gcc-bugs at gcc dot gnu dot org,prw at ceiriog1 dot demon dot co dot uk GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21306
[Bug c++/21306] [4.0 Regression] Another way to generate inline function A::~A() used but never defined errors
--- Additional Comments From prw at ceiriog1 dot demon dot co dot uk 2005-04-30 21:01 --- Created an attachment (id=8773) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8773action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21306
