[Bug c++/35890] New: __attribute__((format)) fails for methods of template classes
The following code, which compiles cleanly in gcc 4.2.3, produces an error with
4.3.0:
template typename T
struct X {
void f(const char *fmt, ...)
__attribute__((format (printf, 2, 3) ));
};
template class X void ;
fmt_et.cc: In instantiation of 'Xvoid':
fmt_et.cc:7: instantiated from here
fmt_et.cc:4: error: 'printf' was not declared in this scope
fmt_et.cc:4: error: unrecognized format specifier
The error occurs both with explicit instantiation of the class (as above) and
with implicit instantiation via an invocation of the method Xvoid::f. It
does not occur either for a non-template class or if the template is never
instantiated.
--
Summary: __attribute__((format)) fails for methods of template
classes
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zak at transversal dot com
GCC build triplet: x86_64_pc_linux_gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64_pc_linux_gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35890
[Bug c++/35773] New: [4.3 regression] auto_ptr references don't convert
The following example (which is a cut-down version of some code which passes a
std::auto_ptr through a forwarding function using boost::ref) compiles fine on
4.1.2 and 4.2.3, but fails on 4.3.0 with the error:
ap_ref.cc: In function 'void g(reference_wrapperauto_ptrX )':
ap_ref.cc:23: error: no matching function for call to
'auto_ptrX::auto_ptr(auto_ptrX)'
ap_ref.cc:6: note: candidates are:
auto_ptrT::auto_ptr(auto_ptrT::auto_ptr_ref) [with T = X]
ap_ref.cc:5: note: auto_ptrT::auto_ptr(auto_ptrT) [with T
= X]
ap_ref.cc:23: error: initializing argument 1 of 'void f(auto_ptrX)'
This appears to be treating the result of the conversion operator in
reference_wrapperT as an rvalue of type T (which cannot initialise a
non-const reference) rather than as a non-const reference to T as specified,
and expected by the auto_ptr constructor.
I'm not 100% sure of the semantics of auto_ptr-related conversions and
copy-constructors with non-const arguments, so it's possible I've overlooked
something and the code which used to compile isn't actually valid. However
FWIW I've also tried it with Comeau, which seems to agree with the older gcc
versions and compiles it succesfully.
template typename T
class auto_ptr {
struct auto_ptr_ref { };
public:
auto_ptr(auto_ptr);
auto_ptr(auto_ptr_ref);
operator auto_ptr_ref();
};
template typename T
class reference_wrapper {
public:
reference_wrapper(T t);
operator T () const;
};
struct X { };
void f(auto_ptr X );
void g(reference_wrapper auto_ptr X r) {
f(r);
}
--
Summary: [4.3 regression] auto_ptr references don't convert
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zak at transversal dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35773
[Bug c++/31899] New: [4.2/4.3 regression] -g and using declaration causing ICE in reference_to_unused
The following code, compiled with -g, causes an ICE on 4.2.0 RC3 (20070501) and
on my most recent 4.3.0 snapshot build (20070427):
-
namespace NS {
int x = 0;
int ref = x;
}
using NS::ref;
-
test/ice.cc:6: internal compiler error: in reference_to_unused, at
dwarf2out.c:10128
This compiles cleanly with both 4.1.2 and 4.2.0 RC1 (20070316), suggesting that
this was exposed by a fairly recent patch.
Note that, in particular, this impacts code using Boost.Lambda in the following
style:
#include boost/lambda/lambda.hpp
using boost::lambda::_1;
...
--
Summary: [4.2/4.3 regression] -g and using declaration causing
ICE in reference_to_unused
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zak at transversal dot com
GCC build triplet: x86_64_pc_linux_gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64_pc_linux_gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31899
[Bug c++/31187] New: [4.2 regression] extern declaration of variable in anonymous namespace prevents use of its address as template argument
The following code, which compiles fine on gcc 4.1.2 and I believe is valid,
fails on an up-to-date checkout from the 4.2 branch:
--
class foo { };
namespace
{
extern foo foo1;
foo foo1;
}
template foo *
class bar { };
bar foo1 bar1;
---
giving the error:
test.cc:12: error: 'unnamed::foo1' is not a valid template argument of type
'foo*' because 'unnamed::foo1' does not have external linkage
test.cc:12: error: invalid type in declaration before ';' token
... which I would only expect if foo1 were declared static.
If I remove the line with the extern declaration, the code compiles again on
4.2.
--
Summary: [4.2 regression] extern declaration of variable in
anonymous namespace prevents use of its address as
template argument
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zak at transversal dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31187
[Bug c++/27177] [4.0 Regression] ICE in build_simple_base_path, at cp/class.c:474
--- Comment #8 from zak at transversal dot com 2006-08-18 11:21 ---
However, that patch breaks the following code, which requires *implicit*
derived-to-base conversion:
struct Z {};
struct A : Z {};
Z* implicitToZ (Z*);
struct B : A
{
static const int i = sizeof(implicitToZ((B*)0));
};
Without the patch, the above compiles cleanly (as it does in 4.0.3, 4.1.1 and
Comeau). With the patch, I get:
$ g++ -c dtob.cc
dtob.cc:8: error: invalid conversion from 'B*' to 'Z*'
dtob.cc:8: error: initializing argument 1 of 'Z* implicitToZ(Z*)'
The standard (in 4.10 [conv.ptr], paragraph 3) states that a program requiring
a derived-to-base conversion is ill-formed if the base class is inaccessible or
ambiguous; it does not mention any requirement that the derived class must be
complete.
This breaks code like this using boost::is_base_and_derived (this is cut down
from a real-world example):
#include boost/type_traits/is_base_and_derived.hpp
#include boost/static_assert.hpp
struct Base { };
template typename T
struct A {
BOOST_STATIC_ASSERT(( boost::is_base_and_derived Base, T ::value ));
struct Inner { };
};
struct Derived : Base {
typedef A Derived ::Inner Inner;
};
--
zak at transversal dot com changed:
What|Removed |Added
CC||zak at transversal dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27177
[Bug c++/26195] [4.0/4.1/4.2 regression] pragma interface no longer handles explicit names
--- Comment #9 from zak at transversal dot com 2006-03-01 15:57 --- The previous target milestone was 4.0.3 -- does the retargeting mean that this regression will not be fixed on that branch at all? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26195
[Bug c++/26195] [4.0/4.1/4.2 regression] pragma interface no longer handles explicit names
--- Comment #7 from zak at transversal dot com 2006-02-14 12:08 --- (We are currently using these pragmas extensively to ensure that various symbols are laid down *only* in low-level libraries, as a partial workaround for the COMDAT/dlopen issues described in http://gcc.gnu.org/ml/gcc/2004-10/msg01118.html) My patch doesn't touch the lbasename call used to create the implicit parameter to the directives (ie the one stored in ifiles and passed to interface_strcmp) -- so the path by which the file is included shouldn't affect the matching between pragmas without explicit parameters. The change only affects the filename passed to get_fileinfo. If a header is included in one place as [path1]/foo.h and in another as [path2]/foo.h, then there will be two c_fileinfo structs, but both will have processed the pragmas in the same way (and with the same implicit parameter foo.h), causing interface_only and interface_unknown to be identical in the two structs. Even if it was necessary, retaining the lbasename calls for the implicit case doesn't seem practical as the calls to get_fileinfo are made precisely to find out whether these pragmas are in effect (by looking at interface_only and interface_unknown) -- hence the argument to the call can't easily depend on those same pragmas. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26195
[Bug c++/26195] [4.0 regression] pragma interface no longer handles explicit names
--- Comment #4 from zak at transversal dot com 2006-02-13 18:46 --- Marking as 4.0 regression, filling in versions known to work/fail. Here is a patch, tested against mainline, which seems to fix this: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01002.html -- zak at transversal dot com changed: What|Removed |Added Keywords||patch Known to fail||4.0.3 4.1.0 4.2.0 Known to work||3.3.6 3.4.5 Summary|pragma interface no longer |[4.0 regression] pragma |handles explicit names |interface no longer handles ||explicit names http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26195
[Bug c++/26195] pragma interface no longer handles explicit names
--- Comment #1 from zak at transversal dot com 2006-02-10 15:00 --- I think the bug here is that handle_pragma_interface in gcc/cp/lex.c is calling get_file_info(filename), which refers to the name in the #pragma, rather than get_file_info(lbasename(input_filename)) -- hence it is updating the wrong c_fileinfo struct. This was changed here: http://gcc.gnu.org/viewcvs/branches/gcc-4_0-branch/gcc/cp/lex.c?r1=87774r2=87786diff_format=h Reverting that one line appears to fix the problem, although I haven't (yet) tested it extensively. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26195
[Bug c++/26195] pragma interface no longer handles explicit names
--- Comment #2 from zak at transversal dot com 2006-02-10 15:53 --- On thinking about this further, I don't understand the application of lbasename to the input_filename before it is passed to get_fileinfo. I included this for consistency with the code in cxx_make_type that checks for the interface_* settings. However, doesn't this mean that files included as file1.h, dir1/file1.h and dir2/file1.h will share the same c_fileinfo struct for these purposes? The calls to get_fileinfo(input_filename) in gcc/c-lex.c, by constrast, do not use lbasename. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26195
[Bug c++/26195] pragma interface no longer handles explicit names
--- Comment #3 from zak at transversal dot com 2006-02-10 17:05 ---
After making the change suggested in comment #1, the following test case
demonstrates the problem mentioned in comment #2.
$ g++ -Wall -pedantic -I. foo.cc nm -A foo.o
[no output]
If you switch the name in the pragma implementation directive to dir2/foo.h,
then the implementations of *both* headers are output:
foo.o: U __gxx_personality_v0
foo.o: W _ZN2A1C1Ev
foo.o: W _ZN2A1C2Ev
foo.o: W _ZN2A2C1Ev
foo.o: W _ZN2A2C2Ev
In 3.4.5, the implementation of the header with the matching pragma interface
directive is correctly output in each case.
I'm currently testing a patch that, in addition to the above change, removes
all the uses of lbasename in this context (two in decl.c, one in lex.c and one
in semantics.c, all in code specific to handling #pragma interface and
introduced in revision 87786).
// foo.cc
#pragma implementation dir1/foo.h
#include dir1/foo.h
// dir1/foo.h
#pragma interface dir1/foo.h
#include dir2/foo.h
struct A1
{
A1() { }
};
// dir2/foo.h
#pragma interface dir2/foo.h
struct A2
{
A2() { }
};
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26195
[Bug c++/26195] New: pragma interface no longer handles explicit names
If I compile the two files below, where the interface/implementation
relationship is based on an explicitly-given name rather than the basename of
the files, then no implementation appears to be produced.
This occurs on both the 4.0 branch and trunk, and is a regression against
3.4.5.
With 3.3.6:
$ g++-3.3 -c -Wall -pedantic pragii2.cc nm -A pragii2.o
pragii2.o: W _ZN1AC1Ev
pragii2.o: W _ZN1AC2Ev
With 3.4.5:
$ g++-3.4 -c -Wall -pedantic pragii2.cc nm -A pragii2.o
pragii2.o: W _ZN1AC1Ev
pragii2.o: W _ZN1AC2Ev
With recent 4.0 branch:
$ /opt/gcc-svn/gcc-4_0-branch/bin/g++ -c -Wall -pedantic pragii2.cc nm -A
pragii2.o
[no output]
With recent trunk:
$ /opt/gcc-svn/trunk/bin/g++ -c -Wall -pedantic pragii2.cc nm -A pragii2.o
[no output]
///
// pragii.h
#pragma interface pragii-imaginary.h
struct A
{
A() { }
};
///
/
// pragii2.cc
#pragma implementation pragii-imaginary.h
#include pragii.h
/
Failing compiler versions:
$ /opt/gcc-svn/gcc-4_0-branch/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4_0-branch/configure
--prefix=/opt/gcc-svn/gcc-4_0-branch --enable-threads --disable-libgcj
--enable-languages=c,c++
Thread model: posix
gcc version 4.0.3 20060209 (prerelease)
$ /opt/gcc-svn/trunk/bin/g++ -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../trunk/configure --prefix=/opt/gcc-svn/trunk
--enable-threads
Thread model: posix
gcc version 4.2.0 20060203 (experimental)
--
Summary: pragma interface no longer handles explicit names
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zak at transversal dot com
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=26195
[Bug libstdc++/26127] New: tr1/hashtable compile errors
There are a couple of minor errors in tr1/hashtable that cause some of the rarely-instantiated members defined in TR1 (http://open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf) not to compile, eg: std::tr1::unordered_set int s; s.key_eq();// Not declared: // error: 'class std::tr1::unordered_setint, std::tr1::hashint, // std::equal_toint, std::allocatorint, false' has no member // named 'key_eq' // (The function simply isn't there.) s.bucket(42); // Implementation fails to compile: // /opt/gcc-svn/trunk/lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/tr1/hashtable:1099: // error: no matching function for call to 'std::tr1::hashtableint, int, // std::allocatorint, Internal::identityint, std::equal_toint, // std::tr1::hashint, Internal::mod_range_hashing, // Internal::default_ranged_hash, Internal::prime_rehash_policy, false, false, // true::bucket_index(const int, unknown type, const size_t) const // (Missing parentheses on function call.) s.max_load_factor(); // /opt/gcc-svn/trunk/lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../include/c++/4.2.0/tr1/hashtable:656: error: base operand of '-' has non-pointer type 'const Internal::prime_rehash_policy' // (member access using - instead of .) The above applies to the 4.0 branch and current trunk. (Line numbers above are from trunk.) Patches to follow. -- Summary: tr1/hashtable compile errors Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zak at transversal dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26127
[Bug libstdc++/26131] New: TR1 unordered associative containers: insert with hint returns wrong type
The TR1 specification of insert(iterator, value_type) on unordered associative containers states that it returns an iterator (as for ordered associative containers). However the current implementation returns std::pairiterator,bool instead in the case of unique keys. Patch to follow. -- Summary: TR1 unordered associative containers: insert with hint returns wrong type Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zak at transversal dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26131
[Bug libstdc++/26132] New: tr1/hashtable: rehash not implemented
Attempting to call rehash produces a link error: std::tr1::unordered_set int s; s.rehash(42); // undefined reference to `std::tr1::hashtableint, int, std::allocatorint, // Internal::identityint, std::equal_toint, std::tr1::hashint, // Internal::mod_range_hashing, Internal::default_ranged_hash, // Internal::prime_rehash_policy, false, true, true::rehash(unsigned int)' -- Summary: tr1/hashtable: rehash not implemented Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zak at transversal dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26132
[Bug libstdc++/26131] TR1 unordered associative containers: insert with hint returns wrong type
--- Comment #2 from zak at transversal dot com 2006-02-06 15:18 --- Sorry, my mistake -- I thought I had checked this on both. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26131
[Bug target/18300] Infinite loop when passing object with 3+ base classes by value
--- Additional Comments From zak at transversal dot com 2004-11-12 16:33 --- Amended patch: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00948.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18300
[Bug target/18300] Infinite loop when passing object with 3+ base classes by value
--- Additional Comments From zak at transversal dot com 2004-11-10 12:36 --- I've submitted a patch which fixes this: http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00811.html -- What|Removed |Added Keywords||patch Known to fail|3.2.3 3.3.3 3.3.4 3.3.5 |3.2.3 3.3.3 3.3.4 3.3.5 ||3.4.2 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18300
[Bug target/18300] New: Infinite loop when passing object with 3+ base classes by value
On x86_64 (but not on i686) the following legal code sends gcc 3.2.3, 3.3.4 and
current 3.3-branch CVS into an infinite loop.
/
struct Base1 { };
struct Base2 { };
struct Base3 { };
struct Derived : Base1, Base2, Base3 { };
void foo(Derived);
int main()
{
foo(Derived());
}
//
The problem appears to be in classify_argument in gcc/config/i386.c: in both the
RECORD_TYPE and UNION_TYPE branches, the same loop variable (i) is used in two
nested loops. I'm not sure I fully understand this code, but it seems unlikely
that this is the intention. I'm also not sure if it's possible for this to
result in other failure modes besides the infinite loop, although it certainly
seems possible.
Using two distinct loop variables appears to fix the problem -- a patch will
follow after I've done testsuite runs on current CVS. (Looking at the source,
the above problem appears to still be present on the 3.4 branch and CVS HEAD,
although I've not tested there yet.)
--
Summary: Infinite loop when passing object with 3+ base classes
by value
Product: gcc
Version: 3.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zak at transversal dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18300
[Bug target/18300] Infinite loop when passing object with 3+ base classes by value
-- What|Removed |Added Keywords||compile-time-hog Known to fail||3.2.3 3.3.3 3.3.4 3.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18300
