Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Общие вопросы > Сборки MinGW (GCC-win32/win64)

Автор: boostcoder 30.7.2011, 20:09

с этого момента, буду производить тестовые/пререлизные/релизные сборки mingw.
файлы с пометкой snapshot и prerelease - не стабильные версии. в реальных проектах использовать не рекомендую. использую для тестирования новых фитчей.
файлы с пометкой release - стабильные, прошедшие тесты.
скачать можно http://code.google.com/p/mingw-builds/downloads/list.

в скором времени начну формировать пакеты для разработчиков состоящие из компилятора(mingw), IDE(http://qt.nokia.com/products/developer-tools//http://www.codeblocks.org//http://www.bloodshed.net/devcpp.html/http://wxdsgn.sourceforge.net/), и некоторого набора предкомпилированных библиотек(http://www.boost.org/, http://www.wxwidgets.org/, http://qt.nokia.com/, http://www.openssl.org/, и еще каких-то.. понять бы что в спросе...). пакеты не будут требовать установки/настройки. распаковал - используй.

Автор: Sahab 30.7.2011, 20:26

boostcoder, кул...
ато в инете только офф.сборки да tdm, ито - 4.5.2

Автор: boostcoder 31.7.2011, 07:29

моя первая сборка стабильной версии gcc-4.6.1 для windows(т.е. MinGW) с полной поддержкой http://en.wikipedia.org/wiki/Link-time_optimization, http://en.wikipedia.org/wiki/OpenMP, http://gcc.gnu.org/wiki/Graphite, http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.4/a01022.html и http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.4/a01000.html.

скачать можно http://code.google.com/p/mingw-builds/downloads/detail?name=mingw32-gcc-4.6.1-release-lto_fixed%2Bfor_nanosleep_patched.7z&can=2&q=. бесплатно! smile

при использовании классов из http://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-html-USERS-4.4/a01000.html, добавляйте опцию "-lpthread". в будущих сборках исправлю.

Автор: kemiisto 31.7.2011, 08:07

Цитата(Sahab @ 30.7.2011, 19:26

)

ато в инете только офф.сборки да tdm, ито - 4.5.2

Неа. Есть ещё http://www.equation.com/servlet/equation.cmd?fa=fortran. Там и 4.6 и 4.7 есть.

boostcoder, а ты можешь запилить поддержку LTO (Link-Time Optimization)?

Автор: boostcoder 31.7.2011, 08:20

Цитата(kemiisto @ 31.7.2011, 08:07

)

Есть ещё сборки от Equation Solution.

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

Цитата(kemiisto @ 31.7.2011, 08:07

)

можешь запилить поддержку LTO (Link-Time Optimization)?

в смысле "запилить" ? в этих сборках она есть. по твоему блогу проверял: http://kemiisto.blogspot.com/2010/09/lto.html

Автор: kemiisto 31.7.2011, 08:27

Цитата(boostcoder @ 31.7.2011, 07:20

)

в этих сборках она есть.

boostcoder, извини, не посмотрел.

Автор: boostcoder 31.7.2011, 08:41

эм.. обнаружил такую неудобность...

если собирать коды из блога kemiisto с отключенным LTO, то линкер ругается на unresolved externals на pthread`ы.
если LTO включить - все ок.

получется что с отключенным LTO ничего не собрать.
ушел разбираться. сорри smile

Добавлено через 3 минуты и 27 секунд
OpenMP линкуется как надо.

и этот код тоже:

Код



#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>

static const int cnt = 1024;

int main() {
   std::mutex mutex;
   {
      std::condition_variable cond;
      std::unique_lock<std::mutex> l(mutex);
      std::cout << "before std::condition_variable::wait_for()" << std::endl;
      cond.wait_for(l, std::chrono::milliseconds(1000));
      std::cout << "after std::condition_variable::wait_for()" << std::endl;
   }
   
   std::thread t1(
      [&mutex]() {
         for ( int idx = 0; idx < cnt; ++idx ) {
            std::this_thread::sleep_for(std::chrono::milliseconds(100));
            std::unique_lock<std::mutex> locker(mutex);
            std::cout << "id: " << std::this_thread::get_id() << ": Hello from thread!" << std::endl;
         }
      }
   );
   std::thread t2(
      [&mutex]() {
         for ( int idx = 0; idx < cnt; ++idx ) {
            std::unique_lock<std::mutex> locker(mutex);
            std::cout << "id: " << std::this_thread::get_id() << ": Hello from thread!" << std::endl;
         }
      }
   );
   std::thread t3(
      [&mutex]() {
         for ( int idx = 0; idx < cnt; ++idx ) {
            std::unique_lock<std::mutex> locker(mutex);
            std::cout << "id: " << std::this_thread::get_id() << ": Hello from thread!" << std::endl;
         }
      }
   );
   t1.join();
   t2.join();
   t3.join();
}

странно... что-то я с ключами configure намутил smile

Добавлено через 8 минут и 5 секунд
если отключить LTO и при этом добавить "-lpthread" - все равно линкер ругается. какие-то взаимоисключающие опции ведать указал..

Автор: boostcoder 31.7.2011, 09:06

Цитата(boostcoder @ 31.7.2011, 08:41

)

если собирать коды из блога kemiisto с отключенным LTO, то линкер ругается на unresolved externals на pthread`ы.

и -

Цитата(boostcoder @ 31.7.2011, 08:41

)

OpenMP линкуется как надо.

и этот код тоже:

что-то не сходится...

Автор: boostcoder 31.7.2011, 09:53

kemiisto, кстати. в сборках присутствует только g++. а ты, насколько мне известно, еще и фортран юзаешь.. в принципе он собирается с полпинка, так что могу включить. вообще не включал остальные ЯП чтоб архивы сильно не росли. там только жава 150Мб занимает не в сжатом виде..

Автор: boostcoder 31.7.2011, 17:09

исправил.
качать http://code.google.com/p/mingw-builds/downloads/detail?name=mingw32-gcc-4.6.1-release-lto_fixed%2Bfor_nanosleep_patched.7z&can=2&q=.

Автор: boostcoder 31.7.2011, 22:36

скажите, кто-то тестил последнюю сборку?
я хочу сообществу GNU-gcc предложить применить мой патч в основную ветку, для корректной сборки MinGW с поддержкой всех перечисленных фитчей.

буду благодарен если кто-то попробует собрать и потестить свои реальные проекты.
спасибо.

Автор: boostcoder 6.8.2011, 21:04

залил новую сборку: http://code.google.com/p/mingw-builds/downloads/detail?name=mingw32-gcc-4.7.0-snapshot-20110805.7z&can=2&q=

пофиксил:
1. Исправлена необходимость указывать "-lpthread" при линковке с использованием std::threads классов.
2. Исправлена ошибка линковки при использовании std::async.
3. Использована возможность указать способ линковки стандартных библиотек. По умолчанию, линкуются shared-версии. При указании линкеру флага "-static" - используются статические библиотеки.

Автор: Garese 12.8.2011, 23:01

Что то http://code.google.com/p/mingw-builds/downloads/detail?name=mingw32-gcc-4.6.1-release-lto_fixed%2Bfor_nanosleep_patched.7z&can=2&q= откомпилированные файлы минимум 4 Мб получаются.

Автор: boostcoder 13.8.2011, 02:20

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

Автор: Garese 13.8.2011, 11:04

Код


#include <iostream>
using namespace std;
 
int main()
{
     cout<<"HELLO, WORLD!!!"<<endl;
     return 0;
}

g++ -c hello.cpp
g++ -o hello hello.o

На выходе файл 3.94Mb.

Если компилить официальной сборкой 4.5.2 или вашей gcc-4.7.0-snapshot-20110805, то все нормально.

А вообще, большое спасибо за сборку.

Автор: boostcoder 13.8.2011, 11:15

Garese, линкеру, опцию "-s" добавьте же.

Автор: Garese 13.8.2011, 11:28

Добавил, все равно великоват 600Kb.

Он по умолчанию -static подставляет походу, как это отключить?

Автор: boostcoder 13.8.2011, 12:30

да.
4.6.1-release-lto_fixed+patched_for_nanosleep собран так, что использует только статическую линковку.
постараюсь пересобрать так чтоб была возможность указывать способ линковки.

Автор: boostcoder 16.8.2011, 12:00

залил новую сборку: http://code.google.com/p/mingw-builds/downloads/detail?name=mingw32-gcc-4.7.0-snapshot-20110815.7z.

Исправлен баг вызывающий "зацикливание" при использовании omp_set_num_threads().
При использовании классов из std::thread`s части, необходимо добавлять линкеру флаг "-static". Иначе получим исключение. Разбираюсь...

Добавлено Добавлено @ 11:55
В планах:
1. перейти на использование pthreads-w32, вместо используемой сейчас winpthreads.
2. разобраться со сложностями сборки версий 4.6.1-4.6.2 возникшими в следствии изменения конфигурационных скриптов в офф. репозитарии.

Автор: boostcoder 28.8.2011, 16:30

долгожданный релиз 4.6.1: http://code.google.com/p/mingw-builds/downloads/detail?name=mingw32-gcc-4.6.1-release-20110828.7z
пора готовиться к релизу 4.6.2 smile

Автор: boostcoder 30.8.2011, 15:58

пересобрал релиз 4.6.1: http://code.google.com/p/mingw-builds/downloads/list
исправлен последний известный баг("При использовании классов из std::thread`s части, необходимо добавлять линкеру флаг "-static". Иначе получим исключение.") путем сборки компилятора без использования динамических библиотек.

с этого момента, сборка версии 4.6.1 считается стабильной и завершенной.
с этого момента, по просьбам пользователей, буду заливать сборки в виде .7z и .zip архивов.

в архив добавлены следующие компоненты:
1. GNU make-3.82
2. libpython-2.7
3. GNU gdb-7.3a

Добавлено @ 16:06
нарвался на такую новость: http://software.intel.com/en-us/articles/intel-cilk-plus/
не понял, с версии 4.7.0, Cilk™ Plus будет входить в состав GCC по дефолту, как OpenMP, или как?... но технология невероятно востребована!

такими темпами, gcc вберет в себя все лучшее.

Автор: boostcoder 10.9.2011, 00:15

добавил новые сборки версии 4.7.0 содержащие ЯП: C, C++, Objective-C, Objective-C++, fortran: http://code.google.com/p/mingw-builds/downloads/list
планирую разобраться с проблемами сборки Java, и далее выкладывать сборки включающие в себя C, C++, Objective-C, Objective-C++, Fortran, Java.

Автор: boostcoder 17.9.2011, 22:18

добавил новые snapshot сборки.
отныне, все сборки будут включать в себя следующие ЯП: c, c++, objc, obj-c++, fortran.

в планах - разобраться со сборкой java.

Автор: kemiisto 17.9.2011, 22:28

boostcoder, я правильно понимаю, что там нет 64-битных сборок?

Автор: boostcoder 17.9.2011, 22:29

kemiisto, да. но будут. сейчас это приоритетная задача.

Добавлено @ 22:41
вообще, в планах, создать инсталлятор, в котором юзер сможет выбрать:
1. способ реализации исключений(sjlj/dwarf)
2. версию компилятора.
3. x86/x86_64 как цель, так и хост архитектуры.
4. список необходимых ему предкомпилированных библиотек. (да. юзеру не нужно будет шарахаться по инету в поисках собранной библиотеки, или маять свой моцг в попытках собрать ее)
5. IDE. планирую следующие: QtCreator, NetBeans, Code::Blocks, Dev-C++, wxDev-C++. т.е. получится своего рода portable версия среды разработки со всем перечисленным.

по этому, проект переезжает на sf.net, ибо там нет ограничения на пространство для проекта, плюс, больше возможностей по управлению проектом(в отличии от гуглкода).
сейчас занимаюсь следующими задачами:
1. переписываю скрипты системы сборки.
2. пытаюсь разобраться со сборкой java.
3. пытаюсь разобраться со сборкой под x86 и x86_64 архитектуры. как для хоста, так и для цели.
4. дописываю скрипты для сборки библиотек.
5. разбираюсь с NSIS инсталлятором.

Автор: kemiisto 17.9.2011, 22:44

boostcoder, понял. Интересно будет взглянуть.

А сложно под вынду собирать? MSYS, конечно, как минимум, нужен...

Автор: boostcoder 17.9.2011, 22:54

Цитата(kemiisto @ 17.9.2011, 22:44

)

А сложно под вынду собирать?

теперь нет. но по началу, когда я только задался этой целью, у меня ушло около месяца на попытки... нет, я не каждый день и не целый день этим занимался. но в сумме, все равно очень много времени ушло на эти попытки. и это я пробовал собрать в венде, на виртуалке. и, из-за того что в венде приходилось ждать по 8 часов чтоб увидеть очередную ошибку, я решил попробовать собирать в лине, кросскомпилятором. и да, помогло. в лине, все это дело собиралось в двое быстрее. в общем я однажды все таки собрал свой первый мингв. но без OpenMP+Graphite+LTO+std_threads. но кому он такой был нужен? в инете полно подобных сборок smile

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

так что, в сумме, я бы сказал, месяца четыре попыток...
и да, без MSYS никуда.

Автор: Sahab 19.9.2011, 22:35

А кто какими цветовыми стилями пользуется?...
в QtCreator юзаю такое:
http://s2.ipicture.ru/uploads/20110919/vjEVC21S.png

з.ы. кто-нить знает где можно для KDevelop/Kate найти?

Автор: borisbn 20.9.2011, 06:20

Sahab, вот это щаз в тему было (про раскраску критера). Да? smile

Автор: Sahab 20.9.2011, 08:53

"Компиляторы и IDE(!) для C++"
какбэ понимаю, что не совсем то. Но к иде же)

