avr-gcc 4.7.0 for the brave

Go To Last Post
205 posts / 0 new

Pages

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

SprinterSB wrote:
gives me this error:
eep.c:1:21: error: braced-group within expression allowed only inside a function

You might not be interested in potential problems, but that does not mean you may be rude.

JW

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

Magister wrote:
with 4.7.1 prerelease from 20120322 : 15468 bytes
with 4.7.1 prerelease from 20120606 : 15674 bytes
It's likely because of PR53595.

Just uploaded a new avr-gcc-4.7.1-rc1-mingw32.zip stamped 2012-06-07 with a tentative fix for that PR.

wek wrote:
SprinterSB wrote:
gives me this error:
eep.c:1:21: error: braced-group within expression allowed only inside a function

You might not be interested in potential problems, but that does not mean you may be rude.
I though you were well aware that copying some lines out of context is pretty much useless in most cases, so is here:

#include 
int eep;
int pp;
typedef struct { int eeRot; } TCfgRot;
void foo (void)
{
  eep = (__extension__({ uint32_t __addr32 = (uint32_t)((uint32_t)(0x30000UL + pp + __builtin_offsetof (TCfgRot, eeRot))); uint16_t __result; __asm__ ( "out %2, %C1" "\n\t" "movw r30, %1" "\n\t" "elpm %A0, Z+" "\n\t" "elpm %B0, Z" "\n\t" : "=r" (__result) : "r" (__addr32), "I" ((((uint16_t) &((*(volatile uint8_t *)((0X3B) + 0x20)))) - 0x20)) : "r30", "r31" ); __result; }));
}

compiles without complaints with

avr-gcc -c -mmcu=avr6 -Os eep.c

Am I to be blamed because me ran out of crystal balls?

avrfreaks does not support Opera. Profile inactive.

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

...same with

avr-gcc -c -mmcu=avr6 -Os eep.c -mstrict-X

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
Magister wrote:
with 4.7.1 prerelease from 20120322 : 15468 bytes
with 4.7.1 prerelease from 20120606 : 15674 bytes
It's likely because of PR53595.

Just uploaded a new avr-gcc-4.7.1-rc1-mingw32.zip stamped 2012-06-07 with a tentative fix for that PR


with 4.7.1 prerelease from today : 15464 bytes

Problem seems corrected, I will have to test the code on the unit, but the one from 20120322 is running for months now, and as there is only 2 bytes diff, I guess it will be ok.

Thanks again for all your work!

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

SprinterSB wrote:
I though you were well aware that copying some lines [...]

I posted the "some lines" (which is actually ONE line) as a response to:

SprinterSB wrote:
Something is wrong with your inline assembler. It's not a compiler bug.
where you accused specifically the inline assembler - thus I provided it for you to inspect.

SprinterSB wrote:
out of context is pretty much useless in most cases
I have hinted about the context already:
I wrote:
The functions are lengthy (which is IMO expected for the kind of error above), which is why I can't provide a minimal example at the moment, but am willing to discuss/cooperate if you are interested.
I am still willing to discuss/cooperate, if you choose professional discussion rather than attempts to ridicule me.

But I understand also if you are not interested in the apparently laborious path to finding the source of the problem. As I said above, one of the viable options is simply to notify the user through documentation of potential problems when the switch in question is used in conjunction with inline assembler.

JW

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

wek wrote:
SprinterSB wrote:
I though you were well aware that copying some lines [...]

I posted the "some lines" (which is actually ONE line) as a response to:

SprinterSB wrote:
Something is wrong with your inline assembler. It's not a compiler bug.
where you accused specifically the inline assembler - thus I provided it for you to inspect.
Some lines above you wrote that you use pgm_read_byte_far. Consulting avr/progmem.h from AVR-LibC tells that it expands to inline assembler that uses constraint "p".

Using "p" is wrong, wrong, wrong!

Your copy of pgm_read_byte_far does not use "p". How am I supposed to know how your local copy of some code looks like?

If you use other code than you state, then please don't be unfriendly if that leads to wrong or funny conclusions.

