Спасибо. Не знаете, кто-нибудь под AVR8 собирал 4.9? Или Вы - можете под windows собрать?

-Os сильно помогло. Но всё равно результат на 43к больше чем без lto (это без thumb).

Незнаю как отключить thumb-interwork. Если убрать опцию -mthumb-interwork, то начинает ругаться о недопустимости некоторых команд в thumb режиме. И это в файле который компилируется в arm (в нём обработчик прерывания).

FreeRTOS для сборки требует define THUMB_INTERWORK, без него компилятор ругается на асмовые макросы, а может и на асм вставки.

можно попробывать

Проверил на своём проекте.

-mthumb-interwork не влияет на размер кода, а вот добавление -mlong-calls повлияло:

Странно, с чего data увеличилась? Я думал, адреса попадут в .rodata
Утилита size от AVR8.

Поборол проблему с неинлайнящейся sqrtf():
помогло добавление подчеркнутого.

MCU = cortex-m4
MCFLAGS = -mcpu=$(MCU) -mthumb -mfpu=fpv4-sp-d16 -mfloat-abi=hard -fno-math-errno

Найдено тут https://answers.launchpad.net/gcc-arm-embed...question/211248

свежак для arm
хост x68_64-linux
http://klen.org//Files/DevTools/linux-x86_...0_9MAY.tar.lzma

хост x86_64-mingw
http://klen.org/Files/DevTools/x86_64-kgp-...0140512_9MAY.7z

ветка 4.10.0
libgcc,libctdc++,newlib т.е. все таргет лиьы собраны с ключикаи -g0 -Ofast -fomit-frame-pointer -funroll-loops -ffunction-sections -fdata-sections -fgraphite -flto=8 -ffat-lto-objects

сборку для масдая нада тестить. для линуха - мои текщие проекты пересобраны и в железе работают
те кто юзает C++ настоятельно рекомендубю пользоватся плюшками с++11 - полезно и питательно.

для людского юзания STL необходимо подсунуть свои заглушки хендлеры чтоб STL не пыталась генерить эксепшены. если будет народу интересно напишу микростатейку и запощу отельную тему по юзанию STL.

Спасибо, потестируем

Очень интересно!

Работает на немаленьком проекте с фильтрами с использованием floating point и integer операциями. Оптимизация работает.

очередной свежак для мелко-армов под хост линукс64 но не совсем свежак ибо релиз
релизная сборка тулсов с компиллером версии GCC 4.9.1 released [2014-07-16]
обычно я собираю свежак из транка но сегодня это релизная сборка - добрые люди попросили собрать, собрал проверил выкладываю. сборку назвал именем HEDERA.
http://klen.org/Files/DevTools/linux-x86_6...HEDERA.tar.lzma

очередной обычный свежак для армиков
версия 4.10.0
если выше описана сборка релизного состояния компиллера то это как обыно самое свежее сегодняшнее, что интересно -
1. четвертая версия LTO формата - это должно приводить к лучшей упаковке кода при оптимизации
2. реализован стандарт с++14 - много интересных фич позволяющих настоящим С++ задротам писать фиерически красивый и правильный код - котрый хорошо сопровождать. характерный вид такого програмиста http://lurkmore.to/%D0%A4%D0%B0%D0%B9%D0%BB:Nerd-46422.jpg. я и Вы приемущественно инженеры которые пишем в силу необходимости на c/с++ для эмбеддед и поэтому нам практически недоступны глубыны таких глубин... те кто думает что это неприменимо на stm32 - недогоняет. объем флеша растет вместе сос скоростью - проекты решаемые на контроллерах становится архитектурно сложнее и сложнее, поэтому надо писать ПРОВИЛЬНО а не так как умею.
http://klen.org/Files/DevTools/linux-x86_6...40813_HEDERA.7z

также прикладываю дистр компиллера которым был собран свежак для армов - свжак для носта linux-x86_64.
http://klen.org/Files/DevTools/linux-x86_6...EDERA.tar.lzma
эта сборка может пригодится если Вы захотите собрать чтото по линухом64 а штатный установленный в системе компиллер слишком старой версии для проверки новых языковых фич или дает редкий глюк.
плюшки которые могут заинтересовать - поддержка с++14 и поддержка Intel® Cilk™ Plus ( libcilkrts )
собрано статически, должно сразу заработать при прописывании пути к bin в пити пользователя. если система не ubuntu подобная то возможно потребуется поправить пути к системным либам и хидерам в файле спеков компиллера (если чето не будет работать - раскурим, заодно напишу доку - давно пора начать чтото такое сделать для сопровождения моих сборок)

