1, да, поскольку линкер теперь несовсем только линкер - прицепляемые плагины в состоянии из него сделать все что угодно. а поскольку плагины могут делать мало ли чего хитрого то им наверняка потребуется больше информации чем надо лиинкеру. с одной стороны это решается расширением формата ELF (читай добавление новых полей это сзади), и что важнее расширения формата объектников (читай тоже расширение DWARF, Tree SSA и тд ) это по входу, а через ключи передается тайные женания пользователя. таким образом если оптимизатор LTO не в компилере а в плагине линкера то ему тоже очень хоца знать режимоптимизации что и требует передачи ключей оптимизации таких как в компилятор были просунуты. в действительности в будующе методом расширения полей форматов объектников эту инфу можно будет вытягивать из них и передавать ключи по цепочке не будет необходимо. (я сильно не ковырялся но как мне кажется в кранем фрормате DWARF это все уже есть ибо gdb с места не сдвинеся при отладке бинаря по которому LTO оптимайзер прошелся.) както так.

2. что касается LTO: опции должны идти парой -flto -ffat-lto-objects иначе порежутся секции данных и хрен соберется - это не ошибка это фича, рассуждаю так - если вы соберете кристалл с процом cm3 без озу и без данных которые на старте нада инициализировать то можно будет ЕЩЕ сильнее окучить код. машинке без озу на одних регистрах - может иметь смысл в клинических случаях, и тогда компиллер еще и подн ее ужмет.

Как посмотреть, не включён ли этот ключ у меня по умолчанию (4.8)? Его добавление не сказалось в моём проекте, используется компилятор с launchpad.

Сообщение отредактировал Genadi Zawidowski - Apr 6 2014, 09:54

если при компиляции или ликовке к ключам присовокупить ключ -v что означает verbose то вывалится лог всех операций и полный реальный набор ключей, том то и можно посмотреть что кроме того что ВЫ напихали засовывается по умолчанию

Что-то нету ничего похожего...

у Вас компилер 4.8 у меня 4.9
разное поведение. 4.8 более правильное видимо 4.9 более интересное. если заглянуть в свн лог транка то будет видно что добрая часть мук графоманства оседает именно в оптимизвторах, это влияет на изменчивость реакции компиллера на ключики с ней связанные.
нада учитывать что lto находится в активном развитии.

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

Сообщение отредактировал Genadi Zawidowski - Apr 6 2014, 15:40

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

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

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

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

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

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

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

Сообщение отредактировал Genadi Zawidowski - Apr 7 2014, 12:15

Поборол проблему с неинлайнящейся 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

Сообщение отредактировал Genadi Zawidowski - May 5 2014, 22:32

свежак для 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