`wide-exec-charset` dose not change the charset of `wchar_t` - c++

Here is the simple C++ code.
#include <iostream>
#include <locale>
int main() {
std::wcout.sync_with_stdio(false);
std::wcout.imbue(std::locale(""));
std::cout << std::locale("").name() << std::endl; // C.UTF-8
wchar_t s {L'\xd0b8'};
std::wcout << s << std::endl;
// expected: и
// actual: 킸
}
'\xd0b8' is и in UTF-8 and is 킸 in UTF-16
The reference mentioned:
The encoding of narrow multibyte string literals (1) and wide string literals (2) is implementation-defined. For example, gcc selects them with the commandline options -fexec-charset and -fwide-exec-charset.
I complied and executed the code with g++ -O3 -fwide-exec-charset=UTF-8 source.cc -o out.a && out.a in Ubuntu 20.04.1 LTS (WSL) and expected the output is и, however, the actual output is 킸. g++ doesn't treat the hex in the literal string which was used to directly initialize the wide char s. How to make g++ consider the wide char in UTF-8?
System Infomation:
> lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.1 LTS
Release: 20.04
Codename: focal
> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.3.0-10ubuntu2' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2)

man gcc says
-fwide-exec-charset=charset
Set the wide execution character set, used for wide string and character
constants. The default is UTF-32 or UTF-16, whichever corresponds to the width
of "wchar_t". As with -fexec-charset, charset can be any encoding supported by
the system's "iconv" library routine; however, you will have problems with
encodings that do not fit exactly in "wchar_t".
UTF-8 is a multi-byte encoding which does not fit exactly in wchar_t. So you've got exactly what is specified in the documentation: problems. Since sizeof(wchar_t) on Linux is 4, you need to specify a 4-bytes-wide encoding such as UTF-32.
There is no real reason to use wchar_t for anything except interfacing with legacy code anyway.

Related

Specify thread model on ubuntu mingw (if possible)

Im running a program on linux with g++ and everything works fine. If i compile using x86_64-w64-mingw32-g++ it crashes with error: ‘std::thread’ has not been declared.
The part where my code crashed is fairly simple:
#include <thread>
int main()
{
int cores = std::thread::hardware_concurrency();
}
I figured out that mingw uses win32 threads, i want it to use posix threads. Version is:
:~$ x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/9.3-win32/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --with-headers=/usr/x86_64-w64-mingw32/include --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto --enable-threads=win32 --program-suffix=-win32 --program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32 --with-as=/usr/bin/x86_64-w64-mingw32-as --with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic --enable-libstdcxx-filesystem-ts=yes --enable-dependency-tracking
Thread model: win32
gcc version 9.3-win32 20200320 (GCC)
As you can see thread model is win32, (how) can i change it? In the mingw include paths there is a 9.3-posix folder, but it seems it isnt used so far.
As you can see here you can:
I'm installing mingw-w64 on Windows and there are two options: win32 threads and posix threads.
Is that possible on linux aswell?
It seems that the package g++-mingw-w64-x86-64 provides two executables:
x86_64-w64-mingw32-g++-posix: which uses posix
x86_64-w64-mingw32-g++-win32: which uses win32
Using the first executable should solve your issue.

C++11 used by default? [duplicate]

This question already has answers here:
How do I check for C++11 support?
(9 answers)
Closed 4 years ago.
How can I know whether c++11 is used by default in my g++ compiler? My OS is ubuntu 18.04.1.
zell#ubuntu:~$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.3.0-27ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.3.0 (Ubuntu 7.3.0-27ubuntu1~18.04)
It is--one resource out there is gcc/g++ web page on C++ status and standards:
g++ 4.8.1 and above support C++11 and I recall g++-7 having it as default
and I had seen that stated on that page before but I am not seeing it now...
g++ 6.1 and above default to C++14 as per the page
You can of course switch and make explicit choices with the usual -std=... flag.
My way (no compiler dependand): compile and run the following program
#include <iostream>
int main()
{ std::cout << __cplusplus << std::endl; }
You'll get (supposing a standard compliant compiler)
"199711", for C++98
"201103", for C++11
"201402", for C++14
"201703", for C++17

Prefer sysroot headers over headers in the toolchain using gcc

