GCC bugs, could someone test with a recent version?

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!

 

I found some bugs in avr-gcc, using version 4.8.1 and 4.9.2. One I already reported, likely affecting all 8 bit AVR devices is here:

 

https://gcc.gnu.org/bugzilla/sho...

 

The other I found just today is the handling of ELPM, here is a minimal test case for it:

#include <stdint.h>

volatile uint8_t tmp;
volatile uint8_t* volatile const __flash1 ptr = &tmp;

int main(void)
{
    tmp = *ptr;
    while(1);
}

The assembly output will show the problem (avr-gcc -S), it is that for the elpm, RAMPZ is set up to 1 as exceptable, however after the load, it is not restored to zero, and, at least in my case, the load from RAM is performed by ld r24, Z. On an AVR with external bus interface (such as the ATxmega128A1U), this is an error as the load happens from RAMPZ:Z.

 

My problem is that I don't have access to any newer version of avr-gcc, at least one which I could set up without too much hassle (my development machine is Debian Linux), and apparently the GCC team doesn't care at all for these versions, being too old for them (not even as much as giving the test case a go on a recent one).

 

Could someone with a newer version try these out?

Last Edited: Fri. May 25, 2018 - 12:13 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dev.null wrote:
My problem is that I don't have access to any newer version of avr-gcc, at least one which I could set up without too much hassle (my development machine is Debian Linux),
Can't you take the .tar.gz packages that Atmel/Microchip build/distribute? I think they are up to 5.3 or 5.4

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Microchip Technology Inc

Microchip Technology

SAM(ARM) and AVR Toolchains (C Compiler)

https://www.microchip.com/mplab/avr-support/avr-and-arm-toolchains-(c-compilers)

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dev.null wrote:
... (my development machine is Debian Linux), and apparently the GCC team doesn't care at all for these versions, being too old for them ...
FSF AVR GCC 8.1 is in Arch Linux.

GCC 8.1

https://www.avrfreaks.net/forum/gcc-81

Debian will likely stay on the Microchip AVR GCC path :

https://packages.debian.org/search?keywords=gcc-avr&searchon=names&suite=all&section=all

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dev.null wrote:
... (my development machine is Debian Linux), and apparently the GCC team doesn't care at all for these versions, being too old for them ...
FSF AVR GCC 8.1 is in Arch Linux.

GCC 8.1

https://www.avrfreaks.net/forum/gcc-81

Debian will likely stay on the Microchip AVR GCC path :

https://packages.debian.org/search?keywords=gcc-avr&searchon=names&suite=all&section=all

 

oops

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Wed. May 23, 2018 - 01:59 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I did a test with the Microchip package, the 64 bit bug is still there, however the other seems to be fixed (not sure, it could be that simply the test case no longer triggers it, 4.9.2 wasn't consistent failing, in some cases, it generated correct code while in others, it didn't).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wouldn't just do ad-hoc testing. Report to the Bugzilla and let the developers test/reject it more methodically. Chances are Georg-Johan will probably recognize it anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
I wouldn't just do ad-hoc testing. Report to the Bugzilla and let the developers test/reject it more methodically. Chances are Georg-Johan will probably recognize it anyway.
That's what I would like to do, but the 64 bit bug is sitting there since 2 weeks without any comment except for that my compiler version is too old. That's why I asked here for some help, if someone had a newer version installed and ready to go, it should be a matter of a copy-paste-compile to see whether it is still present (at least for the 64 bit bug), and if so, I could refer that in the bug report without me having to actually install the new version (the Microchip version thankfully didn't depend on anything not available on Debian, so I could try that).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I tried with avr-gcc 8.1.0, same behaviour (output from -O2 level).

 

0000008a <test_64>:
  8a:	08 95       	ret

0000008c <test_32>:
  8c:	66 27       	eor	r22, r22
  8e:	77 27       	eor	r23, r23
  90:	80 78       	andi	r24, 0x80	; 128
  92:	61 15       	cp	r22, r1
  94:	71 05       	cpc	r23, r1
  96:	80 48       	sbci	r24, 0x80	; 128
  98:	9f 4f       	sbci	r25, 0xFF	; 255
  9a:	09 f0       	breq	.+2      	; 0x9e <test_32+0x12>
  9c:	08 95       	ret
  9e:	80 91 00 01 	lds	r24, 0x0100	; 0x800100 <_edata>
  a2:	8f 5f       	subi	r24, 0xFF	; 255
  a4:	80 93 00 01 	sts	0x0100, r24	; 0x800100 <_edata>
  a8:	08 95       	ret

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried with "avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.1_495) 5.4.0" and got the same result...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the reports! A week passed, and no response on the GCC Bugzilla, though. Anyway, at least it is there, maybe eventually someone will pick it up.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dev.null wrote:
A week passed, and no response on the GCC Bugzilla
It's manned by volunteers who donate their free time (and are possibly working on the more serious faults".

 

One option you  have is to learn abut the internal operation of the compiler and offer a patch to the project to fix the issue yourself.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I understand this (that it is volunteer-ran, and may or may not have time for quick fixes), I was rather expecting some feedback, just as much as checking it, marking it confirmed, accepting that it is indeed a bug if it is (and not for example some very unusual manifestation of undefined behaviour of the C language, which people there certainly know better).

 

It isn't my find, so it is not like there was any tangible project around me which would be affected by this.

 

Otherwise this, that it is entirely volunteer-ran, is definitely a problem on the part of the users. I can't even get the company where I work at to lift a finger for any of the open-source software they are using, neither in worktime, neither as donations. Of course, then they would be upset if one or another of those would be gone without maintenance (I myself am participating in open-source stuff, and do volunteering in non-IT related things. Trying to understand the compiler's innards well enough just to fix a bug which isn't really affecting me just isn't my cup of tea, maybe if I planned on picking up actively contributing to it, but for a one-shot effort I believe it is too much).

