On Wed, Jun 1, 2016 at 6:32 AM, Jeffrey Walton <noloader@xxxxxxxxx> wrote: >>> I'm not sure I would agree. GCC needs to know intent (q.v.), >> >> No, it does not. It needs to follow the language specification: >> intent is entirely in the head of the programmer, and they'd >> better learn that specification. >> >>> Sorry to sound argumentative. I'm frustrated when a correct program is >>> turned into a misbehaving program :) >> >> It's not a correct program. > > Please forgive my ignorance... How, exactly, is it not a correct > program? For the program to be ill-formed, it would have to fall into > one of the many undefined behavior traps. As far as I know, there's no > UB. I would agree that it is a correct program. However, the CRC instructions do nothing, and, as such, the compiler may correctly remove them. For your purposes, the program is not correct. The compiler implements the standard language, and the standard language does not give you a way to do what you want to do. GCC may give you the tools to do what (I think) you want to do. You can use function attributes to compile CRC functions at different architectural levels. If you are using GNU/Linux, you can use the ifunc attribute to select one of those functions at runtime. This assumes that there is some way to query the processor at runtime to know what capabilities it has, similar to the cpuid instruction on x86 processors. I don't know whether that facility exists on your processor. > And how is removing code and causing a SIGILL maintaining the > observable behavior required by the as-if rule? The program does not > crash a -O0. The program does not crash at -O2 when the code in > question is present. The program crashes when the code is removed. >From the C language perspective, a correct program never includes an illegal instruction and never triggers a SIGILL signal. A program that uses an illegal instruction is clearly incorrect. > Nearly everyone seems to realize the code is needed, and removing it > does _not_ produce an equivalent program. You are trying to execute code for a side effect. However, that side effect can not be expressed in the language, and since the compiler implements the language it ignores it. I would say that the problem boils down to this: you are using the wrong language. You want to use a language that permits you to specify precisely which machine instructions are executed. There is such a language: assembler. C is not such a language. C is defined in terms of an abstract machine model. These disagreements between programmers and compilers are common. The key point to understand is that the programmer and the compiler must agree on how to translate the program into machine code. In the case of the C language, that agreement is expressed in the form of a written standard. In order to argue that the compiler is doing the wrong thing, you need to point to the part of the written standard that the compiler is mishandling. Or you need to argue that the standard should be changed, but this is the wrong mailing list for that argument. Your suggestion that "nearly everyone seems to realize" is not true. People disagree. When they disagree, there needs to be a way to resolve that disagreement. That is the language standard. You are asking for something that people sometimes call DWIM programming, where DWIM means Do What I Mean. A DWIM programming environment could be very useful. However, it would not use the C language. C is not a DWIM programming language. Ian
