Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: IAR 6.4 Optimization Bug
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Cредства разработки для МК > IAR
Страницы: 1, 2
Sagittarius
Здравствуйте.

Была в проекте написана простая функция преобразования числа uint32 в строку, без оптимизации работает, при включении Optimization/High/Speed и наличии опции Function Inlining вместо всего числа в строку заносит только последнюю цифру. Функцию конечно поправил так чтоб работала и при оптимизации но как то все равно неприятно, где еще ждать косяков.
сам код:

CODE
//
///8*************************************************
// перевод числа i в строку символов в buf длиной = maxlen
uint32_t Int2Str(uint32_t i,uint8_t *buf,uint32_t maxlen){
uint32_t j;
uint32_t k,l;
uint32_t idx;

idx=0;
// используется только для преобразования даты
if((i<10000)&&(maxlen)&&(maxlen<=4)){
for(j=(maxlen-1);j;j--){
buf[idx]='0';
k=Pow10(j);
for(l=9;l;l--){
if(i>=k){
i-=k;
buf[idx]++;
}else l=1; // выход из цикла
}
idx++;
}
buf[idx]='0'+i;
idx++;
}
// buf[idx]=0;
return idx;
}

///8*************************************************
uint32_t Pow10(uint32_t p){// возвращает 10^p
uint32_t ret=1;
if(p>8)ret=0;
else{
for(;p;p--)ret*=10;
}
return ret;
}




Отдельный проект с этими функциями в IAR:
Нажмите для просмотра прикрепленного файла
Было обнаружено на STM32F103, проверено наличие бага и для LPC2378

Спасибо.
Lotor
Что Вы хотели донести до общественности? Правильнее выложить asm-листинги и указать различия до и после оптимизации.
Sagittarius
Цитата(Lotor @ Oct 3 2012, 10:01) *
Что Вы хотели донести до общественности? Правильнее выложить asm-листинги и указать различия до и после оптимизации.

1. Есть баги изменяющие работающий без оптимизации алгоритм
2. выложен проект, кто хочет - скомпилит и посмотрит сам.
Lotor
Цитата(Sagittarius @ Oct 3 2012, 10:17) *
1. Есть баги изменяющие работающий без оптимизации алгоритм
2. выложен проект, кто хочет - скомпилит и посмотрит сам.

Т.е. Вы не в состоянии указать почему эти баги появились/исчезли? Если хотите обвинить оптимизацию в иаре, то потрудитесь выложить асм код до/после оптимизации и покажите на "IAR 6.4 Optimization Bug".
Цитата(Sagittarius @ Oct 3 2012, 09:50) *
но как то все равно неприятно, где еще ждать косяков.

С таким подходом везде... =)
VslavX
Цитата(Sagittarius @ Oct 3 2012, 08:50) *
Была в проекте написана простая функция преобразования числа uint32 в строку

Вы меня извините, но это далеко не простая функция, сразу бросаются в глаза алгоритмические косяки:

- вычисление степени 10 в цикле (facepalm)
(это можно сделать таблицей, да и вообще без степеней можно обойтись)

- вычисление очередной цифры циклом вычитания (facepalm)
(про деление автору ничего неизвестно?)

- выход из цикла с лишним сравнением условия (l=1) (facepalm)
(банальный break там просится)

ИМХО, тут не в компиляторе "собака порылась".
Sagittarius
Цитата(VslavX @ Oct 3 2012, 10:55) *
Вы меня извините, но это далеко не простая функция, сразу бросаются в глаза алгоритмические косяки:
ИМХО, тут не в компиляторе "собака порылась".

Речь не о кривости алгоритма а о разной его работе при отключенной и включенной оптимизации в компиляторе.
про степень согласен, но тогда баг скорее всего бы не вылез :-)
деление - писалось под ARM7TDMI, там нет аппаратного деления, был бы вызов библиотечной функции
break - просто мне он не нравится, так же как и return из середины функции.