для упорядочивания названий сборок придумал такую систему - имя файла архива пакета будет формироватся так:
TARGET_@_HOST_REVISION_BUILDNAME.7z
где TARGET - таргет в который генерим код, например arm-kgp-eabi
HOST_REVISION - хост, тоекть платформа на которой работает пакет. например x86_64-kgp-linux-gnu или x86_64-kgp-mingw32
REVISION - ревизия исходников из коротых собран пакет, если это релиз компиллера то она равна названию релиза например R4.9.1 или если свежак из транка то просто дата текщей ревизии например 20140813.
BUILDNAME - имя сборки - любое название удобное слово возможно нессущее какую нибудь смысловую нагрузку

Ангара полетела!!!! - все в космосмос!!
поздравляю всех кто имел отношение к этому - а имели многие, некоторые даже не подозревая.... слава жителям села что кормят нас инженеров ржаным и пшеничным хлебом.
за лето проехал по порядка 5 килокилометров но нашей необятной - на югах все земли распаханы и засеяны, в направлении Пскова и севера - появились редкие стада коров!!

Ангара полетела - теперь все полетит.

ну что ж... начинаем жить в ветке GCC 5.X.X
транк репозитория gcc теперь предлагает 5.0.0 как основную ветку.

собрал, проверил - перепрошил свой самодельный спектроанализатор в котором много вычислений - работет(девайс). LTO не падает, зачОт!

http://klen.org/Files/DevTools/linux-x86_6...817_ALBURNUS.7z

А под винды 64 (или 32) пятерочку? Устройство с DSP функциями и возможностью оценить прирост производительности есть.

Присоединяюсь к просьбе. Предстоит работать с цифровым микрофоном - по-dsp-эшничать тоже придется.

разумеется буду делать. Русские своих не бросают. И не русских тоже... и нерусские наверо тоже..

все ближайщие и работа над ошибками в сборках будут носить имя людей которые нас вывели в космос, которые достигли результатов в автоматике , системах радиуправления, ситемах тракекторного управления, динамики твердых тел с измением массы и тд. одним словом фамилий людей жизнь и опыт которых дает силы и надежды несмотря а всЁ блядство боротся надеятся и тварить
http://video.yandex.ru/users/mediamaster-studio-ru/view/1/

имена сборок будут иметь имена совета главных конструкторов

Лишь бы эти конструкторы не сконструировали какую-нибудь овночастицу бога №Х с обязательством называть её папой фундаментальной

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

свежак таргет arm-kgp-eabi хост x86_64-linux-gnu
http://electronix.ru/redirect.php?http://k...KB_SPETZMASH.7z

под масдай чето нехочет с ходу собиратся, но я буду повторять попытки.

а я под масдай и в масдае (в mingw) так и не смог собрать gcc 4.8 и новей.
4.7 собиралось нормально

можно но пинать нада...

в результате заявки от товарища по имени vlad собран пакет для мотороловского таргера m68k.
где это применяется? в керосиновых примусах?

URL:
http://electronix.ru/redirect.php?http://k...inux-gnu.tar.7z

binutils-trunk
gcc release 4.9.1
newlib-trunk

че получилось я не знаю, неначем проверить. надеюсь vlad проверит и сообщит всем полетела ракета или нет.

свежак для армиков, хост linux64

www.klen.org/Files/DevTools/linux-x86_64/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20141006_VALENTIN_GLUSHKO_OKB_456.7z

Добрый вечер, форумчане!)
Прошу извинить если мой вопрос поднимался ранее и направить на нужную страничку)
Кто-нибудь работал с нашим микропроцессором 5890ВЕ1Т ? Есть ли под него рабочие отладочные платы и более-менее рабочий компилятор?
А то пока кроме офиц документации от НИИСИ РАН ничего нет (лаборатория, которая этим занималась, закрылась).

