OrangeC
OrangeC copied to clipboard
LADSoft
OrangeC Compiler And Tool Chain
run the libcxx tests and add an appveyor build to run them as well,
https://www.gnu.org/software/make/manual/html_node/Target_002dspecific.html Target specific variables at first, seem highly situational, but recently I actually ran into a situation where target specific variables are a way for ensuring that targets generate variables...
the backend generates spurious setne instructions... get rid of them where possible
investigate what happens when destructors at the end of a function are inlined. It seems like some spurious code is generated, for example in min_alloc::operator ==
Right now, function parameters are spilled to memory during inlining. Improve this so that when possible, the values can be kept in temporary registers.
get rid of bt_const, bt_volatile, and other similar qualifiers, using flags on the type instead. This will speed up the compiler, and use less memory at compiler time.
if you do something like this: ``` #define MYCODE \ { \ /* declare some vars */ \ /* do something slightly complicated, maybe a loop or maybe function calls...
The OCC Symbol table processing is one of the biggest single remaining uses of CPU time. It averages between 5 and ten percent of the compile time for typical C++...
https://open-std.org/JTC1/SC22/WG14/www/docs/n3047.pdf We actually have a lot of code that works for this as this is mostly an update to get C++ features in C, however the main workload I see...
I've been recently having an error where the assert for `LibFiles::ReadOffsets` in LibFilesLinker.cpp has been failing for an unknown reason, normally only occuring when using one of the `*compiles.bat` systems,...