wek wrote:
SprinterSB wrote:
[...] out of context is pretty much useless in most cases
I have hinted about the context already:
I wrote:
The functions are lengthy (which is IMO expected for the kind of error above), which is why I can't provide a minimal example at the moment, but am willing to discuss/cooperate if you are interested.
All I can say is:
  • Again and again: 'asm' operand has impossible constraints is an application error. You abuse inline assembler. Fix that.
  • The splill fail is not related to -mstrict-X. Any option that affects cdoe generation up to and including register allogacion might make appear/disapperar that bug.
  • The spill fail is not related to the impossible constraint error! They are two disctinct artifacts.
  • There is already a spill fail reportd: PR50925. This bug is present in all supported versions of gcc and the attached test case #26765 also shreds 4.7.1 if compiled with -Os. Notice that compilation passes if -mstrict-X is added. Or if compiled -O2.
wek wrote:
But I understand also if you are not interested in the apparently laborious path to finding the source of the problem.
If you expect that I guess what source triggered the problem and maybe waste hours, days, or weeks trying around without hitting that bug: Then yes, I am not interested in that.

You abviously have an example that triggers the problem. I undestand the reasons why you are not allowed to post the test case.

However, that does not help. Source code is the interface to communicate. Source code of a test case or source code of the compiler.

You can try to minimize the test case by techniques/tools like delta-debugging to get it under the critical size so that you are allowed to show it.

Or you can explain the compiler sources and where they are wrong: If the test case is secret, then you can debug the compiler or review the sources and get in touch with the GCC developers (I am none of them).

avrfreaks does not support Opera. Profile inactive.

Last Edited: Fri. Jun 8, 2012 - 07:05 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Magister wrote:
with 4.7.1 prerelease from 20120322 : 15468 bytes
with 4.7.1 prerelease from today     : 15464 bytes
You still be interesting where that difference comes from.

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
Some lines above you wrote that you use pgm_read_byte_far. Consulting avr/progmem.h from AVR-LibC tells that it expands to inline assembler that uses constraint "p".

Using "p" is wrong, wrong, wrong!

But that would mean that you were aware that it is NOT *my* asm which is wrong, wrong, wrong; yet accused me of it.

Moreover, if you are aware of that a library function is wrong, wrong, wrong, why don't you post an avr-libc bug report then?

But let's just take one step back. Which avr/progmem.h did you look into? I just had a look into c:\Program Files\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-mingw32\avr\include\avr\pgmspace.h, which comes directly from your bundle - and as far as I know, I used that particular pgmspace.h without modifications.
pgm_read_byte_far() "translates" into __ELPM() and that in turn for atmega2561 into __ELPM_enhanced__(). I see no "p" there. (The posted snippet in fact contained pgm_read_word_far(), but the above text is valid for that one too; and I have a function also with pgm_read_byte_far() which throws the same error).

What did I overlook?

JW

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

avrfreaks does not support Opera. Profile inactive.

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

That's not pgm_read_byte_far() but pgm_get_far_address(var).

I *am* interested in discussing [EDIT]here[/EDIT] why is using "p" constraint in that one wrong, wrong, wrong, but that's irrelevant for our discussion in this thread.

JW

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

Sorry for guessing what your code might do. I should really wait until there is a test case. Just skimmed the far stuff and that line fit perfectly with an error like impossible constraint.

avrfreaks does not support Opera. Profile inactive.

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

I found the shortest function exhibiting the problem, spent nice two hours sectioning it from the project and reducing it somewhat. Here you are (w.c):

#include 
#include 
#include 


register unsigned char __attribute__((used)) _r2 asm("r2");
register unsigned char __attribute__((used)) _r3 asm("r3");
register unsigned char __attribute__((used)) _r4 asm("r4");
register unsigned char __attribute__((used)) _r5 asm("r5");




#define GETItem(p)  (pgm_read_byte_far(pgm_read_word_far((p))))



