On Wed, 11 Oct 2006, Mark Mitchell wrote:
> Kaveh R. GHAZI wrote:
> > On Mon, 9 Oct 2006, Mark Mitchell wrote:
> >
> >> Kaveh R. GHAZI wrote:
> >>> Has there been any thought to including GMP/MPFR in the GCC repository
> >>> like we do for
ion! That certainly helps
increase my confidence. If anyone else has additional info they can
contribute I'd very much appreciate it.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
ith an
older MPFR version and with current versions. It did the "right thing" in
all cases.
Okay for stage1?
Thanks,
--Kaveh
PS: nuts, I just realized I need up update install.texi accordingly. If
this patch is acceptable I'll post a followup patch f
e info")
shortly.
Ironically given the nature of this patch, configure is saying I need to
get a more recent makeinfo in order to build the docs. :-)
Thanks,
--Kaveh
2006-10-13 Kaveh R. Ghazi <[EMAIL PROTECTED]>
* configure.in: Require G
On Fri, 13 Oct 2006, Kaveh R. GHAZI wrote:
> On Thu, 12 Oct 2006, DJ Delorie wrote:
>
> >
> > > Okay for stage1?
> >
> > Ok, assuming everyone agrees to those versions ;-)
>
> Great, thanks. I haven't heard anyone disagree with those versions, so
&
older libraries at the moment.
The configury bit was approved by DJ for stage1, but do you see any reason
to hold back? Or is this posting sufficient warning that people may need
to upgrade? (I.e. people should start upgrading their libraries now.)
http://gcc.gnu.org/ml/gcc/2006-10/msg00284.h
or later, but I would suggest the latest, which
is version 4.2.1. (Also don't forget the mpfr cumulative patch!)
Regards,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
You'll need to name the patches file something meaningful.
I'd be happy to upload these once I get access (unless someone beats me to
it).
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Mon, 23 Oct 2006, Kaveh R. GHAZI wrote:
> I'd be happy to upload these once I get access (unless someone beats me to
> it).
Ben - Gerald uploaded the files. (Thanks Gerald!)
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
S (no problem under Mac OS X)
> or change the TCP window scaling[*] if you can.
>
> [*] http://lwn.net/Articles/92727/
FWIW I was using solaris10, and I had no problems accessing the GMP site.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
est -d" fragment
would be appropriate. Would you please submit that one line change for a
configury maintainer to review?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
test instead.
> Paolo
Shrug. Be my guest, I don't feel that strongly about it.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
ll work on a patch which
> just disables the check for Darwin.
As was noted, if you disable the check, you'll simply get a build failure
in the middle-end which now uses gmp/mpfr. Let's see if you can get these
libraries installed before going down that road.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
cc/2006-10/msg00167.html
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
on both x86 and powerpc.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
quot; checks in gcc-4.3. If you avoid passing an
--enable-languages configure flag that takes it out, it'll be in the
default. Older releases may also simply work if you merely tell gcc
where to find gmp/mpfr.
I don't know if telling older gcc release where to find gmp/mpfr violates
your &qu
ol over those, the
GMP/MPFR maintainers do.
Do we have a GCC FAQ somewhere? Maybe we can add GMP/MPFR build problems
and solutions there. You can add your experiences to that collection.
I'm sorry you've had trouble, hopefully all this is a one-time thing that
doesn't cause too
ing the info in more than one
place. If prerequisites needs more info, I'll fill in there better.
Thoughts?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
e latter issue an appropriate warning?
> Gerald
Sure, I'll try and get to it this week.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Tue, 31 Oct 2006, Ian Lance Taylor wrote:
> "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:
patches/2000-10/msg00756.html
Perhaps we could take a second look at this decision? The average system
has increased in speed many times since then. (Although sometimes I feel
like bootstrapping time has increased at an even greater pace than chip
improvements over the years. :-)
--K
On Tue, 7 Nov 2006, DJ Delorie wrote:
> > Okay for mainline?
>
> Ok. src too, please.
>
Sorry, I don't have access to that repo.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Tue, 7 Nov 2006, Mike Stump wrote:
> On Nov 7, 2006, at 3:48 PM, Kaveh R. GHAZI wrote:
> > Perhaps we could take a second look at this decision? The average
> > system has increased in speed many times since then. (Although
> > sometimes I feel like bootstrapping tim
patching middle-end RTL files
and especially backend target files to try using RTL checking to validate
their patches if they have enough spare cpu and time.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Thu, 2 Nov 2006, Gerald Pfeifer wrote:
> On Mon, 30 Oct 2006, Geoffrey Keating wrote:
> > configure: error: Building GCC requires GMP 4.1+ and MPFR 2.2+. Try the
> > --with-gmp and/or --with-mpfr options.
>
> Indeed, as a user I ran into problems with this on a system where both of
> these act
; - Matt
I tend to be reluctant about run tests because they don't work with a
cross-compiler. Would you please tell me specifically what problem
checking at runtime would prevent that the existing compile test doesn't
detect?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
e to pass my various tests using this mpfr hooked up to gcc
mainline to evaluate transcendentals at compile-time.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
Thanks. http://www.mpfr.org/mpfr-current/mpfr-2.2.1.tar.bz2
Patch below installed as obvious after testing on sparc-sun-solaris2.10.
--Kaveh
2006-12-02 Kaveh R. Ghazi <[EMAIL PROTECTED]>
* configure.in: Update MPFR version in error message.
* conf
was to put my stuff in another directory (e.g.
/usr/local/foo) then I could safely put that directory ahead of /usr and
not worry about wierd side-effects from unrelated things. Try installing
gmp (and mpfr) in their own dir and use --with-gmp=PATH when configuring
gcc. Let me know if that works
me to update their personal
installations and regression testers before installing this. Does one
week sound okay? If there are no objections, that's what I'd like to do.
Okay for mainline?
Thanks,
--Kaveh
2006-12-02 Kaveh R. Ghazi &l
If you're missing mpfr *entirely*, and request fortran to be built, then
it'll give you an error message. But it does that already. I simply
update which version of mpfr that it recommends in this case.
Tested on sparc-sun-solaris2.10, and installed as obvious.
--Kaveh
and MPFR. But a simple solution would be to punt if base is not a power
of 2 and let the builtin evaluate to a library call.
I'm not sure if these issues come up for fortran in prior releases. I
think i370 was removed before 4.0/f95 and decimal floats were added in
4.2, which is not y
On Mon, 4 Dec 2006, Joe Buck wrote:
> On Sat, Dec 02, 2006 at 12:01:45PM -0500, Kaveh R. GHAZI wrote:
> > Hi Vincent, thanks for making this release. Since this version of mpfr
> > fixes important bugs encountered by GCC, I've updated the gcc
> > documentation and
eciate.
DJ, as a build machinery maintainer, you are authorized to approve such a
patch. Is anything holding you back?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
edback I sent, and
(possibly) change to creating static libs with no install:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00083.html
I never saw an updated version. I'd like to test it and see if we can get
it aproved. Then the discussion moves on to whether to include the
sources or not (which I agr
sed. Perhaps not even
all of them require the warning. Or at least not all of them necessarily
have to be in the first go around.
Care to submit a patch?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
and extrapolating in this discussion so
far IMHO.
Such a flag has been already suggested more than once. Here are two cases
I found without trying too hard.
http://gcc.gnu.org/ml/gcc/2006-12/msg00507.html
http://lists.gnu.org/archive/html/bug-gnulib/2006-12/msg00151.html
Is there some technical reason
On Sat, 30 Dec 2006, Gabriel Dos Reis wrote:
> "Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | I'd like to see a -Warning flag added to GCC to spot places where GCC does
> | something potentially too aggressive. Having that would do two
ely agree we need one or more new x86 maintainers. We are
already discussing the issue, hopefully you'll see something posted soon.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
h".
Predicate functions are automatically prototyped in "tm-preds.h". I
believe that file gets pulled in by "tm_p.h" also.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
any of these are important enough to hold up the
release, most appear not. Maybe Eric can comment.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
nfig.in?revision=120315&view=markup
I think a patch adding descriptions to the docs would be an improvement.
Would you like to submit one?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
hout any extra flags? Etc.
Any thoughts would be appreciated.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Tue, 13 Feb 2007, Mark Mitchell wrote:
> Kaveh R. GHAZI wrote:
>
> > What I need to work out is what combinations of target and flags this
> > problem occurs under. E.g. is this problem sparc-solaris only or does it
> > occur on any target using pic? Or is it some
:3705: error: undefined machine-specific constraint at
> this point: "Y"
> config/i386/i386.md:3705: note: in operand 1
> make[2]: *** [s-output] Error 1
anybody else seeing this?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
about MPFR WRT mainline, we should warn users for
one release the same way we do for deprecated features. Hopefully by the
time 4.3 is out (a year from now based on history) it'll be less of an
issue because a new enough version of MPFR will be included in most
distros.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Tue, 20 Feb 2007, Andi Kleen wrote:
> "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.
>
> For me
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
> > seri
in. I think that would help clear up the
backlog while still allowing people to comment *before* the patch goes in.
I think it would be fair to directly CC: relevant maintainers in these
cases so they don't miss the patch by accident.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
s? Perhaps you could also measure memory usage for all three
solutions? I think that would give us a complete picture to make an
informed decision.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
6 would
get hosed worse because it's 16-bit accesses are not as efficient as it's
8 or 32 bit ones.
http://gcc.gnu.org/ml/gcc/2007-03/msg00763.html
I assume you tested on Darwin? Can you tell me if it was ppc or x86?
Thanks,
--Kaveh
--
Kaveh R. Gh
then perhaps it would
be worth investigating this route. Until then, I wouldn't fix what isn't
broken. :-)
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01176.html
Hope this helps,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
(and gfortran.dg/cray_pointers_2.f90 when using -fPIC)
The cray_pointers_2.f90 failure is already noted under PR30774, it's a
solaris issue not necessarily specific to fortran.
The other two, I've opened PRs 31615 and 31616.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
care would be necessary to ensure that the
resulting flags don't completely hose other large classes of apps. But
IMHO once you decide to do per-target flags, something like this seems
like the natural conclusion.
http://www.coyotegulch.com/products/acovea/
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
esses are:
1. Do nothing for non-C.
2. Punt.
3. Declare signgam and proceed.
4. Ditto.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
(set (mem (sym_ref "_signgam")) (const_int VALUE)))
>
> and let the user worry about what happens if they haven't included the correct
> header file?
I'm doing this at the tree level, so AIUI I have to be mindful of type,
scope and conflicts. I also
the above PI case, folding atan also allows GCC to fold
the mult.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
ed on i686 if
that matters.
When I back down to expect-5.42.1, the testsuite results go back to
normal. Anyone else seeing this?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
> From: Andrew Haley
>
> Kaveh R. Ghazi writes:
> > After I upgraded to expect-5.43, I noticed that I'm getting extra
> > java failures on the 3.3 branch on x86_64-unknown-linux-gnu. Other
> > gcc branches do not have problems.
> >
> >
tin_1() given we have
ccp_fold_builtin() ?
Would someone please enlighten me?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
collection heuristics were
changed from hardcoded to dynamic as of 3.3 and so comparing newer gcc
to 3.2 or previous isn't apples-to-apples.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
4. Not critical.
The regression in 4.0 is pretty bad, definitely file a PR. See:
http://gcc.gnu.org/bugs.html for instructions. It may be a known
problem or a new one, let's find out.
If you can't reduce the .ii testcase, don't worry so much. Just bzip
it and submit it as a c
cuts the 48 hours to
single digits.
What I don't get is, why isn't autoconf setting CONFIG_SHELL to
something sane and re-exec-ing? I heard rumor that 2.59 was supposed
to do that automagically.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
utomatically updated.
Also, when I click on the link above, it doesn't follow down the page
to the anchor. I'm not sure why that is. Gerald?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
t REEXECED
exec $CONFIG_SHELL $0 $@
fi
It's untested so you may need to tweek it. But it conveys my idea.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
he if-stmt.
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02109.html
Nathanael, can you please take a look?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
What do you think?
> Gerald
I like prepending a string, for example target= or triplet=, etc.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
x27;s text label? E.g.:
alpha*-*-*
That way, the part people actually read in the document still uses
asterisk that they are used to seeing.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
rvative. I think we should fix it there also.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
> > Would you care to take care of that? (I am travelling, and don't have
> > much time online.) If so, I'd be very appreciative.
Sure but...
> Done.
> I'll apply to mainline soon.
> Paolo
Aleady done.
Thanks Paolo! :-)
--
Kaveh R. Ghazi [EMAIL PROTECTED]
> On Thu, 14 Apr 2005, Kaveh R. Ghazi wrote:
> > I guess "x" is fine with me. However can we use "x" only in the
> > anchor and not the link's text label? E.g.:
> >
> >alpha*-*-*
> >
> > That way, the part people actu
05/msg01233.html
So we're not quite OK yet.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
er the fact.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
/c++ intersection could be
similarly refined.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
> In fact, i had someone recently send me a *104 page PDF file* on how
> RTL really works organized in a way that most developers would
> probably find better.
So share it with the masses, put it in the wiki.
--
Kaveh R. Ghazi [EMAIL PROTECTED]
is patch.
But I don't see fprintf_unlocked on my linux-gnu box nor does it
appear in e.g. glibc-2.3.4. Any ideas?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
therefore neither fputs_unlocked or fprintf_unlocked should transform
into fputc_unlocked.
Dave, does hpux have fprintf_unlocked or was mentioning it a mistake?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
mplementations will need a language to specify
exactly what they do.
Alternatively or maybe in addition, we could have a way to say "like
printf, but delete these specifiers, and these modifiers. Then add
these other things." Ultimately if a complete language is available
as well as &
's
behavior based on the C standard in effect when compiling it.
Therefore if we implement an inherit, it should force the user to
choose "inherit printf90", "inherit printf99" or "inherit printfGNU".
Or something along those lines.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
for users?)
Anyway, I conclude we need both fixed and the adjustable inheriting.
So "inherit printf" for BFD and "inherit printf90" (etc) for other
implementations. That's easy enough to code up.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
lace so
that we'll know if we introduce bugs into bfd in this conversion.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
iolating the rules
keeping "sec" in the front.
So I favor rewriting _bfd_default_error_handler to do the safer thing
which is to use natural arg positions. Then create a format check
with only the stuff you need, not the whole printf style.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
e, then we can perhaps evaluate how to keep this from
regressing.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
bout that?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
rly&late switch is off does
-Wuninitialized degenerate to 2 (early-only) or 3b (late-only) in your
mind? If 2 then IMHO it's not horrible but not useful, if 3b then I
don't like it.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
e 3a. (I'm still not
sure what happens in #4 when the flag is off.)
Why not try your patch and see how many of the meta-bug PRs it solves?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
s
life. If you were only interested in concurring opinions, you should
have said that and I could have saved myself some typing. :-/
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
ke gcc to have it,
but it seems to be an orthogonal project.
--
Kaveh R. Ghazi [EMAIL PROTECTED]
> jeff
If it helps, I withdraw my objection.
Out of curiosity, I bootstrapped your patch with -Wuninitialized=2 in
STRICT2_WARN and got 63 hits within GCC on x86_64-unknown-linux-gnu.
That's not too terrible to fix, if we decide to add that flag to the
bootstrap sequence.
op-base/vect-83_64.c.svn-base",
0xFFBEF1F8) = 0
lstat("gcc/testsuite/gcc.dg/vect/vect-83_64.c", 0xFFBEE900) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/props/vect-11.c.svn-work", 0xFFBEF1F8) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/prop-base/vect-11.c.svn-base", 0xFFBEF1F8)
= 0
lstat("gcc/testsuite/gcc.dg/vect/vect-11.c", 0xFFBEE900) = 0
stat("gcc/testsuite/gcc.dg/vect/.svn/props/vect-30.c.svn-work", 0xFFBEF1F8) = 0
--
Kaveh R. Ghazi [EMAIL PROTECTED]
> On Sat, 2005-11-19 at 10:14 -0500, Kaveh R. Ghazi wrote:
> > Hi Dan,
> >
> > (BTW, sorry for the reposted messages.)
> >
> > While I was waiting for some svn commands to finish (cleanup,
> > update) on my solaris2.7 box, which has a slow filesyste
> On Mon, Nov 21, 2005 at 10:20:26PM -0500, Kaveh R. Ghazi wrote:
> > Some OSes (like linux I believe) cache the lookups of the parent
> > directories so the speedups are not as pronounced. However GCC is
> > developed, and SVN is probably used, on many more places
://lkml.org/lkml/2005/11/9/290
But while I'd like to see openat etc adopted in SVN, unfortunately
that doesn't help systems without those calls like older solaris2,
e.g. solaris2.7.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
> Steve Ellcey <[EMAIL PROTECTED]> writes:
>
> | Has GCC 3.4.5 been officially released?
>
> Yes, tarballs are on gcc.gnu.org and ftp.gnu.org since Dec 1st. Only
> official announcement is missing.
What are you waiting for?
--
Kaveh R. Ghazi [EMAIL PROTECTED]
onths going back to June.
As of the May page, you start getting results again.
I don't know how long this has been broken. (If it's been broken
since May, it would be funny that nobody noticed.)
Would you please look into it?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
> I just came to think of contrib/warn_summary... how does that filter
> out different stages warnings since this change?
> Cheers,
> /ChJ
It doesn't work anymore, I'll fix it eventually.
--
Kaveh R. Ghazi [EMAIL PROTECTED]
hat patch fixed this to evaluate how hairy it
is. Andrew do you remember?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
2004:
http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg01290.html
http://gcc.gnu.org/ml/gcc-testresults/2004-07/msg01240.html
So it seems that if we backport the above patches and remove the first
two (passing) xfails we'd be result-clean. We could remove the third
(currently failing) x
--Kaveh
PS: I'm going to try applying the patch to 3.4 and see if it fixes
tinfo1.C.
--
Kaveh R. Ghazi [EMAIL PROTECTED]
ps related problem.
For reference, here's what I tested against current 3.4.x. It may be
worthwhile installing it if we can figure out what it fixes apart from
tinfo1.C. (I'm CC'ing gcc-patches now.)
--Kaveh
2005-12-23 Kaveh R. Ghazi <[EMAIL PROTECTED]>
1 - 100 of 303 matches
Mail list logo