Кстати, насчёт комдива интересный вопрос, присоединяюсь! комдив-32 и комдив-64 новые процы сейчас в ОКР находятся. Если бы получилось их привязать к GCC, я бы к ним стал пристальнее приглядываться...

У меня что-то не взлетают последние свежаки.
Компиляция падает с "internal compiler error: Недопустимая инструкция".
Пробовал
20140813_HEDERA
20140817_ALBURNUS
20140902_VLADIMIR_BARMIN_GSKB_SPETZMASH
20141006_VALENTIN_GLUSHKO_OKB
Компиляю c++ код под STM32F4.
Падает на невинной строке
someVar = 12.79;
Если заменить значение на 0.0, то начинает падать где-то в глубине стандартных инклюдов.
Ключи компиляции:


Пробовал менять O2 на O3 - не помогло.
-mfloat-abi=soft - тоже не сработало.

Дык, я еще в посте №937 жаловался.
Причем, удаленный доступ к системе, на которой это воспроизводится, давал...

Если у меня не взлетает очередной свежак, я к этом отношусь спокойно: понятно, что в силу своей свежести он подвержен глюкам. Обычно в следующей версии глюк исправляют.
Но тут, похоже, какая-то уже системная ошибка, раз она есть столько сборок подряд.
Причём, судя по тому, что у вас на одной машине ошибка есть, а на другой - нет, ошибка не в самом компиляторе, а именно в сборке. Хотя не представляю, как может статически слинкованная сборка работать по-разному на разных машинах...

будем разбиратся.
несколько дней ваше несобиралось из транка, но щас много накомитили, надо посмотреть где кто и кого.
усушка утряска и пересортица в ветке 5.0.0
я кстате если заметили не меняю изза этого название сборки.
скоро выложу как соберу и потестю.

под масдай чето последнее время транк вообще не собирается перманентно , видимо масдай по остаточному принципу. в коде видно явные недаделки , в данный момент функционал gcov не может собратся на венде.

а так все ходошо прекрасная маркиза.

klen, поскольку вы следите за новыми веяниям, можете описать в двух словах - что там такого радикального добавили/изменили, что пришлось менять старшую цифру версии?

...после долгих мытарств красноармейцы завели бронепоезд с толкача...

свежак для мелкоармов, ност x86_64-linux-gnu
www.klen.org/Files/DevTools/linux-x86_64/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20141128_NIKOLAY_LIDORENKO_NPO_KVANT.7z
таргет либы компиллера и newlib собраны с ключиками
-Ofast -fomit-frame-pointer -funroll-loops -ffunction-sections -fdata-sections -fgraphite -flto=8 -ffat-lto-objects
в newlib пропихнуто --enable-interwork --enable-multilib --disable-newlib-atexit-alloc --enable-newlib-multithread --disable-newlib-supplied-syscalls --enable-newlib-mb --disable-werror --enable-newlib-reent-small -DPREFER_SIZE_OVER_SPEED -DSMALL_MEMORY

тоже самое
www.klen.org/Files/DevTools/arm-kgp-eabi_@_x86_64-kgp-linux-gnu_20141127_VALENTIN_GLUSHKO_OKB_456.7z
либы собраны без LTO
для newlib отсутствует --enable-newlib-reent-small

основная тема сборок - они должны генерить рабочий код для работы под FreeRTOS или другой ОС, поэтому все должно поддержиывать реентрантность(будь она неладна)

для графоманов в стиле main() {...all...} по идее надо собрать без реентрантной байды в newlib.. да?

сборки тестилися на рабочем проекткте содержащем
FreeRTOS
TLSF
LUA-5.3b
USB CDC интерфейс
моя пользовательская шняга выполняющая матрично-векторные флотовые расчеты на FPU, гребенка фильтров Герцеля и тд.

Все накрывается LTO и не падает при линковке.
Есть особенности....

Подскажите сборка arm-none-eabi-gcc должна нормально компилить примеры с FreeRTOS и Ip стеками? или надо сразу на Klen сборки переходить?
Пробовал примеры uip и lwip падают в hardfault. Скомпилил с помощью gcc-kgp-eabi тестовый пример TE-STM32F107_uIP_demo - работает.

