Hi Kenneth,> Well...strictly as LLVM IR I find externally visible incorrect behavior > unlikely, it's just a "different definition". For C and C++, I'd be > looking at more complicated variations of > > int main() > { > volatile int i = 1; > return 0; > } > > It's clear that the LLVM IR representation of i cannot be simply > IR-volatile qualified, as that load gets optimized out while C and C++ > won't optimize it out. I'd *hope* that DragonEgg and llvm-gcc both > leave the load of i in, when in --pedantic mode. [That is, I expect it > to take something more intricate than this elementary test case to > trigger any bugs here.]both dragonegg and llvm-gcc remove the volatile. I don't see why they shouldn't, since the program behaves exactly the same (as far as anyone external can tell) as if it had been left there. Ciao, Duncan.
On Tue, 26 Oct 2010 10:00:32 +0200 Duncan Sands <baldrick at free.fr> wrote:> Hi Kenneth, > > > Well...strictly as LLVM IR I find externally visible incorrect > > behavior unlikely, it's just a "different definition". For C and > > C++, I'd be looking at more complicated variations of > > > > int main() > > { > > volatile int i = 1; > > return 0; > > } > > > > It's clear that the LLVM IR representation of i cannot be simply > > IR-volatile qualified, as that load gets optimized out while C and > > C++ won't optimize it out. I'd *hope* that DragonEgg and llvm-gcc > > both leave the load of i in, when in --pedantic mode. [That is, I > > expect it to take something more intricate than this elementary > > test case to trigger any bugs here.] > > both dragonegg and llvm-gcc remove the volatile. I don't see why they > shouldn't, since the program behaves exactly the same (as far as > anyone external can tell) as if it had been left there.What if its address is taken, or it is a global variable? --Edwin
Hi Torok,>>> Well...strictly as LLVM IR I find externally visible incorrect >>> behavior unlikely, it's just a "different definition". For C and >>> C++, I'd be looking at more complicated variations of >>> >>> int main() >>> { >>> volatile int i = 1; >>> return 0; >>> } >>> >>> It's clear that the LLVM IR representation of i cannot be simply >>> IR-volatile qualified, as that load gets optimized out while C and >>> C++ won't optimize it out. I'd *hope* that DragonEgg and llvm-gcc >>> both leave the load of i in, when in --pedantic mode. [That is, I >>> expect it to take something more intricate than this elementary >>> test case to trigger any bugs here.] >> >> both dragonegg and llvm-gcc remove the volatile. I don't see why they >> shouldn't, since the program behaves exactly the same (as far as >> anyone external can tell) as if it had been left there. > > What if its address is taken, or it is a global variable?the volatile is only removed if it can be proved that doing so is harmless. It is not removed in the cases you mention. Ciao, Duncan.