[Bug c++/19404] [4.0 Regression] anonymous types and templates and rejecting valid code
--- Additional Comments From lars at trolltech dot com 2005-04-08 14:36
---
Hi Mark,
(In reply to comment #3)
> This code is invalid. The use of ">>" requires the instantiation of the
> declaration of the overloaded "operator>>", but that instantiation fails
because
> one of the template argument is anonymous.
I don't see why the code is invalid. If you leave out the forward declaration
of the template operator everything compiles fine, as the values in the
anonymous enum get cast to integers, and the builtin operator>>(int, int)
applies.
So this compiles just fine (and to the correct code as far as I can tell):
enum { HSize = 6, HMask = 0x3f, VMask = HMask << HSize };
int verData(unsigned int data){ return (int)( (data & VMask) >> HSize ); }
while this doesn't:
class Base;
template
inline Base const& operator>>(Base const& rConfiguration, Type& rType) ;
enum { HSize = 6, HMask = 0x3f, VMask = HMask << HSize };
int verData(unsigned int data){ return (int)( (data & VMask) >> HSize ); }
The types in the forward declaration have no connection whatsoever with the
values in the anonymous union, so the template should not apply.
Lars
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19404
[Bug c++/19404] [4.0 Regression] anonymous types and templates and rejecting valid code
--- Additional Comments From lars at trolltech dot com 2005-04-08 16:35 --- Subject: Re: [4.0 Regression] anonymous types and templates and rejecting valid code On Friday 08 April 2005 17:34, mark at codesourcery dot com wrote: > --- Additional Comments From mark at codesourcery dot com 2005-04-08 > 15:34 --- Subject: Re: [4.0 Regression] anonymous types and templates > and rejecting valid code > > lars at trolltech dot com wrote: > > --- Additional Comments From lars at trolltech dot com 2005-04-08 > > 14:36 --- Hi Mark, > > > > (In reply to comment #3) > > > >>This code is invalid. The use of ">>" requires the instantiation of the > >>declaration of the overloaded "operator>>", but that instantiation fails > > > > because > > > >>one of the template argument is anonymous. > > > > I don't see why the code is invalid. If you leave out the forward > > declaration of the template operator everything compiles fine, as the > > values in the anonymous enum get cast to integers, and the builtin > > operator>>(int, int) applies. > > Lars -- > > As I said earlier in the thread, there is now an open DR about this > issue. So, it might be resolved either way, eventually. Sorry, I didn't see the connection clearly. I was just wondering as we got a few bug reports about compile failures using Qt with gcc 4. > But, what the standard says at present is that you do overload > resolution on both operators. That requires that you instantiate their > declarations, and the instantiation of the one using anonymous enums is > invalid. There's nothing in the standard that says that you discard > instantiations that don't work -- except in cases of SFINAE. And SFINAE > does not let you ignore all errors, as some people think; it's a very > specific set. I haven't read the standard to that level I have to admit :) But if this invalid instantiation can't be ignored it seems to mean to me that one can not use any anonymous enum in C++ (better in a C++ header), as you would get compile errors as soon as someone uses a template to overload an operator that happens to be used together with values in the enum. Cheers, Lars -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19404
[Bug c/22432] New: Wrong code generation using MMX intrinsics on amd64
The following example generates wrong code when compiled with -O2 on amd64. It
doesn't seem to happen when compiling in 32bit mode though.
#include
#include
typedef unsigned int CARD32;
static void
mmxCombineAddU (CARD32 *dest, const CARD32 *src, int width)
{
const __m64 mmx_0 = _mm_setzero_si64();
const CARD32 *end = dest + width;
while (dest < end) {
__m64 s, d;
s = _mm_unpacklo_pi8 (_mm_cvtsi32_si64(*src), mmx_0);
d = _mm_unpacklo_pi8 (_mm_cvtsi32_si64(*dest), mmx_0);
s = _mm_add_pi16(s, d);
*dest = (CARD32)_mm_cvtsi64_si32(_mm_packs_pu16(s, mmx_0));
++dest;
++src;
}
_mm_empty();
}
int main()
{
CARD32 a = 0x;
CARD32 b = 0x10101010;
mmxCombineAddU(&a, &b, 1);
assert(a == 0x);
return 0;
}
The compiled assembler for the mmx instructions looks like this:
400555: 0f 6e 00movd (%rax),%mm0
400558: 0f 60 capunpcklbw %mm2,%mm1
40055b: 0f 60 c2punpcklbw %mm2,%mm0
40055e: 0f fc c1paddb %mm1,%mm0
400561: 0f 67 c3packuswb %mm3,%mm0
400564: 0f 7e 00movd %mm0,(%rax)
It should use paddw instead of paddb here.
best regards,
Lars
--
Summary: Wrong code generation using MMX intrinsics on amd64
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lars at trolltech dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: linux-amd64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22432
[Bug c++/21476] New: g++ puts read only data into the .data section
Hi,
in the following small example program, g++ puts the constant data into
the .data section and not into .rodata as it should. It works just fine with
the C frontend. This is a regression from at least 3.3/3.4.
Cheers,
Lars
[EMAIL PROTECTED] rodata]$ cat main.c
const char rodata[] = "Hello World";
const char * foo() { return rodata; }
[EMAIL PROTECTED] rodata]$ g++ -c main.c
[EMAIL PROTECTED] rodata]$ objdump -h main.o
main.o: file format elf64-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 000b 0040 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 000c 004c 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 0058 2**2
ALLOC
3 .eh_frame 0048 0058 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
4 .comment 0028 00a0 2**0
CONTENTS, READONLY
5 .note.GNU-stack 00c8
2**0
CONTENTS, READONLY
[EMAIL PROTECTED] rodata]$ gcc -c main.c
[EMAIL PROTECTED] rodata]$ objdump -h main.o
main.o: file format elf64-x86-64
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 000b 0040 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 004c 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 004c 2**2
ALLOC
3 .rodata 000c 004c 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .eh_frame 0038 0058 2**3
CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
5 .comment 0028 0090 2**0
CONTENTS, READONLY
6 .note.GNU-stack 00b8
2**0
CONTENTS, READONLY
--
Summary: g++ puts read only data into the .data section
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lars at trolltech dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21476
[Bug c++/19199] New: Wrong warning about returning a reference to a temporary
Hi,
The code below produces a warning about returning a reference to a temporary
when using enum types for the qMin method. It works fine when using primitive
types or classes instead of enums.
Fortunately it's rather easy to work around the warning :)
Best regards,
Lars
enum Foo { A, B };
template const T &qMin(const T &a, const T &b)
{ return a < b ? a : b; }
int main(int, char **)
{
Foo f = A;
Foo g = B;
Foo h = qMin(f, g);
return 0;
}
--
Summary: Wrong warning about returning a reference to a temporary
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: lars at trolltech dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19199
