On Thu, 17 Oct 2013, DJ Delorie wrote: > > At least on ARM, you can e.g. have a non-bit-field "char" that occupies > > part of the same 4-byte unit as an "int" bit-field. > > Ok, "when the user doesn't give the compiler conflicting requirements." > (which is why I contemplated making those conflicts errors at first)
I don't consider them conflicting. My default starting point is that the user has a GNU C program, using target-independent semantics of GNU C, and expects that program to be compiled and executed according to those semantics. (In this case, it can be an ISO C program; no GNU extensions are required.) Those semantics include the memory model. The fact that the user happens to be compiling for an ARM processor shouldn't change those semantics. If, say, a GNU/Linux distribution contains code expecting the memory model, we shouldn't make the distributor use special options for building that code on ARM; building for a new architecture should, as far as possible, just work (and new architecture porters are hardly likely to know if one of thousands of packages might have such a requirement). You seem to be starting from a user having a program that instead of expecting the normal target-independent semantics expects some other semantics specified by an ABI document, where those semantics contradict the semantics of ISO C. -- Joseph S. Myers jos...@codesourcery.com
