I notice that gcc 4.9 has the same issue, but that the gcc 4.9 release
notes say you should use "gcc-ar" instead of ar to make it work correctly
in conjunction with LTO (and similarly "gcc-ranlib" instead of ranlib).
In my testing, it seems to work correctly... so... maybe this bug should be
close
Package: gcc-snapshot
Version: 20131201-1
Severity: normal
With the most recent Debian gcc snapshot[1] and using the gold
linker[2], I'm getting linker "undefined reference" errors when
compiling with LTO. This only happens when the object file containing
the undefined symbol is stored in an .a
Matthias Klose writes:
>> Is there an official way to make ld.gold the default with the new
>> state of things, or is one expected to just manually change the
>> symlink in /usr/bin?
>
> yes, pass -fuse-ld=gold to the linker.
Right, I understand that method, I'm wondering how I can make it the
_d
Recent changes get rid of the binutils-gold package and put gold in
the normal binutils package. A side effect of this is that ld.bfd is
now the default, whereas ld.gold was the default with binutils-gold
install.
Is there an official way to make ld.gold the default with the new
state of things,
Matthias Klose writes:
>> I'm surprised. From what I see, copying of the GCC manual
>> components is covered by the GNU Free Documentation License,
>
> right, but including front and back cover texts and an invariant
> section, which unfortunately is not DFSG compliant.
>
>> Version 1.3. It's not
Package: g++-4.7
Version: 4.7-20120129-1
Severity: important
This one's easy to illustrate: :]
$ echo '#include ' > v.cc
$ g++-4.7 -c v.cc
v.cc:1:18: fatal error: vector: No such file or directory
compilation terminated.
$ g++-4.7 -v -c v.cc
Using built-in specs.
COLLECT_G
The Wanderer writes:
> Eh? How is this "wishlist"?
>
> The bug here is that it is possible, using only Debian-provided
> packages and the Debian dependencies system, to get the system into
> a state where it is not possible to compile modules for the
> currently-running kernel.
Wait, I'm confused
Ian Jackson writes:
>> The 486-class processors that would no longer be supported are:
>> 1. All x86 processors with names including '486'
>
> I'm still running the machine below, and it would be irritating to
> have to replace it.
...
> vendor_id : CentaurHauls
> cpu family: 6
> model
Samuel Bronson writes:
> We appreciate that the Debian project is even more zealous about free
> software than RMS himself, and recognize that the GFDL, when used with
> invariant sections and/or cover texts, is not totally free.
>
> Nevertheless, for practical reasons, we really do want that manu
Tsendrovskiy Vladislav writes:
> Gcc in package gcc-4.6 is compiled with i686 support. And it fails to
> run on i586 or k5 processor. And it's impossiple to recompile it, or any
> other package for this architecture besause it fails to compile
> anything.
Is this a bad thing? The i586 had its h
Philip Ashmore writes:
> "reference to a char *" should read "reference to a char * on the stack"
gcc does warn about obvious instances of this; do you know why it
doesn't in this case?
For instance in this case:
#include
char *f ()
{
char a[10];
return strcpy (a, "hello");
Philip Ashmore writes:
> It appears that gcc-4.6 (and clang for that matter) make some dodgy
> decisions about what appear to be references to temporaries created
> during optimization.
You don't seem to have addressed the issue raised by Matthias Klose in
the bug thread though: specifically, wh
Ludovic Rousseau writes:
> I found a strange bug I can't explain myself. I am not a C++ expert so
> maybe this construction is illegal.
...
> If my C++ construction is not supported by the language feel free to
> refer me to the C++ specification with details.
It looks like a bug in your program:
I sent a followup to a bug I had filed (#599572), and got the following
two emails in rapid succession.
I don't know how the forwarding for the gcc-snapshot package is
setup, but surely it's Not Good for bug reports to be sent to a
only-subscribers-can-post mailing list...?
Thanks,
-Miles
(1)
Package: gcc-snapshot
Version: 20100918-1
Severity: normal
There are many bugs in gcc's bugzilla related to bogus array-bounds
warnings, but most of them seem to involve non-trivial loops and other
situations that may need non-trivial analysis by the compiler.
By contrast, the appended code seem
Matthias Klose writes:
> Same in 4.4.
>
> libstdc++-v3/acinclude.m4:
> dnl Check for clock_gettime, nanosleep and sched_yield, used in the
> dnl implementation of 20.8.5 [time.clock], and 30.2.2 [thread.thread.this]
> dnl in the current C++0x working draft.
> dnl
> dnl --enable-libstdcxx-time
> dn
BTW, one thing I noticed is that the "error code" field in the
std::system_error exception which is raised, seems to be set to EPERM
("Operation not permitted"), but this code is not apparently caused by a
system call (determined by stracing the process).
For instance, changing the test case to th
Package: libstdc++6
Version: 4.5-20100227-1
Severity: normal
File: libstdc++
The following program:
#include
#include
int g = 0;
void f ()
{
g++;
}
int main ()
{
std::thread t (f);
t.join ();
std::cout << "after joing, g = " << g << std::endl;
return 0;
Is std::thread (only usable with g++-4.5 I think) known to be broken?
The following program:
#include
#include
int g = 0;
void f ()
{
g++;
}
int main ()
{
std::thread t (f);
t.join ();
std::cout << "after joing, g = " << g << std::endl;
return
Package: libstdc++6-4.5-dev
Version: 4.5-20100103-1
Severity: normal
The file "/usr/include/c++/4.5/x86_64-linux-gnu/bits/c++config.h"
doesn't seem to actually reflect the available facilities of the system.
In particular (from that file):
/* Defined if nanosleep is available. */
/* #und
Package: libstdc++6-4.5-dev
Version: 4.5-20100202-1
Severity: normal
The random-number distributions in C++0x include a special
"one-shot" facility, where the random bounds can be passed to the
generator function. This is explicitly intended (judging from committee
writings, and source comment
Package: libstdc++6-4.4-doc
Version: 4.4-20090329-1
Severity: normal
I see this error when trying to install manpages-dev; I'm not sure where
where the fault actually lies, but given that libstdc++6-4.4-doc is in
experimental, I'll report it here instead:
$ LANG=C sudo aptitude install
Re
"Vijaya Kumar B.H." <[EMAIL PROTECTED]> writes:
> I am trying to compile pthread application , but getting the following
> error . I think this is a bug in GCC libraries.
...
> connEntities[connid]->rcvWinFillMutex = PTHREAD_MUTEX_INITIALIZER;
It looks to me like your code is wrong -- PTHREAD_MUTE
BTW, I just tried the same test-case on a different machine -- and it
seems to work properly there (-march=native results in a correct default
value for -mtune).
The only real difference between the machines is that the previous
machine (where gcc showed the bug) has a pentium3 cpu, whereas the
cu
Package: gcc-4.2
Version: 4.2.2-3
Severity: normal
The option "-march=native" can be used to set the target architecture
from the current host (and "-mtune=native" should do the same thing for
tuning).
By my reading of the docs, "-march=native" should otherwise work just
like any other -march o
Package: gcj-4.2
Version: 4.2-20070405-1
Severity: normal
Trying to compile a very simple test program fails:
$ LANG=C gcj-4.2 -c Test.java
gcj-4.2: libgcj.spec: No such file or directory
Here's the simple test prog ftw:
public class Test
{
public static void main(String[]
Thiemo Seufer <[EMAIL PROTECTED]> writes:
>> Hi, I noticed that the "gcc-snapshot" package seems to have a lot of
>> rather dubious dependencies -- in particular, it depends on a bunch of
>> libraries from both gtk and qt4 (and x11 etc).
>
> I figure the java support may need that.
Both gtk _and_
Hi, I noticed that the "gcc-snapshot" package seems to have a lot of
rather dubious dependencies -- in particular, it depends on a bunch of
libraries from both gtk and qt4 (and x11 etc).
None of the actual binaries in the package seem to depend on any of
these libraries, so I'm curious why all tha
2005/11/19, Miles Bader <[EMAIL PROTECTED]>:
> Really? I only started using -frepo because my executable had become
> bloated, and it seemed to help quite a bit; I'll have to try again
> without...
Ok, I tried it without -frepo, and you're absolutely right -- the
bina
2005/11/19, Florian Weimer <[EMAIL PROTECTED]>:
> Thanks to the .gnu.linkonce sections, the finaly binary should be of
> the same size. Compilation time might increase, though.
Really? I only started using -frepo because my executable had become
bloated, and it seemed to help quite a bit; I'll h
2005/11/19, Steinar H. Gunderson <[EMAIL PROTECTED]>:
> BTW, you are _linking_ with -frepo as well, right?
I've tried both with and without [at link time], it doesn't seem to
affect the compiler's behavior.
-MIles
--
Do not taunt Happy Fun Ball.
I wrote earlier
> I've noticed that with recent updates, I'm suddenly getting tons of
> undefined function errors resulting from STL-related template
> instantiation. [I've attached an example at the end of this message.]
Er, any comments on this? It's driving me nuts that I now can't compile
my
32 matches
Mail list logo
