Re: target/10733: Modulus bug

Re: target/10733: Modulus bug

[Dara Hazeghi]

The following reply was made to PR target/10733; it has been noted by GNATS.

From: Dara Hazeghi <dhazeghi@yahoo.com>
To: gcc-gnats@gcc.gnu.org, jbright@winfordeng.com
Cc:  
Subject: Re: target/10733: Modulus bug
Date: Sat, 10 May 2003 11:40:16 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=10733
 
 Hello,
 
 would it be possible for you to give include a copy of the bad assembly  
 generated (as well as what it should be)? Also your sample is not  
 complete (ie won't compile at all). Could you include a complete  
 sample? Thanks,
 
 Dara
 

Re: target/10733: Modulus bug

[giovannibajo]

Synopsis: Modulus bug

State-Changed-From-To: open->analyzed
State-Changed-By: bajo
State-Changed-When: Mon May 12 11:11:37 2003
State-Changed-Why:
    Confirmed to still exist in the 3.3 branch and mainline

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10733

Re: target/10733: Modulus bug

[Dara Hazeghi]

The following reply was made to PR target/10733; it has been noted by GNATS.

From: Dara Hazeghi <dhazeghi@yahoo.com>
To: gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: target/10733: Modulus bug
Date: Sun, 11 May 2003 17:12:56 -0700

 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit- 
 trail&database=gcc&pr=10733
 
 John responded to me, and the bug still exists in gcc 3.3 branch and  
 mainline (20030509).
 
 Dara
 

Re: target/10733: Modulus bug

[John Bright]

The following reply was made to PR target/10733; it has been noted by GNATS.

From: John Bright <jbright@winfordeng.com>
To: Dara Hazeghi <dhazeghi@yahoo.com>, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: target/10733: Modulus bug
Date: Sat, 10 May 2003 19:03:46 -0400

 No problem.  I'm new at dealing with gcc bugs, so I'm not always sure
 what you're asking for.  I gather you want the output of avr-gcc -E? 
 Assuming so, here it is:
 # 1 "test.c"
 # 1 "<built-in>"
 # 1 "<command line>"
 # 1 "test.c"
 # 1 "/usr/avr/include/io.h" 1 3
 # 20 "/usr/avr/include/io.h" 3
 # 1 "/usr/avr/include/io-avr.h" 1 3
 # 42 "/usr/avr/include/io-avr.h" 3
 # 1 "/usr/avr/include/io8535.h" 1 3
 # 43 "/usr/avr/include/io-avr.h" 2 3
 # 21 "/usr/avr/include/io.h" 2 3
 # 1 "/usr/avr/include/iomacros.h" 1 3
 # 21 "/usr/avr/include/iomacros.h" 3
 # 1 "/usr/avr/include/inttypes.h" 1 3
 # 24 "/usr/avr/include/inttypes.h" 3
 typedef signed char int8_t;
 typedef unsigned char uint8_t;
 
 typedef int int16_t;
 typedef unsigned int uint16_t;
 
 typedef long int32_t;
 typedef unsigned long uint32_t;
 
 typedef long long int64_t;
 typedef unsigned long long uint64_t;
 
 typedef int16_t intptr_t;
 typedef uint16_t uintptr_t;
 # 22 "/usr/avr/include/iomacros.h" 2 3
 # 22 "/usr/avr/include/io.h" 2 3
 # 2 "test.c" 2
 
 
 int main(void)
 {
         unsigned char t1;
         t1=2;
         t1=(t1+40)%30;
 
         do { if ((__builtin_constant_p((0x17)) && ((0x17)) <= 0x40 + 0 -
 (1))) { if (__builtin_constant_p((0xff)) && ((0xff) == 0)) __asm__
 __volatile__ ( "out %0,__zero_reg__" : : "M" ((uint8_t)(((0x17))-0)) );
 else __asm__ __volatile__ ( "out %1,%0" : : "r" ((uint8_t)((0xff))), "M"
 ((uint8_t)(((0x17))-0)) ); } else (*((volatile uint8_t *)(((0x17)) - 0 +
 0x20))) = (0xff); } while (0);
         do { if ((__builtin_constant_p((0x18)) && ((0x18)) <= 0x40 + 0 -
 (1))) { if (__builtin_constant_p((t1)) && ((t1) == 0)) __asm__
 __volatile__ ( "out %0,__zero_reg__" : : "M" ((uint8_t)(((0x18))-0)) );
 else __asm__ __volatile__ ( "out %1,%0" : : "r" ((uint8_t)((t1))), "M"
 ((uint8_t)(((0x18))-0)) ); } else (*((volatile uint8_t *)(((0x18)) - 0 +
 0x20))) = (t1); } while (0);
 
         return(0);
 }
 
 As far as the assembly output, you just want me to compile the assembly
 and upload the result to my chip and see what happens?  I can do that.
 
 Thanks,
 John Bright

Re: target/10733: Modulus bug

[Dara Hazeghi]

The following reply was made to PR target/10733; it has been noted by GNATS.

From: Dara Hazeghi <dhazeghi@yahoo.com>
To: John Bright <jbright@winfordeng.com>, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: target/10733: Modulus bug
Date: Sat, 10 May 2003 14:54:37 -0700 (PDT)

 Sorry to keep asking for more, but could you also
 include the preprocessed source? Thanks.
 
 Dara
 
 P.S. If I send you assembly output from 3.3 and
 mainline, would you be able to test it? That way we
 can determine if the bug's fixed in current sources.
 
 __________________________________
 Do you Yahoo!?
 The New Yahoo! Search - Faster. Easier. Bingo.
 http://search.yahoo.com

Re: target/10733: Modulus bug

[John Bright]

The following reply was made to PR target/10733; it has been noted by GNATS.

From: John Bright <jbright@winfordeng.com>
To: Dara Hazeghi <dhazeghi@yahoo.com>, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: target/10733: Modulus bug
Date: Sat, 10 May 2003 17:16:49 -0400

 Ok, a complete example where the value is obtained by writing to one of
 the AVR's ports:
 --------- test.c -------------
 #include <io.h>
 #include <io8535.h>
 
 int main(void)
 {
         unsigned char t1;
         t1=2;
         t1=(t1+40)%30;
 
         outp(0xff, DDRB);
         outp(t1, PORTB);
 
         return(0);
 }
 ------------------------------
 compile:
 avr-gcc -g -Os -Wall -Wstrict-prototypes -mmcu=at90s8535 test.c
 
 I'm assuming you want the assembly generated with avr-gcc -S and just
 the section beginning with main:
 main:
         .stabn 68,0,5,.LM1-main
 .LM1:
 /* prologue: frame size=0 */
         ldi r28,lo8(__stack - 0)
         ldi r29,hi8(__stack - 0)
         out __SP_H__,r29
         out __SP_L__,r28
 /* prologue end (size=4) */
 .LBB2:
         .stabn 68,0,8,.LM2-main
 .LM2:
         ldi r24,lo8(42)
         ldi r25,hi8(42)
         ldi r22,lo8(30)
         ldi r23,hi8(30)
         rcall __divmodhi4
         mov r25,r24
         .stabn 68,0,10,.LM3-main
 .LM3:
         ldi r24,lo8(-1)
 /* #APP */
         out 23,r24
         .stabn 68,0,11,.LM4-main
 .LM4:
         out 27,r25
         .stabn 68,0,13,.LM5-main
 .LM5:
 /* #NOAPP */
 .LBE2:
         .stabn 68,0,14,.LM6-main
 .LM6:
         ldi r24,lo8(0)
         ldi r25,hi8(0)
 /* epilogue: frame size=0 */
 
 I'm afraid I don't know what the correct assembly should be.  Does it
 appear that __divmodhi4 is not behaving correctly?
 
 
 Thanks,
 John Bright
 
 
 
 
 Dara Hazeghi wrote:
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-
 > trail&database=gcc&pr=10733
 > 
 > Hello,
 > 
 > would it be possible for you to give include a copy of the bad assembly
 > generated (as well as what it should be)? Also your sample is not
 > complete (ie won't compile at all). Could you include a complete
 > sample? Thanks,
 > 
 > Dara

target/10733: Modulus bug

[jbright]

>Number:         10733
>Category:       target
>Synopsis:       Modulus bug
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          wrong-code
>Submitter-Id:   net
>Arrival-Date:   Sat May 10 15:36:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     John Bright
>Release:        avr-gcc (GCC) 3.2.3 20030221 (Debian prerelease)
>Organization:
>Environment:
Linux host system, AVR cross-compiler for Atmel AT90S8535
>Description:
C Source code:
--------------------------------
int t1;

t1=2;
t1=(t1+40)%30;
--------------------------------
This results in t1 having a value of 42.

Compile options:
avr-gcc -g -Os -Wall -Wstrict-prototypes -mmcu=at90s8535

I found this bug while using avr-gcc 3.0.3 (in Debian stable).  I tried out with 3.2.3 and the same bug still exists.
>How-To-Repeat:

>Fix:
In the above example, the bug can be worked-around by doing the modulus separately:

t1=2;
t1=t1+40;
t1%=30;
>Release-Note:
>Audit-Trail:
>Unformatted: