Í just tried to build gcc-4.1.2 for cygwin... but failed. My old way
of test building does not seem to work anymore for me.
Windows XP Pro/SP2 cygwin Pentium M processor 2.13GHz system with packages:
binutils 20060817-1 2.17.50 20060817
bison2.3-1 2.3
cyg
Christian Joensson wrote:
Í just tried to build gcc-4.1.2 for cygwin... but failed. My old way
of test building does not seem to work anymore for me.
[...]
grep '^#' < kinds.h > kinds.inc
/bin/sh: kinds.h: No such file or directory
[...]
Any ideas of what might be going wrong?
A quick bit o
> > That said, I think it would not be bad to put 4.3 in stage3 mode until
> > dataflow branch is ready and, at that point, rebranch 4.2 and soon
> > after that merge dataflow branch.
FWIW I agree with Vlad and Paolo Bonzini.
It seems as if 4.2 was branched with critical flaws (it happens, no
bi
Brooks Moses wrote:
> > Í just tried to build gcc-4.1.2 for cygwin... but failed. My old way
> > of test building does not seem to work anymore for me.
> [...]
> > grep '^#' < kinds.h > kinds.inc
> > /bin/sh: kinds.h: No such file or directory
> [...]
> > Any ideas of what might be going wrong?
>
Brooks Moses wrote:
However, this seems to be hardcoding something that texinfo has
perfectly good macros for, and it's also missing the standard GCC-manual
subtitle; the usual form is:
--
@titlepage
@title Installing GCC
@subtitle for GCC ve
>
>
> > > That said, I think it would not be bad to put 4.3 in stage3 mode until
> > > dataflow branch is ready and, at that point, rebranch 4.2 and soon
> > > after that merge dataflow branch.
>
> FWIW I agree with Vlad and Paolo Bonzini.
>
> It seems as if 4.2 was branched with critical flaws
Brian Dessent wrote:
Brooks Moses wrote:
In short, from what I could tell from a quick scan of that PR, the
problem is that you've got LD_LIBRARY_PATH set in such a way that it's
not including the GMP header files.
If you're using the standard Cygwin-package installation of GMP, I'd
guess this
4.0 branched with critical flaws that were not noticed until 4.2.0 which
is why we end up with the missed optimiation regression in the first place.
So the question is do we want to correct the regressions or not, because
right now we sound like we don't. Which regression is more important?
Wr
[ adding gcc@ back to CC ]
Christian Joensson wrote:
> > for k in 4 8 10 16; do
> > echo " real (kind=$k) :: x" > tmp$$.f90
> > echo " end" >> tmp$$.f90
> > /usr/local/src/branch/objdir/./gcc/gfortran \
> >-B/usr/local/src/branch/objdir/./gcc/ \
> >-B/usr/local/i686-pc-cygwin/bin/
On 2/21/07, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
> 4.0 branched with critical flaws that were not noticed until 4.2.0 which
> is why we end up with the missed optimiation regression in the first place.
>
> So the question is do we want to correct the regressions or not, because
> right now
Gabriel Dos Reis wrote:
Andi Kleen <[EMAIL PROTECTED]> writes:
| "Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
| >
| > And we don't want to arm our detractors with bad SPEC numbers. I can just
| > imagine the FUD spreading... we've got to fix it or backout.
So what if gcc is a bit behind som
Hello all,
As far as I know, GCC 4.x is easily retargetable for a new architecture.
I would be interested by source-to-source compilation with the GCC
framework. For instance, let's say the input language is C and the
output language is C annotated with pragmas which are the results of
some c
On 2/21/07, Thomas Bernard <[EMAIL PROTECTED]> wrote:
Hello all,
As far as I know, GCC 4.x is easily retargetable for a new architecture.
I would be interested by source-to-source compilation with the GCC
framework. For instance, let's say the input language is C and the
output language is C ann
On Tue, 20 Feb 2007, Daniel Jacobowitz wrote:
> On Tue, Feb 20, 2007 at 06:23:14PM -0500, Kaveh R. GHAZI wrote:
> > No it doesn't need stating, at least not for me. :-) Sure nobody likes
> > bugs/miscompilations, but all compilers have them. We evaluate how
> > serious they are and whether a per
On Wed, Feb 21, 2007 at 11:33:39AM -0500, Kaveh R. GHAZI wrote:
> My tolerance is pretty low. I'm relying on the fact that the bug occurs
> rarely in real code. I'm trying to reconcile your statement about
> customer feedback with Daniel B's claim here:
> http://gcc.gnu.org/ml/gcc/2007-02/msg0047
Kaveh R. GHAZI wrote:
> We have to make a judgement about how serious this bug really is. Some
> people seem to think correctness *always* wins, I don't like absolutes,
> they are too limiting. I don't at all think performance always wins, but
> correctness of rare corner cases which comes at hi
On Mon, 19 Feb 2007, Brooks Moses wrote:
> The 4.2.0 release is fairly significant to GFortran. In my opinion, it's
> really the first 4.x release for which we have a mature Fortran compiler
FWIW, this is something I have clearly heard from FreeBSD ports
maintainers responsible for ports being b
Brooks Moses wrote:
The install.texi manual has the following bit of code for the title page:
Looking at the svn history, I see that this titlepage line is present in
the initial checkin, and the initial checkin says
* doc/install.texi: New file. Converted to texinfo from the HTML
Thomas Bernard wrote:
framework. For instance, let's say the input language is C and the
output language is C annotated with pragmas which are the results of
some code analysis (done at middle-end level).
It is possible to write a backend that emits C. Sun has one for
instance. However, at
Shekhar Divekar wrote:
(insn 5 4 6 0x0 (set (reg/v:SI 71)
(ashiftrt:SI (reg/v:SI 71)
(const_int 24 [0x18]))) -1 (nil)
(nil))
This looks suspect. You shouldn't be using the same input and output
pseudo regs here. You should instead generate a temporary for the
output
Brooks Moses wrote:
> Given that the _real_ situation seems to be that no two manuals have the
> same title format (except for gcc.texi and gccint.texi), are there any
> opinions on me coming up with a standard format for this, and proposing
> a patch to standardize them?
I can't imagine there wo
On 2/21/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
To be honest, my instinct for the FSF is to take the 4% hit and get rid
of this nasty class of bugs. Users measure compiler quality by more
than just floating-point benchmarks; FP code is a relatively small
(albeit important, and substantial)
On Wed, Feb 21, 2007 at 11:00:00PM +0100, Richard Guenther wrote:
> Of course the speed of a compiler is measured on testcases where
> speed matters - and this is usually FP code. Now based on this reasoning
> we could (as CodeSourcery probably did) enable -fno-strict-aliasing by
> default, which
Follows the build info:
config.guess:
i386-pc-mingw32
$ gcc -v
Using built-in specs.
Target: mingw32
Configured with: ../../source/gcc-4.1.2/configure --prefix=/mingw
--host=mingw32 --target=mingw32 --program-prefix="" --with-gcc --with-gnu-ld
--with-gnu-as --enable-threads --disable-nls --enab
Snapshot gcc-4.2-20070221 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20070221/
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
On Wed, 21 Feb 2007, Brooks Moses wrote:
> Given that the _real_ situation seems to be that no two manuals have the
> same title format (except for gcc.texi and gccint.texi), are there any
> opinions on me coming up with a standard format for this, and proposing
> a patch to standardize them?
Y
well, I ended up reinstalling gmp, libgmp-devel, libgmp3, mpfr,
libmpfr-devel, libmpfr0 (which I don't think is nessecary) and
libmpfr1.
now, its testsuite is being run
thanks brian and brooks for you help.
--
Cheers,
/ChJ
[EMAIL PROTECTED] wrote on 18/02/2007 17:01:31:
> Hi,
>
> >
> > I am not sure if this message is still relevant. Anyhow, I think
> > following another built-in under zero_arg_builtins
("__builtin_alpha_rpcc"
> > in alpha.c for example) could help in finding the missing part in this
> > implemen
28 matches
Mail list logo