Автор: newbee 20.9.2011, 08:59

Sahab, kate: Settings -> Configure Kate -> Editor Component -> Fonts & Colors.

Автор: Sahab 20.9.2011, 09:06

имелось в виду не самостоятельно набивать а готовые...
где их найти в файловой и в настройках и сам знаю.

Автор: newbee 20.9.2011, 12:58

Цитата(Sahab @ 20.9.2011, 10:06

)

имелось в виду не самостоятельно набивать а готовые...
где их найти в файловой и в настройках и сам знаю.

Настроить цвета по готовому шаблону - дело пяти минут. Боюсь такому ленивцу предлагать гуглить, но все же: "kate color scheme", в т.ч. несколько есть на kde-look.

Автор: Sahab 20.9.2011, 14:36

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

Цитата(newbee @ 20.9.2011, 12:58

)

kde-look.

бывал не только тут.

з.ы. не скажу что в гугле нет... но толкового совсем мало.

Автор: boostcoder 26.9.2011, 11:54

залил пререлиз сборки версии 4.6.2. собственно, эта сборка является подготовительной к релизу 4.6.2, ибо сборка этой ветки осложнена правкой кучи конфигов т.к. патчи в эту ветку не принимаются.
релиз ожидается к концу этой недели. конечный список багфиксов так же пока не сформирован. какие-либо нововведения(в сравнении 4.6.1) вряд ли будут добавлены. зато исправлено больше ошибок. к тому же, мне известно только одно существенное отличие от версий 4.7.0 - в последнем, OpenMP-3.1 которая предоставляет task-based параллелизм. что, конечно, добавит еще больше возможностей применять OpenMP.

всем спасибо.

http://code.google.com/p/mingw-builds/downloads/list

Автор: boostcoder 4.10.2011, 10:15

в списке рассылки GCC прошла информация о том, что изменилась лицензия компилятора языка D. и сейчас, она позволяет использовать его коды под лицензиями GPL/LGPL. сейчас идет обсуждение о принятии в GCC фронтэнда D на постоянную основу.
я на D не пишу, но возможно кому-то эта новость покажется полезной. мне же, интересно, соберется ли фронтэнд в венде smile

Автор: boostcoder 5.10.2011, 18:04

в течении прошлой недели были реализованы две новые возможности:
1. http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2009/n2928.htm.
2. http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2008/n2756.htm.

залил на http://code.google.com/p/mingw-builds/downloads/

Автор: boostcoder 19.10.2011, 10:37

залил новые сборки версий 4.6.2 и 4.7.0.
исправлен SEGFOLT при использовании std::this_thread::yield().

в скором времени выйдет первая версия mingw-env(так далее будет называться проект) включающая:

компилятор MinGW
IDE Code::Block, Dev-C++, wxDev-C++, QtCreator
множество предкомпилированных библиотек

все из перечисленного будет доступно при помощи онлайн-инсталлятора.

Автор: boostcoder 28.10.2011, 10:36

Вчера состоялся релиз компилятора GCC версии 4.6.2, в котором проведена работа по исправлению ошибок, регрессивных изменений и проблем с совместимостью. С момента выхода прошлой версии отмечено http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.6.2, большинство из которых связано с устранением внесенных ранее регрессивных изменений и с улучшением поддержки спецификаций C++11. Исходные тексты компилятора можно загрузить с http://ftp://gcc.gnu.org/pub/gcc/releases/gcc-4.6.2/ или с его http://gcc.gnu.org/mirrors.html.

Сборки MinGW на базе GCC-4.6.2 вы уже сейчас можете скачать на http://code.google.com/p/mingw-builds/downloads/list.
Следующее обновление GCC 4.6.3 ожидается в феврале.

Автор: boostcoder 22.11.2011, 10:02

залил новые сборки тестовой ветки 4.7.0 в которых впервые реализована технология http://gcc.gnu.org/wiki/TransactionalMemory(кстати Intel эту фитчу реализовал довольно давно). полагаю, эта фитча станет невероятно востребована в паре с OpenMP, что позволит сделать мир многопоточных программ проще smile

отдельно хочется поблагодарить Red Hat inc. за "подаренную" реализацию http://gcc.gnu.org/wiki/TransactionalMemory, которая, к тому же, всего три месяца назад "подарила" реализацию http://www.openmp.org/mp-documents/OpenMP3.1.pdf.

скачать версии GCC для windows вы как всегда можете скачать http://code.google.com/p/mingw-builds/downloads/list. совершенно бесплатно smile

Автор: boostcoder 30.11.2011, 19:22

занимаюсь сборкой для x86_64 архитектуры, и возникли такие вопросы:
1. нужна ли сборка хост-x86_64 - цель-x86_64 ? или же достаточно будет хост-х86 - цель-х86_64? ибо последняя сможет работать как на х86 так и на х86_64.
2. есть ли смысл собирать отдельные сборки для х86 и х86_64 хостов? или же собрать хост-х86 и мультицель х86/х86_64 указываемую при помощи стандартных опций "-m32" "-m64" ?

Автор: bsa 1.12.2011, 00:11

boostcoder, имхо, лучше второй вариант.
для начала делай хост x86. Потом, если попросят, всегда можно собрать еще и x86_64.

Автор: boostcoder 10.12.2011, 01:50

добавил http://code.google.com/p/mingw-builds/downloads/list в которых реализованы http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1986.pdf и http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf.

качаем. тестим. осваиваем.

Автор: Trotil 10.12.2011, 09:00

Есть ли плагин для Notepad++, чтобы список функций, классов, методов был доступен отдельно от кода?

