public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Is this code legal?
@ 2009-10-05 19:29 Sergey Sadovnikov
  2009-10-06 10:05 ` Paolo Bonzini
  0 siblings, 1 reply; 5+ messages in thread
From: Sergey Sadovnikov @ 2009-10-05 19:29 UTC (permalink / raw)
  To: gcc

Hello all.

I try to compile the following code sample:

(with MinGW gcc version 4.5.0 20090819 (experimental) (GCC))

#include <iostream>
#include <algorithm>
#include <array>

template<wchar_t... Chars>
struct Message
{
    std::array<wchar_t, sizeof ... (Chars)> m_Message;
    
    Message() : m_Message{Chars...}             // {*1}
    {
                std::array<wchar_t, sizeof ... (Chars)> msg = {Chars ... };     // {*2}
    }
};

int main(int argc, char* argv[])
{
    setlocale(LC_ALL, ".OCP");
        
    Message<L'\x421', L'\x20', L'\x434', L'\x43D', L'\x451', L'\x43C', L'\x20', L'\x43F', L'\x440', L'\x43E',
            L'\x433', L'\x440', L'\x430', L'\x43C', L'\x43C', L'\x438', L'\x441', L'\x442', L'\x430', L'\x2C', L'\x20', L'\x43A',
            L'\x43E', L'\x43B', L'\x43B', L'\x435', L'\x433', L'\x438', L'\x21', L'\n'
            > msg;
            
    std::for_each(msg.m_Message.begin(), msg.m_Message.end(), [](wchar_t c){std::wcout << c;});
            
    return 0;
}

Can anybody explain why line marked with '{*1}' produce this error
message:

hello_programmer.cpp: In constructor 'Message<Chars>::Message() [with wchar_t ...Chars = 1057u, 32u, 1076u, 1085u, 1105u
, 1084u, 32u, 1087u, 1088u, 1086u, 1075u, 1088u, 1072u, 1084u, 1084u, 1080u, 1089u, 1090u, 1072u, 44u, 32u, 1082u, 1086u
, 1083u, 1083u, 1077u, 1075u, 1080u, 33u, 10u]':
hello_programmer.cpp:48:15:   instantiated from here
hello_programmer.cpp:34:35: error: could not convert '{1057u, 32u, 1076u, 1085u, 1105u, 1084u, 32u, 1087u, 1088u, 1086u,
 1075u, 1088u, 1072u, 1084u, 1084u, 1080u, 1089u, 1090u, 1072u, 44u, 32u, 1082u, 1086u, 1083u, 1083u, 1077u, 1075u, 1080
u, 33u, 10u}' to 'std::array<wchar_t, 30u>'

Line marked with '{*2}' is compiled successfully.

Or there is no standard-conforming way to initialize std::array
within constructor initializer list?

-------------
Best regards, Sergey.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Is this code legal?
  2009-10-05 19:29 Is this code legal? Sergey Sadovnikov
@ 2009-10-06 10:05 ` Paolo Bonzini
  2009-10-06 18:59   ` Re[2]: " Sergey Sadovnikov
  2009-10-10 15:01   ` Linkage problem with rescent gcc 4.5 in MinGW build Sergey Sadovnikov
  0 siblings, 2 replies; 5+ messages in thread
From: Paolo Bonzini @ 2009-10-06 10:05 UTC (permalink / raw)
  To: Sergey Sadovnikov; +Cc: gcc

On 10/05/2009 09:29 PM, Sergey Sadovnikov wrote:
> Can anybody explain why line marked with '{*1}' produce this error
> message:

I think it's because there is no constructor for array that takes an 
initializer_list.  I get this message if I change your {*2} line to:

std::array < wchar_t, sizeof...(Chars) > msg({Chars...}); // {*2}

f.cc:12: error: no matching function for call to
  ‘std::array<wchar_t, 30ul>::array(<brace-enclosed initializer list>)’
tr1_impl/array:50: note: candidates are:
  std::array<wchar_t, 30ul>::array(const std::array<wchar_t, 30ul>&)
