>What part of "reasonable doubt" don't you seem to comprehend?
For there to be doubt that the crippeling is not intentional, one would need arguments for what reason the crippeling was done. You have not given any half plausable reason, and though I trust intels lawyers will at least achieve a more credible attempt, until I have seen it, unlike you, I will not state as fact that nothing illegal is going on. The jury is still out there so to speak.
>Of course it would take a very unique individual to consider
>any of these a defenition for 'alive'.
Lets cut the semantics; the issue was wether or not Fortran performance was still relevant to AMD or Intel, and my point is that clearly it is. Elsewhere in this thread you said that AMD should make their own compiler, and actually, they did, they hired Pathscale to do a 64bit compiler for them. Guess what, they didnt ask them for C++, Python or any other "hot" language, but FORTRAN. You tell me *why* when fortran is as dead as you claim ? Are they idiots, or perhaps would they know what matters in the real world ?
>Funny, last I knew we were talking law, not science. So
>using a scientific definition of legal terminology is about
>as logical as, well, you
No, we where talking compatibility, proof something works. you claimed some testing would proof a hacked compiler would work, when clearly at best it can give a good indication. Through testing you can only prove a negative, ie, if it doesnt work. But Ill admit that is sematics too.
>Funny, how the US Military fully backed trusted a
>vendor-unsupported fix to a compiler for their sickeningly
>accurate and highly critical takeof and landing proceedure
>software (AFTERPS)
unless you can provide some evidence to back up these claims, Ill just dismiss them as hot air, possibly SVFF's. As an argument such claims have zero value. Futher more your example is barely relevant, since you are talking about an entirely different situation, where you produce standard software that can be (and will) be fully tested, debugged and qualified with controlled releases. That is very much unlike the typical fortran situation where code is often created or modifiled and then compiled on the fly by the researchers/scientists/whomever and excessive ammounts of time can not be spent to test the binaries ad absurdum. finally, and most importantly, I hope you are not claiming this unsupported patch was applied to gain a couple percent performance rather than to get around an essential and obvious bug.
>Or maybe you just don't know anything about programming, so
>you have no idea what segfaulting means?
If you read the article,you should uderstand the issue. The code the compiler generated was not broken, they experimented with optimization flags which gave unexpected results since they assumed forcing SSE support would generate code that would run on athlons too. But using the normal flags, the code ran just fine, even on the athlons, just slower than optimal, and that is the issue we are discussing here. They didnt need to hack it to get it working, they hacked it to get better performance.
>Because most FORTRAN programmers are using either HP's
>compiler or GCC.
or pathscale. and most C developpers use MSVC or GCC, but who the hell cares ? The issue is the intel compiler, not HPs or GCC.
= The views stated herein are my personal views, and not necessarily the views of my wife. =
For there to be doubt that the crippeling is not intentional, one would need arguments for what reason the crippeling was done. You have not given any half plausable reason, and though I trust intels lawyers will at least achieve a more credible attempt, until I have seen it, unlike you, I will not state as fact that nothing illegal is going on. The jury is still out there so to speak.
>Of course it would take a very unique individual to consider
>any of these a defenition for 'alive'.
Lets cut the semantics; the issue was wether or not Fortran performance was still relevant to AMD or Intel, and my point is that clearly it is. Elsewhere in this thread you said that AMD should make their own compiler, and actually, they did, they hired Pathscale to do a 64bit compiler for them. Guess what, they didnt ask them for C++, Python or any other "hot" language, but FORTRAN. You tell me *why* when fortran is as dead as you claim ? Are they idiots, or perhaps would they know what matters in the real world ?
>Funny, last I knew we were talking law, not science. So
>using a scientific definition of legal terminology is about
>as logical as, well, you
No, we where talking compatibility, proof something works. you claimed some testing would proof a hacked compiler would work, when clearly at best it can give a good indication. Through testing you can only prove a negative, ie, if it doesnt work. But Ill admit that is sematics too.
>Funny, how the US Military fully backed trusted a
>vendor-unsupported fix to a compiler for their sickeningly
>accurate and highly critical takeof and landing proceedure
>software (AFTERPS)
unless you can provide some evidence to back up these claims, Ill just dismiss them as hot air, possibly SVFF's. As an argument such claims have zero value. Futher more your example is barely relevant, since you are talking about an entirely different situation, where you produce standard software that can be (and will) be fully tested, debugged and qualified with controlled releases. That is very much unlike the typical fortran situation where code is often created or modifiled and then compiled on the fly by the researchers/scientists/whomever and excessive ammounts of time can not be spent to test the binaries ad absurdum. finally, and most importantly, I hope you are not claiming this unsupported patch was applied to gain a couple percent performance rather than to get around an essential and obvious bug.
>Or maybe you just don't know anything about programming, so
>you have no idea what segfaulting means?
If you read the article,you should uderstand the issue. The code the compiler generated was not broken, they experimented with optimization flags which gave unexpected results since they assumed forcing SSE support would generate code that would run on athlons too. But using the normal flags, the code ran just fine, even on the athlons, just slower than optimal, and that is the issue we are discussing here. They didnt need to hack it to get it working, they hacked it to get better performance.
>Because most FORTRAN programmers are using either HP's
>compiler or GCC.
or pathscale. and most C developpers use MSVC or GCC, but who the hell cares ? The issue is the intel compiler, not HPs or GCC.
= The views stated herein are my personal views, and not necessarily the views of my wife. =