On 17/10/17 13:49, Xi Ruoyao wrote: > On 2017-10-17 12:20 +0200, David Brown wrote: >> Libraries such as avr-libc are written with gcc, in C with gcc >> extensions and possibly inline assembly. Those developers suffer from >> exactly the same issues. And pure assembly does not help - it is the >> interaction between assembly and C that is at issue here. > > Yes. But library maintainer (maybe the developer himself/herself) can > track and fix these issues more easily. Certainly it is easier for a few experienced developers to handle these things, rather than for "ordinary" developers. In this particular case, the guy that found this problem is in this class - he makes code generators from state machine descriptions. > If we have a well-known low-level > library libX for an embedded environment, the maintainer would fix the > issues before the release of new GCC version. Then we can simply put > "please use libX version x.x or newer" in Porting to GCC X page. > > It's cleaner to put low-level assembly code in one function and call it > in C. The calling convention is stable. > >>> >>> We can't forbid GCC to perform new optimizations. The users who don't >>> care about embedded developing would be angry. >> >> I don't want to forbid new optimisations in gcc - I am very happy to see >> steadily more optimisations, as are most embedded developers. Better >> optimisations means we embedded developers can do more with less >> hardware - smaller code means cheaper chips, and faster code means lower >> power. >> >> What I want is to be sure that I can use these optimisations without >> risking incorrect code. > > Yes. But it's hard to tell if an optimization is correct in embedded > code requiring synchronization. Even we don't use inline assembly, the C > code may still be reordered and lead to issue. Linux kernel just use > lot of "memory" clobber. But it's slow on RISC machine. Maybe we should > create an extension keyword to tell GCC not to reorder a statement. > It would be marvellous to be able to mark a statement, block, function, function call, etc., as "volatile", meaning "do not re-order with respect to other volatile statements, memory accesses or volatile asm statements".