Автор: boostcoder 24.12.2011, 11:17

залил новые сборки версии 4.7.0.
разрабатываемая ветка 4.7.0 перешла в stage 3(bug fixes and docs only). все что не было в ней реализовано(а это совсем не много), будет реализовано в ветке 4.8.0.
релиз 4.7.0 обещают в феврале, после чего, ветка перейдет в stage 4(regression fixes and optimization). 4.7.1 обещают в мае.

качать http://code.google.com/p/mingw-builds/downloads/list.

Автор: boostcoder 10.1.2012, 10:15

залил пререлизные сборки 4.6.3.
с этого момента, сборки поддерживают как динамическую, так и статическую линковку. сделано это для соответствия общему принципу. в связи с этим, при использовании std_threads/std_atomics, добавляйте опцию "-static" при линковке. иначе получите сегфолт. проблема известная, и девелоперы обещают ее пофиксить.

зы

Цитата(boostcoder @ 24.12.2011, 11:17

)

релиз 4.7.0 обещают в феврале, после чего, ветка перейдет в stage 4(regression fixes and optimization).

оказывается, я не правильно понял. разрабатываемая ветка сначала перейдет в stage 4, и после, в феврале, ожидается релиз.
в stage 4 ветка уже перешла.

Автор: boostcoder 17.1.2012, 08:30

с гордостью хочу сообщить о том, что исправил последний мне известный баг MinGW, вынуждающий использовать статическую линковку при использовании std_threads!
некоторое время я (на пару с вами) буду тестить этот fix, после чего закоммичу патч.

так же, исправил баг LTO в сборках 4.7.0, который не давал мне покоя уже 4 месяца.

выложил snapshot сборки 4.7.0.
готовлюсь к релизу smile

качать http://code.google.com/p/mingw-builds/downloads/list.

Автор: boostcoder 19.1.2012, 13:17

не к холивару будет пост, но только что в списке рассылки GCC были http://willus.com/ccomp_benchmark2.shtml?p1 сравнительные результаты тестирования компиляторов проводимые Willus.com.
в тестировании принимали участие http://willus.com/ccomp_benchmark2.shtml?p2: MinGW (gcc 4.6.3), Intel 2011, Microsoft 2010 Visual C/C++ Express, и др.(Tiny CC, Digital Mars, MinGW (gcc 3.4.2)). использовались http://willus.com/ccomp_benchmark2.shtml?p3. тестировались http://willus.com/ccomp_benchmark2.shtml?p4 как: BW1D, BZIP2, CRAFTY, K2PDFOPT, LAME, MESHER, MODEL3D, RESIZER, TRANSCEND, X264. тесты проводились http://willus.com/ccomp_benchmark2.shtml?p5 окружении:

Цитата

Intel Core-i3/i5/i7 chips are quite prevalent now, and I'm lazy, so, with no disrespect intended towards AMD and other non-Intel x86 CPUs, I ran the benchmarks only on my home PC, a 2010-vintage system with a Core i5-670 CPU that turbo boosts to 3.73 GHz. My motherboard is an Asus P7H57D-V EVO with 16 GB of DDR-3 1333 MHz RAM. The O/S is 64-bit Windows 7 Ultimate.

в пяти из десяти тестов GCC-4.6.3 незначительно отставал от MSVC.
усредненное значение пересчитанное мною таково:
GCC - 15.13
MSVC - 15.12

т.е. MSVC на одну сотую секунды быстрее из суммы всех времен тестов. а Intel рвет всех.

для остальных компиляторов не считал.

Up.
хотя в результатах тестирования, такие результаты:
gcc-4.6.3-32: 1.38
gcc-4.6.3-64: 1.18
Intel-11-32: 1.21
Intel-11-64: 1.10
msvc2010: 1.59

тут можно скорее сказать, что gcc идет в ногу с intel, чем в ногу с msvc ;)

Автор: borisbn 19.1.2012, 19:05

Несколько раз перечитал описание данного бенчмарка - ничего не понял. Вернее не понял что это за параметр normalized run time
Вот это

Цитата

This is computed by dividing all of the run times by the best run time.

перевести то перевёл, но что это значит - не понял. Зачем делить все времена (и что значит все??? сумму всех?) на лучший результат ?
Можешь разжевать для тупого ?

Автор: newbee 19.1.2012, 19:13

Цитата(borisbn @ 19.1.2012, 20:05

)

Можешь разжевать для тупого ?

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

Добавлено через 2 минуты и 30 секунд
Гцц оказался еще и самым тормозным в плане времени компиляции. Хотя это уже давно известно.

Автор: boostcoder 19.1.2012, 19:19

Цитата(newbee @ 19.1.2012, 19:13

)

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

угу.

Цитата(newbee @ 19.1.2012, 19:13

)

Гцц оказался еще и самым тормозным в плане времени компиляции. Хотя это уже давно известно.

не нужно быть голословной.
все дело в том, что MSVC как и Intel производят сборку в несколько потоков. по умолчанию - сколько ядер. а gcc, точнее make.exe в венде работает в один поток. т.е. опция -j не дает эффекта ;)

Автор: borisbn 19.1.2012, 19:29

Цитата(newbee @ 19.1.2012, 19:13

)

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

скорее это говорит о разбросе в серии тестов. вот взять, например, первый тест.

Цитата

intel11 X X 64-bit 321 3.55 17.1 1.00

Цитата

tcc925 32-bit 21 3.99 91.1 5.31

вроде бы и время работы у tcc925 бешенное (91,1) и этот злополучный параметр плохой (5,31). Но ведь если время выполнения 91,1 сек, а отношение этого времени к лучшему = 5,3, то лучшее время 91,1 / 5,31 = 17,2. А у интела - 17,1 / 1,0 = 17,1.
Нифига не понимаю. smile

Автор: boostcoder 19.1.2012, 19:33

Цитата(borisbn @ 19.1.2012, 19:29

)

tcc925

на сколько я помню, это вообще Си компилятор, при том не оптимизирующий. нафег его вообще приплели к тестам?

Цитата(borisbn @ 19.1.2012, 19:29

)

Нифига не понимаю.

в моих расчетах, я суммировал время работы теста(не компиляции) и поделил на кол-во тестов.

Автор: newbee 19.1.2012, 19:40

Цитата(borisbn @ 19.1.2012, 20:29

)

Нифига не понимаю.

Лучшее время - 17.1, отношение времени тцц к лучшему равно 5.3. Вообще я плохо первый ответ дала, на самом деле это показатель того, во сколько раз одно хуже лучшего. Вот интел - лучший, гцц хуже в полтора раза, тцц - в пять.

Добавлено через 3 минуты и 21 секунду

Цитата(boostcoder @ 19.1.2012, 20:19

)

не нужно быть голословной.

Я знаю про этот баг, но гцц все равно тормоз в соотношении качество/скорость компиляции.

Цитата(boostcoder @ 19.1.2012, 20:33

)

на сколько я помню, это вообще Си компилятор, при том не оптимизирующий. нафег его вообще приплели к тестам?

Ога. Он еще и интерпретировать не компилируя умеет - это главная его фишка. А к тестам его приплели просто чтобы показать насколько простое решение хуже продвинутых технологий. В пять раз всего smile

Автор: boostcoder 19.1.2012, 19:49

newbee, нет, ты чтоб не потроллить о наболевшем, не можешь.

Автор: newbee 19.1.2012, 19:51

Цитата(boostcoder @ 19.1.2012, 20:49

)

newbee, нет, ты чтоб не потроллить о наболевшем, не можешь.

Дохтур, у меня ничего не болит, вы о чем вообще? ;;я честно не поняла, где троллинг.

Добавлено через 8 минут и 11 секунд
Я еще чуть чуть почитала про тцц и повнимательней посмотрела статистику, так этот тцц быстрее всех компилирует - чем не повод засунуть его в эксперимент?

Автор: borisbn 20.1.2012, 08:28

Сорри за тупизм. Вот говорили же мне старшие товарищи, что утро вечера мудреннее... Вот это я вчера протупил. Решил (почему-то), что для одного компилятора делалась серия экспериментов и этот злополучный коэффициент - это среднее время делить на лучшее среди этих экспериментов, а на самом деле это - время работы кода этого компилятора делить на лучшее время среди компиляторов. Теперь ясно.

Автор: boostcoder 1.2.2012, 11:22

скажите, кому либо в моих сборках, нужны ли Objective-C, Objective-C++, Fortran? хочу их исключить. за ненадобностью.

спасибо.

Автор: boostcoder 4.2.2012, 14:18

Objective-C и Objective-C++ были исключены за ненадобностью.

залил http://code.google.com/p/mingw-builds/downloads/list версий 4.6.3-prerelease и 4.7.0-snapshot.

Автор: boostcoder 5.2.2012, 15:10

добавил новые сборки 4.6.2-release с фиксом динамической линковки при использовании std_threads.

Автор: boostcoder 2.3.2012, 00:05

Вчера, 1 Марта, состоялся релиз компилятора GCC версии 4.6.3, являющийся очередным баг-фикс релизом ветки компиляторов 4.6.х

Было исправлено более 70 багов.
Полный список вы можете найти http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.6.3&list_id=25044.

http://news.softpedia.com/news/GCC-4-6-3-Brings-Lots-of-Fixes-256097.shtml.

P.S.
Уже сейчас вы можете скачать MinGW на базе gcc-4.6.3 из http://code.google.com/p/mingw-builds/.
Комплект состоящий из mingw-4.6.3+boost-1.49.0, у меня в подписи.

Автор: Alca 2.3.2012, 11:20

Когда будут сборки mingw64 ? Можешь сделать для версии 4.6.3 ?

