On Sunday 08 June 2008 04:52, Daniel Jacobowitz wrote:
> On Sat, Jun 07, 2008 at 11:26:05AM +0200, Denys Vlasenko wrote:
> > Seen that 4.3.1 has been released, I tried to build
> > i486-linux-uclibc cross-compiler.
>
> You probably forgot to build libgcc. Are you using 'make all' / 'make
> instal
On Sun, 8 Jun 2008, Denys Vlasenko wrote:
> ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:52:18: error:
> fenv.h: No such file or directory
Decimal floating point requires . The DPD code only requires the
header, not any of the actual functions it declares; it looks like the BI
On Sunday 08 June 2008 13:50, Joseph S. Myers wrote:
> On Sun, 8 Jun 2008, Denys Vlasenko wrote:
>
> > ../../../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:52:18: error:
> > fenv.h: No such file or directory
>
> Decimal floating point requires . The DPD code only requires the
> header
> As far as I know, toolchain is built in this order:
>
> 1. binutils
> 2. C compiler
> 3. libc
No.
That usually only works if you already have the toolchain installed. In which
case ordering is irelevant, you can just build whichever component you want
to update.
A full bootstrap process look
On Sunday 08 June 2008 16:27, Paul Brook wrote:
> > As far as I know, toolchain is built in this order:
> >
> > 1. binutils
> > 2. C compiler
> > 3. libc
>
> No.
>
> That usually only works if you already have the toolchain installed. In which
> case ordering is irelevant, you can just build whi
Accudentally noticed this in my freshly built 4.3.1 tree
in climits C++ header file:
#ifndef LLONG_MIN
#define LLONG_MIN -__LONG_LONG_MAX__ - 1
#endif
#ifndef LLONG_MAX
#define LLONG_MAX __LONG_LONG_MAX__
#endif
#ifndef ULLONG_MAX
#define ULLONG_MAX __LONG_LONG_MAX__ * 2ULL + 1
#endif
Think wh
David,
I've converted the cdce pass to the tuples branch and had a question
about is_call_dce_candidate(). Currently, the function checks
flag_tree_builtin_call_dce, but that seems unnecessary. It's already
checked by the gate function. Is there any other reason why this
check should be there?
Then, running "make all-target-libgcc" built them, but I finally settled
for just "make" - it didn't error out.
Yes, the advantage of Paul's suggested process are not only that the
installations are reproducible and always use the complete feature set
of the underlying libc (that's the big p
On Sunday 08 June 2008 22:41, Paolo Bonzini wrote:
>
> > Then, running "make all-target-libgcc" built them, but I finally settled
> > for just "make" - it didn't error out.
>
> Yes, the advantage of Paul's suggested process are not only that the
> installations are reproducible and always use th
1) Binutils
2) Whatever bits of compiler are required to produce...
3) libc headers
4) A basic C compiler+libgcc that is sufficient to build...
5) libc
6) A full compiler+runtime, c++, fortran, etc.
If someone is willing to expand on the above and explain what exactly
do I need to do in step 2,
On Sun, 8 Jun 2008, Denys Vlasenko wrote:
> What is Paul's suggested process? I just reread his post again
> and it contains no suggestions what to do, it was useful in
> other way: he explained where my understanding of build process
> is incorrect:
The procedure for EGLIBC is documented in deta
This brings in everything from trunk just before the new OMP3 changes.
Jakub, you can do the omp3 merge now. David, this converts
tree-call-cdce.c to use tuples. The only change is the removal of the
flag that I mentioned earlier, if this is something you think it
shouldn't be merged into mainli
12 matches
Mail list logo
