<?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>printf repairs corrupted long long arithmetic</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/42806/printf-repairs-corrupted-long-long-arithmetic</link><description> take a look to my programm: 
When counting how often a unsigned long long integer could be divided by ten, i got strange results. Then i realised, a printf function call repairs the fault. 
Who can explain the strange effect? 
 
//------------------</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: printf repairs corrupted long long arithmetic</title><link>https://community.arm.com/thread/98072?ContentTypeID=1</link><pubDate>Thu, 04 May 2006 04:25:44 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:3f1df05c-80ca-44e1-a1d0-062d9256d218</guid><dc:creator>Georg Bunter</dc:creator><description>&lt;p&gt;looking to assembler code is an endless story...&lt;br /&gt;
for example:&lt;br /&gt;
&lt;pre&gt;
                 ?C?UQDIV?A:
0x0008102C  E92D00F0  STMDB     R13!,{R4-R7}
0x00081030  E3A0C040  MOV       R12,#0x00000040
0x00081034  E2626000  RSB       R6,R2,#0x00000000
0x00081038  E2E37000  RSC       R7,R3,#0x00000000
0x0008103C  E3A02000  MOV       R2,#0x00000000
0x00081040  E0923002  ADDS      R3,R2,R2
0x00081044  E0B00000  ADCS      R0,R0,R0
0x00081048  E0B11001  ADCS      R1,R1,R1
0x0008104C  E0B22002  ADCS      R2,R2,R2
0x00081050  E0A33003  ADC       R3,R3,R3
0x00081054  E0924006  ADDS      R4,R2,R6
0x00081058  E0B35007  ADCS      R5,R3,R7
0x0008105C  21A02004  MOVCS     R2,R4
0x00081060  21A03005  MOVCS     R3,R5
0x00081064  E24CC001  SUB       R12,R12,#0x00000001
0x00081068  E11C000C  TST       R12,R12
0x0008106C  1AFFFFF4  BNE       0x00081044
0x00081070  E0B00000  ADCS      R0,R0,R0
0x00081074  E0B11001  ADCS      R1,R1,R1
0x00081078  E8BD00F0  LDMIA     R13!,{R4-R7}
0x0008107C  E12FFF1E  BX        R14
&lt;/pre&gt;
the &amp;quot;MOVCS R2,R4&amp;quot; instruction doesn&amp;#39;t do the expected:&lt;br /&gt;
while R4=0xFFFFFFF6 the result in R2=0x044CDA92.&lt;br /&gt;
Same with &amp;quot;MOVCS R3,R5&amp;quot;&lt;br /&gt;
&lt;br /&gt;
Who can help?&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: printf repairs corrupted long long arithmetic</title><link>https://community.arm.com/thread/74005?ContentTypeID=1</link><pubDate>Wed, 03 May 2006 07:34:33 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:054e0d29-e01f-4ccb-bf26-a0b313da8b5d</guid><dc:creator>Georg Bunter</dc:creator><description>&lt;p&gt;Yes, a look to the assembler code is a good idea. ;-)&lt;br /&gt;
&lt;br /&gt;
Making n volatile does&amp;#39;nt change a thing.&lt;br /&gt;
Making A volatile changes result n from two to one. (15 expected) So volatile has an effect.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: printf repairs corrupted long long arithmetic</title><link>https://community.arm.com/thread/45995?ContentTypeID=1</link><pubDate>Wed, 03 May 2006 07:22:51 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:9a41ed3a-c0db-4b36-b0c1-bcf91990c84b</guid><dc:creator>Christoph Franck</dc:creator><description>&lt;p&gt;How about having a look at the assembly code ?&lt;br /&gt;
&lt;br /&gt;
I would guess that some attempt by the compiler at optimizing the loop went awry. If you don&amp;#39;t want to examine the assembly code, try disabling the optimizations or declare n and A volatile and see what happens.&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>