At this point, I am fairly certain the front-end is correct. Unfortunately, the back-end is still unhappy.
That said, I've commented out the two lines in globalinit.c that are causing problems.
Chris, please have a look...thanks!
llvm-svn: 44823
between fetching the size of the expression map (for use as
the next integer id for an Expr*) and the creation of the
entry in the map could be non-deterministic. This could
cause the size of the map to be incremented prior to the
index being determine.
On Linux the map entry would be created first, causing the
map to the "size" to be incremented prior to it being
queried. On Mac OS X we had the reverse behavior. Now the
size is always queried prior to the new id being inserted
into the map.
This was the real cause of the bit-overrun triggered in
PR 1847:
http://llvm.org/bugs/show_bug.cgi?id=1847
Also reverted the change in patch 44813, which was a bogus
fix to this problem:
http://llvm.org/viewvc/llvm-project?rev=44813&view=rev
llvm-svn: 44822
Reimplement the xform in Analysis/ConstantFolding.cpp where we can use
targetdata to validate that it is safe. While I'm in there, fix some const
correctness issues and generalize the interface to the "operand folder".
llvm-svn: 44817
dataflow analysis over expressions and decls.
This should fix bug 1847:
http://llvm.org/bugs/show_bug.cgi?id=1847
Thanks to Török Edwin for providing a test case that
identified the problem.
llvm-svn: 44813
These should probably be something like:
CFI(".cfi_def_cfa_offset 16\n")
where CFI is defined to a noop on darwin and other platforms
that don't support those directives.
llvm-svn: 44803
using the minimum possible number of bytes. For little
endian targets run on little endian machines, apints are
stored in memory from LSB to MSB as before. For big endian
targets on big endian machines they are stored from MSB to
LSB which wasn't always the case before (if the target and
host endianness doesn't match values are stored according
to the host's endianness). Doing this requires knowing the
endianness of the host, which is determined when configuring -
thanks go to Anton for this. Only having access to little
endian machines I was unable to properly test the big endian
part, which is also the most complicated...
llvm-svn: 44796
methods are new to Function:
bool hasCollector() const;
const std::string &getCollector() const;
void setCollector(const std::string &);
void clearCollector();
The assembly representation is as such:
define void @f() gc "shadow-stack" { ...
The implementation uses an on-the-side table to map Functions to
collector names, such that there is no overhead. A StringPool is
further used to unique collector names, which are extremely
likely to be unique per process.
llvm-svn: 44769
Steve Naroff