2Lotr: это просто сообщение о наличии проблемы в IAR 6.4 и проект где она воспроизводится. Я ее обошел, мне не мешает. Если кому то надо то он прочитает и разберется сам.
Lotor
Цитата(Sagittarius @ Oct 3 2012, 11:43) *
это просто сообщение о наличии проблемы в IAR 6.4 и проект где она воспроизводится. Я ее обошел, мне не мешает. Если кому то надо то он прочитает и разберется сам.

Я устал намекать, что скорее всего проблема не в оптимизаторе компилятора. Обходили Вы свои же косяки.

PS: Вам нужно самому разобраться и осознать, что 99% ошибок в наши дни - именно авторские, а не компилятора/кристалла.
VslavX
Цитата(Sagittarius @ Oct 3 2012, 10:43) *
Речь не о кривости алгоритма а о разной его работе при отключенной и включенной оптимизации в компиляторе.
про степень согласен, но тогда баг скорее всего бы не вылез :-)

Ну я вообще-то осторожно намекал что там, скорее всего, еще косяки есть, а не только "бросившиеся в глаза".

Цитата(Sagittarius @ Oct 3 2012, 10:43) *
деление - писалось под ARM7TDMI, там нет аппаратного деления, был бы вызов библиотечной функции

А почему не устраивает библиотечная функция? Недостаточно быстрая для использования при выводе строки? Ну если уж такие требования к скорости, то надо было бы рассмотреть алгоритмы быстрого деления на константу (через умножение, Кнут, том 2). И сделать две явные версии - для процессоров с аппаратным делением и без (а при использовании библиотеки это автоматом).

ИМХО, разумным (чтобы не заводить таблицу из 10000 слов) по скорости для вывода в ASCII числа 0-9999 было бы одно деление на 100 с остатком, и вывод двух чисел 0-99 (частного и остатка) по готовой табличке ('00' .. '99'). В этом одном делении, даже универсальном (не константу, на любое число) программном в библиотечной функции, было бы максимум 8 итераций цикла деления. Сравните со своими средним количеством циклов 20 (циклы вычисления степени не учитываем).

Цитата(Sagittarius @ Oct 3 2012, 10:43) *
break - просто мне он не нравится, так же как и return из середины функции.

OK, имейте лишнюю проверку условия, раз уж нравится (за скорость уже не боремся?). И необходимость полной ревизии цикла, если условие в цикле надо будет изменить. "return" - то несколько из другой оперы.

ЗЫ: Я тоже думаю что 99% компилятор тут не при чем. "Листинг в студию, сестра!" ©
scifi
Кстати, и мне интересно. Без доказательств всё это выглядит как наброс. Нет, ЯР не безгрешен, но гораздо чаще встречаются косяки программиста.
Список доказательств:
1) исходники (вроде бы есть)
2) правильный (ожидаемый) результат работы программы
3) неправильный результат
4) дизассембленый листинг кода, давшего неправильный результат
Sagittarius
в архиве проект под IAR, оптимизация включена. Запускаем симулятор. Содержимое buf после выполнения функции {0,0,'7',0,0}
Отключаем оптимизацию, запускаем. Содержимое буфера {'7','7','7',0,0}. По поводу косячности функции - была проверена записью в файл и последующем чтении из файла в диапазоне входных значений 0-9999, результат корректен Задачи оптимизации данной функции не ставилось.
KRS
Так вы бы листинг и привели с указанием ошибки!
Честно говоря такую кривую функцию даже компилировать не хочется!

Если уж нужна быстрая - так у всех АРМ есть умножение и можно обойтись без циклов, примерно так (для 4 разрядных чисел)
Код
    d=(v*8389)>>23;
    v=v-d*1000;
    buf[0]=d+'0';
    d=(v*41)>>12;
    v=v-d*100;
    buf[1]=d+'0';
    d=(v*103)>>10;
    buf[2]=d+'0';
    v=v-d*10;
    buf[3]=d+'0';


scifi
Может быть, кому-то захочется покопаться:
Исходник (орфография и пунктуация автора сохранены):
CODE
#include <ctype.h>
#include <stdint.h>
#include <intrinsics.h>


