Программирование, т. 8

 

Кто-нибудь знает почему?

 

Потому

@GarbageCollector

@@Arthas

Иногда при вызове max_elem_wise крашится на "val = std::max( val, cmp );", но только если компилировать 64-битным кросс-компилятором (mingw) с линуса на винду.

 

Кто-нибудь знает почему?

а с какой ошибкой крашится-то?

 

ed: на первый взгляд всё норм и крашиться нечему

result юзает дефолтный конструктор копирования который должен скопировать содержание std::array тк он статического размера, итератор по массиву тоже должен без проблем таскаит ссылки на объекты оттуда, вообще нигде подвоха не видно, а уж тем более чтоб вылетало на std::max, если там сегфолт при попытке дереференсить ссылку val, то это было бы довольно странно

собирать с -О0 пробовали?

Изменено 21 ноября 2018 пользователем TheDeadSkin

мы сегодня рофлили

что джавка это либа для скалы под жвм 

На уровне джавы половины джаваскрипта

я сейчас ваще на груви/котлин пописываю 

там и до кложура недалеко

TheDeadSkin, 21 Ноябрь 2018 - 21:08, написал:

 

 

KotZhilkina, 21 Ноябрь 2018 - 20:18, написал:

Иногда при вызове max_elem_wise крашится на "val = std::max( val, cmp );", но только если компилировать 64-битным кросс-компилятором (mingw) с линуса на винду.

 

Кто-нибудь знает почему?

а с какой ошибкой крашится-то?

 

ed: на первый взгляд всё норм и крашиться нечему

result юзает дефолтный конструктор копирования который должен скопировать содержание std::array тк он статического размера, итератор по массиву тоже должен без проблем таскаит ссылки на объекты оттуда, вообще нигде подвоха не видно, а уж тем более чтоб вылетало на std::max, если там сегфолт при попытке дереференсить ссылку val, то это было бы довольно странно

собирать с -О0 пробовали?

 

ничего вразумтельного, офк

 

MESSAGE: SIGSEGV: Segmentation fault

STACK TRACE:

@0x5C6AE5

 

Но очень похоже, что вот эту херню словили и MinGW 64 битный ее не умеет нормально обработать:

 

Notes

 

Capturing the result of std::max by reference if one of the parameters is rvalue produces a dangling reference if that parameter is returned:

 

 

Переписали код без использования std::max и все заработало...

а что такого этот макс там делает вообще, что он такой особенный?

а что такого этот макс там делает вообще, что он такой особенный?

не умеет результат в ссылку совать нормально при использовании rvalue в параметрах - получаем висячий указатель

 

https://en.cppreference.com/w/cpp/algorithm/max

крестоблядство сраное

крестоблядство сраное

указатель

t

крестоблядство сраное

еще какое. я на эту лажу за две вечеро-ночи часов восемь считай потратил.

ничего вразумтельного, офк

 

MESSAGE: SIGSEGV: Segmentation fault

SIGSEGV это довольно вразумительно если что

это уже как минимум говорит о том какого рода ошибка - память

 

Capturing the result of std::max by reference if one of the parameters is rvalue produces a dangling reference if that parameter is returned:

 

 

Переписали код без использования std::max и все заработало...

странно что ты ловишь эту хуйню

такое поведение довольно закономерно. если std::max возвращает rvalue то значит ловить его ссылкой это трешак, ты пишешь значение в ссылку, ловить ссылкой можно только lvalue

 

но загвоздка в том что тут ты не ловишь результат в ссылку, она уже инициализирована, ссылки неизменяемы поэтому писать после после инициализации её дереференсит

 

у тебя бинди ссылки происходит _до_ той операции и пишешь результат в неё, то проблем не должно быть

потому что

for (float &hui : pizda) hui = x;
           ^^^^ bind         ^^^ write

тоесть ты пишешь значение напрямую в память, а не ловишь что-то в ссылку

похоже чисто на то что компилятор говна пожрал и пытался сделать какой-то hui = *(std::max(...)) что очевидно должно засегфолтить

какой компилятор юзал?

 

        for( float &val : myresult.values ) {
            val = std::max( val, cmp );
        }

И

        for( float &val : myresult.values ) {
            float *valPtr = &val;
            *valPtr = std::max( *valPtr, cmp );
        }

