On 12/12/2013, at 5:59 PM, GitHub wrote:
> Log Message:
> -----------
> Add support for gcc-4.8
>
The Python build (only) checks if gcc-4.8 --version works on Linux.
If so, a special gcc-48 toolchain is used. This is the same as the
usual gcc toolchain, except it passes "-fno-aggressive-loop-optimization"
to the compiler(s).
Hopefully this will prevent gcc miscompiling various code including
probably libJudy, which is used heavily by the GC. This may or may
not fix the problem building Felix with gcc-4.8. It seems likely,
since gcc itself warns of the problem. Unfortunately this inhibits
many loop optimisations other than the new ones causing the problem.
A rough idea of the problem: in C you're not allowed to index
past the end of an array. So strictly speaking this code is not
conforming C:
struct X { char a[1]; };
struct X *p = malloc(100);
char a = p->a[2]; // array is only 1 long!
Gcc 4.8 does aggressive loop optimisations by estimating
bounds on loop iterations, if it detects a non-compliant piece
of code all bets are off.
That's the theory. In practice this kind of thing is done quite
often by low level code. I think this is a mistake, but the compiler
is entitled to do this and still be considered conforming.
In C++ the situation is quite different. In C++ there is no notion
of conforming code.
In both systems, there's a trade off between defining what the standard
fails to do (undefined behaviour) and optimisation. Break too many real
world programs and your market share will decline. Fail to provide good
performance and the same thing will happen.
I think these optimisations are overkill, that is, they should be off by
default.
Given that C has such a weak type system, one can only expect it to be
twisted around to do things which it fails to support properly. To then go
on to optimise such programs into errors is tantamount to claiming
the type system is adequate, which it isn't.
Just as an example of type punning which is miscompiled without
the -fno-strict-aliasing switch, Felix does this systematically:
struct A { int a[3]; };
struct T { int a1; int a2; int a3; };
and casts between them. It's fairly reasonable to assume an array
and struct of the same number of elements are layout compatible.
These casts literally correspond to the equivalent of tuples and
arrays in Felix. But they're not strictly conforming C, and the behaviour
in C++ is undefined. The casts break strict aliasing rules.
In this case I could probably fix the problem, but wouldn't be
trivial. It's related to the idea that tuples have to be "written out
literally" in a program and so are short enough to provide
a constructor with mem-initialisers.
Arrays on the other hand cannot have constructors with
mem-initialisers, you have to use assignments in the constructor
body of an enclosing class (in C++89 .. C++11 fixes this I think).
So Felix "cheats" and uses a tuple representation to construct
all tuples literally, including arrays, then casts it to an array
if it's an array.
We definitely do NOT want all arrays to have constructors
element by element, think of an array of 10K elements .. :)
--
john skaller
skal...@users.sourceforge.net
http://felix-lang.org
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
