编译器错误， if（）语句缺少代码

这是一个编译器错误！它已经被追溯到最终的输出汇编代码。我完全知道如何绕过这个bug，（我已经工作过了，谢谢）这个帖子的点就是知道bug。错误是没有产生任何输出代码，也没有警告编译器是不快乐的WI。这个代码实际上已经注释掉了所有的代码。“C”的值是不敬的，问题是编译器不产生代码，并且没有进行比较。至于＝=“int”，这不是真的。在定义中，它是最高的可变大小。在这种情况下，一个字节，它实际上是在汇编级上进行的测试，是一个单字节测试，（当输出代码被生成时）。就char而言，除非被编译器设置重写，否则需要将字符视为带符号字节。价值的定义。但是为了让每个人都高兴，我已经完全定义了它。至于“iT8*T”，它被定义为“符号char”，UIT88t被定义为“unChar char”。所以在这种情况下使用它绝对没有区别。{定义TestPoalValue\xFF'实际上是作为一个字符，当与char变量比较时，但是如果与一个未签名的字符比较，就会再次失败，并且不产生代码。这些是失败的条件，在所有情况下都需要编译器。生成输出代码（可能是相同的有效输出汇编代码）。一些编译器可能会发出的警告是：“比较签名和未签名的值”，我使用的每一个编译器都产生正确的结果，包括XC8，除了XC16失败。Q：什么是程序，我们在哪里报告编译器错误，以使它们修复？注意：绕过bug的方法是适当地施展常量，否则失败不会产生警告，也永远不会知道你有问题。当您发现代码不能按预期工作时，您的第一个提示将是。要找到问题，可能需要大量的工作通过代码进行跟踪才能找到丢失的输出程序集代码。



      以下为原文

    This is a compiler bug! it has been tracked right back to the final output assembly code.

I know exactly how to get round this bug, (I had already worked that out, thanks)
The point of the post is make known the bug.

The bug is that no output code whatsoever is produced and there is no warning that the compiler is unhappy with the code and has in effect commented out the entire code out of existence.

The value of 'c' is irreverent, the problem is that compiler produces no code, and no comparison is done.

As far as the == promoting to an 'int' this is not true. by definition it casts to the highest variable size.

In this case a byte,  which is in-fact the test done at the assembly level is a single byte test,( when output code is produced.)

 As far as a char is concerned unless overridden by compiler settings, a char is required to be treated as a signed byte value by its very definition. But to keep everyone happy I have fully defined it.

 As far as 'int8_t'  it is defined as a "signed char" and uint8_t is defined as "unsigned char".   so the use of this in this case makes absolutely no difference.

 #define TEST_VALUE 'xFF'

 does in-effect cast as a char and when comparing with a char variable works, but if compared with an unsigned char will again fail and produces no code.

These are the conditions that fail,



//case 1 - signed char
signed char c;

if(c == 0xFF) // no output code is produced. and no warnings
  {
  ... // this includes all code between the { } missing
  }


//case 2 - unsigned char
unsigned char c;

if(c == 'xFF') // no output code is produced. and no warnings
  {
  ... // this includes all code between the { } missing
  }

if(c == -1) // no output code is produced. and no warnings
  {
  ... // this includes all code between the { } missing
  }




 In all cases the compiler is required! to produce output code ( which is likely to be the same effective output assembly code).
The warning that some compilers may/do issue is 'comparing signed and unsigned values'

Every other compiler i have used produces the right result including XC8, except XC16 which fails.
Q: What is the procedure and where do we report compiler bugs to, to get them fixed?

NOTE: The way around bug is to cast the constant as appropriate, failure to do so will produce no warnings and you will never know you have a problem.  Your first hint will be when you find you code does not work as expected. To find the problem will likely take a lot of work tracing through your code only to find the output assembly code it is missing.

同意NG在POST第8章中的分析，仅供参考，一个普通字符的类型是XC16和XC32的符号字符，而它是XC8的无符号字符。&编辑＞总结：案例1：（0x00到0x00 7f，0xff80到0xfffff）！= 0x00 FFSE 2：（0x00到0x00 FF）！= 0xFFFFSE 3：（0x00到0x00 FF）！= 0xFFFFEY条件测试总是FALSE，因此编译器移除永远不会执行的代码。



      以下为原文

    Agree with NG's analysis in Post #8.
 
For information only, the type of a plain char is signed char for XC16 and XC32, while it is unsigned char for XC8.
 
To summary it up:
 
case 1:
(0x0000 to 0x007F, 0xFF80 to 0xFFFF ) != 0x00FF
 
case 2:
(0x0000 to 0x00FF) != 0xFFFF
 
case 3:
(0x0000 to 0x00FF) != 0xFFFF
 
These conditional tests are ALWAYS false, so the compiler removes code that will never execute.

将相同的分析应用于POST 1中的代码段：CAS1到0xFF（0x000到0x00 7f，0xFF80到0xFFFF）& lt；& gt；0x00 FF（总是false）Case2：比较char C到char t（0x000到0x00 7f，0xff80到0xffffe3）＝＝0xffffcase3：比较int c到0xFFFF（0x000到0xfffff）＝＝0xffFF。



      以下为原文

    Applying the same analysis to the snippets in Post #1,
 
case1: comparing char c to 0xFF
(0x0000 to 0x007F, 0xFF80 to 0xFFFF ) <> 0x00FF (always false)
 
case2: comparing char c to char t
(0x0000 to 0x007F, 0xFF80 to 0xFFFF ) == 0xFFFF
 
case3: comparing int c to 0xFFFF
(0x0000 to 0xFFFF) == 0xFFFF

如果编译器确定代码永远不会被执行，那么它就不允许包含它。这就是优化器的工作原理。是的，可能很烦人。但是，你需要了解工具的行为，这将允许更快地解决问题。它不需要签署。另一个编译器这样做并不意味着什么。编译器中有许多实现定义的规则。



      以下为原文

    If the compiler determines that code will never be executed, then it I allowed to not included it. It is how the optimizer works.
Yes it can be annoying. But you need to learn how the tools behave, this will allow to trouble shoot faster.

If a char is signed or unsigned is implementation defined. It is not required to be signed.
The other compiler do this does not mean anything. There are many implementation Defined rules in compilers.

？？？？不太好。按照标准，char在你能想到的任何土地上占用1字节。当你操作它时，它是16字节的土地中的2字节。（不是存储）空格MyByType（char x）；.0. ARGARX，W0；16位WordyMyByc:CP0.B W0Read



      以下为原文

   
???? WTF
Rubbish. As per the standard, char takes up 1 byte in any land you can think of.


When you manipulate it, it is 2bytes in 16bit land.  (Not the storage)
 
void mybyte(char X);
.equ arg_X,w0   ;16bit word
_mybyte:
cp0.b w0
return
 
 

我从下面的C99标准中引用了一些误解：“5.5.9相等运算符：如果两个操作数都具有算术类型，则执行通常的算术转换。6.3.1算术操作数INT可以表示原始类型的所有值，该值被转换为int；否则，它被转换为未签名的int。这些被称为整数提升。“三种类型的char、签名char和unChar char统称为INTION。字符类型。该实现应定义char具有与已签名的char或unchar char相同的范围、表示和行为。“”在抽象机器中，所有表达式都由语义指定。一个实际的实现不需要评估表达式的一部分，如果它可以推断它的值不被使用，并且没有产生所需的副作用（包括通过调用函数或访问一个易失性对象引起的任何结果）。



      以下为原文

    I've quoted from the C99 standard below to clarify some of your misunderstandings:
 

 
"6.5.9 Equality operators: If both of the operands have arithmetic type, the usual arithmetic conversions are performed.
 
6.3.1.8 Usual arithmetic conversions: [...] Otherwise, the integer promotions are performed on both operands.
 
6.3.1 Arithmetic operands

If an int can represent all values of the original type, the value is converted to an int; otherwise, it is converted to an unsigned int. These are called the integer promotions." 


 
"The three types char, signed char, and unsigned char are collectively called the character types. The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char."
 

 
"In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object)."
 

嗨，我从来没有想过一个简单的“IF（C=＝0xFF）”会造成这样的麻烦。谢谢你的提示。另一件事是：我在这个论坛看到了很多线索，是的，有人可以投一个否定的帖子。但通常没有人这样做。你的帖子中有1个被3个论坛成员投票。我以前从未见过如此咄咄逼人的反应。这个论坛不正常。



      以下为原文

    hi pcmgold,
 

 
I never thought that a simple 'if (c==0xFF) ' could cause such trouble. So thank you for your hint.
 
The other thing is: I saw a lot of threads in this forum and yes, someone can vote a post negative. But normally no one does. One of your posts was voted -1 by 3 forum members. I never saw such an aggressive reaction before. It is not normal in this forum.
 

免责声明，我不是否定它的人。大多数时候我都不担心。但是，我确实认为，当有人开始抱怨特定行为是“编译器错误”时，很多人会很恼火，并引用“编译器需要……”，当他们实际上不知道C标准所说的时候。广告是在第13页发布的。我可以保证，当约翰引用C标准时，他知道他在说什么。



      以下为原文

    Disclaimer, I was not one that voted it negative. Most of the time I couldn't be bothered.
However, I do think a number of people get pretty annoyed when someone starts complaining that particular behaviour  is "a compiler bug", and quoting that "compilers are required to...", when they do not actually know what the C standard says.
Have a careful read of what jtemples posted in #13.
I can assure, you, when John quotes from the C standard, he knows what he is talking about.
 

这篇文章的要点只不过是说似乎有一个问题……实际上我前面的C标准是WG14-（2007），它是C11（2011）的草稿，它取代了C99（1999），类型转换秩方法的定义从来没有变过。在使用算术等式时，HAT值/变量总是提升/转换类型（s）的最高“秩”（大小），并且如果可能的话，该值将被保留（IE签名扩展。2），如果不能保存数字，则两个数字都被视为无符号。ED类型。3）当值为相同类型时，不进行升级/转换。类型2的值被视为类型炭尺寸方程。（正如先前所说的，字符被提升为int），这是不正确的。所有的值都是char，整个算术方程是在8位级完成的。如果你真的看了汇编/二进制代码，它实际上是在这个单字节级别上完成的）4，它还具体地说：“当处理有符号的char＝常数为0xFF或‘FF’时，它将被处理/相互渗透为-1，而无符号char为255。”在比较的情况下，在“C标准”中的MPLE IF（=）首先，所有的操作符都进行算术转换（如上文所述的最高的“秩”）。测试的结果是int类型1或0，真或假。（它的结果是要被提升/降级为int类型，而不是被比较的操作符）（一个帖子的大小限制是什么，因为我必须把它在2中分割成帖子）



      以下为原文

    The point of the post was only to say that there seems to be a problem...
 
I have actually got the C standard in front of me WG14-(2007) which is the draft of C11 (2011), which supersedes C99 (1999 )
never the less this definition of type conversion rank method has never changed.
 
1) It clearly states that values/variables always promote/conversion up the the highest "rank" (size) of type(s) in use of the arithmetic equation in progress, and where possible the value is to be preserved ie signed extended. 
2) In the event that the number can not be preserved, both numbers are to be treated as unsigned type.
 