#define AND &
#define ANL &&
#define SHR >>



  void foo(uint16_t p, uint16_t mask, int16_t p3, uint8_t p4) {

    int16_t a1;
    int16_t a2;
    struct __attribute__((__packed__)) {
      int16_t a3;
      uint8_t a4;
    } buf;


    if ((mask AND (mask-1)) == 0) {
      foo1( foo2(a1) , p3, GETItem(a1), (uint16_t *)pgm_read_word_far(a1));
    } else {

      if (!p4) {
        a1 = p3 - foo3((uint16_t *)pgm_read_word_far(a1));
      } else {
        a1 = 0; //
      }
      p += 1234;

      while (mask != 0) {
        uint16_t pp;

        pp = pgm_read_word_far(p);
        if (pp == 0xFFFF) {
          mask = 0;
        } else if (pp != 0) {
          uint16_t a5;
          uint8_t a6;

          a5 = pgm_read_word_far(pp);
          a6 = foo2(pp);

          if (((mask AND 0x01) != 0) ANL (a6 != 0)) {

            if (p3 == 0x7FFF) {
              buf.a3 = p3;
              buf.a4 = 0;
            } else {

              if (!p4) {
                buf.a3 = foo3((uint16_t *)a5) + a1;
              } else {
                buf.a3 = p3 + a2 - pgm_read_word_far(pp);
              }

              buf.a4 = GETItem(pp);
            }

            foo1(a6, buf.a3, buf.a4, (uint16_t *)a5);
          }

        }
        mask = mask SHR 1;
        p = p + 1234;
      }
    }
  }
c:\tmp>"c:\PROGRA~1\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-ming
w32\bin\avr-gcc" w.c -c -o w.o -mmcu=atmega2561 -Os -mstrict-X
w.c: In function 'foo':
w.c:55:16: error: can't find a register in class 'BASE_POINTER_REGS' while reloa
ding 'asm'
w.c:55:16: error: 'asm' operand has impossible constraints

c:\tmp>"c:\PROGRA~1\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-ming
w32\bin\avr-gcc" w.c -c -o w.o -mmcu=atmega2561 -Os

c:\tmp>"c:\PROGRA~1\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-ming
w32\bin\avr-gcc" w.c -c -o w.o -mmcu=atmega2561 -O3 -mstrict-X
w.c: In function 'foo':
w.c:55:16: error: can't find a register in class 'BASE_POINTER_REGS' while reloa
ding 'asm'
w.c:55:16: error: 'asm' operand has impossible constraints

c:\tmp>"c:\PROGRA~1\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-ming
w32\bin\avr-gcc" w.c -c -o w.o -mmcu=atmega2561 -O2 -mstrict-X
w.c: In function 'foo':
w.c:55:16: error: can't find a register in class 'BASE_POINTER_REGS' while reloa
ding 'asm'
w.c:55:16: error: 'asm' operand has impossible constraints

c:\tmp>"c:\PROGRA~1\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-ming
w32\bin\avr-gcc" w.c -c -o w.o -mmcu=atmega2561 -O1 -mstrict-X

c:\tmp>"c:\PROGRA~1\Atmel\AVRTools\Wavr-gcc-4.7.1-rc1-ming
w32\bin\avr-gcc" w.c -c -o w.o -mmcu=atmega2561 -O0 -mstrict-X

c:\tmp>

The "reserved" registers are instrumental. Removing them removes both errors. Adding -ffixed-rN brings the errors back.

Enjoy! ;-)

JW

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

I can compile that code without problem.

I added -v -save-temps -dp -fverbose-asm to the command options and attached the log, the C-file and the generated assembler for reference.

It also works if "-ffixed-2 -ffixed-3 -ffixed-4 -ffixed-5" is added to the command line, with and without the verbose flags, with and without the global register definitions.

Does it work with nix-friendly path names?

If not I'd guess it's a host problem or some buffer overflow or similar somewhere. If so, the artifact might come or go depending on computer, host, history, other programs running etc...

If you add -fdump-tree-all -fdump-rtl-all how far do the dumps get?

Attachment(s): 

avrfreaks does not support Opera. Profile inactive.

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

I now downloaded the newer version of your bundle (to the same directory, so paths did not change), and the problem is gone.

Does that ring some bells?

JW

[EDIT] added the logs from the failing run with the older version

Attachment(s): 

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

SprinterSB wrote:
Magister wrote:
with 4.7.1 prerelease from 20120322 : 15468 bytes
with 4.7.1 prerelease from today     : 15464 bytes
You still be interesting where that difference comes from.

Yup, it comes from a single function, file is attached if you want to check