Автор: boostcoder 2.3.2012, 11:29

Цитата(Alca @ 2.3.2012, 11:20

)

Когда будут сборки mingw64 ?

эх... руки не доходят.
по возможности, на выходных постараюсь.

Автор: boostcoder 2.3.2012, 22:10

сегодня, основная ветка разработки GCC (http://gcc.gnu.org/viewcvs/trunk/), форкнулась в http://gcc.gnu.org/viewcvs/branches/gcc-4_7-branch/. это означает, что релиз gcc-4.7.0 состоится через неделю-другую. релиз-кандидат соберу на днях.
начата работа над gcc-4.8.0.

Автор: bsa 2.3.2012, 22:19

boostcoder, да ладно? Они что ли собираются нестабильную версию выпустить? Или у них trunk стабильная?

Автор: boostcoder 2.3.2012, 22:37

Цитата(bsa @ 2.3.2012, 22:19

)

trunk стабильная?

trunk становится стабильным по достижению stage4. он достигнут. trunk форкнулся. и с этого момента trunk считается нестабильным, снова.

Автор: Randajad 15.3.2012, 13:22

std::regex запилили бы лучше.

Автор: borisbn 15.3.2012, 13:55

Randajad, а что не так с регексами ?

Автор: boostcoder 15.3.2012, 13:56

Цитата(Randajad @ 15.3.2012, 13:22

)

std::regex запилили бы лучше.

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

Автор: borisbn 15.3.2012, 13:56

кажется понял...
http://liveworkspace.org/code/5633b7a65228b9509264ebd0e7853b69

Автор: boostcoder 15.3.2012, 13:56

borisbn, говорят что не работает. кто-то говорит что тупо сегфолтит. я пока не проверял.

Добавлено через 41 секунду

Цитата(borisbn @ 15.3.2012, 13:56

)

кажется понял...

хм.. а когда-то оно работало. в линуксе точно.

Автор: Randajad 15.3.2012, 14:00

Не сегфолтит.
На простом std::regex r("\\d"); кидает std::regex_error.

Автор: boostcoder 25.3.2012, 00:30

Всем привет.

Если вдруг кто не знает, http://code.google.com/p/mingw-builds/ - это проект предоставляющие сборки компилятора http://gcc.gnu.org/ для Windows платформы, т.е. MinGW.

Итак...
До сих пор, проект предоставлял сборки с двумя типами реализации исключений: 1)http://en.wikipedia.org/wiki/DWARF, 2)sjlj(http://www.di.unipi.it/~nids/docs/longjump_try_trow_catch.html, http://www.on-time.com/ddj0011.htm).
Сборки использующие dwarf, будут исключены из последующих сборок проекта http://code.google.com/p/mingw-builds/.
Связанно это с двумя причинами:
1. dwarf, для windows ОС - это инородный способ реализации исключений, он не может работать правильно в windows из-за того, что реализация как С++ так и Си(http://en.wikipedia.org/wiki/Microsoft-specific_exception_handling_mechanisms#Structured_Exception_Handling) исключений в компиляторе MSVC использует SJLJ. В связи с этим, возникают трудноуловимые ошибки связанные с разрушением стека и пробросом/ловлей исключений между .dll модулей. Мнение разработчиков CRT для MinGW(mingw-w64) http://sourceforge.net/apps/trac/mingw-w64/wiki/Exception%20Handling.
2. и вторая причина, вытекающая из первой - отсутствие реализации dwarf для windows-x86_64.

Посему, пользователям dwarf сборок придется пересобирать либы. Увы...

С этого момента, проект http://code.google.com/p/mingw-builds/ предоставляет сборки для двух хостов: a)i686, b)x86_64.
Каждая такая сборка, является двухцелевым кросс-компилятором. Компилятор для i686 хоста по умолчанию собирает для i686 цели. Компилятор для x86_64 хоста по умолчанию собирает для x86_64 цели.

Для того, чтоб при помощи компилятора для i686 хоста собрать для x86_64 - при компиляции и линковке добавляйте флаг -m64.
Для того, чтоб при помощи компилятора для x86_64 хоста собрать для i686 - при компиляции и линковке добавляйте флаг -m32.

Разумеется, все зависимости цели должны быть собраны соответствующим образом.

Теперь о зависимостях цели от .dll модулей поставляемых в составе компилятора(libstdc++-6.dll, etc...).
Как правило, при использовании MinGW, путь к mingw/bin прописывается в PATH. Все необходимые для хоста .dll модули так же находятся в mingw/bin. По этому, проблем с выполнением полученных исполняемых файлов нет. Но при использовании кросс-компилятора все немного сложнее.
Если производится сборка при которой host==target - тут все как обычно, ибо .dll модули находятся в mingw/bin. Однако, в случаях когда host!=target, .dll модули оказываются недоступными для целевого исполняемого файла.
Для i686 компилятора, .dll модули для x86_64 цели располагаются в mingw/i686-w64-mingw32/lib64.
Для x86_64 компилятора, .dll модули для i686 цели располагаются в mingw/x86_64-w64-mingw32/lib32.

Если что не понятно - задавайте вопросы.

Сборка для i686 уже готова. Со сборкой для x86_64 хоста возникли некоторые сложности. На страницу проекта пока не выгружал. Хочу одновременно.

Всем спасибо.

Автор: Randajad 25.3.2012, 18:02

Исправьте в первом посту пожалуйста: пишется CodeBlocks, а не CodeBlock. smile

Автор: boostcoder 26.3.2012, 23:50

визуализация всего периода разработки GCC: http://www.youtube.com/watch?v=ZEAlhVOZ8qQ

Автор: boostcoder 29.3.2012, 05:48

Выгрузил следующие сборки:
1. i686-mingw32-gcc-4.6.3-release-c,c++,fortran-sjlj
2. x86_64-mingw32-gcc-4.6.3-release-c,c++,fortran-sjlj
3. i686-mingw32-gcc-4.7.0-release-c,c++,fortran-sjlj
4. x86_64-mingw32-gcc-4.7.0-release-c,c++,fortran-sjlj

жду отзывов smile

Автор: borisbn 29.3.2012, 08:38

boostcoder, спасибо. Ждём 4.7.0 на LWS smile

Автор: boostcoder 29.3.2012, 10:13

Цитата(borisbn @ 29.3.2012, 08:38

)

4.7.0 на LWS

кстати да. совсем забыл %)

готово: http://liveworkspace.org/code/6331a929ef26265c656bf1839fb8065d

Цитата

gcc version: 4.7.0
boost version: 1_50

Автор: Randajad 8.4.2012, 12:22

http://liveworkspace.org/code/6f1ea9af8809ddd0510e6af33c05cebf
Не работаэ. Причем в заголовках функции есть.

Взято с:
http://en.cppreference.com/w/cpp/io/manip/get_time

Автор: boostcoder 8.4.2012, 14:55

походу недореализовано.

Автор: boostcoder 12.4.2012, 13:36

gcc-4.8.x будет формировать вывод информации о ошибках и варнингах по мотиву CLang. но говорят что даже лучше чем CLang.
в принципе, эта фишка уже сейчас перенесена в trunk. на неделе соберу, поглядеть.

Автор: borisbn 12.4.2012, 14:05

Цитата(boostcoder @ 12.4.2012, 13:36

)

по мотиву CLang

стыдно признаться, но никогда не видел CLang (да и слышал-то немного)... поэтому, можешь дать ссылку на их способ отображения ?
Только не на сам CLang (его-то я найти смогу)))
Спасибо.

Автор: boostcoder 12.4.2012, 14:16

читай ветку: http://gcc.gnu.org/ml/gcc/2012-04/msg00477.html
там примеры есть.

Автор: boostcoder 17.4.2012, 13:27

Итак.
В проекте http://code.google.com/p/mingw-builds/ произошли два изменения:
1. проект переехал на sf.net. http://sourceforge.net/projects/mingwbuilds/.
2. опубликованы скрипты сборки с помощью которых вы самостоятельно можете собрать MinGW.
Получить вы можете выполнив эту команду:
git clone git://git.code.sf.net/p/mingwbuilds/code mingw-builds

Архивы с собранным MinGW вы сможете скачать http://sourceforge.net/projects/mingwbuilds/files/.
На данный момент скачивать нечего. Сейчас пересобираю все доступные версии. Сегодня залью.

Так же, для каждого собранного MinGW буду выгружать архивы с исходниками, ибо этого требует лицензия GPL.

Буду признателен если кто-либо попробует воспроизвести процесс сборки на своей машине и в своем окружении.
http://sourceforge.net/p/mingwbuilds/code/ci/72b33e43ffe791e9a3a54722c70193b2f3446f13/tree/README.TXT по использованию скриптов.

Всем спасибо!

Автор: boostcoder 18.4.2012, 05:08

Залил следующие сборки:
https://sourceforge.net/projects/mingwbuilds/files/windows-host/4.6.2/
https://sourceforge.net/projects/mingwbuilds/files/windows-host/4.6.3/
https://sourceforge.net/projects/mingwbuilds/files/windows-host/4.6.4/
https://sourceforge.net/projects/mingwbuilds/files/windows-host/4.7.0/
https://sourceforge.net/projects/mingwbuilds/files/windows-host/4.7.1/
https://sourceforge.net/projects/mingwbuilds/files/windows-host/4.8.0/

Тестим, отписываемся.

Автор: Randajad 26.4.2012, 12:07

Цитата

