<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/26378/why-keil-generates-differen-outputs-from-the-other-compilers-with-the-same-code</link><description> 
I am using the following code in different compiler: 

 
#include &amp;lt;stdio.h&amp;gt;

int main(void)
{
 int i = 0;
 int b[10] = {100,101,102,103,104,105,106,107,108,109};
 int c[10] = {0,1,2,3,4,5,6,7,8,9};

 b[i + 0] = c[i++ % 100];
 b[i + 0] = c[i++ % 100</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/146472?ContentTypeID=1</link><pubDate>Thu, 29 Oct 2009 07:52:19 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:3e2beae7-9c2c-470e-9764-d856a8d0054d</guid><dc:creator>Jack Sprat</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Note that a variable doesn&amp;#39;t need to be modified multiple times
between sequence points. In this case the user modified the value
once, but combined the modification with a second use of the
variable.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Yes, that&amp;#39;s what I should have said...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/144763?ContentTypeID=1</link><pubDate>Thu, 29 Oct 2009 05:37:20 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b01a5777-a7ec-49fb-94a4-7d263f641070</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
&amp;quot;The problem is that &amp;#39;i&amp;#39; is being modified more than once between
sequence points which invokes undefined behaviour.&amp;quot;&lt;/p&gt;

&lt;p&gt;
Note that a variable doesn&amp;#39;t need to be modified multiple times
between sequence points. In this case the user modified the value
once, but combined the modification with a second use of the
variable.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/144764?ContentTypeID=1</link><pubDate>Thu, 29 Oct 2009 05:21:27 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:c53fb023-5a02-4f54-af52-71309f8bb893</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;I suggest that you take a look at the comp.lang.c faq for
&amp;#39;undefined behaviour&amp;#39; and &amp;#39;order of eveluation&amp;#39;.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Interesting. The FAQ even mentions the discrepance between K&amp;amp;R
(whose wording suggests that the behavior is unspecified) and the C
standard (which states that the behavior is indeed undefined).&lt;/p&gt;

&lt;p&gt;
Advice taken, I&amp;#39;ll make an appropriate note in my K&amp;amp;R.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/142483?ContentTypeID=1</link><pubDate>Thu, 29 Oct 2009 03:33:21 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e88763ea-e36e-4972-ba90-12e69edab042</guid><dc:creator>Jack Sprat</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;It causes undefined behaviour --- which means no matter how
unspeakably bizarre this code behaves, that&amp;#39;s precisely
correct.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;...&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;My copy of K&amp;amp;R seems to disagree with that. It states that
the order in which the operands of an operator (in this case: the
assignment operator =) are evaluated is left to the compiler.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
That doesn&amp;#39;t constitute a disagreement. The problem is that &amp;#39;i&amp;#39; is
being modified more than once between sequence points which invokes
undefined behaviour. Once that has happened all bets are off.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;And in this case, the compiler has only two options - evaluate
the left-hand operand first, or evaluate the right-hand argument
first. Any behavior that&amp;#39;s more bizarre than that would point to a
faulty compiler. The compiler may not produce code that omits the
statement, enters an endless loop, or exits the program, for
example.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Every aspect of that paragraph is completely wrong. I suggest that
you take a look at the comp.lang.c faq for &amp;#39;undefined behaviour&amp;#39; and
&amp;#39;order of eveluation&amp;#39;.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/139387?ContentTypeID=1</link><pubDate>Thu, 29 Oct 2009 00:55:40 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:ea478cba-8dbd-4d88-aaa0-d5b35176d131</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;It causes undefined behaviour --- which means no matter how
unspeakably bizarre this code behaves, that&amp;#39;s precisely
correct.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
My copy of K&amp;amp;R seems to disagree with that. It states that the
order in which the operands of an operator (in this case: the
assignment operator =) are evaluated is left to the compiler.&lt;/p&gt;

&lt;p&gt;
And in this case, the compiler has only two options - evaluate the
left-hand operand first, or evaluate the right-hand argument first.
Any behavior that&amp;#39;s more bizarre than that would point to a faulty
compiler. The compiler may not produce code that omits the statement,
enters an endless loop, or exits the program, for example.&lt;/p&gt;

&lt;p&gt;
Of course, an evil-yet-standard-compliant compiler could flip a
coin to determine the order of evaluation for every multi-operand
operator it encounters. At least I didn&amp;#39;t see anything about always
having to chose the same order.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/135980?ContentTypeID=1</link><pubDate>Wed, 28 Oct 2009 12:46:08 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:cd51ebd5-eb5e-4fd6-b79a-8398bde75230</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Does add a rather tricky portability issue.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Actually it doesn&amp;#39;t. The issue here is not portability but
outright &lt;b&gt;incorrecness&lt;/b&gt; of the code. Code along the lines of&lt;/p&gt;

&lt;pre&gt;
a[i]=i++;
&lt;/pre&gt;

&lt;p&gt;
doesn&amp;#39;t just yield an implementation-defined result, like some
earlier respondents stated. It causes &lt;b&gt;undefined behaviour&lt;/b&gt; ---
which means no matter how unspeakably bizarre this code behaves,
that&amp;#39;s precisely correct.&lt;/p&gt;

&lt;p&gt;
You guys are ultimately discussing the wrong question here. You
should worry about repairing the code, not about what compilers might
make of it in its current, buggy state. It makes no sense whatsoever
to discuss particular results of running this code on any compiler.
It&amp;#39;s impossible for any compiler to get this wrong.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/125827?ContentTypeID=1</link><pubDate>Wed, 28 Oct 2009 09:33:42 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7ce34999-4735-4e99-8334-8c865987e8c6</guid><dc:creator>Dirk Veramaak</dc:creator><description>&lt;p&gt;&lt;p&gt;
Having said that, it does seem the Keil is a little bit out on
it&amp;#39;s own here. I just tried GCC and it works the same as the
others.&lt;/p&gt;

&lt;p&gt;
Does add a rather tricky portability issue.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/125839?ContentTypeID=1</link><pubDate>Wed, 28 Oct 2009 09:31:50 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:f843ccb1-608c-4cea-84f1-2569054e6e80</guid><dc:creator>ramazan arikan</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thank you for your important advices.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/115346?ContentTypeID=1</link><pubDate>Wed, 28 Oct 2009 09:01:42 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:dab76d50-e7b9-4501-a193-563910983366</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Even when/if standards do specify exact order of evaluation, a
developer should make sure that a reasonably skilled reader will
understand the code.&lt;/p&gt;

&lt;p&gt;
It is easy to understand precedence rules for + in relation to *,
but when expressions gets complex, extra parentheses should be
added.&lt;/p&gt;

&lt;p&gt;
And expressions with side effects should really not be accepted,
if the evaluation order and side effect may interfere. Just do not -
ever - write code where you use ++ or -- on a variable and use the
variable somewhere else in the same statement.&lt;/p&gt;

&lt;p&gt;
And do not write code where the address of the same variable is
taken twice as parameters to a function call. The function will
probably expect that there are no aliasing between the two
pointers.&lt;/p&gt;

&lt;p&gt;
And do not try to write code that accesses a global variable both
directly and through a pointer.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/103566?ContentTypeID=1</link><pubDate>Wed, 28 Oct 2009 07:57:52 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a25ffc04-9dc3-43f1-8693-66ccfa2bbe5e</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
Compilers don&amp;#39;t work to arbitrary user&amp;#39;s &lt;i&gt;thoughts&lt;/i&gt; and
&lt;i&gt;hopes&lt;/i&gt; - they work to their published specifications, which
will be based on appropriate standards.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/103569?ContentTypeID=1</link><pubDate>Wed, 28 Oct 2009 07:40:22 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:fb3889c3-cc57-4a67-acd1-5f3343034dd1</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;With a visual studio background, I think or hope that would be
the same in keil.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
No - you need a standard C background, and this would tell you
that you cannot expect any particular order in which the left and the
right side of a statement are evaluated. This also means that side
effects of the statements may occur in either order. If you require a
certain order even across different compilers, you will need to
change the code accordingly.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/77879?ContentTypeID=1</link><pubDate>Wed, 28 Oct 2009 07:30:43 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d191e843-7d69-471c-9ef3-00fe462e2312</guid><dc:creator>ramazan arikan</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thank you for your reply.&lt;/p&gt;

&lt;p&gt;
In visual STD the following code:&lt;/p&gt;

&lt;pre&gt;
int main(void)
{
  int i = 0;
  int b[10] = {100,101,102,103,104,105,106,107,108,109};
  int c[10] = {0,1,2,3,4,5,6,7,8,9};

  b[i++ + 0] = c[i % 100];
  b[i++ + 0] = c[i % 100];
  b[i++ + 0] = c[i % 100];
  b[i++ + 0] = c[i % 100];
  b[i++ + 0] = c[i % 100];
  b[i++ + 0] = c[i % 100];

  for(i = 0; i &amp;lt; 10; i++)
     printf(&amp;quot;b[%d] = %d\n&amp;quot;,i,b[i]);
  return 0;
}
&lt;/pre&gt;

&lt;p&gt;
generates the following output(there is no difference):&lt;/p&gt;

&lt;pre&gt;
b[0] = 0
b[1] = 1
b[2] = 2
b[3] = 3
b[4] = 4
b[5] = 5
b[6] = 106
b[7] = 107
b[8] = 108
b[9] = 109
&lt;/pre&gt;

&lt;p&gt;
And the following code:&lt;/p&gt;

&lt;pre&gt;
int main(void)
{
  int i = 0;
  int b[10] = {100,101,102,103,104,105,106,107,108,109};
  int c[10] = {0,1,2,3,4,5,6,7,8,9};

  b[i++ + 0] = c[i++ % 100];
  b[i++ + 0] = c[i % 100];
  b[i++ + 0] = c[i % 100];
  b[i++ + 0] = c[i % 100];
  b[i++ + 0] = c[i % 100];
  b[i++ + 0] = c[i % 100];

  for(i = 0; i &amp;lt; 10; i++)
     printf(&amp;quot;b[%d] = %d\n&amp;quot;,i,b[i]);
  return 0;
}
&lt;/pre&gt;

&lt;p&gt;
&lt;br /&gt;
Generates the following output:&lt;/p&gt;

&lt;pre&gt;
b[0] = 0
b[1] = 101
b[2] = 2
b[3] = 3
b[4] = 4
b[5] = 5
b[6] = 6
b[7] = 107
b[8] = 108
b[9] = 109
&lt;/pre&gt;

&lt;p&gt;
With a visual studio background, I think or hope that would be the
same in keil.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/90083?ContentTypeID=1</link><pubDate>Wed, 28 Oct 2009 07:19:31 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b9d3b62f-f3c6-4a44-8336-fb3d0b7f9b19</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
Even when the behaviour is clearly defined, there is absolutely no
requirement whatsoever for the compiler to generate any specific set
of machine instructions.&lt;/p&gt;

&lt;p&gt;
In fact, you should &lt;i&gt;&lt;b&gt;expect&lt;/b&gt;&lt;/i&gt; different compilers to
generate different sets of machine instructions!&lt;/p&gt;

&lt;p&gt;
Even different versions of the same compiler can generate
different sets of machine instructions - which is why it is never
trivial to upgrade the compiler part-way through a project.&lt;/p&gt;

&lt;p&gt;
And, of course, changing options can cause the same version of the
same compiler to generate different sets of machine instructions!&lt;/p&gt;

&lt;p&gt;
This is why you really must not write timing loops in any
high-level language - see: &lt;a href="http://www.8052.com/forum/read/98544"&gt;www.8052.com/.../98544&lt;/a&gt;&lt;br /&gt;

and: &lt;a href="http://www.8052.com/forum/read/150987"&gt;www.8052.com/.../150987&lt;/a&gt;&lt;br /&gt;

etc,...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/57148?ContentTypeID=1</link><pubDate>Wed, 28 Oct 2009 07:01:35 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:6135e4ff-5eee-4adf-a2b8-7c8688acb2f7</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Could you tell me something about this problem?&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
There is no problem. The behavior of statements like&lt;/p&gt;

&lt;pre&gt;
a[i] = i++:
&lt;/pre&gt;

&lt;p&gt;
is implementation-defined in C (see K&amp;amp;R, chapter &amp;quot;Precedence
and Order of Evaluation&amp;quot;. It contains this example). Different
compilers are free to evaluate the left or the right side of the
assignment first.&lt;/p&gt;

&lt;p&gt;
It is up to the programmer to deal with the consequences.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/77881?ContentTypeID=1</link><pubDate>Wed, 28 Oct 2009 07:01:03 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9d1e0218-bd9b-46c3-ad96-71dc4c69050c</guid><dc:creator>ramazan arikan</dc:creator><description>&lt;p&gt;&lt;p&gt;
Nothing happen, I just wonder. Previously I think that the value
of &amp;#39;i&amp;#39; would be changed before the next line. From know on I will be
carefull. Thanks for your reply.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Why Keil generates differen  outputs from the other compilers with the same code?</title><link>https://community.arm.com/thread/57149?ContentTypeID=1</link><pubDate>Wed, 28 Oct 2009 06:51:27 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:58dcb2b5-1aec-40fa-9e78-1471797c6dcc</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
Always be careful about using a variable twice in an expression,
if you also change the value of the variable in the expression.&lt;/p&gt;

&lt;p&gt;
In your code, both the left and right side of the assign makes use
of i, but the right side is also modifying i with the ++.&lt;/p&gt;

&lt;p&gt;
What happens if the compiler computes the destination address
before - or after - it evaluates the right-hand side?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>