The SC has appointed Ben Elliston as maintainer of the Decimal
Floating-Point components of the compiler, including relevant portions
of the front ends, libraries, etc.
Ben, please update MAINTAINERS to reflect your expanded role.
Thanks!
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 33
Andrew Haley wrote:
> Yuri Pudgorodsky writes:
> >
> > > We can say something like:
> > >
> > > "In GNU C, you may cast a function pointer of one type to a function
> > > pointer of another type. If you use a function pointer to call a
> > > function, and the dynamic type of the function po
[EMAIL PROTECTED] writes:
> I am getting the following compilation error:
>
> /tmp/ccIUvX3i.o(.gnu.linkonce.d._ZTV4ListIiE+0x8): undefined reference to
> `List::Find(int const&)'
Wrong mailing list. This sort of question should go to
[EMAIL PROTECTED] Thanks.
I don't know the answer to your q
On Wed, Jul 12, 2006 at 02:04:37AM +0100, Tristan Wibberley wrote:
> If the programmer had intended that the type should appear to not exist.
> it wouldn't be defined in a header #include-able by client code. The
GCC doesn't know if the header is includable by client code; I assume
that's the us
On Sun, 9 Jul 2006, Roger Sayle wrote:
Interesting. Richard Guenther's post for the above change, which was
based upon a previous proposal by Brian Makin, suggested that this
patch reduced the compile-time of his tramp3d benchmark by 1%.
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00294.html
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mike Stump wrote:
> On Jul 11, 2006, at 7:18 AM, Laurynas Biveinis wrote:
>> I don't know how many yet, as testsuite takes more than 24 hours
>> here on Cygwin, 1.8GHz Turion. I can run it much faster inside in
>> VMWare on Linux on the same machin
Hi :
I am getting the following compilation error:
/tmp/ccIUvX3i.o(.gnu.linkonce.d._ZTV4ListIiE+0x8): undefined reference to
`List::Find(int const&)'
the declaration is:
virtual int Find (const Etype &X);
and the definition is:
template
int
List::Find (const Etype &X){
Node
Jason Merrill wrote:
It seems that you have a different mental model of type visibility. The
way I was thinking about it, if a type has hidden visibility, we can't
refer to it from outside its object. Thus, it doesn't make sense for
members or objects with that type to have greater visibilit
Daniel Berlin <[EMAIL PROTECTED]> writes:
[...]
| > libelf (0.8.5-35)
|
| This libelf is too old, see michael matz's message.
Which one is it?
-- Gaby
On Jul 11, 2006, at 7:18 AM, Laurynas Biveinis wrote:
I don't know how many yet, as testsuite takes more than 24 hours
here on Cygwin, 1.8GHz Turion. I can run it much faster inside in
VMWare on Linux on the same machine.
Is there any way to speed it up on Cygwin?
Sure, install Linux. :-)
Benjamin Smedberg wrote:
Jason, I'm sorry to email you directly, as I don't know which email list
I should be discussing on. I've built gcc trunk after your visibility
patch landed, and there are some serious issues with compiling Mozilla now:
Take the following code:
class __attribute__ ((vi
Jakub Jelinek <[EMAIL PROTECTED]> writes:
| > Should that read
| >
| >#include
|
| No, because on other systems it is directly in /usr/include:
| rpm -qf /usr/include/libelf.h
| elfutils-libelf-devel-0.119-1.2.1
| and there is no /usr/include/libelf/ directory.
| Guess GCC configure should
Gabriel Dos Reis wrote:
> Hi,
>
> My first attempt to compile the lto branch met with resistance:
>
> /home/gdr/redhat/lto.gcc/gcc/lto/lto-elf.c:27:20: error: libelf.h: No such
> file or directory
>
>
> libelf (0.8.5-35)
This libelf is too old, see michael matz's message.
You are going to
On Tue, Jul 11, 2006 at 11:13:11PM +0200, Gabriel Dos Reis wrote:
> lto/lto-elf.c:27 currently says
>
>#include "libelf.h"
>
>
> Should that read
>
>#include
No, because on other systems it is directly in /usr/include:
rpm -qf /usr/include/libelf.h
elfutils-libelf-devel-0.119-1.2.1
an
Hi,
My first attempt to compile the lto branch met with resistance:
/home/gdr/redhat/lto.gcc/gcc/lto/lto-elf.c:27:20: error: libelf.h: No such file
or directory
libelf (0.8.5-35) is installed on my system in the standard include
directory (/usr/include) as libelf/libelf.h.
lto/lto-elf.c
On Thu, Jul 06, 2006 at 10:48:50PM +0200, FX Coudert wrote:
> I'd like to include cases in the gfortran testsuite to check that we
> correctly issue a run-time error, and exit with non-zero code.
>
> I have the following example:
>
> $ cat runtime_error.f90
> ! { dg-do run }
> ! { dg-options "-f
> See PR 28290 (the errors) and PR 28217 (the ICE). Both were reported
> before the actual
> bootstrap issue.
Paolo's patch for 28290 is now in.
I don't know what to do about the ICE: it looks like Mike has a patch.
Temporary workaround is to configure with --disable-libstdcxx-pch.
-benjamin
"Rodney M. Bates" <[EMAIL PROTECTED]> writes:
> I don't understand this. A pointer to anywhere in an activation record
> (or even outside it, if outside by a fixed offset) allows access to
> exactly the same set of things as any other, including the value the base
> register holds when the activa
On 11 July 2006 16:36, truelies wrote:
> Up!
Off! .
What part of
"Please note this is NOT, I repeat NOT, a GCC users list - this is a GCC
developers list. For user general questions, post to GCC - Help."
don't you get?
cheers,
DaveK
--
Can't think of a witty .sigline today..
Up!
--
View this message in context:
http://www.nabble.com/How-to-deal-with-1.-IND--tf1862819.html#a5271851
Sent from the gcc - Dev forum at Nabble.com.
Hi,
This patch does three things:
1) Fix broken --with-gc=page. Now it is possible to build GCC with
these two collectors from exactly same sources.
2) Boehms's GC makes GCC print collector warnings time from time about
very large blocks being allocated. These warnings are meaningless, so
they a
Ian Lance Taylor wrote:
"Rodney M. Bates" <[EMAIL PROTECTED]> writes:
The following example C code and disassembly is compiled by gcc 3.4.3,
for i686. It uses two different invariants for what the value of
a static link is. Everywhere inside P, static link values are consistently
the same
> I successfully bootstrapped yesterday and have been very few
> patches recently.
I ran into a similar problem on SPARC/Solaris on Sunday morning (revision
115296). The same tree bootstrapped fine on AMD64/Linux.
--
Eric Botcazou
> Andreas Schwab writes:
Andreas> Mike Stump <[EMAIL PROTECTED]> writes:
>> /Volumes/mrs3/net/gcc-darwin/powerpc-apple-darwin8.5.0/libstdc++-v3/
>> include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp:235: internal
>> compiler error: Bus error
>> Please submit a full bug report,
>> with prep
On Jul 11, 2006, at 8:51 PM, Gerald Pfeifer wrote:
Is it possible the new bootstrap failure (log below) I started seeing
within the last 24 hours is related to the following patch?
This is not that new, in fact the only reason why Ben's patch exposes
it is because
it was make was not stopp
Is it possible the new bootstrap failure (log below) I started seeing
within the last 24 hours is related to the following patch?
2006-07-10 Benjamin Kosnik <[EMAIL PROTECTED]>
PR libstdc++/15448
* include/Makefile.am: Clean up pch rules.
* include/Makefile.in: Regener
jacob navia writes:
> Hi
>
> I have now everything in place for dynamically register the
> debug frame information that my JIT (Just in time compiler)
> generates.
>
> I generate a CIE (Common information block), followed by
> a series of FDE (Frame Description Entries) describing
> each
Joern RENNECKE schrieb:
In http://gcc.gnu.org/ml/gcc/2006-07/msg00156.html, your wrote:
We could use a cheap hash and base start compare / branch trees in
every hash bin.
Say we have a 16 k range, 200 nodes, and want to keep the hash
bin/node ratio between 2 and 4.
Let i be the switch argume
Mike Stump <[EMAIL PROTECTED]> writes:
> /Volumes/mrs3/net/gcc-darwin/powerpc-apple-darwin8.5.0/libstdc++-v3/
> include/ext/pb_ds/detail/binary_heap_/binary_heap_.hpp:235: internal
> compiler error: Bus error
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See http:
Since I got advised both for and against adding a ChangeLog entry, I'm
inclined to leave things as they are for now unless somebody beats me
to it.
--
Thanks,
Laurynas
30 matches
Mail list logo
