search for: _g0

On Tue, Apr 08, 2014 at 04:08:13PM +0400, Robert Khasanov wrote: > Hi Reid, > > Would you approve your patches r203146 and r202774 to be backported to > 3.4.1? They fix stability issues in x86 asm. > Hi Robert, I was able to merge r203146, but it used a c++11 feature: std::string::back() which I replaced with std::string::at(std::string::size() - 1). r202774 was not merged,

>> Any thoughs? > > I'm now struggling to see how GCC justifies it. What if a different > translation-unit declared those variables in a different order? I also > can't get the same behaviour here, do you have a more complete > command-line? Ah, I see; the translation-unit that does the optimisation needs to have them as a definition (i.e. "= {0}") rather

..._-(.LPC0_0+8) .LCPI0_1: .long g0(GOTOFF) For ARM, codegen already keeps tracks of offset so it can implement the constant islands, so it should be able to see that the two globals are close enough that offset between them fits an immediate. Nick, will this work on MachO or can ld64 move _g0, _g1 and _g2 too far apart? BTW, what will gcc produce for void init(void *); extern int g0[100] __attribute__((visibility("hidden"))); extern int g1[100] __attribute__((visibility("hidden"))); extern int g2[100] __attribute__((visibility("hidden"))); void foo() {...