s — вывод строки с нулевым завершающим байтом; если модификатор длины — l, выводится строка wchar_t*. В Windows значения типа s зависят от типа используемых функций. Если используется семейство printf функций, то s обозначает строку char*. Если используется семейство wprintf функций, то s обозначает строку wchar_t*.
S — то же самое что и s с модификатором длины l; В Windows значения типа S зависит от типа используемых функций. Если используется семейство printf функций, то S обозначает строку wchar_t*. Если используется семейство wprintf функций, то S обозначает строку char*.

© Педивикия.

Однако в реальности %S в wprintf все также обозначает wchar_t * строку, а %s - все так же обычную char *.
GCC 4.7.

Автор: Randajad 29.4.2012, 14:03

__attribute__((packed))
Не работает на структурах на GCC 4.8, на других не тестил. Связи с чем сборка крупных прожэктов затруднена этим компилятором.

Автор: Randajad 29.4.2012, 14:34

Методом тестов установлено: от 4.6.2 по ссылкам выше до 4.6.4 работает без проблем, начиная с 4.7.0 - баг.

Автор: alexvs11 29.4.2012, 14:44

Цитата(boostcoder @ 12.4.2012, 13:36

)

gcc-4.8.x будет формировать вывод информации о ошибках и варнингах по мотиву CLang. но говорят что даже лучше чем CLang.в принципе, эта фишка уже сейчас перенесена в trunk. на неделе соберу, поглядеть.

это же замечательно!
честно говоря периодически не осиливая сообщения об ошибках gcc - скармливаю программу clang'у smile

Автор: boostcoder 29.4.2012, 14:53

не ты один ;)

начальную стадию уже сейчас можно посмотреть в версиях 4.8.0: https://sourceforge.net/projects/mingwbuilds/files/windows-host/4.8.0/

Автор: Randajad 29.4.2012, 15:05

Да, в гцц вырвиглазные ошибки.
Кстати разницы в 4.8 по сравнению с другими не заметил. smile

Автор: boostcoder 29.4.2012, 15:06

Randajad, покажи примеры для 4.8.0 и той, с которой сравниваешь.

Автор: Randajad 29.4.2012, 15:14

4.8.

Цитата

In file included from Q:\Tools\CodeBlocks\Custom\include/boost/program_options/value_semantic.hpp:14:0,
                 from Q:\Tools\CodeBlocks\Custom\include/boost/program_options/options_description.hpp:13,
                 from Q:\Tools\CodeBlocks\Custom\include/boost/program_options.hpp:15,
                 from Q:\Tools\CodeBlocks\Custom\include/lib/options.h:2,
                 from Q:\Work\rwork\nedtest\main.cpp:1:
Q:\Tools\CodeBlocks\Custom\include/boost/lexical_cast.hpp: In instantiation of 'bool boost::detail::lexical_stream_limited_src<CharT, Traits, RequiresStringbuffer>::shr_using_base_class(InputStreamable&) [with InputStreamable = main(int, const char**)::<anonymous struct>; CharT = wchar_t; Traits = std::char_traits<wchar_t>; bool RequiresStringbuffer = false]':
Q:\Tools\CodeBlocks\Custom\include/boost/lexical_cast.hpp:1704:90:   required from 'bool boost::detail::lexical_stream_limited_src<CharT, Traits, RequiresStringbuffer>::operator>>(InputStreamable&) [with InputStreamable = main(int, const char**)::<anonymous struct>; CharT = wchar_t; Traits = std::char_traits<wchar_t>; bool RequiresStringbuffer = false]'
Q:\Tools\CodeBlocks\Custom\include/boost/lexical_cast.hpp:1920:17:   required from 'static Target boost::detail::lexical_cast_do_cast<Target, Source>::lexical_cast_impl(const Source&) [with Target = main(int, const char**)::<anonymous struct>; Source = std::basic_string<wchar_t>]'
Q:\Tools\CodeBlocks\Custom\include/boost/lexical_cast.hpp:2087:50:   required from 'Target boost::lexical_cast(const Source&) [with Target = main(int, const char**)::<anonymous struct>; Source = std::basic_string<wchar_t>]'
Q:\Tools\CodeBlocks\Custom\include/boost/program_options/detail/value_semantic.hpp:88:13:   required from 'void boost::program_options::validate(boost::any&, const std::vector<std::basic_string<charT> >&, T*, long int) [with T = main(int, const char**)::<anonymous struct>; charT = wchar_t]'
Q:\Tools\CodeBlocks\Custom\include/boost/program_options/detail/value_semantic.hpp:169:13:   required from 'void boost::program_options::typed_value<T, charT>::xparse(boost::any&, const std::vector<std::basic_string<charT> >&) const [with T = main(int, const char**)::<anonymous struct>; charT = wchar_t]'
Q:\Work\rwork\nedtest\main.cpp:23:1:   required from here
Q:\Tools\CodeBlocks\Custom\include/boost/lexical_cast.hpp:1544:29: error: cannot bind 'std::basic_istream<wchar_t>' lvalue to 'std::basic_istream<wchar_t>&&'
                 Traits::eof();
                             ^

4.6.

Цитата

In file included from Q:\Tools\CodeBlocks\Custom\include/boost/program_options/value_semantic.hpp:14:0,
                 from Q:\Tools\CodeBlocks\Custom\include/boost/program_options/options_description.hpp:13,
                 from Q:\Tools\CodeBlocks\Custom\include/boost/program_options.hpp:15,
                 from Q:\Tools\CodeBlocks\Custom\include/lib/options.h:2,
                 from Q:\Work\rwork\nedtest\main.cpp:1:
Q:\Tools\CodeBlocks\Custom\include/boost/lexical_cast.hpp: In member function 'bool boost::detail::lexical_stream_limited_src<CharT, Traits, RequiresStringbuffer>::shr_using_base_class(InputStreamable&) [with InputStreamable = main(int, const char**)::<anonymous struct>, CharT = wchar_t, Traits = std::char_traits<wchar_t>, bool RequiresStringbuffer = false]':
Q:\Tools\CodeBlocks\Custom\include/boost/lexical_cast.hpp:1704:90:   instantiated from 'bool boost::detail::lexical_stream_limited_src<CharT, Traits, RequiresStringbuffer>::operator>>(InputStreamable&) [with InputStreamable = main(int, const char**)::<anonymous struct>, CharT = wchar_t, Traits = std::char_traits<wchar_t>, bool RequiresStringbuffer = false]'
Q:\Tools\CodeBlocks\Custom\include/boost/lexical_cast.hpp:1920:17:   instantiated from 'static Target boost::detail::lexical_cast_do_cast<Target, Source>::lexical_cast_impl(const Source&) [with Target = main(int, const char**)::<anonymous struct>, Source = std::basic_string<wchar_t>]'
Q:\Tools\CodeBlocks\Custom\include/boost/lexical_cast.hpp:2087:50:   instantiated from 'Target boost::lexical_cast(const Source&) [with Target = main(int, const char**)::<anonymous struct>, Source = std::basic_string<wchar_t>]'
Q:\Tools\CodeBlocks\Custom\include/boost/program_options/detail/value_semantic.hpp:88:13:   instantiated from 'void boost::program_options::validate(boost::any&, const std::vector<std::basic_string<charT> >&, T*, long int) [with T = main(int, const char**)::<anonymous struct>, charT = wchar_t]'
Q:\Tools\CodeBlocks\Custom\include/boost/program_options/detail/value_semantic.hpp:169:13:   instantiated from 'void boost::program_options::typed_value<T, charT>::xparse(boost::any&, const std::vector<std::basic_string<charT> >&) const [with T = main(int, const char**)::<anonymous struct>, charT = wchar_t]'
Q:\Work\rwork\nedtest\main.cpp:23:1:   instantiated from here
Q:\Tools\CodeBlocks\Custom\include/boost/lexical_cast.hpp:1544:29: error: cannot bind 'std::basic_istream<wchar_t>' lvalue to 'std::basic_istream<wchar_t>&&'

Ах, нововведение заключается в стрелочке, как я забыл.
Кроме нее ничего полезного. В случае маленькой ошибки gcc выводит всякую ересь. Порой даже ересь не относится к ошибке. smile

В MSVC с этим лучше, там таки более-менее вменяемое выдает.

Автор: boostcoder 29.4.2012, 15:29

и правда.
ну ждем. разрабы обещали что будет не хуже чем у кланга.

Автор: Randajad 30.4.2012, 22:25

Когда кланг стоит ждать? smile

Автор: boostcoder 30.4.2012, 23:18

эм... сейчас решается вопрос.

Автор: Randajad 8.5.2012, 17:04

На гцц 4.8 лто не распаралелливается. Выдает ошибку: lto-wrapper: CreateProcess: No such file or directory

Автор: boostcoder 8.5.2012, 17:16

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

Автор: Randajad 8.5.2012, 21:21

main.cpp:

int main(){}

g++ main.cpp -flto=4

sourceforge.net/projects/mingwbuilds/files/windows-host/4.8.0/snapshot/i686-mingw32-gcc-4.8.0-snapshot-20120430-rev-186947-c%2Cc%2B%2B%2Cfortran.7z/download

Автор: boostcoder 9.5.2012, 00:42

Randajad, у меня происходит такая ошибка:

Цитата

"make": [C:\Users\юзер\AppData\Local\Temp\ccKXUcye.ltrans0.ltrans.o] Error 1 (ignored)