tr1_impl/array:50: note:
  std::array<wchar_t, 30ul>::array()

In general, this kind of question is best asked on a C++ forum.

Paolo

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re[2]: Is this code legal?
  2009-10-06 10:05 ` Paolo Bonzini
@ 2009-10-06 18:59   ` Sergey Sadovnikov
  2009-10-10 15:01   ` Linkage problem with rescent gcc 4.5 in MinGW build Sergey Sadovnikov
  1 sibling, 0 replies; 5+ messages in thread
From: Sergey Sadovnikov @ 2009-10-06 18:59 UTC (permalink / raw)
  To: Paolo Bonzini; +Cc: gcc

Hello, Paolo.

Tuesday, October 6, 2009 at 2:05:10 PM you wrote:

PB> On 10/05/2009 09:29 PM, Sergey Sadovnikov wrote:
>> Can anybody explain why line marked with '{*1}' produce this error
>> message:

PB> I think it's because there is no constructor for array that takes an 
PB> initializer_list.  I get this message if I change your {*2} line to:
No. I think it's because my version of gcc compiler was without
'Standard layout types' C++0x extension. There were no errors after I updated my trunk,
recompile gcc and then recompile the sample.

PB> In general, this kind of question is best asked on a C++ forum.
Probably you're right.

-- 
Best Regards,
 Sergey                          mailto:flex_ferrum@artberg.ru



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Linkage problem with rescent gcc 4.5 in MinGW build
  2009-10-06 10:05 ` Paolo Bonzini
  2009-10-06 18:59   ` Re[2]: " Sergey Sadovnikov
@ 2009-10-10 15:01   ` Sergey Sadovnikov
  2009-10-10 15:17     ` Kai Tietz
  1 sibling, 1 reply; 5+ messages in thread
From: Sergey Sadovnikov @ 2009-10-10 15:01 UTC (permalink / raw)
  To: gcc

Hello.

There is linkage problem with recent gcc 4.5 in MinGW configuration
build. Executables which are produced by gcc with default options set
treated as 'not a valid win32 application' by the system (Win2008 x64
server). After stripping with the 'strip' utility executables are
successfully ran. I suppose that problems in 'debug-xxx' sections
generated by the new gcc/linker.

I made the section dumps of the 'good' and 'bad' executable produced
by the gcc 4.4 and gcc 4.5 with the same options set. Here they are:

Section produced by gcc 4.4:
  0 .text         00009a2c  00401000  00401000  00000400  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
  1 .data         00000040  0040b000  0040b000  0000a000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  2 .rdata        000017c0  0040c000  0040c000  0000a200  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 .bss          00000b20  0040e000  0040e000  00000000  2**5
                  ALLOC
  4 .idata        0000051c  0040f000  0040f000  0000ba00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  5 .debug_aranges 00000060  00410000  00410000  0000c000  2**3
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_pubnames 00000076  00411000  00411000  0000c200  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_info   00000d4d  00412000  00412000  0000c400  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_abbrev 0000037c  00413000  00413000  0000d200  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_line   00000316  00414000  00414000  0000d600  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_frame  00000070  00415000  00415000  0000da00  2**2
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_loc    00000539  00416000  00416000  0000dc00  2**0
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_ranges 000000f8  00417000  00417000  0000e200  2**0
                  CONTENTS, READONLY, DEBUGGING


Sections produced by gcc 4.5:
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .debug_pubtypes 0000017c  00000000  00000000  000003d0  2**0
                  CONTENTS, READONLY, DEBUGGING
  1 .text         00009a2c  00401000  00401000  00000600  2**4
                  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
  2 .data         00000040  0040b000  0040b000  0000a200  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .rdata        000017c0  0040c000  0040c000  0000a400  2**5
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .bss          00000b20  0040e000  0040e000  00000000  2**5
                  ALLOC
  5 .idata        0000051c  0040f000  0040f000  0000bc00  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  6 .debug_aranges 000000e0  00410000  00410000  0000c200  2**3
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_pubnames 00000317  00411000  00411000  0000c400  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .debug_info   00002b04  00412000  00412000  0000c800  2**0
                  CONTENTS, READONLY, DEBUGGING
  9 .debug_abbrev 000008e2  00415000  00415000  0000f400  2**0
                  CONTENTS, READONLY, DEBUGGING
 10 .debug_line   00000882  00416000  00416000  0000fe00  2**0
                  CONTENTS, READONLY, DEBUGGING
 11 .debug_frame  000005f0  00417000  00417000  00010800  2**2
                  CONTENTS, READONLY, DEBUGGING
 12 .debug_str    0000007a  00418000  00418000  00010e00  2**0
                  CONTENTS, READONLY, DEBUGGING
 13 .debug_loc    00001e11  00419000  00419000  00011000  2**0
                  CONTENTS, READONLY, DEBUGGING
 14 .debug_ranges 00000198  0041b000  0041b000  00013000  2**0
                  CONTENTS, READONLY, DEBUGGING

As you can see there is two new debug sections ('.debug_pubtypes' and
'.debug_str') and .debug_pubtypes is the first section in the
executable.

gcc build configured with following options:
--prefix=/mingw-4.5 --host=mingw32 --target=mingw32 --program-prefix= --with-as=/mingw/bin/as.exe --with-ld=/mingw/bin/ld.exe --with-gcc --with-gnu-ld --with-gnu-as --enable-threads --disable-nls --enable-languages=c,c++ --disable-win32-registry --disable-shared --without-x --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug --with-gmp-include=/projects/common/GMP/4.3.1 --with-gmp-lib=/projects/common/GMP/4.3.1/.libs --with-mpfr-include=/projects/common/MPFR/2.4.1 --with-mpfr-lib=/projects/common/MPFR/2.4.1/.libs --enable-bootstrap

Because of I'm not a specialist in compilers and linkers so I can't
fix this problem by myself.

-- 
Best Regards,
 Sergey                          mailto:flex_ferrum@artberg.ru



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Linkage problem with rescent gcc 4.5 in MinGW build
  2009-10-10 15:01   ` Linkage problem with rescent gcc 4.5 in MinGW build Sergey Sadovnikov
