То така и така се отплесваме към посока оптимизации, та да те питам: Тествал ли си, при LTO дали няма да ги inline тези аритмитичени __eabi_... функции? Теоретично би трябвало да може, но на практика много ме съмнява, защото за да работи читаво трябва да е сдъвкан C код а не ръчно написан на асемблер, а предполагам точно тези библиотеки, че са си писани на асемблер.

Какво е LTO?

ако имаш предвид link time optimization.... честно казано ме съмнява да разбутва функци, не съм го виждал да го прави

Нормално при GCC ако искаш да имаш супер добро инлайнване ще ползваш static inline функция, писана в хедър... Тогава GCC заебава ABI-то, демек не е нужно да се грижи да спасява определени регистри, слага променливите както му удобно, въобще това е най-доброто...
За съжаление обаче в стандартната библитека (libc май беше) не са така декларирани и съответно отива на задължително викане.

А най-големия проблем на GCC беше (не знам новите тулчейни как са), че не всичко е портнато за АРМ. Говоря за newlib преди години, пак казвам сега не знам как е. Самият newlib позволява това. Просто ако не имплементираш дадена функция изпада до изцяло софтуерно решение. Примерно спомням си, че не бяха имплементирали 64-бит int аритметика. При което да кажем умножение тръгва да го прави само със събиране и изваждане. Изобщо не използва наличните 32*32=64 инструкции... Аз затова навремето им теглих една и айде " -nostdlib" към флаговете

баш link time optimisation

GCC го има от едно известно време насам. Общо взето оптимизиациите се правят не по време на компилация а по късно по време на линкване. Тогава се знае какво точно се ползва, какво не се ползва, съответно много код който не се изпълнява направо се маха, друг пък се инлайнва, разни променливи които не се ползват и кода около тях изчезва, регистрите се разпределят по читаво по време на сметки и т.н. и т.н.

Само една ракета падна така?

При х86 32 битовото умножение е с 64бит резултат. Който после може да се раздели на 32бит и се получава доста добре. в паскала имаше функция, която го правеше - хем бързо, хем приятно

Ако умножавам два int-a се получава пак int. Трябва да се кастне поне единият към long за да може да се получи резулт по-голям от 32767:

Интересно защо компилаторите не разбират автоматично след като result е long, че резултата трябва да е long Лошото е, че даже доста user friendly езици като C# също работят така.
А това е вярно за запетайката и точката в програмата заради която е паднала ракета

Мноого, много общо казано и с риск някой спец да се подхилне под мустак ,
заради начина по който работят процесорите, тяхното ALU има две основни линии A и B и бинарен декодер, който сетва логическата операция която да се извърши между А и Б ( AND, OR, NOT, ADD). Компилатора превръща твоя аритметичен израз в тристейт код (от три части - оператор/операнд/операнд) - остатък от времената на перфо-картите.
Оператора застава най-отгоре(или най-отдолу при ревърс полиш нотейшън(според зависи)) на стека и се фечва пръв или последен, сетвайки бинарния декодер на АЛУ-то или каквато е там друга логика за логическата операция която ще се извършва между А и Б,
След това стека се pop-ва и така се фечва първия операнд. Следва нов пулс на програм-каунтъра, ново pop-ване на стека и фечване на втория операнд към линиите Б.
Резултата се записва в резервоар (или обратно в регистъра където е била една от променливите), който резултат се подава обратно на линия А, нов пулс- на програм каунтъра, ново фечване към линията Б .... Заради това записване на резултата в един от регистрите в които е била една от изходящите ти променливи, с цел да се подаде в следващия цикъл обратно към А, имаш два вида променливи L_var, R-var . В първите можеш да записваш резултат, във втoроите не. Както и имаш асоциативитет на операторите -ляв и десен. ' * ' е с ляв асоциативитет, т.е. -ако имаш израза: result = a*b*c*d*e*f, това което се случва е: а=a*b , а=a*c, а=a*d, а=a*e, a=a*f; result = a;
Т.е. , както виждаш , в твоя случай 'а' ти се тайпкаства към ' b' или 'b' към 'a', според правилата на Ц- тоя който заема по-малко памет, към тоя който заема повече.
а при теб и двата са 'int' . След което по правилата на аритметиката в модул int a=32000 ,b=32000; a=a*b , 'a' ти овър-флоутва и почва да брои от начало.
Така. Ще ме извиниш за цялата тирада , ако вече ги знаеш тея работи и ако съм сбъркал нещо в бързината, не се знаем тука кой на каква вълна и докъде е и от това дискусията страда понякога или някой рискува да се направи на 'смарт асс' , но не е това целта.
Всичко добро.

Ако се абстрахираме от перфокартите - компилаторът вижда звездичка и трябва да назначи
оператор. Оглежда операндите и ги вижда ,че са int. Съответно вика оператор за умножение INT_INT.
Изобщо не поглежда какъв е типа на дестинацията. Така предполагам ...Всичко това няма нищо общо с началния проблем.