options are:
-mmcu=atmega168 -I. -ffreestanding -fno-move-loop-invariants -fno-tree-loop-optimize -funsigned-char -funsigned-bitfields -fshort-enums -fpack-struct -ffunction-sections -fdata-sections -Wl,--relax,--gc-sections -mcall-prologues -mstrict-X -flto -gstabs -DF_CPU=16000000 -Os -Wall -Wstrict-prototypes -std=gnu99

Compiler removed 4 bytes, these 2 lines:

std	Y+18, r15	; 0x12
std	Y+17, r14	; 0x11

I will upload the code to my board and run it.

Attachment(s): 

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

@Jan: I filed it as http://gcc.gnu.org/PR53615

avrfreaks does not support Opera. Profile inactive.

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

Thanks.

Quote:
And here is the source file wek.c
:-)

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

Johann,

When trying to compile http://gcc.gnu.org/bugzilla/atta... with the "first" bundle, it fails even if the shorter version of CODE32 is used.

Why?

JW

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

I don't know the root cause of the problem. A reason might be as speculated in the PR.

avrfreaks does not support Opera. Profile inactive.

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

Hi,
I've compiled a toolchain on x86_64 Linux with:
avr-gcc (GCC) 4.7.1 20120606 (prerelease)
binutils 2.22.52
avr-libc 1.8.0

The results of avr-size look like this:
my old GCC 4.3.4, binutils 2.20.1, libc 1.7.1:

avr-size -C --mcu=atxmega128a1 main.elf
AVR Memory Usage
----------------
Device: atxmega128a1

Program:   79544 bytes (57.1% Full)
(.text + .data + .bootloader)

Data:       6974 bytes (85.1% Full)
(.data + .bss + .noinit)

new toolchain:

avr-size -C --mcu=atxmega128a1 main.elf
AVR Memory Usage
----------------
Device: atxmega128a1

Program:   73598 bytes (52.8% Full)
(.text + .data + .bootloader)

Data:       6664 bytes (81.3% Full)
(.data + .bss + .noinit)

The smaller program size IMHO is impressive, but I wonder why Data also loses that much?

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

Quote:

but I wonder why Data also loses that much?

The .map file wil tell you. (or the output of avr-nm, whichever you prefer).

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

In my case, I could attribute the difference to better handling of compound literals (things which look like a typecast initializer, can be used e.g. to assign to structs or other complex data).

Originally, each occurence of any compound literal involved one instance of it in .data; in 471 compound literals of the same value in one module (source file) are "compressed" to one instance.

(I just realized it was not a good idea to use compound literals to assign values to struct because of the RAM usage, but the code is quite involved so I am not going to change it now just make a mental note not to do it again).

The same may have occured for string literals, if you keep them in RAM (again a bad idea generally).

JW

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

clawson wrote:
The .map file wil tell you. (or the output of avr-nm, whichever you prefer).
I had a look at the map file. This is what I've noticed:

1. constants are moved from .data to .rodate. Also some other stuff is splitted from .data to .data and .rodata, e.g. what does this mean (4.7.1):

 .rodata.str1.1
                0x00000000008020af       0xd5 main.o

2. These seem to be the only missing 0x100 bytes in the 4.7.1 build:

 .data          0x0000000000802338      0x100 /opt/avr-4.3.4/bin/../lib/gcc/avr/4.3.4/avrxmega7/libgcc.a(_clz.o)
                0x0000000000802338                __clz_tab

3. sizes in .bss are identical

PS: Adding "-flto" also saves some more space. At least it strips global variables from .bss that are not used anywhere.

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

salixer wrote:
1. constants are moved from .data to .rodate.
Not really a "move". It's different input sections but they go into the same output section. I don't know how size works, but I'd guess it looks at output sections.
salixer wrote:
Also some other stuff is splitted from .data to .data and .rodata, e.g. what does this mean (4.7.1):
 .rodata.str1.1
                0x00000000008020af       0xd5 main.o

It means that module main.o defines an object in section .rodata.str1.1. Presumably it is a string literal, aligned to 1 byte and with section flags "aMS", i.e. it can be merged with other strings.
salixer wrote:
2. These seem to be the only missing 0x100 bytes in the 4.7.1 build:

 .data          0x0000000000802338      0x100 /opt/avr-4.3.4/bin/../lib/gcc/avr/4.3.4/avrxmega7/libgcc.a(_clz.o)
                0x0000000000802338                __clz_tab