собраные cygwin64/g++ напрямую под виндой производит одинаковый asm, поэтому оно 100% рабочее как надо
Изменено 22 ноября 2018 пользователем TheDeadSkin

64-битные clang на linux, msvc++ (v15 tools, 2017) на винде, gcc под MSYS на винде и i686-w64-mingw32.static на linux - std:max не вызывало креша

 

кросс x86_64-w64-mingw32.static - вызывало

так что я почти уверен, что баг именно в компиляторе - слишком он умный сука

да он небось увидел там массив всего на 4 элемента

жахнул какую-нибудь SSE команду типа умный

и получил по ебалу 

SSE вряд ли причина проблемы потому что один хуй он изменит структуру данных и будет копировать элементы, да и вроде векторизация не делается если не поставить флаг компилятору, даже если стоит -O3

тут скорее выглядит как неправильный inference типов из-за того что один из аргументов std::max это lvalue из-за того что val это float& и он какого-то хуя решил что результат это тоже всегда float&, а не ссылка/значение зависимо от того кто больше и если max выигрывался аргументом cmp то он пытался перейти по указателю с бинарным паттерном cmp, что очевидно сегфолт

всё хуйня, давай по новой. до меня ток что дошло что там оба аргумента это lvalue, cmp находится в переменной, а значит в T& max(T& a, T& b) он всё-равно передаст ссылку на cmp и всегда получит валидную ссылку

 

но это было бы странно потому что судя по всему компилятор всё-равно gcc, а значит фронтенд/бекенд компиляции делается им и ему поебать какой таргет

 

мне аж интересно что будет при -O0 если он не пытается выёбываться и ещё какая версия с++, т.к. с 14ой сига std::max всегда содержит contexpr

Изменено 22 ноября 2018 пользователем TheDeadSkin

C++11, оптимизация -O3, точную версию gcc на билд машине не знаю, а у себя локально в докере apt-get install -y mxe-i686-w64-mingw32.static-gcc делал и вывод /usr/lib/mxe/usr/bin/x86_64-w64-mingw32.static-gcc -v вот такой:

 

COLLECT_GCC=/usr/lib/mxe/usr/bin/x86_64-w64-mingw32.static-gcc

COLLECT_LTO_WRAPPER=/usr/lib/mxe/usr/libexec/gcc/x86_64-w64-mingw32.static/5.4.0/lto-wrapper

Target: x86_64-w64-mingw32.static

Configured with: /usr/lib/mxe/tmp-gcc-x86_64-w64-mingw32.static/gcc-5.4.0/configure --target=x86_64-w64-mingw32.static --build=x86_64-unknown-linux-gnu

--prefix=/usr/lib/mxe/usr --libdir=/usr/lib/mxe/usr/lib --enable-languages=c,c++,objc,fortran --enable-version-specific-runtime-libs --with-gcc --with-gnu-ld

--with-gnu-as --disable-nls --disable-shared --disable-multilib --without-x --disable-win32-registry --enable-threads=win32 --enable-libgomp

--with-gmp=/usr/lib/mxe/usr/x86_64-unknown-linux-gnu --with-isl=/usr/lib/mxe/usr/x86_64-unknown-linux-gnu --with-mpc=/usr/lib/mxe/usr/x86_64-unknown-linux-gnu

--with-mpfr=/usr/lib/mxe/usr/x86_64-unknown-linux-gnu --with-as=/usr/lib/mxe/usr/bin/x86_64-w64-mingw32.static-as

--with-ld=/usr/lib/mxe/usr/bin/x86_64-w64-mingw32.static-ld --with-nm=/usr/lib/mxe/usr/bin/x86_64-w64-mingw32.static-nm

Thread model: win32

gcc version 5.4.0 (GCC)

 

с -O0 к сожалению не пробовал - очень мне не хочется по makefile лазить (

 

Кстати, сейчас вспомнил, что мы недавно уже отключали оптимизацию (-O0 вместо -Os/-O3) для кросс-компиляции под MacOS из-за другой херни какой-то.

 

В общем все эти кросс-компиляторы капризные очень.

Ребзи, киньте плез легкую в использовании и функциональную либу для драг энд дропа на jQuery.