openSUSE:Сообщить об ошибке gcc
Отчёты об ошибках в gcc
Ну, нам собственно нужно три вещи, чтобы знать об ошибках в gcc:
- тесты
- тесты
- и вы не поверите, тесты
Тесты
Тесты — это нечто короткое. Это не значит, залезь на тот сайт, стяни ту фиговину, скомпилируй и посмотри ошибки Хороший тест состоит из одного замкнутого файла. Только подумайте один файл! Это значит, не включая ничего абсолютно. Следовательно это должно быть препроцессом. Препроцесс с:
gcc -E [other options ...] source.c > source.i
Или используем -save-temps. В C++ препроцессные файлы называются source.ii.
Кроме того, это должно коротким. Файл может содержать только источник, который показывает ошибки. Никаких дополнительных функций и примочек. Удалите все не существующие блоки. Сначала удаляйте целые функции, потом наикрутейшие примочки, т.е. упрощая функцию, на которой эта ошибка происходит. Удалите не существующие структуры и классы, вероятно это потребует изменений в коде. Будет хорошо, если ошибка будет показываться в течении длительного времени. Помните, что только необходимые нам функции откомпилированы. Статическая, не откомпилированная, функция не используется новыми GCCs. Следовательно надо сделать функцию не статической :).
Что-либо больше 200 потоков не даст нужного эффекта. Лучше использовать 100 для эффективной информации об ошибках. Что-либо содержащее более 3-х функций, также осложнит процесс. Это труднее и на это потребуется много времени, если же вам так хочется, то рекомендуется исследовать кусками. Это означает, что вы могли бы смотреть ваши отчёты постепенно.
Главный совет
Хороший отчёт, должен соответствовать стандарту, дабы другим было удобно работать с ним:
Перед тем как компилить это: source code или присоединение с этой командой: % gcc [ваши параметры] bla.i будет означать: <outcome> с этой системой: <gcc -v output> <uname -a output> По идее должно получится так: <expected outcome> из-за <Причина, по которой вы так думаете :)>.
Иногда ожидаемый результат очевиден и не стоит его упоминать. Например, если Вы сообщаете внутреннюю ошибку компилятора, ожидаемый результат «замораживания» конечно не случится. Просто нет необходимости упоминать об этом. Если вы подозреваете, что компиляция пройдёт плохо, разработайте тестинг на время прогона теста, который имеет более видимый эффект (например, прерывая, когда неправильный результат вычислен, или печатая результат, говорить о том что вы должны были это предусмотреть).
Пожалуйста вставляйте точные командные потоки для использования, вставляйте -v выход и -a выход. Мы не хотим компилировать с -O2, т.е. описание наших слов, когда проще скомпилить с помощью# gcc -c -O2 -fPIC -всякие параметры bla.i, причём команда скопирована из терминала.
Не забывайте системные установки и настройки.
Хорошо бы иметь
Мы используем компиляторы, которые обычно имеют изменения на верхней части FSF GCC. Но это — все еще часто случается, FSF GCC показывает точно ту же ошибку. Если Вы в состоянии проверять это, тогда пожалуйста сообщите дефект непосредственно на bugzilla GCC.