uint32_t Int2Str(uint32_t i,uint8_t *buf,uint32_t maxlen);
uint32_t Pow10(uint32_t p);

volatile uint8_t buf[5];

void main(void){
// Int2Str(777,buf,3);
while(1){
Int2Str(777,(uint8_t*)buf,3);
buf[0]++;
buf[2]++;
buf[4]++;
}
}



///8*************************************************
// перевод числа i в строку символов в buf длиной = maxlen
uint32_t Int2Str(uint32_t i,uint8_t *buf,uint32_t maxlen){
uint32_t j;
uint32_t k,l;
uint32_t idx;

idx=0;
// используется только для преобразования даты
if((i<10000)&&(maxlen)&&(maxlen<=4)){
for(j=(maxlen-1);j;j--){
buf[idx]='0';
k=Pow10(j);
for(l=9;l;l--){
if(i>=k){
i-=k;
buf[idx]++;
}else l=1; // выход из цикла
}
idx++;
}
buf[idx]='0'+i;
idx++;
}
// buf[idx]=0;
return idx;
}

/*
// корректно оптимизируемый код
uint32_t Int2Str(uint32_t i,uint8_t *buf,uint32_t maxlen){
uint32_t j;
uint32_t k,l;
uint32_t idx;

idx=0;
// используется только для преобразования даты
if((i<10000)&&(maxlen)&&(maxlen<=4)){
for(j=(maxlen-1);j;j--){
*buf='0';
k=Pow10(j);
for(l=9;l;l--){
if(i>=k){
i-=k;
(*buf)++;
}else l=1; // выход из цикла
}
buf++;
}
*buf='0'+i;
idx++;
}
// buf[idx]=0;
return idx;
}

*/



///8*************************************************
uint32_t Pow10(uint32_t p){// возвращает 10^p
uint32_t ret=1;
if(p>8)ret=0;
else{
for(;p;p--)ret*=10;
}
return ret;
}

