Kayvan Aghaiepour Sylvan wrote:
>
> On Wed, Jun 30, 1999 at 12:30:55AM -0600, Michal Jaegermann wrote:
> >
> > I reported a while ago problems with lyx-1.0.3 on alpha and
> > [...]
> >
> > Here is a patch which makes math_iter.C "safe" in the face
> > of a broken compiler.
>
> I vote that we don't put in this patch since compiling without optimization
> is a good enough workaround for now.
This is, of course, up to you to decide what to do with the issue. I only
identified the problem beyond "it breaks" and proposed a workaround in
a code which works even when somebody is not using modified rpm specs
but compiles things directly.
Note that the replacement code may actually end up a bit faster on most
platforms, or roughly of the same speed, and it is NOT Alpha specific.
It is also possible to "fix" the problem, and shave off few cycles,
by using 'put_unaligned()' facility with a proper cast; but this one
would be definitely platform-specific even if code-simpler and cheaper
in cycles than a call to memcpy(). :-)
> I don't see much benefit in putting in platform-specific compiler bug
> workarounds
The advantage is that you can apply whatever optimizations are
applicable to all other functions in math_iter.C and you reduce
complexity in Makefiles and/or spec files and user compilation
instructions. For example, I *am* in a habit of reading various
READMEs, INSTALLs and NEWS files and originally I missed that tidbit
about math_iter.C troubles on Linux/Alpha.
> if we end up complicating the code (even slightly).
Note that the current code in this fragment is not a paragon of clarity.
I had to look at it at least two or three times before I caught full
implications of what it is really doing. It is still a mystery to me
why it frames stored value in these type bytes on both ends and why such
unaligned storage for pointers requiring all this 'memcpy' on in and out
in the first place. I guess that there are overriding reasons somewhere
else but they better be good ones. Even with that it seems to me that
what I wrote in a replacement is easier to comprehend - but this may be
just me.
Like I said above - this is not my project and not my decision.
Do whatever you feel is suitable. Compilers with the problem will hang
around for quite a while yet. If you "fix" this trouble by modifying
spec files it is equally easy, or maybe even easier, as turning off
optimization for math_iter.C to apply there a platform specific patch
without touching the main code at all. The current spec modifications,
which I proposed myself, I consider hacky and "voodoo" but I did not
have anything better at the time. And you can even just include the
patch in README for users to apply "by hand" if they wish to do so.
That is about it and I am outa here...
Take care,
Michal
[EMAIL PROTECTED]
