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
--- 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
--- 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 compiler
--- 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
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
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,
++
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 << &quo
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 (0
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
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
li
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.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348
Nach changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID
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++ curre
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
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 use
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
16 matches
Mail list logo