@ 2009-10-10 15:17     ` Kai Tietz
  0 siblings, 0 replies; 5+ messages in thread
From: Kai Tietz @ 2009-10-10 15:17 UTC (permalink / raw)
  To: Сергей
	Садовников
  Cc: gcc

2009/10/10 Sergey Sadovnikov <flex_ferrum@artberg.ru>:
> Hello.
>
> There is linkage problem with recent gcc 4.5 in MinGW configuration
> build. Executables which are produced by gcc with default options set
> treated as 'not a valid win32 application' by the system (Win2008 x64
> server). After stripping with the 'strip' utility executables are
> successfully ran. I suppose that problems in 'debug-xxx' sections
> generated by the new gcc/linker.
>
> I made the section dumps of the 'good' and 'bad' executable produced
> by the gcc 4.4 and gcc 4.5 with the same options set. Here they are:
>
> Section produced by gcc 4.4:
>  0 .text         00009a2c  00401000  00401000  00000400  2**4
>                  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
>  1 .data         00000040  0040b000  0040b000  0000a000  2**2
>                  CONTENTS, ALLOC, LOAD, DATA
>  2 .rdata        000017c0  0040c000  0040c000  0000a200  2**5
>                  CONTENTS, ALLOC, LOAD, READONLY, DATA
>  3 .bss          00000b20  0040e000  0040e000  00000000  2**5
>                  ALLOC
>  4 .idata        0000051c  0040f000  0040f000  0000ba00  2**2
>                  CONTENTS, ALLOC, LOAD, DATA
>  5 .debug_aranges 00000060  00410000  00410000  0000c000  2**3
>                  CONTENTS, READONLY, DEBUGGING
>  6 .debug_pubnames 00000076  00411000  00411000  0000c200  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  7 .debug_info   00000d4d  00412000  00412000  0000c400  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  8 .debug_abbrev 0000037c  00413000  00413000  0000d200  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  9 .debug_line   00000316  00414000  00414000  0000d600  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  10 .debug_frame  00000070  00415000  00415000  0000da00  2**2
>                  CONTENTS, READONLY, DEBUGGING
>  11 .debug_loc    00000539  00416000  00416000  0000dc00  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  12 .debug_ranges 000000f8  00417000  00417000  0000e200  2**0
>                  CONTENTS, READONLY, DEBUGGING
>
>
> Sections produced by gcc 4.5:
> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>  0 .debug_pubtypes 0000017c  00000000  00000000  000003d0  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  1 .text         00009a2c  00401000  00401000  00000600  2**4
>                  CONTENTS, ALLOC, LOAD, READONLY, CODE, DATA
>  2 .data         00000040  0040b000  0040b000  0000a200  2**2
>                  CONTENTS, ALLOC, LOAD, DATA
>  3 .rdata        000017c0  0040c000  0040c000  0000a400  2**5
>                  CONTENTS, ALLOC, LOAD, READONLY, DATA
>  4 .bss          00000b20  0040e000  0040e000  00000000  2**5
>                  ALLOC
>  5 .idata        0000051c  0040f000  0040f000  0000bc00  2**2
>                  CONTENTS, ALLOC, LOAD, DATA
>  6 .debug_aranges 000000e0  00410000  00410000  0000c200  2**3
>                  CONTENTS, READONLY, DEBUGGING
>  7 .debug_pubnames 00000317  00411000  00411000  0000c400  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  8 .debug_info   00002b04  00412000  00412000  0000c800  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  9 .debug_abbrev 000008e2  00415000  00415000  0000f400  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  10 .debug_line   00000882  00416000  00416000  0000fe00  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  11 .debug_frame  000005f0  00417000  00417000  00010800  2**2
>                  CONTENTS, READONLY, DEBUGGING
>  12 .debug_str    0000007a  00418000  00418000  00010e00  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  13 .debug_loc    00001e11  00419000  00419000  00011000  2**0
>                  CONTENTS, READONLY, DEBUGGING
>  14 .debug_ranges 00000198  0041b000  0041b000  00013000  2**0
>                  CONTENTS, READONLY, DEBUGGING
>
> As you can see there is two new debug sections ('.debug_pubtypes' and
> '.debug_str') and .debug_pubtypes is the first section in the
> executable.
>
> gcc build configured with following options:
> --prefix=/mingw-4.5 --host=mingw32 --target=mingw32 --program-prefix= --with-as=/mingw/bin/as.exe --with-ld=/mingw/bin/ld.exe --with-gcc --with-gnu-ld --with-gnu-as --enable-threads --disable-nls --enable-languages=c,c++ --disable-win32-registry --disable-shared --without-x --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug --with-gmp-include=/projects/common/GMP/4.3.1 --with-gmp-lib=/projects/common/GMP/4.3.1/.libs --with-mpfr-include=/projects/common/MPFR/2.4.1 --with-mpfr-lib=/projects/common/MPFR/2.4.1/.libs --enable-bootstrap
>
> Because of I'm not a specialist in compilers and linkers so I can't
> fix this problem by myself.
>
> --
> Best Regards,
>  Sergey                          mailto:flex_ferrum@artberg.ru
>
>
>
>

The issue is the '>  0 .debug_pubtypes 0000017c  00000000  00000000
000003d0  2**0' ...
This bug was fixed on binutils and is a spec file issue. Please update
binutils to a more recent version.

Cheers,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2009-10-10 15:10 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-10-05 19:29 Is this code legal? Sergey Sadovnikov
2009-10-06 10:05 ` Paolo Bonzini
2009-10-06 18:59   ` Re[2]: " Sergey Sadovnikov
2009-10-10 15:01   ` Linkage problem with rescent gcc 4.5 in MinGW build Sergey Sadovnikov
2009-10-10 15:17     ` Kai Tietz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).