I'm trying to cross-compile a simple code snippet
1 #include <sys/socket.h>
2 #include <stdio.h>
3
4 int main()
5 {
6 printf("%d\n", SOL_NETLINK);
7 return 0;
8 }
with arm-linux-gnueabihf-g++ (from Ubuntu) against Raspbian sysroot with --sysroot switch set to $SYSROOT
The compilation fails with this error:
test.cpp:6:20: error: ‘SOL_NETLINK’ was not declared in this scope
Even though $SYSROOT/usr/include/arm-linux-gnueabihf/bits/socket.h contains
the needed define.
So I figured that toolchain contains the mentioned header as well and it's included first. The latter header somehow doesn't have this SOL_NETLINK define. So I need a way to tell the compiler to prefer the toolchain's headers to sysroot's ones.
> arm-linux-gnueabihf-g++ -v
Using built-in specs.
COLLECT_GCC=arm-linux-gnueabihf-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-cross/arm-linux-gnueabihf/5/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-5 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-armhf-cross --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-armhf-cross --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libgcj --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-linux-gnueabihf --program-prefix=arm-linux-gnueabihf- --includedir=/usr/arm-linux-gnueabihf/include
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.4)
#include <sys/socket.h> will include a file which is under the folder {include path}/sys/socket.h.
Include path can be any folder that you add with various options like gcc -I or --includedir. In addition there are some default include path, which you should be able to see with gcc -xc++ -E -v -.
Using gcc "-I" option will put the include path to search first, before any of the default include paths.
Now, this should give you enough information to understand that the include you give can't point to the file $SYSROOT/usr/include/arm-linux-gnueabihf/bits/socket.h as it isn't end with {include path}/sys/socket.h
Use -isystem flag with $SYSROOT/usr/include/arm-linux-gnueabihf
Albeit GCC can resolve triple (arm-linux-gnueabihf part) in the path, but it won't do so with --sysroot option.

Why can the same code be compiled successfully through gcc while not g++?

The following test.c can be compiled successfully by using gcc compiler:
$ cat test.c
#include <complex.h>
int main(void) {
double complex a = 0;
return 0;
}
$ gcc -o test1 test.c
$
While after changing the name to test.cpp, and compile it with g++ compiler, there is an error:
$ cat test.cpp
#include <complex.h>
int main(void) {
double complex a = 0;
return 0;
}
$ g++ -o test2 test.cpp
test.cpp: In function ‘int main()’:
test.cpp:4:20: error: expected initializer before ‘a’
double complex a = 0;
^
Why can the same code be compiled successfully through gcc while not g++?
P.S. My compiler versions:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 6.2.1 20160830 (GCC)
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/6.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --enable-libmpx --with-system-zlib --with-isl --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-gnu-indirect-function --disable-multilib --disable-werror --enable-checking=release
Thread model: posix
gcc version 6.2.1 20160830 (GCC)
The basic reason is that C and C++ support complex numbers in fundamentally different ways, which are code incompatible. So C code which uses complex variables, and operations on them, cannot be used in any version of C++, and vice versa.
In C++ (all versions) complex arithmetic is supported by a templated class named complex, which is defined in header <complex>, and is in namespace std. Since it is a C++ (templated) class in namespace std, which C does not support at all, this type and the C++ header <complex> cannot be used in C.
Standard C, before 1999, did not support complex variables or arithmetic. In C (since 1999), complex arithmetic is supported using a _Complex keyword, and a convenience macro complex (#defined in <complex.h>) which uses it. C++ does not support the _Complex keyword or <complex.h>.
$ cat test.cpp
#include <complex>
int main(void) {
std::complex<double> a = 0;
return 0;
}
In C++, complex is a template, here is the reference std::complex.
For C++ Complex type : http://en.cppreference.com/w/cpp/numeric/complex
For C Complex type: How to work with complex numbers in C?
The Complex.h works differently in C and C++

gdb error message: DW_OP_reg, DW_OP_piece, and DW_OP_bit_piece

I'm debugging somebody else's Qt program and ran into the following error message which I don't understand:
DWARF-2 expression error: DW_OP_reg operations must be used either alone or in
conjuction with DW_OP_piece or DW_OP_bit_piece.
I'm not sure what that means and Google isn't of much help.
Here's the context - sLocation is a QString that was declared a few lines earlier. However, it was created from functions which were inlined, so I'm not sure of its value and am attempting to check before being appended to:
(gdb) printqstring suffix
(QString)0xffffbd80: "sorted"
(gdb) next
1241 sLocation += suffix;
(gdb) printqstring sLocation
Can't take address of "sLocation" which isn't an lvalue.
(gdb) info local
sLocation = <error reading variable sLocation (DWARF-2 expression error:
DW_OP_reg operations must be used either alone or in conjuction with
DW_OP_piece or DW_OP_bit_piece.)>
Could somebody please explain what that error message means or what could cause it?
The error message means that GDB is reading DWARF2 debug info from the executable, and is rejecting that info as invalid (not following the DWARF2 standard).
The invalid info is likely due to a bug in GCC, fixed in SVN revision 147187:
2009-05-06 Jakub Jelinek <jakub#redhat.com>
* dwarf2out.c (new_reg_loc_descr): Don't ever create DW_OP_regX.
(one_reg_loc_descriptor): Create DW_OP_regX here instead of calling
new_reg_loc_descr.
(loc_by_reference): If loc is DW_OP_regX, change it into DW_OP_bregX 0
instead of appending DW_OP_deref*.
I got the same problem running a Ubuntu 10.10 64bit. However, the same code on a 10.04 LTS 32bit works perfectly.
Here is the version output of both setups
Ubuntu 10.10:
$ gcc -v
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
GCC on 10.04 LTS:
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.4.3-4ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --program-suffix=-4.4 --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i486 --with-tune=generic --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5
Cheers,
Andre