но это нормально если учесть, что snapshot`ы вообще работать не обязаны)

Автор: Randajad 9.5.2012, 08:21

Не обязаны работать? Да ладно. smile

Работает кошерно. Никаких особых трабл, кроме описаных выше, нету. Лто - вещь, кстати. Прирост ощутимый дает, плюс теперь гцц научилось выкидывать dead-code из экзешки по-нормальному. На крупном проекте с 6,7 метров стало всего 3,5. Правда без распаралелливания линкуется 3 минуты. smile

Скорее бы релиз новый, что-ли. smile

Автор: Randajad 9.5.2012, 11:08

К сведению на release gcc 4.7.0 оно тоже не распаралелливается.

lto-wrapper: CreateProcess: No such file or directory
gcc/bin/../lib/gcc/i686-w64-mingw32/4.7.0/../../../../i686-w64-mingw32/bin/ld.exe: lto-wrapper failed
collect2.exe: error: ld returned 1 exit status

http://sourceforge.net/projects/mingwbuilds/files/windows-host/4.7.0/release/i686-mingw32-gcc-4.7.0-release-c%2Cc%2B%2B%2Cfortran.7z/download

Так что ваши релизы тоже не работают. smile

Автор: boostcoder 9.5.2012, 11:32

Цитата(Randajad @ 9.5.2012, 11:08

)

release gcc 4.7.0 оно тоже не распаралелливается

смогу проверить часов через 8мь, к сожалению.
но что-то мне подсказывает, что ошибка тоже будет чем-то вроде:

Цитата

"make": [C:\Users\юзер\AppData\Local\Temp\ccKXUcye.ltrans0.ltrans.o] Error 1 (ignored)

Добавлено через 6 минут и 17 секунд
а где ты выполняешь эту команду?
в смысле, откуда запускаешь?

Автор: Randajad 9.5.2012, 15:10

Откуда-нибудь.
gcc/bin в path стоит.
Увы, ваша ошибка мне ни о чем не говорит, совсем.

Автор: Randajad 13.5.2012, 13:28

Эм, а почему gcc 4.8.0 использует sse2 по-умолчанию? Экзешка отказалась запускаться на моем старом компе. Только после указания -march вручную заработало.

Автор: boostcoder 13.5.2012, 14:22

Цитата(Randajad @ 13.5.2012, 13:28

)

почему gcc 4.8.0 использует sse2 по-умолчанию?

а 4.7.х и 4.6.х так же?

Автор: Randajad 13.5.2012, 15:32

http://sourceforge.net/projects/mingwbuilds/files/windows-host/4.7.0/release/x86_64-mingw-w64-gcc-4.7.0-release-c%2Cc%2B%2B%2Cfortran.7z/download
Та же история.

Добавлено через 7 минут и 56 секунд
UPD:
http://sourceforge.net/projects/mingwbuilds/files/windows-host/4.7.0/release/i686-mingw-w64-gcc-4.7.0-release-c%2Cc%2B%2B%2Cfortran.7z/download
Тут проблемы нет.
Видимо, она только с x64 хостом, который собирает x86 приложение.

Автор: boostcoder 13.5.2012, 15:42

Цитата(Randajad @ 13.5.2012, 15:32

)

Видимо, она только с x64 хостом, который собирает x86 приложение.

приведи еще код, которым детектируешь такое поведение. попробую разузнать.

Автор: Randajad 13.5.2012, 15:46

3D движок irrlicht + любой из его примеров.

Автор: boostcoder 13.5.2012, 15:53

Цитата(Randajad @ 13.5.2012, 15:46

)

3D движок irrlicht + любой из его примеров.

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

Добавлено @ 15:55
скинь тогда обе экзешки. я на примере сгенеренного ассемблера им покажу разницу.

Добавлено через 3 минуты и 6 секунд
они статически линкуют зависимости от irrlicht?
если нет - тогда и dll`ки тоже скинь.

Автор: Randajad 13.5.2012, 16:06

Да наверняка любая программка с каким-нибудь циклом, который гцц может векторизировать. smile

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

Автор: boostcoder 14.5.2012, 15:48

Цитата(Randajad @ 13.5.2012, 16:06

)

Чуть попозже сделаю таковой и предоставляю.

пинг?

Автор: boostcoder 24.5.2012, 04:06

Сегодня, состоялся релиз системы сборки MinGW в рамках проекта MinGW-builds под версией 0.1.0.
Из основных изменений произошедших с момента первого коммита, можно отметить следующие:

Добавлен ключ --preload, заставляющий систему сборки сначала скачать все исходники, и только потом собирать. Необходим для одновременной сборки сразу нескольких версий.
Добавлен ключ --dwarf, информирующий систему сборки использовать DWARF вместо SJLJ. При этом, доступна сборка только для i686 хоста, и только для i686 цели.
Для каждой версии GCC отныне отдельный конфигурационный файл.
Аргументы командной строки более не зависят от порядка написания.
Логи сборки более не вставляются в архив со сборкой.
С этого момента, архивы со сборками снова содержат суффикс используемой сборкой реализации исключений.
https://sourceforge.net/projects/mingwbuilds/files/External%20binary%20packages/, со всеми необходимыми для сборки MinGW тулзами(7z+wget+svn+git+mercurial+cvs) вы теперь можете скачать на странице проекта.
Добавлен патч исправляющий https://sourceforge.net/mailarchive/message.php?msg_id=29215821 возникающую при генерации компилятором кода развертывания стека и использованием http://msdn.microsoft.com/en-us/library/windows/desktop/ms679360(v=vs.85).aspx в этом скопе.
Добавлены следующие тесты: 1)тест POSIX-RT функций, 2)тест С++11 sleep_for/sleep_until функций, 3)тест GetLastError() при развертывании стека.

Инструкцию по использованию системы сборки MinGW-builds вы можете прочесть http://sourceforge.net/p/mingwbuilds/wiki/Installing%20MinGW-builds/.

Автор: AndrewMT 31.5.2012, 18:27

Подскажите, пожалуйста...

Всё-таки возможно собрать Qt под Windows (64-bit) 64-битным MinGW? С нормальной поддержкой OpenMP?

До этого пользовалься Qt с компилятором от MSVC++, нашёл в нём баг (связанный с threadprivate), который
ещё в 2005 г. GNU исправил - я сам проверял на 32-битном MinGW...

Насколько я знаю, Nokia официально Qt с MinGW 64-bit не поддерживает....

Автор: boostcoder 31.5.2012, 19:13

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

Автор: AndrewMT 31.5.2012, 19:21

ОК, попробую, сообщу. Надеюсь, разберёмся ))

Автор: Randajad 5.6.2012, 17:10

d:\msys\mingw-gcc-trunk-x32\lib\gcc\i686-w64-mingw32\specs
Почему GCC этот файлик хочет? У меня винда из-за этого выдает табличку про отсутствие диска "D:", ибо у меня его нет.

Автор: boostcoder 5.6.2012, 17:12

покажи аргументы командной строки.

Автор: Randajad 5.6.2012, 18:28

gcc -v.

Автор: boostcoder 5.6.2012, 18:45

похоже, ты второй человек у которого на машине нет диска D: smile

такая же проблема описана https://sourceforge.net/mailarchive/message.php?msg_id=29336204.

как решить проблему правильно - я так и не понял.
можно обойти ее, собирая MinGW на диске C:

Автор: Randajad 5.6.2012, 19:03

Исходники GCC есть, какие проблемы? smile

Выпилить из кода этот участок. smile

Все-равно не найдет же.

P.S.: оно проверяет наличие файла через _access.

Автор: boostcoder 5.6.2012, 19:18

Цитата(Randajad @ 5.6.2012, 19:03

)

какие проблемы?

никаких проблем.
но почему-то от от тебя я патча так и не получил. сколько нужно ждать?

Цитата(Randajad @ 5.6.2012, 19:03

)

оно проверяет наличие файла через _access

как определил?

Автор: Randajad 5.6.2012, 19:27

Дизассемблил. smile

Я ж в личку ответил причину. :3

.text:00456B7B                 mov     [esp+0Ch+var_8], 4
.text:00456B83                 mov     [esp+0Ch+var_C], ebx
.text:00456B86                 call    ds:_access

Автор: boostcoder 5.6.2012, 19:49

порою в этом направлении...

Автор: borisbn 6.6.2012, 10:35

Цитата(Randajad @ 15.3.2012, 13:22

)

std::regex запилили бы лучше.

оно, конечно, три месяца прошло... но лучше поздно, чем никогда...
вот - http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011
п. 28 - Regular expressions
и вот - http://stackoverflow.com/questions/8060025/is-this-c11-regex-error-me-or-the-compiler
будем ждать
они что, не могли тупо переименовать boost::regex в std::regex ? Все ж привыкли уже к бустовским, так зачем было что-то менять ???

Автор: Randajad 6.6.2012, 11:54

Видимо решили свою реализацию. Уже вон сколько времени, а до сих пор нету. smile

Автор: boostcoder 14.6.2012, 23:57

Несколько часов назад состоялся релиз компилятора GCC версии 4.7.1.
Это первый баг-фикс релиз для ветки 4.7.х.
Было исправлено 117 багов. Полный список вы можете обозрить http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.1&list_id=34041.

Уже сейчас вы можете скачать http://sourceforge.net/projects/mingwbuilds/files/windows-host/4.7.1/release/.

Автор: Randajad 15.6.2012, 08:06

Скачал. Другие баги остались.

wchar.h, 950.

Код


  int wmemcmp(const wchar_t *s1, const wchar_t *s2,size_t n);

Тот же файл, 973.

