On Mon, Oct 09, 2006 at 08:22:25PM -0700, Mark Mitchell wrote:
> Kaveh R. GHAZI wrote:
> >Has there been any thought to including GMP/MPFR in the GCC repository
> >like we do for zlib and intl?
>
> I do not think we should be including more such packages in the GCC
> repository. It's complicated
Kaveh R. GHAZI wrote:
Has there been any thought to including GMP/MPFR in the GCC repository
like we do for zlib and intl?
I do not think we should be including more such packages in the GCC
repository. It's complicated from an FSF perspective and it bloats our
software. GCC is a complicate
Hi,
I would like to reopen the discussion for pr/15795, or at least get
clarification on the current resolution of WONTFIX.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795
Let me state right at the beginning that I am also volunteering to do
the actual work to come up with an agreed solution an
Joseph S. Myers wrote:
On Mon, 9 Oct 2006, Brooks Moses wrote:
I would like to propose that a "make pdf" target be added to the GCC general
makefile.
I agree. If you look at the current GNU Coding Standards you'll see a
series of targets {,install-}{html,dvi,pdf,ps} and associated directorie
Dear Steering Committee,
We, Sony Computer Entertainment, would like to contribute a port for a
new target, the Cell SPU, and seek acceptance from the Steering
Committee to do so.
(David Edelsohn indicated that before submitting patches we should
request acceptance for the new port from the Steer
On Mon, 9 Oct 2006, Brooks Moses wrote:
> I would like to propose that a "make pdf" target be added to the GCC general
> makefile.
I agree. If you look at the current GNU Coding Standards you'll see a
series of targets {,install-}{html,dvi,pdf,ps} and associated directories
for installation.
Robert Dewar wrote:
I would think it perfectly reasonable for the S/390 to be
considered a primary platform on the popularity basis
Another, technical, reason to consider the s390x to be a primary
platform is that it is a different 64-bit big-endian target.
I always watch the test-result ou
Basile STARYNKEVITCH wrote:
>
> How does one get the source location (e.g. start and end filename,
> linenumber, ...) of a tree node;
You can use the same code as in tree-vectorizer.h:
#ifdef USE_MAPPED_LOCATION
typedef source_location LOC;
#define UNKNOWN_LOC UNKNOWN_LOCATION
#define EXP
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
> How does one get the source location (e.g. start and end filename,
> linenumber, ...) of a tree node; for example, the source position of every
> loop inside current_loops or of every function body inside cgraph_nodes?
> for these nodes, doing EXP
I would like to propose that a "make pdf" target be added to the GCC
general makefile.
I did a search to see if there was any previous discussion on this, and
what I found were a few messages from 1999 and 2001 that seemed to imply
that it might be a good idea, and even included a partial patc
On Mon, 9 Oct 2006, Mike Stump wrote:
> On Oct 8, 2006, at 1:42 PM, Kaveh R. GHAZI wrote:
> > It turned out to be much easier than I thought to decipher the top level
> > machinery and get GMP/MPFR building inside the GCC tree. :-)
>
> Some thoughts, if this configures and builds most (all?) of t
On Oct 8, 2006, at 1:42 PM, Kaveh R. GHAZI wrote:
It turned out to be much easier than I thought to decipher the top
level
machinery and get GMP/MPFR building inside the GCC tree. :-)
Some thoughts, if this configures and builds most (all?) of the time,
then we are changing the portability
Dear All
(sorry for such a naive question, I am a beginner within GCC)
How does one get the source location (e.g. start and end filename,
linenumber, ...) of a tree node; for example, the source position of every
loop inside current_loops or of every function body inside cgraph_nodes?
for these
Peter,
Thanks. This problem was holding up the testing of the
libffi i386 Darwin patch because Sandro has a non-EMT64
MacBook Pro. He had to resort to --disable-multi.
Jack
ps If I understand this issue correctly, even if the automake
maintainers accepted the patc
On Oct 9, 2006, at 9:27 PM, Jack Howarth wrote:
Geoff,
Can you point me to the proposed patch in the gcc-patches
mailing list archives? I can't seem to find it.
http://lists.gnu.org/archive/html/automake-patches/2006-09/msg00027.html
It's automake -patches.
Peter
Hi Robert,
On Mon, Oct 09, 2006 at 08:21:45AM -0400, Robert Dewar wrote:
> >In the criteria for primary plattforms I've read that primary plattforms
> >have to be "popular systems". Reading this as "widely used" I think that
> >this will be a requirement which mainframes are unlikely to meet in th
Geoff,
Can you point me to the proposed patch in the gcc-patches
mailing list archives? I can't seem to find it.
Jack
On Sun, Oct 08, 2006 at 10:24:36PM -0700, Geoffrey Keating wrote:
>
> I believe trying to disable the multilib is fundamentally the wrong
> approach.
In the criteria for primary plattforms I've read that primary plattforms
have to be "popular systems". Reading this as "widely used" I think that
this will be a requirement which mainframes are unlikely to meet in the
near future, so I propose to make s390 and s390x secondary plattforms for
now. I
On Oct 9, 2006, at 2:24 PM, Geoffrey Keating wrote:
Jack Howarth <[EMAIL PROTECTED]> writes:
Shouldn't configure in gcc be made to
automatically test if -m64 is working on
the build machine in question and automatically
invoke --disable-multilib if not? Currently
on Darwin for example we h
Hello Everyone,
> In the criteria for primary plattforms I've read that primary plattforms
> have to be "popular systems". Reading this as "widely used" I think that
> this will be a requirement which mainframes are unlikely to meet in the
> near future, so I propose to make s390 and s390x seconda
20 matches
Mail list logo