3) When the values are of the same type no promotion/conversion is to be done.  
ie 2 values of type char are to be treated as type char size equation.  (as suggested by someone previously the char is promoted to int. - this is not true. With all values being of char the whole arithmetic equation is done at 8 bit level. If you do actually look at the assembly/binary code produced it is in-fact done at this single byte level)
 
4) It also specifically states that "when dealing with signed char = constant of 0xFF  or 'FF' it is to be treated/interpenetrated as -1, and with unsigned char as 255."  This is given as an example in the 'C standard'
 
In the event of a comparison ie if(==) first all the operators undergo the normal conversion (ie highest "rank" as described above ) for the arithmetic comparison.   the 'result' from the test is to be of type int either 1 or 0, true or false.  ( it is the result that is to be promoted/demoted to type int not the the operators being compared.)
 
(what is the size limit on a post as i have had to split it in 2 to post ? )
 

我不是C专家，但请放心，约翰（J庙宇）或杰夫（MADYC）可以提供更多的细节。从我的理解，XC编译器符合ANS X3.159－1989标准。这通常被称为C89标准。也支持来自C99标准的一些特征，即在对它们执行操作时，比INT小的整数类型被提升。如果原始类型的所有值都可以表示为int，则将较小类型的值转换为int；否则，将其转换为未签名的int。也就是说，整数提升需要在比较之前执行类型CHAR变量到int大小的提升。



      以下为原文

   
 
