void finding
libiconv.so during configure in stage1, but it still uses the wrong
iconv.h as of stage2. And with mainline, since configure is run every
stage it gets worse.
Any ideas?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
27;s no libiconv.so in /usr/lib, just libc.so which contains
the iconv*() function calls.
IMHO, the fact that GCC includes /usr/local/include by default in it's
system header search path is brain damaged, but it's probably way too
entrenched to revisit that. :-(
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
--Kaveh
PS: building GCC is too complicated. :-P
--
Kaveh R. Ghazi [EMAIL PROTECTED]
ype. So what does the ALL_GTFILES_H rule do?
Turns out the problem was I had /usr/ucb in my path. The rule in
ALL_GTFILES_H does: tr ' ' '\n' but newlines don't work with
/usr/ucb/tr. When I use /bin/tr instead, it works (I'm on
solaris2.10).
So a wo
ocal
> when configuring GCC.
Aha, --with-local-prefix= plus --without-libiconv-prefix did the
trick for me.
Thanks,
--Kaveh
PS: --with-local-prefix= wasn't documented in cpp.texi, only in
install.texi which is why I missed it. Thanks again.
--
Kaveh R. Ghazi [EMAIL PROTECTED]
become clear that this was a configure (and
therefore installation) option.
--
Kaveh R. Ghazi [EMAIL PROTECTED]
our help in ensuring a smooth transition
is greatly appreciated.
Thanks,
--Kaveh
--
Kaveh R. Ghazi
From: "Dave Korn"
Dave Korn wrote:
Attached allowed it to build,
And with that patch:
===
All 45 tests passed
===
Thanks Dave!
This MPC release may happen early next week. Anyone else have success
results, problems or portability patches?
-
Hi,
mpc-0.7 now has been released, you can get the package here:
http://www.multiprecision.org/index.php?prog=mpc&page=download
Here's the official announcement:
http://lists.gforge.inria.fr/pipermail/mpc-discuss/2009-September/000554.html
Of particular interest in this release are bugfixes, esp
history:
>
> -#define EXP_BITS (32 - 5)
> +#define EXP_BITS (32 - 6)
The following change fixes the comment. Tested with "make" on
x86_64-unknown-linux-gnu. I'll install this as "obvious" tomorrow if
nobody comments on t
On Mon, 26 Oct 2009, Steve Ellcey wrote:
> I have tried:
> /* { dg-final { scan-assembler-times "(byte|data1).*?0x3.*? DW_AT_inline" 3 }
> } */
> /* { dg-final { scan-assembler-times "(byte\|data1).*?0x3.*? DW_AT_inline" 3
> } } */
> /* { dg-final { scan-assembler-times "\(byte\|data1\).*?0x3.*?
the compiler version you
used, and the versions of gmp/mpfr used to compile it. You do not
necessarily need to bootstrap mainline GCC with this MPC, but if you
have the spare time and cycles it would be nice too.
Thanks,
--Kaveh
--
Kaveh R. Ghazi gh...@caip.rutgers.edu
From: "David Fang"
On powerpc-apple-darwin8:
gmp: 4.3.1
mpfr: 2.4.1
% gcc -v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with:
/var/tmp/gcc/gcc-5370~2/src/configure --disable-checking -enable-werror --prefix=/usr
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++
From: "Allan McRae"
Nothing exotic:
i686-pc-linux-gnu & x86_64-unknown-linux-gnu
Both:
===
All 57 tests passed
===
gcc-4.4.2
mpfr-2.4.1
gmp-4.3.1
Also fine on i686-pc-linux-gnu with gcc-4.5-20091008
Allan
Thanks!
From: "Ed Smith-Rowland" <3dw...@verizon.net>
I'm on MacOSX 10.3
MacOSX:~/Tarballs/mpc-0.8-dev ed$ gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1671)
The -Werror kills it.
Once I deleted -Werror out of
From: "Gerald Pfeifer"
===
All 57 tests passed
===
i386-unknown-freebsd7.2
gcc version 4.2.1 20070719 [FreeBSD]
mpfr-2.4.1_1
(FWIW, on FreeBSD I have made MPC a hard requirement for the GCC 4.5
port already. I assume the next steps on your side are waiting fo
From: "Dennis Clarke"
> target GCC GMP MPFR
>
> sparc-sun-solaris2.11 4.1.1 4.2.1 2.3.2
> i386-pc-solaris2.10 4.1.1 4.2.1 2.3.2
> mips-sgi-irix6.5 3.4.5 4.3.0 2.3.2
> alpha-dec-osf4.0f 3.4.4 4.2.1 2.3.2
>
> All tests passed everywhere.
what about sparc-sun-solaris2.10 ? sparc-sun-solaris2.9 an
I was looking through the gcc-4.5 primary and secondary platform list
to ensure we have coverage for MPC testing. It occurs to me that some
of the OS versions are outdated.
I've included the list from the page
http://gcc.gnu.org/gcc-4.5/criteria.html
Should we update:
1. solaris2.10 -> 2.11
2.
"Kaveh R. GHAZI" writes:
Please test this version and report back in this thread (not to me
privately) the results of "make check". Also include your target
triplet,
and the versions of your compiler, gmp and mpfr.
Wow we've gotten a lot of results, thanks everyone!
From: "David Edelsohn"
MPC-0.8 build fails on AIX due to libtool. The changes to libtool
between MPC-0.7 and MPC-0.8 rely on Bash-specific features. Manually
editing libtool to use Bash allowed the build to succeed.
Hi David,
Can you please be more specific about this problem? I've seen se
On Mon, 9 Nov 2009, Paolo Bonzini wrote:
> On 11/08/2009 10:29 PM, David Edelsohn wrote:
> > The problem is shell append += and libtool not running with the same
> > shell used by configure.
>
> What version of libtool is used by mpc? Libtool HEAD could fix this bug.
> Paolo
(GNU libtool) 2.2.6
From: "David Edelsohn"
AIX Shell is KSH.
The problem is shell append += and libtool not running with the same
shell used by configure.
Hm, the mpc configure script actually has a check for shell +=, and on my
solaris box it correctly detects that it doesn't work.
checking whether t
On Mon, 9 Nov 2009, Paolo Bonzini wrote:
> On 11/09/2009 06:33 AM, Kaveh R. Ghazi wrote:
> > From: "David Edelsohn"
> >
> >> AIX Shell is KSH.
> >>
> >> The problem is shell append += and libtool not running with the same
> >>
From: "David Edelsohn"
On Tue, Nov 10, 2009 at 1:16 AM, Kaveh R. GHAZI
wrote:
So IIUC, David is setting SHELL=/path/to/bash first, then running
configure, then getting an error. This happens because configure tests
that bash understands +=, but libtool is run with (presumably) /b
From: "Mark Mitchell"
Richard Guenther wrote:
If config.gcc handles both triples the same (*-*-solaris2.10 and
*-*-solaris2.11) then we can consider both at the same level.
Indeed. Furthermore, we certainly wouldn't want to break support for
Solaris 2.10 at this point, so having 2.10 liste
From: "David Edelsohn"
On Thu, Nov 12, 2009 at 10:00 AM, Kaveh R. Ghazi
wrote:
And do we want to update aix5.2 to aix5.3 in our platforms list?
AIX should be updated to 5.3 or 6.1.
David
For the last two months or so, the AIX reports I see are mostly (all?) for
5.3, so I
On Wed, 25 Nov 2009, Richard Guenther wrote:
> That's not an option. That would basically tell you that you can get
> away with breaking the rules if you just take the blame. And I just
> checked and none of my 12 local patches I queued for stage1 apply
> anymore. And as usual there are big hun
From: "Dave Korn"
But does it, though? From http://gcc.gnu.org/svnwrite.html:
Free for all
The following changes can be made by everyone with SVN write access:
Fixes for obvious typos in ChangeLog files, docs, web pages, comments and
similar stuff. Just check in the fix and copy it to gcc
From: "Richard Guenther"
The change certainly didn't fall under the obvious rule because of its
size. One might argue that 'and similar stuff' covers coding-style
changes, but here again I'd fear of a certain kind of people going
wild and follow the coding-style by word rather than existing
pr
From: "Dave Korn"
Agreed, but what I'm not at all certain is whether it counts as *in*
"ChangeLog files, docs, web pages, comments and similar stuff",
specifically
when it's at the end of a line of functional C code in a source file.
Since whitespace in C has no syntactic effect, certainly
From: "Richard Kenner"
I suspect the web page in question needs to be updated to
more accurately reflect current standard practice. It appears wrong to me
on more counts than just this one (my understanding has always been that
no
approval is needed to fix typos, whether in code or comments,
On Wed, 25 Nov 2009, Vincent Lefevre wrote:
> The release of GNU MPFR 2.4.2 ("andouillette sauce moutarde"
> patch level 2) is imminent.
I tested mpfr-2.4.2rc3 on sparc-sun-solaris2.9 in 32 and 64 bit modes. I
compiled with both gcc-3.4.6 and Sun C 5.5. All four configurations built
and passed
On Sun, 29 Nov 2009, Richard Guenther wrote:
>
> This is a remainder to not catch you in surprise when we announce
> the end of stage 3. Starting Dec 1st the trunk will go into
> regression and documentation fixes only mode (thus, same rules
> apply as for a release branch). When the release cri
The patch which makes the MPC library a hard requirement for GCC
bootstrapping has been approved today. As promised, I'll wait one week
before applying it to give everyone a chance to install MPC on their
systems.
You can download mpc-0.8 from either of these two locations:
ftp://gcc.gnu.org/pub/
From: "Michael Witten"
On Mon, Nov 30, 2009 at 12:04 AM, Kaveh R. GHAZI
wrote:
The patch which makes the MPC library a hard requirement for GCC
bootstrapping has been approved today.
Out of curiosity and ignorance: Why, specifically, is MPC going to be
a hard requirement?
S
hpux. If you can convince your favorite package site (e.g.
blastwave.org or hpux.connect.org.uk) to offer binaries for these systems,
please do and notify the MPC mailing list (not me) about it here:
http://lists.gforge.inria.fr/mailman/listinfo/mpc-discuss
Thanks,
--Kaveh
--
Kaveh R. Ghazi
On Fri, 22 Jan 2010, Piotr Wyderski wrote:
> Paolo Carlini wrote:
>
> > The C library, to which library printf belongs, is not part of the GCC
> > project.
>
> In that case it certainly isn't a GCC issue.
Assuming this feature is accepted in glibc, you'll want to update GCC's
-Wformat flag.
On Mon, 1 Mar 2010, Jack Howarth wrote:
> Somehow the recursive make is broken for libiberty and is silently using
> the system compiler.
> Jack
I believe this is PR29404. IIRC, in addition to libiberty, other
recursive "make check"s fail too due to using the system (stage1)
compil
ing so people can
upgrade their regtesters if necessary.
Okay for mainline?
Thanks,
--Kaveh
2008-10-04 Kaveh R. Ghazi <[EMAIL PROTECTED]>
* configure.ac (MPFR check): Bump minimum version to 2.3.0 and
recommended version to 2.3.2.
From: "Adrian Bunk" <[EMAIL PROTECTED]>
On Sat, Oct 04, 2008 at 09:33:48PM -0400, Kaveh R. GHAZI wrote:
Since we're in stage3, I'm raising the issue of the MPFR version we
require for GCC, just as in last year's stage3 for gcc-4.3:
http://gcc.gnu.org/ml/gcc/200
From: "Richard Guenther" <[EMAIL PROTECTED]>
On Sun, Oct 5, 2008 at 3:33 AM, Kaveh R. GHAZI <[EMAIL PROTECTED]>
wrote:
Okay for mainline?
Ok if there are no objections within the week.
Thanks,
Richard.
Great, thanks. Can I get an explicit ack from a fort
From: "Tobias Schlüter" <[EMAIL PROTECTED]>
[EMAIL PROTECTED] and @option{--with-gmp-include}. Alternatively,
+if a GMP source ditribution is found in a subdirectory of you GCC
+sources named @file{gmp}, it will be built together with [EMAIL PROTECTED]
+Library is not installed in your default
From: "Geoff Keating" <[EMAIL PROTECTED]>
I found that simply building MPFR in a non-default location (configure
--prefix && make) and then pointing GCC at it with --with-mpfr, as in
the installation instructions, causes the bootstrap to fail when first
running xgcc, because xgcc can't find the
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
.0:
> [...]
> - Bug fixes.
Vincent,
Are there any MPFR bugs fixed in 2.4.0 that can be exposed through the
limited way GCC uses MPFR?
Thanks,
--Kaveh
--
Kaveh R. Ghazi gh...@caip.rutgers.edu
From: "Vincent Lefevre"
On 2008-12-13 01:46:21 -0500, Kaveh R. GHAZI wrote:
> Changes from version 2.3.2 to version 2.4.0:
> [...]
> - Bug fixes.
Are there any MPFR bugs fixed in 2.4.0 that can be exposed through the
limited way GCC uses MPFR?
The announce was incorr
proposal to the SC.
Regards,
--Kaveh
--
Kaveh R. Ghazi gh...@caip.rutgers.edu
On Tue, 27 Jan 2009, James Dennett wrote:
> On Mon, Jan 26, 2009 at 11:52 PM, wrote:
> > I was debugging a function and by inserting the debug statement crashed
> > the system. Some investigation revealed that gcc 4.3.2 arm-eabi (compiled
> > from sources) with -O2 under some circumstances assum
ession without having
the real part get changed?
Thanks,
--Kaveh
--
Kaveh R. Ghazi gh...@caip.rutgers.edu
From: "Tobias Burnus"
Hi Kaveh,
Kaveh R. GHAZI wrote:
I'm trying to create complex number expressions that contain inf or
nan in the imaginary part. I.e. (0 + inf I) or (0 + nan I).
If it does not need to be C (e.g. to try MPC in the middle end), you
could use Fortran:
From: "Joseph S. Myers"
On Thu, 29 Jan 2009, Kaveh R. GHAZI wrote:
I don't think these results are a bug, rather it's just an artifact of
the
way complex multiplcation is done and having these special values in
See bug 24581. Some aspects are a bug (GCC doesn't
From: "Richard Guenther"
Thanks, I do want to test the middle-end. However I need to do more than
just create the complex expression. I also have to pass it to a builtin
that evaluates using MPC like __builtin_csin(). The fortran frontend
evaluates complex transcendentals in fortran/simplify
On Mon, 23 Feb 2009, Paolo Bonzini wrote:
> Jack Howarth wrote:
> > The same issue in the libiberty testsuite run can be seen with
> > the Apple regress server log at
> > http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip.
> > If you search for test-demangle, you will find...
>
> I'm sur
On Thu, 26 Feb 2009, Vincent Lefevre wrote:
> After a buffer overflow has been found (and fixed) in the
> mpfr_snprintf and mpfr_vsnprintf functions of MPFR 2.4.0,
> it has been decided to release MPFR 2.4.1 immediately.
> It is available for download from the MPFR web site:
>
> http://www.mpfr.
ng
compiler when built with g++ rather than gcc. E.g. testsuite regressions,
changes in the speed or size of cc1, etc. Also, is cc1 linked with
libstdc++.so ? Stuff like that.
Would you please consider checking this?
Thanks,
--Kaveh
--
Kaveh R. Ghazi
On Thu, 12 Mar 2009, H.J. Lu wrote:
> > Executing on host:
> > /sw/src/fink.build/gcc44-4.3.999-20090312/darwin_objdir/gcc/xgcc
> > -B/sw/src/fink.build/gcc44-4.3.999-20090312/darwin_objdir/gcc/
> > /sw/src/fink.build/gcc44-4.3.999-20090312/gcc-4.4
> > -20090312/gcc/testsuite/gcc.dg/asm-b.c -
On Wed, 18 Mar 2009, Ralf Wildenhues wrote:
> I tried to send the message below to the list, without subscribing. It
> was thus rejected. I then tried to send it to you off-list, which your
> mail server doesn't like either, due to unblock.secureserver.net. Would
> you please forward it for me?
create a patch.
Thanks,
--Kaveh
--
Kaveh R. Ghazi
From: "Steven Bosscher"
On Thu, Mar 26, 2009 at 10:39 PM, Kaveh R. Ghazi
wrote:
If there are no objections, I'll create a patch.
P... for those of us who just install the latest-and-greatest
fedora/suse/ubuntu/... once and don't change installations for two or
riteria list.
http://gcc.gnu.org/gcc-4.5/criteria.html
Thanks,
--Kaveh
--
Kaveh R. Ghazi
From: "Richard Guenther"
I get 1 failure on linux-{i586,x86_64,ppc,ppc64,ia64,s390,s390x}
platforms:
inp_str.c:131: MPC assertion failed: n == nread
/bin/sh: line 4: 2347 Aborted (core dumped) ${dir}$tst
FAIL: tio_str
Richard.
Thanks for the thorough testing!
I don't get
From: "Richard Guenther"
I tested on openSUSE Factory which currently has gcc 4.3.3, gmp 4.2.3,
mpfr 2.4.1 and some pre-2.10 glibc.
I tried with vanilla mpfr-2.4.1 and gmp-4.2.3, and mpc still passed all it's
tests on gcc14. Would it be fair to suspect something in your prerelease
glibc?
From: "Janis Johnson"
Same behavior with openSUSE 11.1 (glibc 2.9, gcc 4.3.2, gmp 4.2.3, mpfr
2.3.2).
Note that I build with -D_FORTIFY_SOURCE=2 -fstack-protector.
I get the failure Richard mentioned when I use -D_FORTIFY_SOURCE=2
-fstack-protector but no failures without those options. Th
From: "Marc Glisse"
This could be related to a call to sprintf(str,...,str,...), which
according to the doc is undefined behaviour.
Doc? I don't see it in the man page. Got a url?
From: "Jakub Jelinek"
man 3p sprintf says:
If copying takes place between objects that overlap as a result of a call
to
sprintf() or snprintf(), the results are undefined.
ISO C99 7.19.6.6 has similar wording:
If copying takes place between objects that overlap, the behavior is
undefined
From: "Janis Johnson"
I get the failure Richard mentioned when I use -D_FORTIFY_SOURCE=2
-fstack-protector but no failures without those options. This is on
powerpc64-linux (but defaulting to -m32) with:
RHEL 5.3
GCC 4.3.2
GMP 4.2.4
MPFR 2.4.1
MPC 0.6
Okay the -D_FORTIFY_SOURCE=2 bug has b
From: "Gerald Pfeifer"
On Sat, 4 Apr 2009, Andreas Tobler wrote:
I've cc'ed others who have access to the platforms in question based on
GCC test results. Please help if you can.
- powerpc-apple-darwin9.6.0 gcc-4.5.0 gmp-4.2.2 mpfr-2.3.1 ok.
- sparc-sun-solaris2.10 gcc-4.4 gmp-4.2.2 mpfr-2.
From: "Kaveh R. Ghazi"
I've been relaying the messages, (but I haven't seen the MPC webpage
updated to reflect this yet).
Okay it's updated, we've got a pretty comprehensive list of platforms.
http://www.multiprecision.org/index.php?prog=mpc&page=platfo
I'm seeing an issue with the top level configure code. Looking at it
requires juggling m4, guile, shell and make syntax in one's head, I'm
having some trouble so I'm seeking some assistance.
I'm running into the actual problem when I'm integrating the mpc library
with GCC and testing in-tree buil
On Fri, 10 Apr 2009, Ian Lance Taylor wrote:
> Add a new shell variable in configure.ac extra_mpfr_configure_args. Set
> it to what you want to pass to the mpfr configure. Call
> AC_SUBST(extra_mpfr_configure_args). In Makefile.in add a line
> EXTRA_MPFR_CONFIGURE_ARGS = @extra_mpfr_configure_a
From: "Ben Elliston"
On Fri, 2009-04-10 at 23:56 -0400, Kaveh R. GHAZI wrote:
Ah, but cake is only easy when someone else bakes it. :-)
While you're baking, Kaveh :-) could you see if your patch could also
fix:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34818
Thanks
On Thu, 23 Apr 2009, DJ Delorie wrote:
> +# Return 1 if the target supports double larger than float,
> +# 0 otherwise.
> +
> +proc check_effective_target_large_double { } {
> +return [check_no_compiler_messages large_double object {
> + int dummy[sizeof(double) < sizeof(float) ? 1 : -1];
From: "Mark Mitchell"
That is not a decision, however, on whether using MPC is or is not a
good idea. There have been objections raised to MPC, on the grounds
that it may not build on all host systems, or that the costs it brings
in terms of complexity of building GCC outweigh its benefits. W
On Wed, 29 Apr 2009, Joseph S. Myers wrote:
> On Wed, 29 Apr 2009, Richard Earnshaw wrote:
>
> If you are building a non-C front end without bootstrapping you need at
> least 2.95:
>
> To build all languages in a cross-compiler or other configuration where
> 3-stage bootstrap is not perfor
On Sat, 2 May 2009, Anthony Green wrote:
> The top level configury suggests that you can simply drop gmp, ppl, etc
> into the top level source dir and they will get configured and used.
> Does this really work?
It is supposed to. I haven't worked on or tested the ppl machinery so I
don't know wh
On Tue, 28 Apr 2009, Kaveh R. Ghazi wrote:
> From: "Mark Mitchell"
>
> > That is not a decision, however, on whether using MPC is or is not a
> > good idea. There have been objections raised to MPC, on the grounds
> > that it may not build on all host systems,
On Tue, 5 May 2009, Mark Mitchell wrote:
> I personally think relying on MPC is a reasonable choice, given the fact
> that (as you say) the language specifications do in some cases require
> support for these kinds of manipulations of complex numbers at compile-time.
>
> In the past, however, othe
On Thu, 14 May 2009, Eric Botcazou wrote:
> > The build went through without any error,
> > but most of the tests failed in "make check".
> > unexpected failures = 6472 and passed = 52.
>
> Try with "make -k check" and no -j, parallel testing is broken on Solaris.
> Eric Botcazou
To clarify, is i
On Wed, 13 May 2009, Mark Mitchell wrote:
> Kaveh R. GHAZI wrote:
>
> > 1. Consider MPC as an optional library now, install all the code and make
> > it hard-required only when all the complex math functions are made
> > available in a future released version of
From: "Allan McRae"
I have noticed that mpc is not automatically detected even when
installed in the standard library path (with gcc-4.5-20090604). This
means that building with mpc always requires using the
--with-mpc-lib=/usr/lib flag.
This is fixed by adjusting configure{.ac} to have:
m
If I write a complex double constant -3.I (as opposed to 0-3.I), what is
it supposed to evaluate to? This program:
#include
int main(void)
{
const __complex double C1 = (-3.I);
const __complex double C2 = (0-3.I);
printf ("%f %f\n", __real__ C1, __imag__ (C1));
printf ("%
From: "Joseph S. Myers"
On Mon, 8 Jun 2009, Kaveh R. GHAZI wrote:
If I write a complex double constant -3.I (as opposed to 0-3.I), what is
it supposed to evaluate to? This program:
Because GCC does not implement imaginary types, this applies unary minus
to 0.0+3.0I. Whereas 0
From: "Joseph S. Myers"
On Mon, 8 Jun 2009, Kaveh R. Ghazi wrote:
Perhaps the only safe way to create the value, even in the presence of
rounding mode changes, is to use conj(3.I) ?
Setting the __real__ and __imag__ parts of a temporary variable should
always be reliable fo
On Tue, 9 Jun 2009, Art Haas wrote:
>
> Hi.
>
> I've had no luck with recent bootstraps on both i386-pc-solaris2.10 and
> sparc-sun-solaris2.10. The error messages below are from builds performed
> after updating my repo this morning.
>
> i386-pc-solaris:
>
> cc1: warnings being treated as errors
On Sat, 20 Jun 2009, Ian Lance Taylor wrote:
> That said,
> I'm perfectly amenable to moving the new warning to -Wextra or just
> turning it on only with -Wc++-compat. I don't personally care that
> much, actually.
I also agree with Robert's comments that all warnings are about valid C,
with -Wa
On Tue, 7 Jul 2009, Diego Novillo wrote:
> 4- Test on primary and secondary platforms. What is the current
>suggested list of platforms?
http://gcc.gnu.org/gcc-4.5/criteria.html
lt list so I don't miss any existing (or
newly added) flags as time goes by. (The "yes" flag works as of 4.0.)
I did this on i686 last night, so your problem is probably confined to
x86_64.
http://gcc.gnu.org/ml/gcc-testresults/2006-01/msg01144.html
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
cessary to link in the
extra objects during stage2 where we have GCC and inline gets turned
on again.
I'm also not feeling comfy given the warnings about null dimensions
above.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
> Not this issue again :(.
> I thought I fixed it the last time it came up.
> -- Pinski
URL?
--
Kaveh R. Ghazi [EMAIL PROTECTED]
: acomp failed for build/gencondmd.c
make[3]: *** [build/gencondmd.o] Error 2
(I'm going to sleep, so I won't be able to test anything more until
tomorrow.)
--
Kaveh R. Ghazi [EMAIL PROTECTED]
plus this one:
http://gcc.gnu.org/ml/gcc/2006-01/msg00951.html
was sufficient to get a C-only bootstrap working on solaris2.10 using
cc for stage1.
I'm going to run a full test, but that'll take many many hours
longer.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
/2006-01/msg01332.html
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
compile the java
frontend as if the java FE was a target library. No extra
dependencies are introduced for bootstrap it just modifies the order
things get done.
It'll be more complicated for a cross-config, but at least everything
you need is in the local src tree.
--Ka
infrastructure
handle everything correctly?)
Looking at the testsuite results, many of the people who don't bother
to compile Ada do currently compile and test java. I suspect if we
make it harder to boot/test java then we'll see it's testing and
support decline.
-
> "Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
>
> | However with Tom's proposal, we need an existing java compiler for
> | our target.
>
> I don't believe the issues at hand here (Java specific case) are as
> severe as they sound from you
gnu.org/gcc-4.0 instead.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
holdup?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
acy and following the
rules. Notice I didn't say "technical merit" because that can be
learned. It's easier to teach technical stuff to an eager person than
to teach good manners to a jerk. :-)
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
plit out whether the format specifier could be null...
We could also create a new attribute name for the new behavior. This
would preserve backwards compatibility. I like this idea better.
Next you need to recruit someone to implement this enhancement, or
submit a patch. :-) Although given that y
fy their
arguments. This would require introducing the const_tree and
const_rtx typedefs Tristan suggested.
Something for stage1, obviously.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
101 - 200 of 303 matches
Mail list logo
