sting away const-ness and modifying it leads to a core
dump...
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
> "Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | I'd like to do for tree and rtx what I did for const char *,
> | namely constify those tree/rtx functions that aren't supposed to
> | modify their arguments. This would requir
27;m regtesting some
patches now.
Thanks!
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
YMMV,
--Kaveh
PS: I'm having a problem inbound email and I'm reading the list on the
web archive. So don't send me private messages or I'll miss them.
--
Kaveh R. Ghazi [EMAIL PROTECTED]
body in an if-statement
>
> Thanks!
> Simon
Older versions of gcc called this option simply `-W'. Try that
instead if you can't use a 4.x gcc. I'm able to produce a warning
about this problem with 3.4.6, for example.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
p.
Am I reading the situation correctly? Thoughts on fixing it?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
hatever solution we come up
with, I'd like to avoid duplicating setting STDC_0_IN_SYSTEM_HEADERS,
i.e. bad idea to do it once in gcc and once in fixincludes. Better is
if we can include the target config file somehow.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
system header. Then just see if you can
compile this:
# fake us into system header land...
#if __STDC__ - 0 == 0
#error "STDC_0_IN_SYSTEM_HEADERS"
#endif
If it fails, then fixincludes knows we have stdc_0_in_system_headers.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
hanks,
--Kaveh
Kaveh R. Ghazi [EMAIL PROTECTED]
y comments on these or any other issues I haven't thought of?
Thanks,
--Kaveh
PS: Patch below has been tested on Solaris 10 with my transcendentals
patch for PR 29335 via a c-only --disable-bootstrap and three-stage -j30
c-only bootstrap on Solaris 7 to ensure I g
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 zlib and intl?
>
> I do not think we should be including more such packages in the GCC
> repository. It&#
C will intentionally
bypass folding. So this particular case is not something I can use.
I don't know if this mpfr case should be setting the underflow flag or if
it's a bug. Calling the glibc tgamma doesn't seem to think it underflowed
when looking at fetestexcept().
--Ka
before exiting. Now, this isn't really necessary in practice since the
> memory will be freed anyway.
Jerry - does this fix it?
--Kaveh
2008-01-16 Kaveh R. Ghazi <[EMAIL PROTECTED]>
* toplev.c (toplev_main): Call mpfr_free_cache().
diff -rup orig/e
From: "Tom Tromey" <[EMAIL PROTECTED]>
"Kaveh" == Kaveh R GHAZI <[EMAIL PROTECTED]> writes:
Kaveh> + mpfr_free_cache ();
Why not just add a valgrind suppression for this?
There's little point in freeing things just before exit.
Tom
A valgrind
From: "Tom Tromey" <[EMAIL PROTECTED]>
"Kaveh" == Kaveh R Ghazi <[EMAIL PROTECTED]> writes:
Kaveh> A valgrind suppression only silences the error for valgrind. What
if
Kaveh> someone uses another memory checking tool? Better to fix it for
real
Kav
On Wed, 16 Jan 2008, Andrew Haley wrote:
> Kaveh R. Ghazi writes:
> > A valgrind suppression only silences the error for valgrind. What if
> > someone uses another memory checking tool? Better to fix it for real IMHO.
>
> Because it's not a bug? You're chang
, or header file mismatches can caused problems.
The file foo.c can be empty, you have to mention something.c in order to
invoke cc1 which has the info.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
;s in beta, and I've tested RC1 which worked fine
for me.
> The minimum version is supposed to be 2.3.0 [*]. Or is that page outdated?
> [*] http://gcc.gnu.org/install/prerequisites.html
That page is up to date WRT mpfr.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Mon, 21 Jan 2008, [ISO-8859-1] Manuel L?pez-Ib??ez wrote:
> On 20/01/2008, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> >
> > What does "gcc -v foo.c" say about GMP and MPFR?
>
> [EMAIL PROTECTED]:~/131656/build/gcc$ ./xgcc -v -c -B . foo.c
> [...]
>
27;s current or not.) I suppose that means the top level target
library tests are not handled in parallel for their multilibs.
I'd be interested in your results if you try it out.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
d out, since the concat call here is NULL terminated, the
problem is likely not in GCC sources. But the .i file would show for
sure.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Mon, 21 Jan 2008, Kaveh R. GHAZI wrote:
> > Exactly this issue. I am not sure how this can happen. My configure
> > options are above. I am using the Compile Farm.
>
> This happens because you linked GCC with a shared MPFR library in
> /opt/cfarm/mpfr-2.3.0/lib, but becau
my mbox, e.g.
"pine -f ~/foo". It'll contain this one message which you read and then
reply to. All the mail thread stuff then "just works".
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
norm3 = 1.7976931348623157e+308
sub = 1.1125369292536007e-308
zero = 0
Thanks but I meant: of the many if-aborts, which is triggered when running
under gdb? That will tell us which builtin is failing. (May be they all
are.) I don't know what the header looks like to know what if anything
should be changed by fixincludes.
--Kaveh
--
Kaveh R. Ghazi
CC). (Avoiding the need for
any headers to be fixincluded was one thing explicitly desired by Sun as
part of supporting GCC as a system compiler for OpenSolaris.)
Well, since it's not working I guess something got lost in translation? I
don't have access to solaris11, can you please help?
--Kaveh
--
Kaveh R. Ghazi
_builtin_fabs(__x_i),__DBL_MAX__), 0); })
It may pass isinf, but fail on a later if-abort. But hopefully this is the
only broken bit in that header on solaris.
--Kaveh
--
Kaveh R. Ghazi
it should work with any gcc version, not just the latest ones.
But that's up to them. In fixincludes we're free to make any choice we want
for mainline and/or branches as needed.
Thoughts?
Thanks,
--Kaveh
--
Kaveh R. Ghazi
hanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
and add you to the CC list. :-)
--Kaveh
--
Kaveh R. Ghazi
From: "Kaveh R. Ghazi" <[EMAIL PROTECTED]>
From: "Mike Stump" <[EMAIL PROTECTED]>
Perhaps others are rooted from generic parts of the compiler, not
objc++. Still it would be nice to clean them up.
Agreed. If you want to work on it, I'd be happy to help
Hi Uros,
This broke on x86_64 in the last day or so, I thought maybe you might know
what happened. (You touched config/i386 FP stuff recently.) I'm seeing a
regression in gcc.target/i386/pr32268.c as seen here:
http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01108.html
Right now the execute fa
if (r != ((double) a > (double) b))
32 abort();
33
34return 0;
35 }
(gdb) p a
$1 = 0
(gdb) p b
$2 = 0
"b" should be 1.0.
--Kaveh
--
Kaveh R. Ghazi
working on fixing anything in the FSF
sources? If not, maybe we need more Darwin maintainers.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
From: "Mike Stump" <[EMAIL PROTECTED]>
On Feb 21, 2008, at 8:31 PM, Kaveh R. GHAZI wrote:
Are current Darwin maintainers working on fixing anything in the FSF
sources?
Currently no. The transition to GPL v3 is problematic for us in the
short/mid term. :-( Longer term,
n
I'll raise it with the rest of the SC. Thanks for volunteering.
--Kaveh
--
Kaveh R. Ghazi
Nov 18 12:27:41 UTC 2005 i686 GNU/Linux
on x86_64 I get:
Linux gcc12 2.6.18-4-vserver-amd64 #1 SMP Fri May 4 01:21:52 UTC 2007 x86_64
GNU/Linux
Any help would be appreciated.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
> working on those FAIL?
Uros looked at this for me and thinks it might be due to using an old
libc on the cfarm. I'll let him explain exactly what's needed.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
, and happy hacking!)
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
on
> fsf.gnu.org that has all of the work and people don't have to use SVN
> or a snapshot for anything.
I support the final-release-then-close approach. But can we get a
volunteer to convert that branch to GPLv3... ?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Sat, 15 Mar 2008, NightStrike wrote:
> On 3/15/08, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> > I support the final-release-then-close approach. But can we get a
> > volunteer to convert that branch to GPLv3... ?
>
> How complicated is the task?
It's no
I'd like to hear how long they feel keeping 4.1 open is necessary.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
latter class of users get the same benefit that the clients
of distributors have had.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Mon, 17 Mar 2008, Mark Mitchell wrote:
> Kaveh R. GHAZI wrote:
>
> >> I too think that it would be a bad idea to switch the 4.1 branch to
> >> GPLv3,
> >
> > Can you please elabortate why?
>
> I think it's a bad idea to change the license on a r
From: "Mark Mitchell" <[EMAIL PROTECTED]>
Kaveh R. GHAZI wrote:
My understanding is that *users* of GCC are not impacted by the license
change.
Some users certainly are impacted by the license change -- there are in
fact quite a few companies that disallow their users
st-correct, but I understand not everyone shares my
enthusiasm for it. :-/
--Kaveh
--
Kaveh R. Ghazi
On Tue, 10 Jun 2008, Joern Rennecke wrote:
> > From: "Ian Lance Taylor" <[EMAIL PROTECTED]>
> > >Use CONST_CAST_RTX where necessary.
>
> On Mon, Jun 09, 2008 at 04:45:14PM -0700, Kaveh R. Ghazi wrote:
> > Or pass in a struct pointer to the "data&qu
ome of the easy stuff and make the branch diffs
much smaller.
We could also extend -Wc++-compat to warn about more things, using C++
reserved keywords like "class" in C comes to mind.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Thu, 19 Jun 2008, Kaveh R. GHAZI wrote:
> [...] I believe some work could be done (maybe even on mainline) to
> activate -Wc++-compat during bootstrap as a warning only, (not an
> error). E.g.:
>
> #pragma GCC diagnostic warning "-Wc++-compat"
>
> This
be fixed with simple casts. Again, IMHO
> > these non-controversial patches should go straight into mainline.
> > Once done we can -Werror this warning and avoid regressions.
>
> Strongly agree. Would you mind submitting the patch for activation of
> -Wc++-compat?
Done.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
rse. Mainline is blathering
lots of new warnings right now and I'd like to address those quickly.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Thu, 19 Jun 2008, Ian Lance Taylor wrote:
> "Kaveh R. GHAZI" <[EMAIL PROTECTED]> writes:
>
> > I'd like to avoid stomping on each other and duplicating work. Can you
> > tell me what you've already done and/or plan to do?
>
> I have a bunch of
On Thu, 19 Jun 2008, Kaveh R. GHAZI wrote:
> I'll do fortran next, then some top level files. I'll post in this thread
> which ones so we don't overlap. Please do the same.
Okay, I'm starting on the top level files. I'll go backwards through the
alphabet.
g. changing the fortran or ada frontends doesn't affect java. But IMHO
we shouldn't relax the testing rules for the overlapping parts if we want
to keep our bits all working nicely.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Fri, 20 Jun 2008, Diego Novillo wrote:
> On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
>
> > That aside, our current policy already allows e.g. not testing java if
> > your change is to a part of the compiler that can't possible af
From: "Joe Buck" <[EMAIL PROTECTED]>
On Fri, Jun 20, 2008 at 05:16:41PM -0400, Kaveh R. GHAZI wrote:
On Fri, 20 Jun 2008, Diego Novillo wrote:
> On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI <[EMAIL PROTECTED]>
> wrote:
>
> > That aside, our current p
On Sat, 21 Jun 2008, Andrew Haley wrote:
> Steven Bosscher wrote:
> > On Sat, Jun 21, 2008 at 12:41 AM, Kaveh R. Ghazi <[EMAIL PROTECTED]> wrote:
> >> Fundamentally, our philosophy has been to catch errors *before* they get
> >> into the repository. Sure one d
e to get them in the trunk and 4.3.x
branch.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
t out. :-)
Patch completed bootstrapped on x86_64-unknown-linux-gnu configured with
--enable-gather-detailed-mem-stats. Okay for mainline?
--Kaveh
2008-07-03 Kaveh R. Ghazi <[EMAIL PROTECTED]>
* alloc-pool.c (hash_descriptor, eq_descriptor,
ew minor nits.
Can you suggest a few things to try? E.g. I did --with-gc=zone and a
couple of errors cropped up. If there are other configurations that come
to mind, let me know.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
hecking options overnight.
Meantime, patch below bootstrapped with --with-gc=zone on
x86_64-unknown-linux-gnu. Okay for mainline?
Thanks,
--Kaveh
2008-07-04 Kaveh R. Ghazi <[EMAIL PROTECTED]>
* ggc-zone.c (lookup_page_table_if_allocated,
On Thu, 3 Jul 2008, Kaveh R. GHAZI wrote:
> On Thu, 3 Jul 2008, Diego Novillo wrote:
>
> > > Can you suggest a few things to try? E.g. I did --with-gc=zone and a
> > > couple of errors cropped up. If there are other configurations that come
> > > to mind, le
e->order = order;
> e->bytes = G.pagesize;
> e->page = a;
FWIW, this looks correct to me. (However I can't approve it).
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
From: "NightStrike" <[EMAIL PROTECTED]>
On 7/8/08, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
NightStrike <[EMAIL PROTECTED]> writes:
> I was under the impression that these would be cleaned up before the
> -W options were applied to the trunk.
It's pretty hard to clean up all the warnings f
On Tue, 8 Jul 2008, Kaveh R. Ghazi wrote:
> From: "NightStrike" <[EMAIL PROTECTED]>
>
> > On 7/8/08, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> >> NightStrike <[EMAIL PROTECTED]> writes:
> >>
> >> > I was under the impre
andled.
It seems to me that the union trick is just a way to violate type-safety
without seeing any warnings, same as casting to void* was. :-)
Needless to say, I don't understand this (IMHO convoluted) part of the
bitmap implementation. So I'd rather leave it to someone who does.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
cc.gnu.org/lists.html
Can we rename these lists (perhaps preserving an alias for the old names)
so that they reflect reality?
I would suggest NOT using "svn" in the list name in case we switch version
control software yet again, however unlikely doing so may be today.
E.g. gcc-cvs -> gcc-ch
On Sun, 20 Jul 2008, Richard Guenther wrote:
> > The mailing list webpage still refers to CVS:
> > http://gcc.gnu.org/lists.html
> >
> > Can we rename these lists (perhaps preserving an alias for the old names)
> > so that they reflect reality?
>
> I don't see a reason to rename the list.
> Richar
From: "Dave Korn" <[EMAIL PROTECTED]>
Hear, hear. The name of the list is an arbitrary label, not instructions
on what kind of client to use to access the repository; why, just for the
sake of making it "correct" in some non-functional sense of the word
should
everyone in the world have to adju
On Sun, 21 Sep 2008, NightStrike wrote:
> On Sun, Sep 21, 2008 at 12:36 PM, Brian Dessent <[EMAIL PROTECTED]> wrote:
> > Simon Hill wrote:
> >
> >> http://gcc.gnu.org/onlinedocs/gccint/index.html. (Of course I was
> >> horrified to see it's not written in C++, and it's loaded with macros
> >> ---
--Kaveh
PS: A related problem with shared libraries is that currently all binaries
(xgcc, collect2, cpp, gcov, etc) are linked with gmp/mpfr, whereas only
cc1 etc (stuff containing libbackend.a) really needs to be. It's probably
harmless, but may add a few microseconds of unnecessary startup time.
--
Kaveh R. Ghazi [EMAIL PROTECTED]
the system lib, header and compiler hasn't fundamentally
changed. You can still do it.
Now distributing a dynamically linked cc1 has added a shared lib
dependency. But as noted upthread, some people regard dynamic linking as
a virtue.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
uld you please
do that?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
wait until after the lockdown.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
an attachment in the PR, would you please take a look?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Tue, 12 Jun 2007, Kenneth Zadeck wrote:
> Kaveh R. GHAZI wrote:
> > I'm getting a new bootstrap failure today on sparc-sun-solaris2.10 which
> > I've filed under PR bootstrap/32312. GCC dies in stage1 building libgcc2,
> > I see that it's getting a SEGV b
ly patches that should be
> committed during the lockdown are fixes for regressions.
Timezone please? PDT?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
3.0/mpfr-2.3.0-rc1.tar.gz
> http://www.mpfr.org/mpfr-2.3.0/mpfr-2.3.0-rc1.zip
> [...]
> Please send success and failure reports to <[EMAIL PROTECTED]>.
Works for me on sparc-sun-solaris2.10 and sparc64-sun-solaris2.10.
Thanks,
--Kaveh
--
Kaveh
e being cast to double and therefore
maintains that it is not "normal".
So how do we detect or work around this promotion issue and discriminate
between the case where a float is promoted because of the variadic
prototype vs a user supplied cast or other user code?
Thanks
On Fri, 6 Jul 2007, Joseph S. Myers wrote:
> On Fri, 6 Jul 2007, Kaveh R. GHAZI wrote:
>
> > So how do we detect or work around this promotion issue and discriminate
> > between the case where a float is promoted because of the variadic
> > prototype vs a user supplied
On Sat, 7 Jul 2007, Joseph S. Myers wrote:
> On Sat, 7 Jul 2007, Kaveh R. GHAZI wrote:
>
> > Ok, how about e.g. __attribute__ ((__type_generic__)), which would only be
> > allowed on variadic functions?
>
> I don't think we want this available to user code, just to
On Sat, 7 Jul 2007, Joseph S. Myers wrote:
> No, that's something else entirely (a "float" old-style parameter
> declaration corresponds to a "double" argument in a prototype). It's
> convert_arguments that handles converting to prototype types and default
> argument promotions for arguments not
sn't documented AFAICT, I was just
following that example. We don't want to confuse users into thinking they
can use it IMHO. What do you suggest?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
lity because
> some builtins modify multiple values, so a simple return value is
> insufficient, plus this worked with older versions of gcc so our users
> are used to it syntax-wise.
I don't know about using reference types, but there are several math
builtins that "return" mul
libgcc2.c -mcpu=v9
-auxbase-strip _fixunssfdi.o -g -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -version
-fkeep-inline-functions -fPIC -o libgcc2.s
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
libgcc2.i.gz
Description: libgcc2.i.gz
On Fri, 24 Aug 2007, Brian Sidebotham wrote:
> This ICE is caused by the following patch:
>
> 2007-08-10 Kaveh R. Ghazi <[EMAIL PROTECTED]>
>
> * system.h (CONST_CAST): New.
> * c-decl.c (c_make_fname_decl): Use it.
> * c-lex.c (cb_ident, lex_str
On Sun, 26 Aug 2007, Richard Guenther wrote:
> > +#if defined(__GNUC__) && GCC_VERSION != 4000
>
> There were 4.0.0, 4.0.1, 4.0.2, 4.0.3 and 4.0.4 releases.
Yes, and... ?
GCC_VERSION == 4000 for all of them.
--
Kaveh R. Ghazi [EMAIL PROTECTED]
27;d be happy to address your
issue as well if you help me with more info.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Tue, 28 Aug 2007, Brian Sidebotham wrote:
> > 2007-08-26 Kaveh R. Ghazi <[EMAIL PROTECTED]>
> >
> > * system.h (CONST_CAST): Avoid union for gcc-4.0.x.
> >
> > diff -rup orig/egcc-SVN20070825/gcc/system.h egcc-SVN20070825/gcc/system.h
> > --- or
> + && INSN_P (XEXP (PATTERN (insn), 0)))
> + next = delete_related_insns (insn);
> +}
> +
>obstack_free (&unfilled_slots_obstack, unfilled_firstobj);
>
>/* It is not clear why the line below is needed, but it does seem to be.
> */
This second patch also allows bootstrap to complete on my sparc box.
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
ERN (insn)) == USE
> + && INSN_P (XEXP (PATTERN (insn), 0)))
> + delete_insn (insn);
>if (!JUMP_P (insn))
> continue;
FWIW, this patch fixes the problem. Test results here:
http://gcc.gnu.org/ml/gcc-testresults/2007-09/msg00313.html
I'll try again
te__ ((malloc));
> void* operator new[](std::size_t) throw (std::bad_alloc);
> void operator delete(void*) throw();
> void operator delete[](void*) throw();
If this is accepted, IMHO you should use __attribute__((__malloc__)) not
__attribute__ ((malloc)).
Th
gt;
* config/xtensa/lib2funcs.S (__xtensa_sync_caches): Use an ISYNC even
if there is no i-cache.
Is anyone else having a similar problem?
Thanks,
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
egcc-SVN20070909/gcc/postreload.c:1018
1018 reg_state[i].store_ruid = reload_combine_ruid;
(gdb)
Any luck figuring out which patch broke it?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
think you should only do
this when profile feedback indicates you've hit a heavily used spot in
your code.
E.g. should we turn printf("ab") into putchar('a'); putchar('b'); ?
I'd say not, unless that code was a hot spot.
One simplification
On Wed, 10 Oct 2007, Joe Buck wrote:
> On Wed, Oct 10, 2007 at 12:12:25AM -0400, Kaveh R. GHAZI wrote:
> > One simplification I don't believe we do yet, that should always be a win,
> > is turning: sprintf (foo, "%c", bar); into:*foo = bar;
>
> You ne
,
speed timings) so the RM and perhaps middle-end maintainers can weigh the
risk vs benefit and make an informed decision.
So far you've only shown us the "risky" part, i.e. the patch.
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
eel about "maybe", is the glass half full or half empty?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
On Sun, 18 Nov 2007, David Edelsohn wrote:
> >>>>> Kaveh R GHAZI writes:
>
> Kaveh> I think the answer is "maybe". In the past we have counted
> compile-time
> Kaveh> savings as appropriate for stage3 regression fixes. However IMHO you
> Kav
ion to #2, hard fail for anything less than mpfr-2.3.0.
I have no strong opinion on which way to go.
Thoughts?
--Kaveh
--
Kaveh R. Ghazi [EMAIL PROTECTED]
201 - 300 of 303 matches
Mail list logo