I'm no C expert, but be assured that John (jtemple) or Jeff (mad_c) can provide more details.
 
From my understanding, the XC compilers conform to the ANS X3.159-1989 Standard. This is commonly called the C89 Standard. Some features from the C99 Standard are also supported.
 
That said, integer types smaller than int are promoted when an operation is performed on them. If all values of the original type can be represented as an int, the value of the smaller type is converted to an int; otherwise, it is converted to an unsigned int. That is, integer promotions require the promotion of the type char variables to int size before the comparison is performed.
 

从你引用的文件



      以下为原文

    From the document you quote

不管是否有缺陷。非常滑稽，完全违反逻辑。如果行为依赖于你使用的编译器。非常肯定，微软编译器会发出一个警告：“比较SIGDEND与未签名”（我没有来自微软的C编译器，只有C++ 6：在这种情况下，0xFF被当作一个字节，而不是整数）。



      以下为原文

    char c;
c=0xFF;
if (c==0xFF)
{
   ...catch me if you can
}
 
Whether bug or not. Quite funny and against all logic. Even more if the behavior depends on the compiler you use. Quite sure that Microsoft compilers will produce a warning like "compare sigend with unsigned" ( I have no C compiler from Microsoft, only C++ 6.0: in this case 0xFF is treated as a byte and not as an integer)

那里没有虫子。变量C被提升为int大小，常数0xFF已经是int大小——都为xc16签名。当测试总是正确的时候，这个比较就会得到优化。这种比较总是错误的--有趣！



      以下为原文

   
No bug there. The variable c gets promoted to int size and the constant 0xFF is already int size -- both signed for XC16. That comparison will get optimized out as the test is ALWAYS true.
 
I see your point after looking a bit closer.  That comparison is ALWAYS false -- interesting!