See http://gcc.gnu.org/PR29524

avrfreaks does not support Opera. Profile inactive.

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

The avr-gcc 4.7.1 is released officialy!!!

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

DieCore wrote:
The avr-gcc 4.7.1 is released officialy!!!

GCC 4.7.1 is released officially :P

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

salixer wrote:
I've compiled a toolchain on x86_64 Linux with:
avr-gcc (GCC) 4.7.1 20120606 (prerelease)
[...]

The smaller program size IMHO is impressive

The size might shrink even more with the following patch:

http://gcc.gnu.org/bugzilla/atta...

You can download the patch via the "View" link and then apply it like so:

cd GCC-SOURCES/gcc
patch -p0 < pr53595.diff

Does that patch has further impact on the code size?

avrfreaks does not support Opera. Profile inactive.

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

avr-gcc (GCC) 4.7.1 20120606 (prerelease)

...
Compiling C: main.c
avr-gcc -c -mmcu=atmega1281 -I. -gdwarf-2 -DF_CPU=14745600UL -Os -pedantic -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -fno-split-wide-types -flto -ffunction-sections -fdata-sections -Wl,--relax  -fno-tree-scev-cprop -finline-small-functions -fearly-inlining -Wa,-adhlns=../obj/main.lst -std=c99 -MMD -MP -MF ../obj/dep/main.o.d main.c -o ../obj/main.o 

Linking: ../bin/Paragraph5/Paragraph_PID.elf
avr-gcc -mmcu=atmega1281 -I. -gdwarf-2 -DF_CPU=14745600UL -Os -pedantic -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wstrict-prototypes -fno-split-wide-types -flto -ffunction-sections -fdata-sections -Wl,--relax  -fno-tree-scev-cprop -finline-small-functions -fearly-inlining -Wa,-adhlns=../obj/spi.o -MMD -MP -MF ../obj/dep/Paragraph_PID.elf.d ../obj/spi.o ../obj/rtc_ds1390.o ../obj/rtc.o ../obj/rtc_str.o ../obj/df.o ../obj/ks108.o ../obj/lcd128x64.o ../obj/str_ascii.o ../obj/str_ml.o ../obj/lcd_str.o ../obj/lcd_str_ml.o ../obj/lcd_str_rtc.o ../obj/lcd_img.o ../obj/lcd_gfx.o ../obj/keys.o ../obj/di.o ../obj/led_keyboard.o ../obj/led7.o ../obj/crc16.o ../obj/bin_bcd.o ../obj/filter.o ../obj/gui_progress_bar.o ../obj/gui_scroll_bar.o ../obj/plot_misc.o ../obj/plot_series.o ../obj/plot_background.o ../obj/plot.o ../obj/plot_scroll.o ../obj/plot_zoom.o ../obj/plot_arch.o ../obj/plot_main.o ../obj/menu_content_items_callback.o ../obj/menu_items_rules.o ../obj/menu_items_access.o ../obj/menu_item.o ../obj/menu_item_int.o ../obj/menu_item_enum.o ../obj/menu_item_cmd.o ../obj/menu_item_rtc.o ../obj/menu_item_float.o ../obj/menu_item_submenu.o ../obj/menu_xls.o ../obj/menu_std.o ../obj/menu_plot.o ../obj/menu_arch.o ../obj/menu.o ../obj/rs485.o ../obj/modbus_buffer.o ../obj/modbus_timer.o ../obj/modbus_slave_func.o ../obj/modbus_slave.o ../obj/ad7792.o ../obj/max6627.o ../obj/adc.o ../obj/dac.o ../obj/nsc.o ../obj/ain_cj.o ../obj/ain_tc.o ../obj/ain_rtd.o ../obj/ain_unified.o ../obj/ain_logical.o ../obj/ain_demo.o ../obj/ain.o ../obj/dffs_page.o ../obj/dffs_volume.o ../obj/dffs_info.o ../obj/dffs.o ../obj/timers.o ../obj/gui_base.o ../obj/init_port.o ../obj/init_dev.o ../obj/errors.o ../obj/psychrometer.o ../obj/mathematics.o ../obj/led_misc.o ../obj/relay.o ../obj/pid_timer.o ../obj/pid.o ../obj/registrator.o ../obj/main.o --output ../bin/Paragraph5/Paragraph_PID.elf  -Wl,--gc-section   -Wl,-u,vfprintf -lprintf_flt  -lm

