Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#49284 - [avr-gcc] 6.1.1 does not work correctly with character strings in ram.

Attached to Project: Community Packages
Opened by Jaroslaw Siebert (y0g1) - Tuesday, 10 May 2016, 06:34 GMT
Last edited by Anatol Pomozov (anatolik) - Tuesday, 01 November 2016, 16:38 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Anatol Pomozov (anatolik)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


I recompiled my program for atmega1284 and mostly it works. The only problem is with character strings located
in ram - they didn't display correctly.
Maybe it is needed to recompile avr-libc with new avr-gcc?

Additional info:
* package version(s)
* config and/or log files etc.

Steps to reproduce:
compile any program for avr with avr-gcc-6.1.1 and see if it works.
This task depends upon

Closed by  Anatol Pomozov (anatolik)
Tuesday, 01 November 2016, 16:38 GMT
Reason for closing:  Fixed
Comment by Anatol Pomozov (anatolik) - Tuesday, 10 May 2016, 16:02 GMT
Rebuilt avr-libc is in [testing] now
Comment by Anatol Pomozov (anatolik) - Saturday, 14 May 2016, 16:05 GMT
Please let us know if you see issues with version in [testing]
Comment by Jaroslaw Siebert (y0g1) - Monday, 16 May 2016, 07:49 GMT
It didn't help.
I found other bug description on:

"There seems to be a bug with 6.1.0 when compiling with -ffunction-sections and any optimization level other than -O0, where strings passed to a function will be stored in flash instead of RAM even though PSTR() hasn’t been used.

puts("test"); // "test" is incorrectly stored in flash, puts() will attempt to read from RAM!

A work around is to the store the string in a variable then pass that to the function:
that will allow using strings located in ram (stack).

static const char myString[] = "test";
But I don't think that doing that is a real work around.
I would stay with avr-gcc-5.x.x and wait for real solution.
Comment by Anatol Pomozov (anatolik) - Tuesday, 17 May 2016, 16:35 GMT
It is an upstream bug. Please report it to upstream and put the link here so we can track the issue status.
Comment by Jaroslaw Siebert (y0g1) - Thursday, 26 May 2016, 04:45 GMT Comment by Jaroslaw Siebert (y0g1) - Tuesday, 31 May 2016, 10:19 GMT
the problem can be worked around by adding -fno-merge-constants to the command options
I used it for testing and there is no problems so far.
Comment by Anatol Pomozov (anatolik) - Monday, 08 August 2016, 23:04 GMT
A new version of avr-gcc with upstream fix (6.1.1-2) has been pushed to testing. Please try it and let us know if it fixes your issue.
Comment by Jaroslaw Siebert (y0g1) - Wednesday, 10 August 2016, 09:15 GMT
First tests: some of my programs doesn't compile. There are errors:
/tmp/ccIqFmqw.ltrans14.ltrans.o: In function `check_pakiet_print':
<artificial>:(.text.check_pakiet_print+0x660): relocation truncated to fit: R_AVR_7_PCREL against `no symbol'
collect2: error: ld returned 1 exit status

Testing program that compiles without errors doesn't work correctly. Maybe we need to recompile avr-libc.

Recompilation avr-libc didn't help
The results are worst than before upstream fix (6.1.1-2). I will do more tests later when I will be back.
Comment by Jaroslaw Siebert (y0g1) - Friday, 19 August 2016, 09:44 GMT
I was waiting for new gcc-6 snapshot.
After using gcc snapshot: 6-20160811
my test programs works ok. With and without option -fno-merge-constants.
So use snapshot from 20160811 (not 20160804)

Comment by Anatol Pomozov (anatolik) - Friday, 19 August 2016, 17:36 GMT
avr-gcc-6.1.1-3 has been pushed to testing. Please try it and let me know the result.
Comment by Jaroslaw Siebert (y0g1) - Tuesday, 23 August 2016, 07:23 GMT
I tested it, but the results are the same.
What is strange - that when I recompilled your package from sources - it was broken.
I installed my version build on 18.08.2016 (20160811 snapshot) and it worked.
Then I recompiled today the same snapshot but using archlinux with testing repo enabled, and
avr-gcc I get is broken like yours.
So something wrong with build process. But what I remember from past - always when I build avr tools
I do it in the same order and always complete:
1. avr-binutils
2. avr-gcc
3. avr-libc
I never did it in seperation. And one important point - when I updated host compiler (gcc) and I updated
one of avr packages then I needed to update all of them in proper order.
All of these 3 packages should be built with te same host compiler version and binutils
I do these 3 steps now (avr-binutils, avr-gcc, avr-libc) and will check if it helps.

Comment by Jaroslaw Siebert (y0g1) - Tuesday, 23 August 2016, 10:40 GMT
More tests and more bad results.
My tysts from 18.08.2016 (20160811 snapshot) was broken (I don't know why, but I build 5.3 version, not snapshot from 20160811)
So I don't have any correct avr-gcc-6 installation. The only correct results was with avr-gcc-6.1.0 (first testing release) and compiler
option -fno-merge-constants.
Nowadays, even -fno-merge-constants doesn't help. The only solution for me is to remove string tables from ram space. Without them, I can
run programs compiled with avr-gcc (I tested also gcc-6.2.0 version)
I would like to see community version of avr-gcc in archlinux repo, so let me know if you will find how to fix it.
Comment by Anatol Pomozov (anatolik) - Tuesday, 23 August 2016, 15:37 GMT
Hi Jaroslaw, thanks for the feedback.

The best way you can do is to report to upstream and actively work with them on fixing the issue.

Please report your findings to
Comment by Jaroslaw Siebert (y0g1) - Sunday, 30 October 2016, 10:04 GMT
there is another bug (from binutils) that cuse problems with avr-gcc 6.

This bug is responsible for relocation regression:
It is already fixed in git.

First solution: remove -mrelax option.
Second solution: use binutils from git
Today I compiled binutils from git and gcc from latest snapshot (20161027)
I did first tests. Programs compile without relocation errors. They work without errors (but I did remote tests only).
In few days I will do more tests with more devices. I hope that finally avr tools
will work stable with latest gcc and binutils.
Lets wait for new release of binutils or compile it from git.

Comment by Jaroslaw Siebert (y0g1) - Sunday, 30 October 2016, 17:41 GMT
I can comfirm, that programs compiled with latest snapshot (gcc) and binutils from git are full functional.
There is no more bugs mentioned in this topic.
Comment by Anatol Pomozov (anatolik) - Sunday, 30 October 2016, 17:46 GMT
Using binutils-git is too risky. Pulling just the fix commit;h=bf1865065f64af2f32798c0327143baf99634e8d is safer in this case.
Comment by Anatol Pomozov (anatolik) - Sunday, 30 October 2016, 18:02 GMT
avr-binutils-2.27-2 with upstream fix pushed to [testing] repository. Please check that it works as expected.
Comment by Jaroslaw Siebert (y0g1) - Tuesday, 01 November 2016, 06:29 GMT
I installed:
from repositories.
Programs, that didn't compile with previous avr-binutils now compile.
Remote testing give me positive results. They work without known problems.
We have got functional avr toolchain again.
It is time to close this bug report.