hi,
What might be functional specifications for a GCC porting
project.Output format and ABI might be included in functional
specification.
For writing a compiler from scratch ,funcional specifications are
quite clear ,but for porting GCC what should be included in funcional
specification doc
On Oct 31, 2006, Paul Brook <[EMAIL PROTECTED]> wrote:
> In my experience the first thing you do bringing up a new system is build a
> cross compiler and use that to build glibc and coreutils/busybox. This is all
> done on an established host that has gmp/mpfr ported to it.
> Bootstrapping a nat
"Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
> Should that message refer to this:
> ftp://gcc.gnu.org/pub/gcc/infrastructure/
>
> or this:
> ftp://ftp.gnu.org/gnu/gmp/
> http://www.mpfr.org/mpfr-current/
>
> or this (perhaps with more details):
> http://gcc.gnu.org/install/prerequisites.html
Th
On Tue, 31 Oct 2006, Joe Buck wrote:
> On Mon, Oct 30, 2006 at 10:07:39PM -0800, Mark Mitchell wrote:
> > I don't believe there's a serious problem with the concept, as long as
> > "./configure; make; make install" for GMP DTRT. If you can do it for
> > GCC, you can do it for a library it uses to
Geoffrey Keating wrote:
do you think this is likely to be:
1. some problem in gmp or mpfr,
2. some problem in my build of gmp and/or mpfr, that wouldn't occur if
I'd built it in some other (unspecified) way,
3. some problem in my existing system configuration, maybe I already
have a gmp instal
>
> > So, now if I tell you that despite all reports that it 'works fine',
> > I'm getting
> >
> > > FAIL: gcc.dg/torture/builtin-sin-mpfr-1.c -O0 (test for excess
> > > errors)
> >
> > do you think this is likely to be:
> > 1. some problem in gmp or mpfr,
> > 2. some problem in my build o
> So, now if I tell you that despite all reports that it 'works fine',
> I'm getting
>
> > FAIL: gcc.dg/torture/builtin-sin-mpfr-1.c -O0 (test for excess
> > errors)
>
> do you think this is likely to be:
> 1. some problem in gmp or mpfr,
> 2. some problem in my build of gmp and/or mpfr, th
On 31/10/2006, at 7:45 AM, Mark Mitchell wrote:
Geoffrey Keating wrote:
OK, I agree: a native compiler, with no special options, isn't
too hard. I don't think typing that sequence twice would be too
hard either, though. :-)
For something that's not too hard, it's sure causing me a lot of
I'm about to start merging into the trunk a bunch of small patches,
all of which have been previously posted to gcc-patches with a
notation like 'on hold for 4.3'. I plan to do it as a sequence of
commits; I will send out a final message to gcc-patches listing the
ChangeLog entries of the
Greg Schafer <[EMAIL PROTECTED]> writes:
> Mark Mitchell wrote:
>
> > I don't believe there's a serious problem with the concept, as long as
> > "./configure; make; make install" for GMP DTRT. If you can do it for
> > GCC, you can do it for a library it uses too.
>
> Just another data point.
Mark Mitchell wrote:
> I don't believe there's a serious problem with the concept, as long as
> "./configure; make; make install" for GMP DTRT. If you can do it for
> GCC, you can do it for a library it uses too.
Just another data point.
I tried building GMP on an i686-pc-linux-gnu Ubuntu sys
On Oct 31, 2006, at 12:49 PM, Igor Bukanov wrote:
-- Forwarded message --
From: Igor Bukanov <[EMAIL PROTECTED]>
Date: Oct 31, 2006 9:48 PM
Subject: Re: return void from void function is allowed.
To: Mike Stump <[EMAIL PROTECTED]>
On 10/31/06, Mike Stump <[EMAIL PROTECTED]> wr
-- Forwarded message --
From: Igor Bukanov <[EMAIL PROTECTED]>
Date: Oct 31, 2006 9:48 PM
Subject: Re: return void from void function is allowed.
To: Mike Stump <[EMAIL PROTECTED]>
On 10/31/06, Mike Stump <[EMAIL PROTECTED]> wrote:
This is valid in C++.
My copy of 1997 C++ pu
On Oct 31, 2006, at 12:21 PM, Igor Bukanov wrote:
GCC 4.1.2 and 4.0.3 incorrectly accepts the following program:
void f();
void g()
{
return f();
}
No warning are issued on my Ubuntu Pentium-M box. Is it a known bug?
If you want one:
mrs $ gcc-4.2 -ansi -pedantic-errors t.c
t.c: In funct
On 31 October 2006 20:21, Igor Bukanov wrote:
> GCC 4.1.2 and 4.0.3 incorrectly accepts the following program:
>
> void f();
>
> void g()
> {
> return f();
> }
>
> No warning are issued on my Ubuntu Pentium-M box. Is it a known bug?
>
> Regards, Igor
Yep. PR 5678. This patch worked f
GCC 4.1.2 and 4.0.3 incorrectly accepts the following program:
void f();
void g()
{
return f();
}
No warning are issued on my Ubuntu Pentium-M box. Is it a known bug?
Regards, Igor
On Oct 31, 2006, at 11:52 AM, Andrew Pinski wrote:
#define vector __attribute__((vector_size(16) ))
vector int f(vector int, vector unsigned int);
int g(void)
{
vector int t;
vector int t1;
vector unsigned int t2;
t2 = f(t,t1);
}
Our 3.3 compiler gives:
t.c:10: error: incompatible ty
>
> On Oct 31, 2006, at 10:47 AM, Mark Shinwell wrote:
> > What do others think?
>
> My only concern is that we have tons of customers with tons of code
> and you don't have any and that you break their code. I don't have
> any idea if this would be the case or not, I don't usually do the
Hello gcc-hackers,
Tracking down a gcse bug while unrolling a loop where the count is known to
be one, I've narrowed the problem down to the actions of
commit_edge_insertions and bypass_conditional_jumps, and I could use a little
help in appreciating the reasoning behind what they're /tryi
On Tuesday 31 October 2006 19:02, Mike Stump wrote:
> On Oct 31, 2006, at 10:47 AM, Mark Shinwell wrote:
> > What do others think?
>
> My only concern is that we have tons of customers with tons of code
> and you don't have any and that you break their code. I don't have
> any idea if this would b
> > and that you break their code.
>
> ...is more of a concern, I agree, and is what I worry about most.
The other question how of this was accepted in 3.4.0 or earlier because
the behavior changed in 4.0.0 with respect of accepting these code.
Thanks,
Andrew Pinski
>
> Recently I proposed that implicit conversions between vectors with
> differing numbers of elements yet the same total bitlength be disallowed.
> It was agreed that this was reasonable, and I shall be submitting a
> patch to vector_types_convertible_p and the testsuite in the near future.
>
>
Ian Lance Taylor wrote:
Mark Shinwell <[EMAIL PROTECTED]> writes:
I would now like to propose that the check in that function be made
even stronger such that it disallows conversions between vectors
whose element types differ -- even if an implicit conversion exists
between those element types.
On Oct 31, 2006, at 10:47 AM, Mark Shinwell wrote:
What do others think?
My only concern is that we have tons of customers with tons of code
and you don't have any and that you break their code. I don't have
any idea if this would be the case or not, I don't usually do the
vector bugs.
Mark Shinwell <[EMAIL PROTECTED]> writes:
> I would now like to propose that the check in that function be made
> even stronger such that it disallows conversions between vectors
> whose element types differ -- even if an implicit conversion exists
> between those element types.
As far as I can s
On Oct 29, 2006, at 9:49 PM, Tom Tromey wrote:
Mike> libjava/configure
I updated (svn trunk) and re-ran autoconf here, and didn't see any
change.
Hum, I don't know off-hand if your autoconf 2.59 isn't quite 2.59, or
mine is strange, or I'm getting some sort of cross pollution or you
are.
Recently I proposed that implicit conversions between vectors with
differing numbers of elements yet the same total bitlength be disallowed.
It was agreed that this was reasonable, and I shall be submitting a
patch to vector_types_convertible_p and the testsuite in the near future.
I would now li
Joe Buck <[EMAIL PROTECTED]> writes:
[...]
| We do want to make it as easy as we can make it to allow non-gurus to
| build from source, because we'll get a lot more testing that way. That
| said, I agree that an automatic download is inappropriate.
|
| However, if we detect at configure time th
Basile STARYNKEVITCH <[EMAIL PROTECTED]> writes:
> The GGCC (ITEA) project aims to extend the free GNU Compiler Collection
> by globally processing several compilation units (e.g. work on a whole
> program or on a library) in order to customize and configure GCC to
> European software industry ne
Hi Paolo,
On Mon, 30 Oct 2006, Paolo Bonzini wrote:
> Given that Roger started the ball rolling, by approving Steven's
> -fcse-skip-blocks patch, I'll ping the discussion...
>
> http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01066.html
I believe the appropriate next step is to freshen these patche
Dear All,
My collegues from the GGCC consortium have asked me to send the following
announcement to this GCC mailing list.
Please reply to [EMAIL PROTECTED], [EMAIL PROTECTED]
for any remarks and questions regarding GGCC
ANNOUN
> Because gcc is the first step in bringing up a new system. Having
> complex sets of dependencies makes people's lives harder. I'm sure
> we've all had the unpleasant experience of trying to build something
> from the net only to discover that we had to build five other things
> first.
In my e
On Mon, Oct 30, 2006 at 10:07:39PM -0800, Mark Mitchell wrote:
> I don't believe there's a serious problem with the concept, as long as
> "./configure; make; make install" for GMP DTRT. If you can do it for
> GCC, you can do it for a library it uses too.
>
> I would strongly oppose downloading
Snapshot gcc-4.2-20061031 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20061031/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Geoffrey Keating wrote:
OK, I agree: a native compiler, with no special options, isn't too
hard. I don't think typing that sequence twice would be too hard
either, though. :-)
For something that's not too hard, it's sure causing me a lot of trouble...
But, the trouble you're having is not
Ah, your "&&" did not indicate which command was failing.
You can work around the issue with CFLAGS="-fno-common", which you
probably want to do anyway if this code is ever linked in statically
into libgfortran or something. However, it's just the test code that
has this issue.
You can al
On 10/31/06, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
This question is not related to the apparent
instability and thus
low quality of GMP/MPFR at all.
This is the second time I see someone complain about GMP/MPFR
instability. What is this complaint based on? We've used GMP in g95
and later g
On 2006-10-31, at 01:59, Daniel Berlin wrote:
On 10/30/06, Marcin Dalecki <[EMAIL PROTECTED]> wrote:
On 2006-10-30, at 21:37, Daniel Berlin wrote:
> Honestly, I don't know any mac people who *don't* use either
fink or
> macports to install unix software when possible, because pretty
much
[EMAIL PROTECTED] wrote on 31/10/2006 12:01:20:
> Hello all,
>
> Can anyone tell me what the below expression means ?
>
>
> (insn 38 37 40 4 (parallel [
> (asm_operands/v ("") ("") 0 [ //line
2
> (reg:SI 32 [ s5.1 ])
> //line 3
>
Hello all,
Can anyone tell me what the below expression means ?
(insn 38 37 40 4 (parallel [
(asm_operands/v ("") ("") 0 [ //line 2
(reg:SI 32 [ s5.1 ])
//line 3
]
[
(asm_input:SI ("r")
On 31/10/2006, at 12:28 AM, Mark Mitchell wrote:
Ian Lance Taylor wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
I would strongly oppose downloading stuff during the build
process. We're not in the apt-get business; we can leave that to the
GNU/Linux distributions, the Cygwin distributors, e
I wouldn't object to that. It's a bit more build-system complexity, but
if it makes it easier for people, then it's worth it.
Actually, since we are at it, I would like to have toplevel configure
automatically symlink "foo-1.2.3" to "foo". This way, untarring
gmp/mpfr (and maybe also bison
There is also "fink" (fink.sf.net), which i believe would provide a
new enough gmp, but i am not positive.
Yes, fink packages "gmp gmp-shlibs libmpfr1-dev libmpfr1-shlibs" provide
all that is needed.
Paolo
Ian Lance Taylor wrote:
Mark Mitchell <[EMAIL PROTECTED]> writes:
I would strongly oppose downloading stuff during the build
process. We're not in the apt-get business; we can leave that to the
GNU/Linux distributions, the Cygwin distributors, etc. If you want to
build a KDE application, you h
Steven Bosscher wrote:
On 30 Oct 2006 22:56:59 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
I'm certainly not saying that we should pull out GMP and MPFR. But I
am saying that we need to do much much better about making it easy for
people to build gcc.
Can't we just make it so that, if
45 matches
Mail list logo