Last Edited: Wed. Jun 13, 2018 - 04:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

While GCC is an open source, volunteer lead project, Microchip should support it. They use it as their compiler for both AVR and PIC parts.

 

Unfortunately they are difficult to contact.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well they do support it in a sense in that they are actively adding new device support to it all the time.

 

I guess you meant "bug fixing" by support?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, bug fixing. If they are adding new devices then presumably they are adding support for the new instructions and memory layouts they have, but I don't know if they are involved with whatever is causing this issue.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The thing is though that, unless it's AVR model specific, this is not going to be an area of expertise for Atmel GCC engineers. If this goes to the core of the C++ compiler it really needs to be looked at by experts in that area. The front end or the back end.

 

To be honest I'm guessing that those at the core of C++ are only really interested in the x86 and ARM versions and AVR is just a side-line annoyance to them so they probably don't see this as a high priority.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, I was thinking it was something to do with the AVR code generator.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Heh.  I ran the test64 code through some old compilers.  It looks OK for 4.3.3 (WINAVR-era) and 4.6.2.  It's still correct, but noticeably different, in the 4.8.1 version.

 

Fascinatingly, the older compilers produce smaller (and really nice) code for test64 than they do for test32!

 


__attribute__((noinline)) void test_64(uint64_t d64)
{
 if ((d64 & 0xFF800000UL) == 0xFF800000UL){
   0:	40 78       	andi	r20, 0x80	; 128
   2:	40 38       	cpi	r20, 0x80	; 128
   4:	01 f4       	brne	.+0      	; 0x6 <test_64+0x6>
   6:	5f 3f       	cpi	r21, 0xFF	; 255
   8:	01 f4       	brne	.+0      	; 0xa <test_64+0xa>
  tmp ++;
   a:	80 91 00 00 	lds	r24, 0x0000	; 0x800000 <__SREG__+0x7fffc1>
   e:	8f 5f       	subi	r24, 0xFF	; 255
  10:	80 93 00 00 	sts	0x0000, r24	; 0x800000 <__SREG__+0x7fffc1>
  14:	08 95       	ret

00000016 <test_32>:
 }
}

__attribute__((noinline)) void test_32(uint32_t d32)
{
  16:	dc 01       	movw	r26, r24
  18:	cb 01       	movw	r24, r22
 if ((d32 & 0xFF800000UL) == 0xFF800000UL){
  1a:	80 70       	andi	r24, 0x00	; 0
  1c:	90 70       	andi	r25, 0x00	; 0
  1e:	a0 78       	andi	r26, 0x80	; 128
  20:	80 30       	cpi	r24, 0x00	; 0
  22:	20 e0       	ldi	r18, 0x00	; 0
  24:	92 07       	cpc	r25, r18
  26:	20 e8       	ldi	r18, 0x80	; 128
  28:	a2 07       	cpc	r26, r18
  2a:	2f ef       	ldi	r18, 0xFF	; 255
  2c:	b2 07       	cpc	r27, r18
  2e:	01 f4       	brne	.+0      	; 0x30 <test_32+0x1a>
  tmp ++;
  30:	80 91 00 00 	lds	r24, 0x0000	; 0x800000 <__SREG__+0x7fffc1>
  34:	8f 5f       	subi	r24, 0xFF	; 255
  36:	80 93 00 00 	sts	0x0000, r24	; 0x800000 <__SREG__+0x7fffc1>
  3a:	08 95       	ret

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So, the bug was introduced in recent versions. That's an important clue for whoever will eventually work on this.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Finally the bug was confirmed! https://gcc.gnu.org/bugzilla/sho...