nce -- I had a bad stick of RAM that
caused all sorts of bizarre compile problems. I eventually isolated
the problem and replaced the DIMM; the compile problems went away.)
Good luck!
Best regards,
Anthony Foiani
k activity since they provide binary integer sizes not
otherwise available.
> Of course the generated code is not so efficient, so don't use such
> types in inner loops if you can help it!
Indeed.
Best regards,
Anthony Foiani
ompiler.
Looking at your example on OS, it seems you're concerned with an
array. The above technique should work just as well with arrays, and
there should be no extra runtime cost, since the entire stack frame is
allocated on function entry (SFAIK).
Hope this helps,
Anthony Foiani
an issue.
On the other hand, maybe something I said will trigger a gcc devel to
realize that there's an easy quadratic-to-linear algorithm fix. :)
Regardless, thanks very much for the excellent compiler.
Best regards,
Anthony Foiani
Anthony Foiani writes:
> Is there any particular reason that you're not taking advantage of the
> many person-years of effort that have been put into tools that do
> exactly this?
It's been pointed out to me that Khem very much knows of crosstool and
its ilk, being a committ
Khem Raj writes:
> I a script based on these instructions which is uptodate and builds eglibc
> based toolchains
>
> https://github.com/kraj/ct-scripts/blob/master/toolchain-eglibc.sh
Is there any particular reason that you're not taking advantage of the
many person-years of effort that have been
Apologies for continuing the somewhat off-topic thread...
Sebastian writes:
> Static analysis which work on source code are not ideal, either. They
> don't know which functions will be inlined by the compiler.
I'm pretty sure that the Linux kernel developers have some scripts
that parse object
[Apologies for the somewhat-off-topic nature of this post, but I felt
it would still be of interest to others on this thread.]
> "Jon" == Jon Turner writes:
Jon> I was well aware of the overhead that gprof can introduce,
Jon> but did not recognize that this overhead was not being
Jon> count