errors:

z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(ceil.o):../../../../../source/avr-libc-1.8/libm/fplib/ceil.S:57:(.text.avr-libc.fplib+0xc): relocation truncated to fit: R_AVR_13_PCREL against symbol `__fp_szero' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_zero.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(exp.o):../../../../../source/avr-libc-1.8/libm/fplib/exp.S:53:(.text.avr-libc.fplib+0x4): relocation truncated to fit: R_AVR_13_PCREL against symbol `__fp_inf' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_inf.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(exp.o):../../../../../source/avr-libc-1.8/libm/fplib/exp.S:54:(.text.avr-libc.fplib+0x6): relocation truncated to fit: R_AVR_13_PCREL against symbol `__fp_zero' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_zero.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(exp.o):../../../../../source/avr-libc-1.8/libm/fplib/exp.S:55:(.text.avr-libc.fplib+0x8): relocation truncated to fit: R_AVR_13_PCREL against symbol `__fp_nan' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_nan.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(exp.o):../../../../../source/avr-libc-1.8/libm/fplib/exp.S:59:(.text.avr-libc.fplib+0xa): relocation truncated to fit: R_AVR_13_PCREL against symbol `__fp_splitA' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_split3.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(exp.o):../../../../../source/avr-libc-1.8/libm/fplib/exp.S:72:(.text.avr-libc.fplib+0x20): relocation truncated to fit: R_AVR_13_PCREL against symbol `__mulsf3_pse' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(mulsf3x.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(floor.o):../../../../../source/avr-libc-1.8/libm/fplib/floor.S:56:(.text.avr-libc.fplib+0xc): relocation truncated to fit: R_AVR_13_PCREL against symbol `__fp_szero' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_zero.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fma.o):../../../../../source/avr-libc-1.8/libm/fplib/fma.S:48:(.text.avr-libc.fplib+0x0): relocation truncated to fit: R_AVR_13_PCREL against symbol `__mulsf3x' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(mulsf3x.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fma.o):../../../../../source/avr-libc-1.8/libm/fplib/fma.S:53:(.text.avr-libc.fplib+0xa): relocation truncated to fit: R_AVR_13_PCREL against symbol `__fp_round' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_round.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_powser.o):../../../../../source/avr-libc-1.8/libm/fplib/fp_powser.S:79:(.text.avr-libc.fplib+0x1a): relocation truncated to fit: R_AVR_13_PCREL against symbol `__mulsf3x' defined in .text.avr-libc.fplib section in z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(mulsf3x.o)
z:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(fp_rempio2.o):../../../../../source/avr-libc-1.8/libm/fplib/fp_rempio2.S:50:(.text.avr-libc.fplib+0x0): additional relocation overflows omitted from the output
collect2.exe: error: ld returned 1 exit status
make: *** [../bin/Paragraph5/Paragraph_PID.elf] Error 1

W/O LTO everything is Ok.
Any suggestions are welcome!

Oh, how I miss -combine option:)

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

What means "W/O"?

Looks like a known AVR-Libc issue, see
http://savannah.nongnu.org/bugs/...

I don't think you need -combine with LTO, wasn't -combine removed?

avrfreaks does not support Opera. Profile inactive.

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

SprinterSB wrote:
What means "W/O"?
without

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

SprinterSB wrote:
wasn't -combine removed?
Yes it was. I believe that this was done prematurely.
As I can see (LTO and enviroment) still needs to further adapt.
Thanks you for your reply!

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

demiurg_spb wrote:
SprinterSB wrote:
wasn't -combine removed?
Yes it was. I believe that this was done prematurely.
As I can see (LTO and enviroment) still needs to further adapt.
-combine and -fwhole-program are noe more needed since LTO which is even more powerful.

Even projects as big as Mozilla FireFox or GCC itself build fine with LTO.

There were some issues with linux→mingw32 canadian cross built compiler (PR50616) and AVR-specific built-ins together with LTO (PR52692) but they are fixed now.

avrfreaks does not support Opera. Profile inactive.

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

So, you tell me that gcc+LTO is good enougth to build itself. It's great (realy)!
But avr-libc project is not compliant with LTO for now (maybe I wrong).
Please suggest me what approach should I follow to buld my not so big avr-project with fast-math and LTO?
I can't do it since -combine and -fwhole-program were marked as deprecated and dissapeared ~1.5 years ago.

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

demiurg_spb wrote:
But avr-libc project is not compliant with LTO for now (maybe I wrong).
AVR-Libc makes an assumption that does ot hold: That all bits in the same input section are located close together in their respective output section.

As discussed in abovementioned #33698 that assumption does not hold because the default linker script does ot come with a SORT directive.

Consequently, if you need AVR-Libc and LTO, you can

  1. Call the compiler driver gcc with -Wl,--sort-section=name
  2. Fix the malicious explicit RJMP/RCALL in AVR-Libc and use XJMP/XCALL macros instead, recompile the library (which is straight forward) and use the fixed library.
  3. Use an ld script with sort directive as discussed in #33698 instead of the default ld script which comes without such a directive.
AFAIK Jörg is preparing the AVR-Libc 1.8.1 release that will come with this issue fixed.

@admin: Still greedy for CAPTCHA??

avrfreaks does not support Opera. Profile inactive.

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

Thanks! I will try.
Let's start:

SprinterSB wrote:
Call the compiler driver gcc with -Wl,--sort-section=name
I've gotten other similar errors
c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(inverse.o):../../../../../source/avr-libc-1.8/libm/fplib/inverse.S:50:(.text.avr-libc.fplib+0xc): relocation truncated to fit: R_AVR_13_PCREL against symbol `__divsf3' defined in .text section in c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/avr51\libgcc.a(_div_sf.o)
c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(log.o):../../../../../source/avr-libc-1.8/libm/fplib/log.S:96:(.text.avr-libc.fplib+0x46): relocation truncated to fit: R_AVR_13_PCREL against symbol `__addsf3' defined in .text section in c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/avr51\libgcc.a(_addsub_sf.o)
c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(log.o):../../../../../source/avr-libc-1.8/libm/fplib/log.S:100:(.text.avr-libc.fplib+0x4e): relocation truncated to fit: R_AVR_13_PCREL against symbol `__addsf3' defined in .text section in c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/avr51\libgcc.a(_addsub_sf.o)
c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/../../../../avr/lib/avr51\libc.a(modf.o):../../../../../source/avr-libc-1.8/libm/fplib/modf.S:90:(.text.avr-libc.fplib+0x3e): relocation truncated to fit: R_AVR_13_PCREL against symbol `__subsf3' defined in .text section in c:/gcc/avr-gcc/bin/../lib/gcc/avr/4.7.1/avr51\libgcc.a(_addsub_sf.o)
collect2.exe: error: ld returned 1 exit status
make: *** [../bin/Paragraph5/Paragraph_PID.elf] Error 1

Number of errors have reduced to 4.
It's good but not enough:)

Should I use only gnu99 instead of c99 in case of __flash usage?
With PROGMEM attributes I was able to use c99 and it was habitually.

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

SprinterSB wrote:
-combine and -fwhole-program are noe more needed since LTO which is even more powerful.

I've just made test [LTO vs combine] with other little project and ... :shock:

avr-gcc (WinAVR 20100110) 4.3.3 [with combine]
Program: 13778 bytes (84.1% Full)
Data: 513 bytes (50.1% Full)
EEPROM: 82 bytes (16.0% Full)

avr-gcc (GCC) 4.7.1 20120606 (prerelease) [with lto]
Program: 15860 bytes (96.8% Full) <--------------- +2000bytes !!!
Data: 521 bytes (50.9% Full)
EEPROM: 83 bytes (16.2% Full) <--------------- +1byte ???

I have played with different optimisation parameters... and this is the best result.
Something is wrong. But I can't see it.
Attached files:

Attachment(s): 

Last Edited: Fri. Aug 10, 2012 - 06:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How are the options for the last link, i.e. after lto proper has finished?

avrfreaks does not support Opera. Profile inactive.

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

English is not my native language, and maybe I don't understand what you are asking me for..
Please look attached files in my previous post, all options is here.
Compilation with LTO ends successfully only if project size is <16K and almost without math (because of avr-libc rjmps and rcalls).
Only difference what I see is: last times I've called compiler with all *.c files at once:

Quote:
Another (simpler) way to enable link-time optimization is:
gcc -o myprog -flto -O2 foo.c bar.c
This quote is from http://gcc.gnu.org/onlinedocs/gc...

I yet only haven't try to use gold linker instead collect2.
Should I?

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

Does it work if you link with these?

    -nodefaultlibs -lm -lgcc -lc -lgcc

avrfreaks does not support Opera. Profile inactive.

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

Oh eeeeeeeee!!!

avr-gcc (GCC) 4.7.1 20120606 (prerelease) [with lto and -nodefaultlibs -lm -lgcc -lc]
Program: 13530 bytes (82.6% Full)
Data: 513 bytes (50.1% Full)
EEPROM: 83 bytes (16.2% Full) <--------------- +1byte ???

It's perfect!!! Thank you very much!!!

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

BTW maybe you know why next code compiles without any warnings and errors... If I remember, IAR makes warn in this case.

const __flash char* pcf;
const char* pc;

void test1(void) {pcf = pc;}
void test2(void) {pc = pcf;}
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's odd and I don't understand why the eeprom usage does up.

The -flto -lm issue is discussed in avr-gcc-list: binutils 2.22 blow up program size with -flto. It's an old AVR-Libc issue that's cast into stone...

For the missing warning you can file a GCC problem report.

avrfreaks does not support Opera. Profile inactive.

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

1)
I found an annoying problem:(
The EEPROM data are sorted in reverse order in target hex-file.
I.E. in my src file:
EEMEM int x1;
EEMEM int x2;
EEMEM int x3;

in map and hex files:
EEMEM int x3;
EEMEM int x2;
EEMEM int x1;

2)
And if only lto is turned on all dummy EEPROM variables are disappeared.
I understand if I put all EEPROM data in one structure everything should be ok. But I want to know: other approach is possible?

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

Quote:

The EEPROM data are sorted in reverse order in target hex-file.

But this was always a possibility. C gives no guarantee about the order of data in memory. As you say, if you want to guarantee such an ordering then use a struct:

struct {
  int x1;
  int x2;
  int x3; 
} eevars EEMEM;

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

It's me again.
New error appears if target mcu is mega128

original code of file: avr-libc/avr/boot.h

#if defined (SPMCSR)
#  define __SPM_REG    SPMCSR
#elif defined (SPMCR)
#  define __SPM_REG    SPMCR
#else
#  error AVR processor does not provide bootloader support!
#endif

error: attempt to use poisoned "SPMCR"

modified code (compiles without any errors):

#if defined(SPMCSR)
#  define __SPM_REG     SPMCSR
#elif !defined (__AVR_ATmega128__)
#  if defined(SPMCR)
#    define __SPM_REG   SPMCR
#  endif
#endif

#if !defined(__SPM_REG)
#  error error AVR processor does not provide bootloader support!
#endif

I guess it's avr-gcc bug.
Original avr-libc code is correct.

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

demiurg_spb wrote:
original code of file: avr-libc/avr/boot.h [...]
error: attempt to use poisoned "SPMCR"

I guess it's avr-gcc bug.

No, it's AVR-Libc issue #36410.

avrfreaks does not support Opera. Profile inactive.

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

But how it possible?
There is no bug in boot.h

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

boot.h uses a poisoned macro, namely SPMCR. AVR-Libc poisons it elsewhere, but missed to update the use site.

Or are you saying that AVR-Libc is not poisoning SPMCR anywhere, and the poisoning is out of the blue and a GCC artifact?

avrfreaks does not support Opera. Profile inactive.

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

You are right!
I found in iom128.h:
#pragma GCC poison SPMCR

So that boot.h should be modified to fix this situation...

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

avr-gcc (GCC) 4.7.1 20120606 (prerelease)

CFLAGS += -std=gnu99
CFLAGS += -Os
CFLAGS += -pedantic
CFLAGS += -Wall
CFLAGS += -Wextra
void func(void)
{
	static const int PROGMEM x = 0;
	(void)x; // dummy
}

warning: uninitialized variable 'x' put into program memory area [-Wuninitialized]

static const int PROGMEM x = 0;

void func(void)
{
	(void)x; // dummy
}

No warning...

Pages