[Bug c++/21656] New: Spurious template with C linkage error message
This test program:
# 1 test.cc
# 1 np.h 1
# 1 Math.h 1 3 4
templateclass T static inline void push(T* element, T** head)
{
element-m_flink = *head;
*head = element;
}
produces:
In file included from test.cc:2:
Math.h:1: error: template with C linkage
If I delete the # 1 Math.h 1 3 4 then it works.
Strangely enough, it also works on different builds of the same version: for
example, the native (i386) build, as well as a build targeted to
mipsel-netbsdelf, both accept the test program without complaint.
The failing compiler's --verbose output is:
mips64el-elf-g++ --verbose
Using built-in specs.
Target: mips64el-elf
Configured with: /buildarea/GCC40/gcc-4.0.0/configure
--prefix=/usr/local/EQLGCC_v7/mips64el --enable-languages=c,c++
--target=mips64el-elf --with-newlib --with-arch=sb1 --with-tune=sb1
--with-gnu-as --with-gnu-ld
Thread model: single
gcc version 4.0.0
--
Summary: Spurious template with C linkage error message
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pkoning at equallogic dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-unknown-netbsdelf1.6.2
GCC host triplet: i386-unknown-netbsdelf1.6.2
GCC target triplet: mips64el-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21656
[Bug target/21656] Spurious template with C linkage error message
--- Additional Comments From pkoning at equallogic dot com 2005-05-18 21:41 --- Thanks. I added that to config/mips/elf.h and it works correctly now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21656
[Bug c++/21631] New: Diagnostic for misdefined copy constructor is not particularly clear
If I define a copy constructor as T(T) rather than the correct T(const T), I'll end up with messages of the form: | keyed_obj.hh:159: error: no matching function for call to 'CxnIndex::CxnIndex(CxnIndex)' | Indeces.hh:150: note: candidates are: CxnIndex::CxnIndex(CxnIndex) which is baffling to most users because usually an argument of type T is acceptable for a call with a type T argument. It doesn't help that there isn't a call in the source code -- the compiler generated a copy constructor reference, for reasons that may not be obvious from reading the source. It would be helpful if the compiler could guide the user to the fix, perhaps by doing one or both of the following: a. Warn on the declaration of T(T) with a message along the lines of that looks like a copy constructor, but it really should be T(const T) b. In the message I quoted above, mention that a T(const T) is needed and was not supplied. -- Summary: Diagnostic for misdefined copy constructor is not particularly clear Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pkoning at equallogic dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i386-netbsd GCC host triplet: i386-netbsd GCC target triplet: mipsel-netbsdelf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21631
[Bug target/21472] New: Gcc generates CALL16 reloc that ld objects to
Compiling lib/csu/common_elf/crtbegin.c in the NetBSD 1.6.2 source tree with gcc 4.0.0 and binutils 2.16, I get complaints from ld: crtbeginS.o: CALL16 reloc at 0xfc not against global symbol The call16 is in the .s file generated by gcc, but I can't tell why it's any different from the others. Will attach .i and .s files (it would be nice if you could do that when entering a bug...) -- Summary: Gcc generates CALL16 reloc that ld objects to Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pkoning at equallogic dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i386-netbsdelf GCC host triplet: i386-netbsdelf GCC target triplet: mipsel-netbsdelf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21472
[Bug target/21472] Gcc generates CALL16 reloc that ld objects to
--- Additional Comments From pkoning at equallogic dot com 2005-05-09 16:30 --- Created an attachment (id=8845) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8845action=view) Preprocessed source file of the code that shows the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21472
[Bug target/21472] Gcc generates CALL16 reloc that ld objects to
--- Additional Comments From pkoning at equallogic dot com 2005-05-09 16:31 --- Created an attachment (id=8846) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8846action=view) Assembly file generated by gcc 4.0.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21472
[Bug c/21391] New: referencing a type via a cast does not emit it for debug
Test program:
struct foo
{
int i;
};
int bar (void)
{
return ((struct foo *)0x1234)-i;
}
Compile with -g; readelf does NOT show a definition of struct foo in the debug
data.
If I compile with -fno-eliminate-unused-debug-types, the definition does
appear, but in the example program, foo isn't unused.
--
Summary: referencing a type via a cast does not emit it for debug
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pkoning at equallogic dot com
CC: gcc-bugs at gcc dot gnu dot org
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=21391
[Bug c/21392] New: Wrong code generated for array of enum with mode attribute
Test code:
typedef enum { false, true } bool __attribute__((mode (byte)));
bool foo[16];
bool test (int i)
{
return foo[i];
}
This works with v3.3.3. With V4.0.0, the generated code is wrong -- it
references the array element as a word (4 bytes) yet indexes it as bytes. In
this particular test case, the generated code does unaligned loads (why is not
clear); in an example in my application where the bool array is on the stack, it
generated a regular word load, killing the program due to an unaligned access.
Presumably related: when I ask gdb what it thinks sizeof(foo[0]) is, I get 4
rather than the expected 1.
--
Summary: Wrong code generated for array of enum with mode
attribute
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pkoning at equallogic dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-unknown-netbsdelf1.6.2
GCC host triplet: i386-unknown-netbsdelf1.6.2
GCC target triplet: mipsel-netbsdelf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21392
[Bug c++/21369] New: Template function definition rejected if function return type begins with 'struct'
This test program:
struct bar;
template class T struct bar *foo (T *p)
{
return p-t;
}
produces an error in 4.0.0:
test.cc:3: error: 'bar' is not a template type
Without the keyword struct it compiles fine. Earlier versions
(3.3.2, and I'm pretty sure 3.4.1 as well) don't complain.
I've seen this on a native Linux build, and also a crosscompiler targeted at
netbsd-mips and hosted on i386-mips.
--
Summary: Template function definition rejected if function return
type begins with 'struct'
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pkoning at equallogic dot com
CC: gcc-bugs at gcc dot gnu dot org
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=21369
[Bug c++/21373] New: Strange error message on reference to static const member initialized via cast
Test program:
template class T class foo
{
public:
static const unsigned long long max = (T)~0ULL;
bool toobig (unsigned long long val)
{
return val max;
}
};
Message:
test.cc: In member function bool fooT::toobig(long long unsigned int):
test.cc:7: error: T used where a long long unsigned int was expected
The baffling part is that T doesn't occur anywhere in or near line 7. It's
almost as if the initialization part of the static const member has been
textually substituted in line 7 -- but if it were that should still be legal...
It works ok if I explicitly initialize the member outside the class definition
via specializations, which is tolerable given that only a small number of cases
of this template class are used.
--
Summary: Strange error message on reference to static const
member initialized via cast
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pkoning at equallogic dot com
CC: gcc-bugs at gcc dot gnu dot org
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=21373