Код


  __CRT_INLINE int [color=red]__cdecl[/color] wmemcmp(const wchar_t *_S1,const wchar_t *_S2,size_t _N) {

Добавлено через 1 минуту и 15 секунд
math.h, 426:

Код


  extern float [color=red]__cdecl[/color] sinhf(float _X);
#ifndef __CRT__NO_INLINE
  __CRT_INLINE float sinhf(float _X) { return ((float)sinh((double)_X)); }
#endif

Добавлено через 3 минуты и 1 секунду
Вообщем это везде в math.h в #ifndef __CRT__NO_INLINE и выплывает при изменении стандартного calling convention.

Автор: boostcoder 15.6.2012, 08:11

про эти последствия копипаста ты раньше не говорил.
так что -

Цитата(Randajad @ 15.6.2012, 08:06

)

Другие баги остались.

для меня это новые баги.

Цитата(Randajad @ 15.6.2012, 08:06

)

выплывает при изменении стандартного calling convention.

а для чего это делать?

Автор: Randajad 15.6.2012, 08:13

Жалко, что не поправили распаралелливание лто.

Добавлено через 24 секунды
Ну как. smile

В любом случае должно работать. smile

Автор: boostcoder 15.6.2012, 08:21

какой-то баг с распаралелливанием LTO все же пофиксили: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53019

Автор: Randajad 15.6.2012, 08:27

Какой-то...
А все эти багфиксы в ветку 4.8 перенесены? Если да, то когда снапшотик будет? smile

Автор: boostcoder 15.6.2012, 08:36

Цитата(Randajad @ 15.6.2012, 08:27

)

А все эти багфиксы в ветку 4.8 перенесены?

конечно.

Цитата(Randajad @ 15.6.2012, 08:27

)

Если да, то когда снапшотик будет?

воскресенье-понедельник.
впрочем, как обычно smile

Автор: boostcoder 19.6.2012, 15:56

Цитата(Randajad @ 15.6.2012, 08:13

)

не поправили распаралелливание лто.

ты баг-репорт написал?
как воспроизвести баг?

Автор: Randajad 19.6.2012, 18:23

Я писал в этой теме тебе. =_=
Любую программу/дллку линковать с параметром -flto=4 или любым другим числом, отличным от 1.

Автор: Randajad 26.6.2012, 18:42

Ом-ом-ом!
Не могу обнаружить в сборке от 25 числа i686 GCC 4.8 либу winhttp. Хидер есть, либы нету. :(

Добавлено через 56 секунд
На случай. Выдрал из студии 10-ой.

Автор: boostcoder 26.6.2012, 21:34

эм..

Автор: Randajad 3.7.2012, 17:56

http://fastpic.ru/view/40/2012/0703/9f4eba1fad24a1e8df06ae671af26f5f.png.html

Это гцц/афтар специально более 9000 одинаковых копирастов оставляет?

Автор: boostcoder 3.7.2012, 18:25

я всего один раз указываю. и только для gcc.

Автор: Randajad 4.7.2012, 10:20

Я бы сказал что это, а не GCC.

http://sourceforge.net/projects/mingwbuilds/files/windows-host/4.7.1/release/i686-mingw-w64-gcc-4.7.1-release-c%2Cc%2B%2B%2Cfortran-sjlj-PREFINAL.7z/download
Последняя релизная сборка.

Простой пример:

Код


int main() {
    wchar_t buf[2];
    int len = snwprintf(buf, sizeof(buf) / 2, L"world!");

    printf("%d\n", len);
}

Должно вывести -1. Выводит, если огородить этот пример от мира сего.

Просто инклюдим boost::system(он имеет какие-то статические объекты).

Код


#include <boost/system/system_error.hpp>

Этот невинный пример начинает требовать libboost_system. О-кей. Мы ему его дали.
Этот невинный пример начинает выводить 6.

Поищу нехорошие вещи в boost::system, отпишусь.
Но под вяндой мне этот компилятор начинает нравиться все меньше.

Добавлено @ 10:30
Обнаружил волшебный макрос, который заставляет boost::system не требовать либу. Если дефайнить BOOST_SYSTEM_NO_DEPRECATED, то все собирается и без либы, но результат такой же. Для чистоты эксперимента все собиралось с одним лишь -g.
Копать сотни хидеров буста не собираюсь, о баге отписался.
На сим удачи!

Автор: boostcoder 4.7.2012, 11:59

посмотри, в экспорте msvcrt.dll есть экспорт этой функции? или только этой же функции но с лидирующим подчерком?
в msdn`е нашел только функцию с подчерком.

Автор: Randajad 4.7.2012, 12:15

Код


/* __attribute__((__format__ (gnu_wprintf, 3, 4))) */ __MINGW_ATTRIB_NONNULL(3)
int snwprintf (wchar_t *__stream, size_t __n, const wchar_t *__format, ...)
{
  register int __retval;
  __builtin_va_list __local_argv; __builtin_va_start( __local_argv, __format );
  __retval = __mingw_vsnwprintf( __stream, __n, __format, __local_argv );
  __builtin_va_end( __local_argv );
  return __retval;
}

С бустотой оно юзает это из wchar.h.

Без бустоты оно юзает это

Код


  int snwprintf (wchar_t * __restrict__ s, size_t n, const wchar_t * __restrict__ format, ...)
  {
    int r;
    va_list argp;
    __builtin_va_start (argp, format);
    r = _vsnwprintf (s, n, format, argp);
    __builtin_va_end (argp);
    return r;
  }
  __mingw_ovr
  int __cdecl vsnwprintf (wchar_t * __restrict__ s, size_t n, const wchar_t * __restrict__ format, va_list arg)
  {
    return _vsnwprintf(s,n,format,arg);
  }

Из stdio.h. smile

Разгадка в __USE_MINGW_ANSI_STDIO, я не знаю, что его дефайнит.

Автор: boostcoder 4.7.2012, 12:15

такая мысль еще посетила... может быть boost.system предоставляет реализацию snwprintf() ? smile

Автор: Randajad 4.7.2012, 12:16

Когда пофиксится моя бага с форматом строк в принтфе?

Цитата

Цитата

s — вывод строки с нулевым завершающим байтом; если модификатор длины — l, выводится строка wchar_t*. В Windows значения типа s зависят от типа используемых функций. Если используется семейство printf функций, то s обозначает строку char*. Если используется семейство wprintf функций, то s обозначает строку wchar_t*.
S — то же самое что и s с модификатором длины l; В Windows значения типа S зависит от типа используемых функций. Если используется семейство printf функций, то S обозначает строку wchar_t*. Если используется семейство wprintf функций, то S обозначает строку char*.

© Педивикия.

Однако в реальности %S в wprintf все также обозначает wchar_t * строку, а %s - все так же обычную char *.
GCC 4.7.

Из-за этого код непереносим под вяндой с GCC на MSVC/ICC.

Добавлено через 30 секунд
Нет, я подебажил. Смотреть выше. smile

Автор: boostcoder 4.7.2012, 12:18

Цитата(Randajad @ 4.7.2012, 12:15

)

Разгадка в __USE_MINGW_ANSI_STDIO, я не знаю, что его дефайнит.

наверное boost.system или включаемый им boost.config...

Автор: boostcoder 4.7.2012, 12:52

Randajad, так используя/не_используя __USE_MINGW_ANSI_STDIO, поведение воспроизводится по разному и без boost.system?

Автор: Randajad 4.7.2012, 13:06

Ога.
Без буста и без него - -1.
Без буста и с ним - 6.

Автор: boostcoder 4.7.2012, 13:39

попробую у разрабов CRT`ишки узнать...

Автор: boostcoder 10.7.2012, 17:29

http://sourceforge.net/projects/mingwbuilds/files/windows-host/4.7.1/release/ MinGW на базе gcc-4.7.1-release.
обновил GDB до версии 7.4.1, и GNU make с этого момента собирается с поддержкой job-server.
для пользователей Qt это станет приятным бонусом, ибо теперь у них появится возможность производить сборку Qt и проектов основанных на .pro файлах в требуемое кол-во потоков.

качать архивы с пометкой 'rev2'.

зы
Randajad, по поводу бага с распараллеливанием LTO - я не забил.
по поводу бага с функцией snwprintf() - тоже не забил.

Автор: Randajad 10.7.2012, 21:50

А на

Цитата

Забил?

Кстати, что насчет кланга? Вроде, говорил, что вопрос решается. smile

И вообще, добавляйся ваську! Если тебе интересна перспектива, что я буду тебя мучить. :3

Автор: boostcoder 10.7.2012, 22:30

Цитата(Randajad @ 10.7.2012, 21:50

)

Забил?

а про это забыл, да.

Цитата(Randajad @ 10.7.2012, 21:50

)

что насчет кланга?

локально - скрипты написаны. проект тоже создан. нужно собрать первые сборки, и выгрузить на страницу проекта. ну и вроде все.

Цитата(Randajad @ 10.7.2012, 21:50

)

добавляйся ваську!

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

Цитата(Randajad @ 10.7.2012, 21:50

)

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

давай я тебе почту свою сообщу, если еще не знаешь.

Автор: Randajad 11.7.2012, 18:16

Мыло - это грустно.
Насчет %S и %s в представлении gcc: как workaround юзаю функции с _ в начале, они берутся из crt мелкомягких.

Автор: boostcoder 14.7.2012, 00:14

Сегодня состоялся релиз системы сборки https://sourceforge.net/projects/mingwbuilds/ под версией 0.2.0.
В эту версию вошли следующие изменения:

Добавлен ключ --download, выполняющий только загрузку исходников, без сборки.
Добавлен ключ --no-multilib, информирующий систему сборки собрать одноцелевой MinGW.
Добавлен ключ --rev=N, использующийся для указания номера ревизии сборки.
Добавлен ключ --threads=model, использующийся для указания используемой сборкой модели потоков. Доступны: posix/win32. При использовании win32 модели, функционал из http://en.cppreference.com/w/cpp/thread окажется недоступным. (требуется WIN-программер способный дореализовать http://gcc.gnu.org/viewcvs/trunk/libgcc/gthr.h?view=markup)
Добавлен ключ --mingw-compress, использующийся для указания системе сборки сжать собранный MinGW в архив.
Добавлен ключ --srcs-compress, использующийся для указания системе сборки сжать исходники используемые для сборки MinGW в архив.
Добавлен патч исправляющий ошибку, возникающую при генерации компилятором кода эпилога развертывания стека и затирающую WIN32 LastError в этом скопе.
С этого момента, GNU make поставляемый в составе сборок производимых проектом MinGW-builds, собирается с поддержкой job-сервера.
MSYS доступный для загрузки со страницы проекта MinGW-builds обновлен. Добавлен модуль gettext для M4 макропроцессора. (https://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/ архивы с суффиксом 'rev1')

Благодарность коммитерам и тестерам за внесенные изменений и тесты.

Эта версия системы сборки MinGW-builds является последней и завершенной для нативной сборки в windows. Следующими этапами будет внесение необходимых изменений позволяющих использовать MinGW-builds как для сборки нативного MinGW, так и для сборки кросс-MinGW для Linux и OSX хостов.

Автор: Randajad 16.7.2012, 23:40

Использую гцц 4.8 от 2 числа сего месяца, ссылку искать лениво.
Нашлась трабла: у меня много new на мелких объектах, в итоге при некотором большом их числе вылетает bad_alloc. Кто-нибудь сталкивался? При этом еще свободно где-то 2 гига озу, а само приложение всего 70 захавывает.

Буду искать траблу в коде, отпишусь.

Автор: Randajad 17.7.2012, 00:04

LastError == ERROR_NOT_ENOUGH_MEMORY.

С маллоком то же самое.
Вряд-ли это у меня трабла. Но... Наводит на мысли. Попробую замутить test-case.

Автор: boostcoder 17.7.2012, 10:15

ну, мне кажется, что компилятор тут не при чем... и CRT`ишка то же, ибо она не реализует malloc/free.

Автор: bsa 17.7.2012, 12:42

Цитата(boostcoder @ 17.7.2012, 11:15

)

ну, мне кажется, что компилятор тут не при чем... и CRT`ишка то же, ибо она не реализует malloc/free.

именно CRT и реализует malloc/free. Другое дело, что реализация может сводиться только к перенаправлению вызовов на функции WinAPI.

Цитата(Randajad @ 17.7.2012, 00:40

)

у меня много new на мелких объектах, в итоге при некотором большом их числе вылетает bad_alloc

Думаю, ты просто забил всю таблицу распределения памяти (или что-то в этом духе). Тебе необходимо реализовать пул для своих объектов. Именно для этого у каждого STL-контейнера существует возможность замены аллокатора.

Автор: boostcoder 17.7.2012, 13:01

Цитата(bsa @ 17.7.2012, 12:42

)

именно CRT и реализует malloc/free.

CRT от проекта mingw и mingw-w64 не реализуют.

Автор: bsa 18.7.2012, 13:43

Цитата(boostcoder @ 17.7.2012, 14:01

)

CRT от проекта mingw и mingw-w64 не реализуют.

странно. я думал, проект Mingw использует msvcrt.dll в качестве CRT.

Автор: boostcoder 18.7.2012, 14:11

Цитата(bsa @ 18.7.2012, 13:43

)

я думал, проект Mingw использует msvcrt.dll

да, использует. но не реализует.

Автор: bsa 18.7.2012, 15:16

Цитата(boostcoder @ 18.7.2012, 15:11

)

да, использует. но не реализует.

а где тогда определены символы _malloc, _realloc, _free?

Автор: boostcoder 18.7.2012, 15:30

они импортируются из msvcrt.

Автор: bsa 18.7.2012, 15:39

boostcoder, открою тебе секрет, если ты так и не понял: msvcrt.dll - это и есть CRT (C runtime library) для программ собранных mingw. А mingw10.dll и еще одна либа - чисто служебные, необходимые для работы исключений и потоков.

Автор: boostcoder 18.7.2012, 16:05

Цитата(bsa @ 18.7.2012, 15:39

)

msvcrt.dll - это и есть CRT (C runtime library) для программ собранных mingw.

я бы тебе открыл другой секрет. но не хочу тебя позорить.

Автор: Randajad 18.7.2012, 18:25

Спокойнее, спокойнее.
Видимо, действительно некая таблица с выделенными блоками засиралась/затирало ее что. Но почему-то 1024 * 1024 и даже больше new/malloc в debug в попытке сделать test-case успехом не увенчались. Отрефакторил архитектуру, ошибка пропала.
Всем спасибо. :3

Автор: boostcoder 19.7.2012, 10:30

Randajad, касательно бага описанного http://forum.vingrad.ru/forum/topic-353559.html...
я патч закоммитил. приняли. но просят выслать тест в виде маленькой программы, демонстрирующей воспроизведение ошибки без патча, и исправление этой ошибки патчем.
сделай плиз ;)

Автор: Randajad 19.7.2012, 10:42

Да вроде в том топике все есть, и программка и вообще. smile

Или надо что-то еще?

Код


int main() {
   boost::filesystem::exists("FFFFFFFUUUUUUUUUUU");
}

Без патча кидает. С патчем не кидает.

Скомпилированные экзешки надо?

Автор: boostcoder 19.7.2012, 10:59

так без буста же =)
с бустом я мог выслать им тот пример из темы =)

