LINUX.ORG.RU

extern inline в разных gcc

 , ,


0

1

читаю тут про разницу в интерпретации extern inline в gcc 4->5. Правильно ли я понимаю, что если я код с четвертой ветки на пятую переношу, то код

extern inline f() {
bla-bla-bla;
}

надо привести к виду

inline f() {
bla-bla-bla;
}
?

А то newlib с gcc-5 не очень дружит.

★★★★★

А в Debian, вроде, gcc-arm-none-eabi 5.4.1 должен был использоваться для сборки newlib 2.4.0.20160527.

gag ★★★★★
()

А зачем ты инлайновые функции в сишный файл пихаешь? На уровне оптимизации -Os (а то и -O1) они вообще не будут инлайниться!

Не проще ли их как static inline запихнуть в базовый заголовочный файл (типа stm32f0xx.h), который во все исходники включается?

anonymous
()
Ответ на: комментарий от anonymous

это не я, а авторы newlib. Например, в libgloss/sparc_leon/asm-leon/leon3.h

  extern __inline__ unsigned long sparc_leon23_get_psr (void)
  {
    unsigned int retval;
    __asm__ __volatile__ ("rd %%psr, %0\n\t":"=r" (retval):);
      return (retval);
  }
demidrol ★★★★★
() автор топика

В языке C, который славится своей суперстабильной совместимостью, когда-то не было inline в стандарте, но де-факто был. Затем inline стандартизировали, но сделали несовместимым с существующим де-факто способом использования inline. В результате, если хочешь совместимости - пиши static inline.

http://stackoverflow.com/questions/216510/extern-inline

P.S. Когда приходится с C++ на время переходить на C, волосы начинают шевелиться от таких неожиданностей, потому что C++ в этом плане гораздо стабильнее и предсказуемее (если, конечно, не нужно пользоваться старыми компиляторами от MS).

anonymous
()

Зачем вообще писать inline, если собирать с оптимизацией -O3 то эта оптимизация и так все функции inline делает.

andreykyz ★★
()
Ответ на: комментарий от andreykyz

вот обязательно найдется юродивый, которому только бы напейсать что-то. Сказано же, что код — не мой, а авторов newlib.

demidrol ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.