Переход на сборку от Klen-а потребует переустановки системы, чего хотелось бы избежать.

Конечно должна.
Её тестируют чуть-ли не на сотне проектах прежде чем сделать релиз...
Да, вы же понимаете, что компилятору пофиг, что за проект он собирает.

Я понимаю, что компилятору пофиг, но вот не работает и все тут. arm-none-eabi-gcc обновил до 4.9, не работает.
На диске с TE-STM32F107 шел gcc-kgp-eabi он скомпилил рабочую прошивку, но версия была виндовая.
Скачал августовский релиз gcc-kgp-eabi под линь (пришлось на отдельный винт поставить 64бит версию, я пока на 32битной xubunt-e сижу) этот тоже компиляет рабочую прошивку. Вывод: дело в компиляторе или ключик какой надо указать arm-none-eabi-gcc.

Нет. Неправильный вывод. Дело в проекте. Уверен практически на 100%.
Где-то может быть обращение происходит по не выровненным адресам или
в скрипте линкера, или в стартапе неладно и т.п. и .т.д.
Чтобы понять причину надо отлаживать проект.
Для начала написать обработчик хард фодлта или поставить в нём точку останова, посмотреть map-файл.
ИМХО только так.

Да ставил я обработчик, только поди найди в чужом проекте почему оно вылетает. Дело в том что другой проект с lwip и FreeRTOS, ведет себя точно также. gcc-kgp-eabi я его не компилил, для этого мне надо систему переустанавливать.
ИМХО если ошибка в проекте, так от компилятора зависеть не должно. Просто gcc-kgp-eabi заточен под операционку, а arm-none-eabi-gcc нет. Написано же выше

основная тема сборок - они должны генерить рабочий код для работы под FreeRTOS

??? Если не секрет, почему?

Система 32бит, а сборки 64бит. Переход я сделаю после нового года, не нравится мне как система после обновления с 10.04 до 14.04 стала работать. Сейчас не могу себе позволить пару дней на переустановку.

Что, правда? "Откуда инфа?"

Отсюда.

вот в том что сбока Klen-a генерит рабочий код я убедился, также и то что тот же проект не работает сгенерированный arm-none-eabi-gcc.

Хм. Ну пусть будет по-вашему, пусть виновата сборка. Хотя я уже много лет использую arm-none-eabi-gcc для проектов с ОС (scmRTOS) и без ОС и все работает.

Так и я использовал ее пока на эти грабли не наступил. До этого ОС не пользовался. Думаю дело в каком-нибудь ключике. В gcc-kgp-eabi по умолчанию этот ключ, а в arm-none-eabi-gcc надо руками указать.

А что мешает эти ключики сравнить?

Где их посмотреть? В каталоге с проектом просто запускается make. Ключи в makefile соответственно одинаковые. Я же проект под компилятор не меняю.

Я не специалист, но посоветовал бы начать с "xxx-gcc.exe -v"

Написано ж віше, что єто к тому, каким образом собран Newlib, а не компилятор.
используете ньюлиб?
--

Как определить использует проект newlib или нет?

Грубо: если в проекте используется конструкция типато используется.

Есть такие конструкции. Получается, собранный по другому newlib, приводит к неработоспособности проекта?
С чего начали к тому и пришли, дело в сборке arm-none-eabi-gcc.

"Тут все едут по встречной". Подалуй, да. Пусть дело будет в сборке arm-none-eabi-gcc.

выкладываю перекомпиленный мной вариант доки по встраиваемому асму (gcc inline asm)
вещ полезная - рекомендую всем заинтересованным ознакомится и применять.
по плану перевести статейку, добить недостающими ништяками ништяками, как сделаю выложу, щас переоформленный оригинал.

свежак arm для linux64

http://www.klen.org/Files/DevTools/linux-x...UGIN_NII_855.7z
~85МБ

klen, а возможно ли собрать newlib для mips без привязки к какой-либо операционке. по сути необходима только libm. но она тянет еще и libc за собой. в итоге, в проекте прерывания работают не так как ожидается, точнее не работают если используется libm. если возможно убрать вообще все аппаратные привязки из libc тоже было бы хорошо. спасибо.
не обязательно делать, если возможно то расскажите как, или что читать чтобы не особо грамотный товарищ понял.