I've seen this today both for alpha and s390 cross from x86_64:
> libtool: compile: /home/rth/work/gcc/bld-s390/./gcc/xgcc -shared-libgcc
> -B/home/rth/work/gcc/bld-s390/./gcc -nostdinc++
> -L/home/rth/work/gcc/bld-s390/s390x-linux/libstdc++-v3/src
> -L/home/rth/work/gcc/bld-s390/s390x-linux/l
Hello Everyone,
The Cilk-Plus branch is feature-complete. Programs using Cilk Plus
constructs get great performance on vector and multicore hardware. Programs
that don't use the new language features (enabled by a -fcilkplus flag) see no
change. For details please see http://cilkplus.org
gcc-python-plugin is a plugin for GCC 4.6 onwards which embeds the
CPython interpreter within GCC, allowing you to write new compiler
warnings for C/C++ in Python, generate code visualizations, etc. It
comes with "cpychecker": a tool for static analysis tool of CPython
extensions.
Tarball release
On 8/29/12, Gabriel Dos Reis wrote:
> On Aug 29, 2012 Ian Lance Taylor wrote:
> > Does this seem like something we could usefully add to GCC?
>
> Emphatically, yes!.
Seconded!
> Does anybody see any big problems with it?
>
> Can it would be a great addition to libstdc++ as a GNU extension,
> st
Dunno if alpha is going to be the only glibc port to encounter this, if it
should be considered a gcc bug, or what.
Without this patch, using mainline gcc, I get
./../include/libc-symbols.h:485:26: error: ‘__EI___isnanf’ aliased to external
symbol ‘__GI___isnanf’
extern __typeof (name) __EI_
On Thu, Aug 30, 2012 at 1:04 AM, Florian Weimer wrote:
> On 08/29/2012 09:22 AM, Ian Lance Taylor wrote:
>
>> It uses the GCC unwind interface to collect a stack trace, and parses
>> DWARF debug info to get file/line/function information. (Of course it's
>> silly to write yet another DWARF reader
On 8/30/12, Gabriel Dos Reis wrote:
> On Aug 30, 2012 Richard Henderson wrote:
> > On 08/27/2012 11:58 AM, Lawrence Crowl wrote:
> > > > > I wonder if the second discriminator support is easily
> > > > > generalizable to enabling any derived class being a root
> > > > > class on it own with its o
On 8/30/12, Richard Henderson wrote:
> On 08/27/2012 11:58 AM, Lawrence Crowl wrote:
>>> I wonder if the second discriminator support is easily generalizable
>>> to enabling any derived class being a root class on it own with its
>>> own subtree? If I understand correctly, the GTY syntax would be
On Thu, Aug 30, 2012 at 11:57 AM, Richard Henderson wrote:
> On 08/27/2012 11:58 AM, Lawrence Crowl wrote:
>>> > I wonder if the second discriminator support is easily generalizable
>>> > to enabling any derived class being a root class on it own with its
>>> > own subtree? If I understand correct
On 08/27/2012 11:58 AM, Lawrence Crowl wrote:
>> > I wonder if the second discriminator support is easily generalizable
>> > to enabling any derived class being a root class on it own with its
>> > own subtree? If I understand correctly, the GTY syntax would be the
>> > same.
> If I understand corr
Hello,
I'm not sure about such errors should be reported, but I will try.
Host compiler: gcc-4.7.1-MinGW-x86_64
x86_64-w64-mingw32-g++ -c -O2 -pipe -fomit-frame-pointer
-momit-leaf-frame-pointer -DIN_GCC -fno-exceptions -fno-rtti -W
-Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wmissing
On 30 August 2012 13:43, Nikos Fotoulis wrote:
> Hi.
>
> The cxx-conversion idea does not come without its
> cons. The most important for us is that there will
> not be a plain gcc-core package that is smaller,
The GCC project doesn't make gcc-core tarballs any more anyway.
Third-party packagers
On 08/30/2012 01:43 PM, Nikos Fotoulis wrote:
> The cxx-conversion idea does not come without its cons. The most
> important for us is that there will not be a plain gcc-core package
> that is smaller, builds faster a plain C compiler with a smaller
> binary and is able to bootstrap future version
Hi.
The cxx-conversion idea does not come without its
cons. The most important for us is that there will
not be a plain gcc-core package that is smaller,
builds faster a plain C compiler with a smaller
binary and is able to bootstrap future versions
of a plain C compiler made of the latest vesion
Hi,
I am having issues trying to install GCC (3.0.4) on SCO 5.0.7 i386.
I downloaded gcc-3.0.4.tar.gz from "http://ftp.gnu.org/gnu/gcc/gcc-3.0.4/";, I
then tried untarring the file, by: `gzip -dc gcc-3.0.4.tar.gz | tar xAvf - >
file-list 2>&1`
And that showed me a bunch of files, but no VOLS s
On 08/29/2012 08:40 PM, Toon Moene wrote:
On 08/29/2012 06:21 PM, Ian Lance Taylor wrote:
The DWARF reader calls malloc and is therefore not async-signal safe.
It also is a problem if the crash in the program is due to overwriting
the malloc heap administration (which easily occurs in Fortran
On 08/29/2012 09:22 AM, Ian Lance Taylor wrote:
It uses the GCC unwind interface to collect a stack trace, and parses
DWARF debug info to get file/line/function information. (Of course it's
silly to write yet another DWARF reader, but I didn't find an existing
reader that seemed wholly suitable
17 matches
Mail list logo