Дизассемблер:
CODE
void main(void){
main:
0x2f4: 0x480f LDR.N R0, ??DataTable1 ; buf
0x2f6: 0xe00f B.N ??main_0 ; 0x318
}else l=1; // auoia ec oeeea
??main_1:
0x2f8: 0x2601 MOVS R6, #1
for(l=9;l;l--){
??main_2:
0x2fa: 0x1e76 SUBS R6, R6, #1
0x2fc: 0xd116 BNE.N ??main_3 ; 0x32c
for(j=(maxlen-1);j;j--){
0x2fe: 0x1e64 SUBS R4, R4, #1
for(j=(maxlen-1);j;j--){
0x300: 0xd10c BNE.N ??main_4 ; 0x31c
buf[idx]='0'+i;
0x302: 0x3330 ADDS R3, R3, #48 ; 0x30
0x304: 0x7083 STRB R3, [R0, #0x2]
return idx;
0x306: 0x7803 LDRB R3, [R0]
0x308: 0x1c5b ADDS R3, R3, #1
0x30a: 0x7003 STRB R3, [R0]
0x30c: 0x7883 LDRB R3, [R0, #0x2]
0x30e: 0x1c5b ADDS R3, R3, #1
0x310: 0x7083 STRB R3, [R0, #0x2]
0x312: 0x7903 LDRB R3, [R0, #0x4]
0x314: 0x1c5b ADDS R3, R3, #1
0x316: 0x7103 STRB R3, [R0, #0x4]
??main_0:
0x318: 0x4b07 LDR.N R3, ??DataTable1_1 ; 0x309 (777)
for(j=(maxlen-1);j;j--){
0x31a: 0x2402 MOVS R4, #2
uint32_t ret=1;
??main_4:
0x31c: 0x2501 MOVS R5, #1
if(p>8)ret=0;
0x31e: 0x0026 MOVS R6, R4
for(;p;p--)ret*=10;
??main_5:
0x320: 0x00af LSLS R7, R5, #2
0x322: 0x197d ADDS R5, R7, R5
0x324: 0x006d LSLS R5, R5, #1
for(;p;p--)ret*=10;
0x326: 0x1e76 SUBS R6, R6, #1
for(;p;p--)ret*=10;
0x328: 0xd1fa BNE.N ??main_5 ; 0x320
for(l=9;l;l--){
0x32a: 0x2609 MOVS R6, #9
if(i>=k){
??main_3:
0x32c: 0x42ab CMP R3, R5
0x32e: 0xd3e3 BCC.N ??main_1 ; 0x2f8
i-=k;
0x330: 0x1b5b SUBS R3, R3, R5
buf[idx]++;
0x332: 0xe7e2 B.N ??main_2 ; 0x2fa
??DataTable1:
0x334: 0x40000120 DC32 buf
??DataTable1_1:
0x338: 0x00000309 DC32 777 ; ' ...'
exit:
0x33c: 0xb580 PUSH {R7, LR}
0x33e: 0xf000 0xf825 BL ?Veneer (4) for _exit ; 0x38c
0x342: 0xbc09 POP {R0, R3}
0x344: 0x4718 BX R3

Да, код заполняет в буфере только позицию buf[2] = '7'.
KRS
Видно что
buf[idx]++;
компилятор выкинул

Кстати если inline отключить, т.е. и Pow и Int2Str будут как функции!
Все равно buf[idx]++; выкидывает!


На самом деле бага довольно серьезная!!! И может вылезти в проектах sad.gif
Если в цикле используется buf[i]++, а после цикла присваивание последнему элементу массива проявляется!

Для иллюстрации 2 простых функции
Код
void test_bug(uint32_t v, uint8_t *buf)
{
    unsigned i;
    for(i=0;i<3;i++){
        buf[i]='0';
        if (v & 1<<i)
            buf[i]++;
    }
    buf[i]=v & 0x8;
}

void test_bug2(uint32_t v, uint8_t *buf)
{
    unsigned i;
    for(i=0;i<3;i++){
        buf[i]='0';
        if (v & 1<<i)
            buf[i]++;
    }
}


А вот листинг

Код
  19          void test_bug(uint32_t v, uint8_t *buf)
     20          {
     21              unsigned i;
     22              for(i=0;i<3;i++){
     23                  buf[i]='0';
     24                  if (v & 1<<i)
     25                      buf[i]++;
     26              }
     27              buf[i]=v & 0x8;
   \                     test_bug:
   \   00000000   0x2208             MOVS     R2,#+8
   \   00000002   0x4010             ANDS     R0,R0,R2
   \   00000004   0x70C8             STRB     R0,[R1, #+3]
     28          }
   \   00000006   0x4770             BX       LR              ;; return
     29          

   \                                 In section .text, align 2, keep-with-next
     30          void test_bug2(uint32_t v, uint8_t *buf)
     31          {
   \                     test_bug2:
   \   00000000   0xB418             PUSH     {R3,R4}
     32              unsigned i;
     33              for(i=0;i<3;i++){
   \   00000002   0x2230             MOVS     R2,#+48
     34                  buf[i]='0';
   \   00000004   0x2330             MOVS     R3,#+48
     35                  if (v & 1<<i)
   \   00000006   0x07C4             LSLS     R4,R0,#+31
   \   00000008   0xD500             BPL      ??test_bug2_0
     36                      buf[i]++;
   \   0000000A   0x2331             MOVS     R3,#+49
   \                     ??test_bug2_0:
   \   0000000C   0x700B             STRB     R3,[R1, #+0]
   \   0000000E   0x2330             MOVS     R3,#+48
   \   00000010   0x0784             LSLS     R4,R0,#+30
   \   00000012   0xD500             BPL      ??test_bug2_1
   \   00000014   0x2331             MOVS     R3,#+49
   \                     ??test_bug2_1:
   \   00000016   0x704B             STRB     R3,[R1, #+1]
   \   00000018   0x0740             LSLS     R0,R0,#+29
   \   0000001A   0xD500             BPL      ??test_bug2_2
   \   0000001C   0x2231             MOVS     R2,#+49
   \                     ??test_bug2_2:
   \   0000001E   0x708A             STRB     R2,[R1, #+2]
     37              }
     38          }
   \   00000020   0xBC11             POP      {R0,R4}
   \   00000022   0x4770             BX       LR              ;; return

   \                                 In section .text, align 4, keep-with-next
   \                     ??DataTable0:
   \   00000000   0x........         DC32     buf


Видно что в первом варианте код весь убран!

Вы будете смеяться!!!
все еще проще sm.gif

void test_bug3(uint8_t *buf)
{
unsigned i;
for(i=0;i<3;i++){
buf[i]=0;
}
buf[i]=0;
}

Код
                                In section .text, align 2, keep-with-next
     40          void test_bug3(uint8_t *buf)
     41          {
     42              unsigned i;
     43              for(i=0;i<3;i++){
     44                  buf[i]=0;
     45              }
     46              buf[i]=0;
   \                     test_bug3:
   \   00000000   0x2100             MOVS     R1,#+0
   \   00000002   0x70C1             STRB     R1,[R0, #+3]
     47          }
   \   00000004   0x4770             BX       LR              ;; return

chernenko
Может я не то что-то делаю, но у меня на 6.10 (другого нет) корректно работает.
KRS
так писали про 6.4

у меня
IAR ANSI C/C++ Compiler V6.40.1.53790/W32 for ARM

в итоге самый простой код приводящий к ошибке
Код
void test_bug3(uint8_t *buf)
{
    unsigned i;
    for(i=0;i<100;i++){
        buf[i]=0;
    }
    buf[i]=0;
}


в цикле константа может быть любая! (пробовал 3,4,7,100)
видимо ЯР видя за циклом buf[i]=0, не учитывает что в цикле индекс меняется и buf[i] это разные элементы массива.
chernenko
Цитата(KRS @ Oct 3 2012, 16:52) *
так писали про 6.4

Я понимаю. Я написал для статистики, что результат свойственен последней версии и в одной из предыдущих все работает.
Lotor
Таки глюк компилятора...

PS: Как действовать автору топика в подобных ситуациях наглядно продемонстрировал KRS. =)
KRS
а новый компилер 6.40.4 (кажется) кто нибудь использует?
надо бы в ЯР код послать, если не исправили еще
Sagittarius
Цитата(KRS @ Oct 3 2012, 17:21) *
а новый компилер 6.40.4

IAR C/C++ Compiler for ARM
6.40.4.24170 (6.40.4.24170)
C:\Program Files (x86)\IARM64\arm\bin\iccarm.exe
13/Sep/2012 05:19:20, 27336704 bytes

все еще бажит
KRS
Глючат именно циклы с предусловием (и не только циклы с goto тоже самое) но с проверкой условия в начале.
Причем независимо от управляющей переменной!
из этих функций нормально компилируются только нечетные!
CODE
void test_bug4(uint8_t *buf)
{
unsigned i;
unsigned j;
j=100;
i=0;
while(i<10){
buf[i++]=j;
j-=2;
}
buf[i]=0;
}

void test_bug5(uint8_t *buf)
{
unsigned i;
unsigned j;
j=100;
i=0;
do {
buf[i++]=j;
j-=2;
} while(i<10);
buf[i]=0;
}

void test_bug6(uint8_t *buf)
{
unsigned i;
unsigned j;
j=100;
i=0;
while(j>0){
buf[i++]=j;
j-=2;
}
buf[i]=0;
}

void test_bug7(uint8_t *buf)
{
unsigned i;
unsigned j;
j=100;
i=0;
do {
buf[i++]=j;
j-=2;
}while(j >0);
buf[i]=0;
}

void test_bug8(uint8_t *buf)
{
unsigned i;
unsigned j;
j=100;
i=0;
loop:
if (i < 10) {
buf[i++]=j;
j-=2;
goto loop;
}
buf[i]=0;
}

void test_bug9(uint8_t *buf)
{
unsigned i;
unsigned j;
j=100;
i=0;
loop:
buf[i++]=j;
j-=2;
if (i < 10)
goto loop;
buf[i]=0;
}
VslavX
Версия 5.41 - генерирует нормально. Мда, никак оно на 6.x перейти не получается, серьезно будем рассматривать GCC от CodeSourcery/Mentor.


Цитата(KRS @ Oct 4 2012, 10:29) *
Глючат именно циклы с предусловием

Что-то с тестированием в ЯР плоховато. Такие косяки можно автоматическими тестами выловить. Скомпилируй и запусти на реальном железе - все быстро вылезет.
grisha_scorpion
Используйте квалификатор volatile. И будет вам счастье. Справка: Квалификатор volatile указывает компилятору на то, что значение переменной может измениться независимо от программы, т.е. вследствие воздействия еще чего-либо, не являющегося оператором программы. Например, адрес глобальной переменной можно передать в подпрограмму операционной системы, следящей за временем, и тогда эта переменная будет содержать системное время. В этом случае значение переменной будет изменяться без участия какого-либо оператора программы. Знание таких подробностей важно потому, что большинство компиляторов С автоматически оптимизируют некоторые выражения, предполагая при этом неизменность переменной, если она не встречается в левой части оператора присваивания. В этом случае при очередной ссылке на переменную может использоваться ее предыдущее значение. Некоторые компиляторы изменяют порядок вычислений в выражениях, что может привести к ошибке, если в выражении присутствует переменная, вычисляемая вне программы. Квалификатор volatile предотвращает такие изменения программы.
Сергей Борщ
QUOTE (grisha_scorpion @ Oct 10 2012, 10:33) *
Используйте квалификатор volatile. И будет вам счастье.
В данном случае он абсолютно не нужен, ибо "воздействия еще чего-либо, не являющегося оператором программы" тут нет.
grisha_scorpion
Цитата(Сергей Борщ @ Oct 10 2012, 12:04) *
В данном случае он абсолютно не нужен, ибо "воздействия еще чего-либо, не являющегося оператором программы" тут нет.

Компилятор не знает есть внешнее воздействие или нет. Он не будет оптимизировать код где используются переменные с квалификатором volatile
scifi
Цитата(grisha_scorpion @ Oct 10 2012, 14:58) *
Компилятор не знает есть внешнее воздействие или нет. Он не будет оптимизировать код где используются переменные с квалификатором volatile

Как способ обойти баг компилятора это, возможно, и сработает. Но автор уже обошёл его, поэтому ваше предложение не очень-то интересно. А пафос темы именно в том, что в компиляторе присутствует баг.
Сергей Борщ
QUOTE (grisha_scorpion @ Oct 10 2012, 13:58) *
Компилятор не знает есть внешнее воздействие или нет.
Программист знает. Бага компилятора не является внешним воздействием, а других влияний на эти переменные нет. Прочитайте свою же справку и покажите, какая из перечисленных там причин подходит для этого кода.
KRS
кстати с volatile тоже не все в порядке!
при цикле в 100 байт и присваивание 0. IAR сообразил что это очистка памяти и вызвал
___aaeabi_memclr
дальше не копал, но что то я сомневаюсь что эта функция будет по байтам 0 писать! А все таки раз уж volatile то менять байтовый доступ на словный не совсем корректно.
scifi
Цитата(KRS @ Oct 10 2012, 22:45) *
кстати с volatile тоже не все в порядке!

Чем дальше в лес, тем толще партизаны!
Да уж, ЯР отжигает. Им пора "горячую линию" по поводу своих багов открывать...
MrAlex
а что уже можно тип не указывать? только unsigned?
scifi
Цитата(MrAlex @ Oct 11 2012, 12:35) *
а что уже можно тип не указывать? только unsigned?

Всегда можно было. Читайте учебники. K&R, к примеру.
KRS
В новом IAR 6.40.5
компилятор
IAR ANSI C/C++ Compiler V6.40.4.54170/W32 for ARM
бага осталась
Andy Mozzhevilov
Цитата(KRS @ Oct 15 2012, 14:44) *
В новом IAR 6.40.5
компилятор
IAR ANSI C/C++ Compiler V6.40.4.54170/W32 for ARM
бага осталась

Чтобы поправили, надо бы им в поддержку отписать. А то ж они - не телепаты.
KRS
Цитата(Andy Mozzhevilov @ Oct 15 2012, 14:51) *
Чтобы поправили, надо бы им в поддержку отписать. А то ж они - не телепаты.

ЕМНИП раньше кто то с электроникса им отправлял.
у кого нибудь есть активная поддержка?
ig_z
QUOTE (KRS @ Oct 15 2012, 16:18) *
ЕМНИП раньше кто то с электроникса им отправлял.
у кого нибудь есть активная поддержка?

По моему на сахаре человек с ником ASDFS имеет тех поддержку для армов.
Не знаю как сейчас, но раньше иаровцы игнорили багрепорты от простых смертных. По крайней мере три моих репорта для MSP430 и ARM оставались без внимания, пока не послал их через немецкого кастомера.
Andy Mozzhevilov
Я достаточно давно ловил баг еще в какой-то 4-й версии компилятора и отправлял им, официальной поддержки не было, ессно. В следующей версии компилятора баг был поправлен, не знаю уж, по моему репорту или нет. Я email посылал не с просьбой о поддержке, а именно как bug report. В конце концов это в их интересах улучшать компилятор. Во всяком случае попробовать надо, особенно если баг хорошо локализован на небольшом участке кода.
Dog Pawlowa
Цитата(ig_z @ Oct 15 2012, 16:31) *
Не знаю как сейчас, но раньше иаровцы игнорили багрепорты от простых смертных.

Ну не знаю, года два назад я переписывался с ИАРом по поводу того, что они перестали поддерживать неименнованные unions и убрали прямой доступ внутрь union.
Я прикинулся триал юзером, правда немецким sm.gif
Ответ был простой - пшол вон, у нас ANSI компилятор, что хотим, то делаем. А я уж порезвился тогда, корректируя проект.
jcxz
Если кто отправлять будет, то напишите до кучи и про мой баг (писал о нём недавно сюда: http://electronix.ru/forum/index.php?showtopic=105402 )
Вдруг - поправят? wink.gif
А то сейчас по необходимости пользую IAR 6.21.1 (старый 5.50 который хорошо проверен на вшивость большими проектами с полной оптимизацией,
но к сожалению 5.50 не понимает через JTAG LPC1778) sad.gif(
И поэтому приходится ставить Low оптимизацию в 6.21.1.

ЗЫ: Проверил примеры из этой темы на своём IAR 6.21.1 - бага нет (ни с чётными ни с нечётными размерами циклов). Cortex-M3 High optimization (Size)


Andy Mozzhevilov
Цитата(jcxz @ Oct 19 2012, 08:59) *
Если кто отправлять будет, то напишите до кучи и про мой баг (писал о нём недавно сюда: http://electronix.ru/forum/index.php?showtopic=105402 )
Вдруг - поправят? wink.gif

Чтобы послать баг с надеждой на его исправление и не имея тех.поддержки крайне желательно его локализовать в неком очень небольшом коде, который бы собрался в составе мелкого проекта, созданного в IDE IAR, архив которого им и отсылать. В вашем же коде просто кусок из программы, который не соберется. А если начать выкидывать что-то, может и баг исчезнуть.

Цитата
А то сейчас по необходимости пользую IAR 6.21.1 (старый 5.50 который хорошо проверен на вшивость большими проектами с полной оптимизацией,
но к сожалению 5.50 не понимает через JTAG LPC1778) sad.gif(
И поэтому приходится ставить Low оптимизацию в 6.21.1.

Собирайте проект в 5.50, а отладку запускайте хоть в 6.40. Там все совместимо по форматам out файлов. Главное, чтобы сам компилятор мог делать код для нужного ядра.

Цитата
ЗЫ: Проверил примеры из этой темы на своём IAR 6.21.1 - бага нет (ни с чётными ни с нечётными размерами циклов). Cortex-M3 High optimization (Size)

на 6.30 тоже его нет.
jcxz
Цитата(Andy Mozzhevilov @ Oct 19 2012, 11:14) *
В вашем же коде просто кусок из программы, который не соберется. А если начать выкидывать что-то, может и баг исчезнуть.

Если бы Вы хотя-бы открыли ту тему прежде чем отвечать, Вы бы заметили, что я цеплял там полностью проект.
Цитата(Andy Mozzhevilov @ Oct 19 2012, 11:14) *
Собирайте проект в 5.50, а отладку запускайте хоть в 6.40. Там все совместимо по форматам out файлов. Главное, чтобы сам компилятор мог делать код для нужного ядра.

Это понятно. Но хочется работать без гемора с постоянным переключением между компиляторами.....
IgorKossak
Цитата(jcxz @ Oct 19 2012, 09:43) *
Если бы Вы хотя-бы открыли ту тему прежде чем отвечать, Вы бы заметили, что я цеплял там полностью проект.

В IAR не будут рассматривать большой проект, натыкался на это несколько раз. Они всегда просят сократить его до нескольких строк исходной программы, когда баг ещё проявляется.
jcxz
При дальнейшем уменьшении проблемной функции, баг пропадает. Даже если обрезать не связанную с багом часть функции. Как будто баг возникает когда размер кода функции превышает некий предел.
Sagittarius
Цитата(jcxz @ Oct 19 2012, 08:59) *
ЗЫ: Проверил примеры из этой темы на своём IAR 6.21.1 - бага нет (ни с чётными ни с нечётными размерами циклов). Cortex-M3 High optimization (Size)

первоначально было замечено на Speed, при Size или Balanced все работало.
KRS
Про бак IAR так и не узнал, по крайней мере в
V6.50.1.4415/W32 for ARM
он остался sm.gif
Nixon
А в новой, 6.50.2 версии он не вылечен?
KRS
Цитата(Nixon @ Dec 24 2012, 18:19) *
А в новой, 6.50.2 версии он не вылечен?

Я как раз сразу и проверил, сюда просто забыл написать
Нет не вылечен sad.gif
MK2
Еще один возможно прикол версии 6.4
Код
static class UART_CL{
....
              uint8_t start_enable;
              uint8_t ask_enable;
....
void start_ask(){
          ....
ask_enable = 1;
                  while(start_enable);
...          }    
....
void send_codram(){
....
if(ask_enable)
        start_enable = 0;  
....}
.....
}UART1;

долго бился с багом в этом коде и под отладкой заметил следующие...
переменные ask_enable, start_enable в методах send_codram() и start_ask() находятся там под разными адресами!!!!!
т.е. в методе send_codram() переменная start_enable находится по адресу 0х2000058С, а в start_ask() под адрессом 0х2000051С !!!
подобное поведение встречается и в других статических классах.
решается статическими переменными, но все равно такие фичи разочаровывают =(
Сергей Борщ
QUOTE (MK2 @ Jan 30 2013, 12:07) *
подобное поведение встречается и в других статических классах.
Что такое "статический класс"?
Намекаю дальше: в этих функциях адреса разные при вызове одной функции из одного файла, а другой функции из другого исходного файла?

QUOTE (MK2 @ Jan 30 2013, 12:07) *
но все равно такие фичи разочаровывают =(
Боюсь, в данном случае на зеркало пенять не стоит.
MK2
Цитата(Сергей Борщ @ Jan 30 2013, 13:19) *
Что такое "статический класс"?
Намекаю дальше: в этих функциях адреса разные при вызове одной функции из одного файла, а другой функции из другого исходного файла?

намек понял... 05.gif
zhz
В версии 6.50.5 баг с оптимизацией вроде бы исправили.

jcxz
Цитата(zhz @ Apr 18 2013, 05:48) *
В версии 6.50.5 баг с оптимизацией вроде бы исправили.

Вроде-бы??? какой именно?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.