Добавлено @ 11:01
к примеру, первый баг который был связан с TLS, воспроизводится этим тестом.

Код


#include <windows.h>

struct C { ~C() {} };

int Test() {
    C t;
    return ::GetLastError();
}

int main(int, const char**) {
    ::SetLastError(2);

    return Test()-2;
}

вот нужен пример на подобии этого. но я не понимаю как его воспроизвести.

Автор: Randajad 19.7.2012, 12:11

А! О-кей. Сейчас сделаю.

Автор: boostcoder 19.7.2012, 12:16

Цитата(Randajad @ 19.7.2012, 12:11

)

Сейчас сделаю.

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

Автор: Randajad 19.7.2012, 12:53

Код


#include <windows.h>

struct S {
    ~S() {
        SetLastError(123);
    }
};

void foo() {
    S();
}

int main() {
    foo();
    return GetLastError();
}

На старом возвращает 0. На новом 123. Собирать без оптимизаций. smile

Автор: boostcoder 19.7.2012, 12:56

Randajad, спасибо!

Автор: Randajad 14.8.2012, 20:36

Ом-ном-ном!

Код


struct A {
    ~A() {
        throw 0;
    }
};

int main() {
    try {
        A a;
    } catch(...) {}
}

Делает крашик, что печально и не должно быть.

Оффтоп:
Студия на этот код порождает вареник:
warning C4722: 'A::~A' : destructor never returns, potential memory leak

Она врет, да?

Автор: EnergoHokum 15.8.2012, 09:50

Цитата

Она врет, да?

Нет.

Автор: bsa 15.8.2012, 10:35

Randajad, вообще-то, выход исключения из деструктора приводит к аварийному завершению работы программы. Даже, если снаружи стоит отлов исключений.

Автор: Randajad 15.8.2012, 12:41

Не приводит. Кидать исключения из деструктора разрешено. Если было выкинуто другое исключение и какой-нибудь объект при разрушении кидает еще одно исключение - тогда да, краш.

Почему нет? Это разрешено.

Автор: bsa 16.8.2012, 11:17

точно. уже не раз на эти грабли наступаю. просто сделал себе установку - никаких исключений в деструкторах.

Автор: boostcoder 20.8.2012, 14:44

в линукс отрабатывает корректно: http://liveworkspace.org/code/b441e2e80ab1ff2311295569e7eb3407
проверьте кто-нибудь в венде, что выводит?

Автор: Randajad 20.8.2012, 21:11

Цитата

terminate called after throwing an instance of 'int'

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

Автор: boostcoder 20.8.2012, 22:19

Randajad, хм..
предположения?

Автор: Randajad 20.8.2012, 22:51

Ноу предположений.

Автор: boostcoder 26.8.2012, 12:42

задался целью создать онлайн инсталлятор для MinGW-builds и возникло несколько вопросов.

1. как назвать исполняемый файл инсталлятора?
2. какое использовать лого?
3. нужна ли возможность апдейтить установленную версию MinGW? т.е. к примеру узер установил 4.7.1. после, вышла версия 4.7.2. нужна ли возможность заменить установленную 4.7.1 на 4.7.2?

установка предполагается в шесть шагов:
1. указание версии.
2. указание типа сборки(snapshot/prerelease/release).
3. указание архитектуры(i686/x86_64).
4. для релизов допустим выбор ревизии сборки.
5. в получившемся списке указать конкретную сборку.
6. указание каталога установки.

какие будут предложения/мысли?

спасибо.

Автор: bsa 26.8.2012, 15:59

Цитата(boostcoder @ 26.8.2012, 13:42

)

1. как назвать исполняемый файл инсталлятора?

mingw-x.xx-install.exe

Цитата(boostcoder @ 26.8.2012, 13:42

)

2. какое использовать лого?

А какие варианты? Думаю, официальное.

Цитата(boostcoder @ 26.8.2012, 13:42

)

3. нужна ли возможность апдейтить установленную версию MinGW?

И да и нет. Лучше оставить возможность установки одновременно разных версий компилятора в разные каталоги (например: c:\mingw\4.7.1, c:\mingw\4.8.0-pre). Иногда бывает нужно.

Цитата(boostcoder @ 26.8.2012, 13:42

)

1. указание версии.
2. указание типа сборки(snapshot/prerelease/release).

Противоречий тут случаем нет?

Лучше делать через msi пакет. Так будет возможность автоматического развертывания в домене.

Автор: boostcoder 26.8.2012, 16:56