[Bug c++/29473] New: -masm=intel combined with -march=athlon64 has some issues.
je .L4
mov %rax, QWORD PTR SMode(%rip)
cmp %rax, 1
jne .L2
.L4:
mov BYTE PTR [%rbp-1], 1
jmp .L6
.L2:
mov BYTE PTR [%rbp-1], 0
.L6:
movzx %eax, BYTE PTR [%rbp-1]
leave
ret
I don't know AMD64 assembly well but "Keep4_3Ratio(%rip)" and the like doesn't
look right to me.
If I add -O3 so the line becomes:
g++ -O3 -march=athlon64 -masm=intel -o test.o -c test.cpp
I get "cmp" bugs instead of "mov" and I also get the "rep ret" bug from above
when using GCC 4.1 (but not 4.0).
My 64 bit compilers:
Using built-in specs.
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,java
--prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.0.4 20060904 (prerelease) (Debian 4.0.3-7)
Target: x86_64-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-mpfr --enable-checking=release
x86_64-linux-gnu
Thread model: posix
gcc version 4.1.2 20060928 (prerelease) (Debian 4.1.1-15)
I've conducted this test on two different PCs, one running WinXP SP2, and the
other Debian Unstable.
--
Summary: -masm=intel combined with -march=athlon64 has some
issues.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nachms+gcc at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473
[Bug c++/29473] -masm=intel combined with -march=athlon64 has some issues.
--- Comment #1 from nachms+gcc at gmail dot com 2006-10-14 21:43 ---
Oh I just realized one statement of mine was ambiguous.
>I get "cmp" bugs instead of "mov" and I also get the "rep ret" bug from above
when using GCC 4.1 (but not 4.0).
I mean to say that when using a 64 bit GCC 4.0, I do not get that "rep ret" bug
even with -O3, but I still get errors such as: "Error: invalid operand for
'cmp' ('(' unexpected)"
-Nach
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473
[Bug c++/29473] -masm=intel combined with -march=athlon64 has some issues.
--- Comment #2 from nachms+gcc at gmail dot com 2006-10-14 21:51 --- Oh another thing. If I change return(Keep4_3Ratio && (DSMode == 1 || SMode == 1)); to: return((DSMode == 1 || SMode == 1) && Keep4_3Ratio); The "rep ret" problem in the 32 bit compilers go away for some strange reason. However when doing this, the assembly outputted seems very messy and unoptimized to me. -Nach -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473
[Bug target/29473] -masm=intel combined with -march=athlon64 has some issues.
--- Comment #7 from nachms+gcc at gmail dot com 2007-05-20 10:46 --- I just tested against: Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2 --program-suffix=-4.2 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --disable-werror --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.2.1 20070516 (prerelease) (Debian 4.2-20070516-1) This problem still exists. -- nachms+gcc at gmail dot com changed: What|Removed |Added Severity|normal |major Version|4.1.2 |4.2.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29473
[Bug preprocessor/55971] New: Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971
Bug #: 55971
Summary: Preprocessor macros with C++11 raw string literals
fail to compile
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nachms+...@gmail.com
It does not seem possible to create a macro which contains a C++ raw string
literal, when it should be.
Example:
-
#include
#define CREATE_CLIENTS R"(CREATE TABLE "clients"(
"clientId" INTEGER PRIMARY KEY AUTOINCREMENT,
"clientName" VARCHAR(64) UNIQUE
))"
int main()
{
std::cout << CREATE_CLIENTS << std::endl;
return 0;
}
-
g++ -W -Wall -o test test.cpp -std=c++11
test.cpp:3:24: error: unterminated raw string
test.cpp:6:3: warning: missing terminating " character [enabled by default]
test.cpp:6:1: error: missing terminating " character
test.cpp:10:3: error: stray ‘R’ in program
test.cpp:4:3: error: expected unqualified-id before string constant
On the other hand, clang seems to be able to handle it:
clang++ -W -Wall -o test test.cpp -std=c++11
./test
CREATE TABLE "clients"(
"clientId" INTEGER PRIMARY KEY AUTOINCREMENT,
"clientName" VARCHAR(64) UNIQUE
)
[Bug preprocessor/55971] Preprocessor macros with C++11 raw string literals fail to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55971 --- Comment #2 from Nach 2013-01-14 15:47:25 UTC --- Does look similar. Although this bug here is in the definition of the macro, while that bug is in the call of the macro. I'm sure they're related, but it'd be a shame if one was fixed, and the other was overlooked.
[Bug libstdc++/60348] New: -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
Bug ID: 60348
Summary: -static-libstdc++ broken
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: nachms+gcc at gmail dot com
-static-libstdc++ does not seem to be working anymore.
Consider this following test application:
-
#include
#include
int main()
{
std::string s;
if (s.empty()) { std::cout << "String is empty!" << std::endl; }
return(0);
}
-
g++ -Wall -o test test.cpp -static-libgcc -static-libstdc++
"test" here should not contain any references to libstdc++ symbols as it is
being linked statically, however, "objdump -T test" contains the following:
006915c0 uDO .bss 0020 Base
_ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE
00691600 uDO .bss 0020 Base
_ZNSs4_Rep20_S_empty_rep_storageE
These are both symbols from libstdc++ that should have been staticaly linked,
yet they are now undefined, and indeed, this binary will not run on a system
without a sufficiently up to date libstdc++ installed.
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-16'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--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-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --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.8.2 (Debian 4.8.2-16)
GNU ld (GNU Binutils for Debian) 2.24
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #2 from Nach --- (In reply to Richard Biener from comment #1) > It works for me. What does ldd test show? Do you have the static > libstdc++/libgcc installed (Debian may package those separately?) ldd test linux-gate.so.1 (0xf76ff000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7676000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf765a000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf74e7000) /lib/ld-linux.so.2 (0xf770) Recompiling with -static-libgcc added gives: 00690bc0 uDO .bss 0020 Base _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE 00690c00 uDO .bss 0020 Base _ZNSs4_Rep20_S_empty_rep_storageE And ldd: linux-vdso.so.1 (0x7011e000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fecae56b000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fecae1c2000) /lib64/ld-linux-x86-64.so.2 (0x7fecae8b1000) I also want to confirm that I indeed have the static libstdc++ and libgcc installed. Furthermore, I've compiled huge C++ projects which use at least a dozen std::string methods, iostream, a ton of STL, and these are the only two symbols that are missing when using -static-libstdc++. Without -static-libstdc++, a lot of other libstdc++ symbols are now present in objdump, for example: DF *UND* GLIBCXX_3.4 _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #4 from Nach --- (In reply to Marc Glisse from comment #3) > man nm: > >"U" The symbol is undefined. > >"u" The symbol is a unique global symbol. This is a GNU > extension [...] > > The program does run fine for me with exactly the same compiler on debian. > > How did it fail to run for you, with what error message? The issue isn't that it can't run on a machine with a proper libstdc++ installed, the issue is that -static-libstdc++ is broken, meaning the binary cannot run on a system without libstdc++ installed (or a too old version). Trying to run the Debian compiled binary on RHEL5 is giving me: ./test: symbol lookup error: ./test: undefined symbol: _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE And on RHEL5 system: objdump -T ./test | grep _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE 00690c00 DO .bss 0020 Base _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE Where on Debian it gives: 00690c00 uDO .bss 0020 Base _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE In the past when -static-libstdc++ was working, binaries ran just fine on older systems.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #6 from Nach --- > Does compiling with: -fuse-ld=gold -Wl,--no-gnu-unique > help? Seems like your old system (ld.so?) gets confused by the new feature. Doing so, there are no longer any "u" symbols appearing with objdump, nor those libstdc++ symbols appearing anywhere. Now, other systems are properly running the binary.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #7 from Nach --- Upon further testing, -fuse-ld=gold by itself without -Wl,--no-gnu-unique appears to get the job done.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 Nach changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #10 from Nach --- While you may be marking this as invalid, isn't there a serious issue here? Shouldn't -static-libstdc++ work without any special flags? Also, using -fuse-ld=gold seems to be breaking any application I have which links to non-system libraries.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #12 from Nach --- Isn't the whole point of -static-libstdc++ is to remove the dependency of libstdc++ from the binary? Even without the option, it does indeed work fine on the system it was compiled on. However, -static-libstdc++ currently does not appear to be doing its job, and I would NOT define it as *working*. For nearly 8 years I've been able to provide ready made binaries for practically any system (as long as glibc wasn't ancient). Now after a recent upgrade of build utilities, I can't seem to provide binaries for anyone who isn't using a distro from the past year or so. Even though these are large projects and make use of many statically linked binaries, the culprit as reported is missing libstdc++ symbols which in theory should not be happening if -static-libstdc++ is used, and the two aforementioned symbols are the only libstdc++ I see listed in the binary. Using older build utilities, I've never seen any libstdc++ symbols appear in a binary when -static-libstdc++ was used. Adding -fuse-ld=gold appears to be a *workaround* which works for the sample test case I used above. But if I try using -fuse-ld=gold with more complicated projects, the binary never even ends up linking, with a whole spew of missing symbols, which I know for a fact are contained in libraries which are being specified. If this in fact a bug with binutils and not libstdc++ or GCC, then fine, I don't mind reporting it elsewhere, just please assist me in understanding the issue so I can effectively do so.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #14 from Nach --- (In reply to Richard Biener from comment #13) > If you want to target old dynamic linkers then you have to disable support > for GCC features that exploit features of new dynamic linkers. You > need to rebuild GCC to achieve that and provide --disable-gnu-unique-object > at configure time to disable the use of unique object glibc dynamic linker > extension. Okay thank you. Just one last question then, was there a specific version of GCC (and friends) that began using the glibc dynamic linker extension? Or to put it differently, how can I define whether a system has support for this extension? A certain minimum version of glibc?
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #17 from Nach --- I just tried my above test case on RHEL6 without an up to date libstdc++ but with glibc 2.12, and the binary runs just fine. I double checked my old build system which does not produce these symbols, and I see it uses the following: Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-4' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --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.6.3 (Debian 4.6.3-4) Note the --enable-gnu-unique-object. Also the system uses glibc 2.13. Any reason why this old build setup does not use these glibc unique symbols even though every indication is that it should?
[Bug c++/57854] Would like to have a warning for virtual overrides without C++11 "override" keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57854 Nach changed: What|Removed |Added CC||nachms+gcc at gmail dot com --- Comment #6 from Nach --- (In reply to Jonathan Wakely from comment #2) > (In reply to Thiago Macieira from comment #0) > > > > It should be in -Weffc++. > > Not unless a new C++11 edition of Effective C++ recommends using override on > all overriding functions, and not unless we update -Weffc++ to correspond to > something other than the first edition. > Modern Effective C++ Item 12 is that every virtual derived function should make use of the override keyword. Therefore, -Weffc++ should now include this new warning.
