Показаны сообщения с ярлыком gcc. Показать все сообщения
Показаны сообщения с ярлыком gcc. Показать все сообщения

7 апреля 2011 г.

Вышел GCC 4.6.0

Вышел первый стабильный резиз GCC 4.6.

Помимо улучшений в оптимизаторе еще примечательны следующие изменения:

  • Появилась поддержка языка Go
  • Появилать новая опция предупреждений -Wsuggest-attribute, которая сообщает, что добавление к функциям атрибутов pure, const или noreturn может улучшить кодогенерацию
  • Новая прагма #pragma GCC diagnostic упрощает управление предупреждениями компилятора прямо из кода
  • Ну и в случае, когда какой-то идентификатор не найден в коде, g++ теперь предлагает свои варианты, которые на его взгляд кажутся наиболее подходяшими

Полный список изменений и нововведений можно почитать здесь: http://gcc.gnu.org/gcc-4.6/changes.html

22 ноября 2010 г.

Проблемы линковки библиотек clang и llvm

При линковке приложения с библиотеками clang и llvm может возникнуть такая проблема, что нужно передавать линковщику список библиотек в строгом порядке, иначе может возникнуть ошибка "undefined reference" даже если нужная библиотека указана в параметрах линковки. (Как здесь, например. Правда, там у человека еще и строка линковки некорректна.)

Пример:

$ g++ -o ./a.out main.o `llvm-config --ldflags` -lclangFrontend -lclangBasic -lclangDriver -lclangSerialization -lclangCodeGen -lclangSema -lclangChecker -lclangAnalysis -lclangIndex -lclangRewrite -lclangAST -lclangParse -lclangLex `llvm-config --libs`

libclangParse.a(Parser.o): In function `clang::Parser::ExpectAndConsume(clang::tok::TokenKind, unsigned int, char const*, clang::tok::TokenKind)':
Parser.cpp:151: undefined reference to `clang::tok::getTokenSimpleSpelling(clang::tok::TokenKind)'
libclangLex.a(Preprocessor.o): In function `clang::Preprocessor::DumpToken(clang::Token const&, bool) const':
Preprocessor.cpp:155: undefined reference to `clang::tok::getTokenName(clang::tok::TokenKind)'
collect2: ld returned 1 exit status



Все нужные библиотеки указаны, но не в том порядке, в каком хотелось бы линковщику. Проблема в том, что линковщик ищет в каждой библиотеке по одному разу и именно в том порядке, в каком они указаны в командной строке. Например, символ clang::tok::getTokenName находится в библиотеке libclangBasic.a, которая в списке линковки указана раньше.

Можно попытаться поискать правильный порядок (долгая и неблагодарная работа), а можно воспользоваться возможностью группировки библиотек:

$ g++ -o ./a.out ../build/obj/testclang.o `llvm-config --ldflags` -lgtest -lgtest_main -Wl,--start-group -lclangFrontend -lclangBasic -lclangDriver -lclangSerialization -lclangCodeGen -lclangSema -lclangChecker -lclangAnalysis -lclangIndex -lclangRewrite -lclangAST -lclangParse -lclangLex `llvm-config --libs` -Wl,--end-group

Линковщик будет перебирать библиотеки, указанные между ключами --start-group и --end-group снова и снова, пока не отыщет все требуемые символы.

Теперь всё ОК.

9 ноября 2010 г.

g++ 4.5 и clang

В Ubuntu 10.10 уже входит gcc 4.5, и я вчера решил собрать clang из репозитория. Всё было хорошо, пока процесс линковки не сожрал полтора гигабайта памяти. После этого он был торжественно убит системой, потому что у меня для виртуалки выделено всего полтора гигабайта. Попробовал собрать с gcc 4.4 — собрался без проблем.

Жаль, но gcc 4.5 всё-таки еще сыроват.

UPD: Смог добиться того, чтобы gcc 4.4 тоже сожрал больше 1,5 Гб. Для этого нужно включить дебаг-режим, включить ассерты и expensive checks, и выключить оптимизатор. Но это, конечно, извращение.

Еще жаль, что clang нельзя собрать без сборки llvm. Или я чего-то не знаю?

9 сентября 2009 г.

Ubuntu и g++ 3.4

У меня стоит Ubuntu 9. Понадобился компилятор g++ 3.4. А его нет на Ubuntu. gcc 3.4 — есть, а g++ — нет. Нет, и не будет.

В том же форуме предлагают способ — скачать дебиановские пакеты и установить. Но обнаружилось две проблемы. Первая — эти пакеты старые и их установка сносит крышу убунтовскому менеджеру обновлений. Чтобы восстановить его работоспособность, эти пакеты нужно удалить. Вторая — компилятор-то установился. Но то ли из-за несовместимости версий пакетов, то ли еще из-за чего, но мои сборки рушатся и падают, если я использую g++ 3.4.

В конце концов мне это надоело, я удалил все неродные пакеты и скачал отсюда два архива с исходниками — gcc-core-3.4.6.tar.bz2 и gcc-g++-3.4.6.tar.bz2. Всё собралось на ура и отлично работает. Единственное "но" — собирать нужно c помощью gcc-3.4 (он-то в системе уже есть).

7 сентября 2009 г.

Предупреждения GCC ч.2

Наткнулся тут в тексте статьи на Хабре:
...посмотрим внимательно на вывод компилятора при максимально включенных предупреждениях

$ g++ -W -Wall test.cpp

К самой статье это отношения не имеет, но хочется заметить, что заблуждение насчет максимально включенных предупреждений компилятора встречается довольно часто — -Wall и -Wextra (-W) это еще не все предупреждения. К сожалению, путаница по большей части возникает из-за разработчиков GCC. Начать с того, что имя опции -Wall само по себе вводит в заблуждение, так они еще добавляют или удаляют предупреждения от версии к версии, или вообще меняют их смысл, чем лично меня иногда просто ставят в тупик. Но надо отдать им должное — компилятор все-таки развивается, и сейчас с помощью предупреждений можно узнать гораздо больше, чем в более ранних версиях.

Например, в последней версии GCC (4.4) есть полезные предупреждения, которые нужно включать самостоятельно:
  • -Wcast-qual
    Предупреждает о преобразованиях типа "из const char * в char *".
  • -Wconversion
    Предупреждает, если при преобразовании типов может произойти потеря данных. Например, при преобразовании из long в short.
  • -Wredundant-decls
    Предупреждает об повторном объявлении чего-нибудь в той же области видимости, даже если это ни на что не влияет.
  • -Wshadow
    Предупреждает, если объявление переменной перекрывает объявленную ранее переменную с таким же именем.
  • -Wsign-conversion
    Предупреждает, если результат выражения может изменить знак. Например, при преобразовании из int в unsigned int.
  • -Wunreachable-code
    Предупреждает, если какой-то фрагмент кода никогда не будет выполнен. Например, если перед этим фрагментом стоит return. Этот флаг специально не был включен в группу -Wall для того, чтобы можно было разделять сборки debug и release.

И еще некоторые другие:
  • -Wcast-align
  • -Wformat-nonliteral
  • -Wformat-security
  • -Wformat-y2k
  • -Winit-self
  • -Wlogical-op
  • -Wmissing-format-attribute
  • -Wmissing-include-dirs
  • -Woverlength-strings

30 апреля 2009 г.

Кстати о GCC

Неделю назад вышла очередная версия компилятора GCC — 4.4.

В новой версии расширены возможности оптимизации кода, ключ -Wconversion теперь выводит предупреждение при некорректных попытках привести целочисленный тип к enum, а также включена экспериментальная поддержка стандарта C++0x. И много чего другого не менее интересного...

suncc в качестве подручного инструмента

Сейчас многие компиляторы умеют оптимизировать код, но, к сожалению, далеко не все из них умеют делать это хорошо. Например, GCC оптимизирует код довольно посредственно. Поэтому хочется писать код так, чтобы при одновременном использовании в проекте нескольких компиляторов код был максимально эффективным для любого из них.

Наверное, самый лучший способ достичь этого — изучать алгоритмы и приемы оптимизации кода. Но будь ты хоть семи пядей во лбу, когда рядом есть "подручные средства" — грех не воспользоваться ими.

Я хочу рассказать, как использовать компилятор Sun для того, чтобы повысить производительность вашего кода. У этого компилятора есть замечательная особенность — при выполнении оптимизации он может вставлять свои комментарии в объектные файлы, которые можно потом использовать для дальнейшего улучшения кода. Компилятор Sun прилагается к пакету Sun Studio, который является бесплатным и доступен для скачивания с http://developers.sun.com

В качестве примера рассмотрим простую программу:

int main ()
{
  int c = 0;
  int size = 10000;
  int *a = new int[size * size];

  for (int i = 0; i < size; ++i)
  {
    for (int j = 0; j < size; ++j)
    {
      a[j * size + i] = c++;
    }
  }

  delete [] a;
  return 0;
}

Эта программа создает квадратную матрицу размером size на size, и заполняет ее числами от 0 до N по столбцам. Для матрицы 10 на 10 это будет выглядеть так:

0 10 20 30 40 50 60 70 80 90
1 11 21 31 41 51 61 71 81 91
2 12 22 32 42 52 62 72 82 92
3 13 23 33 43 53 63 73 83 93
4 14 24 34 44 54 64 74 84 94
5 15 25 35 45 55 65 75 85 95
6 16 26 36 46 56 66 76 86 96
7 17 27 37 47 57 67 77 87 97
8 18 28 38 48 58 68 78 88 98
9 19 29 39 49 59 69 79 89 99

Проход по столбцам матрицы заведомо неэффективен, поэтому на такой программе должны быть хорошо видны результаты оптимизации. Попробуем замерить усредненное время выполнения программы для size=10000, скомпилированной с помощью g++ и sunCC:

g++ без оптимизации (g++ -O0 a.cpp): 2.6 сек
g++ c оптимизацией (g++ -O2 a.cpp): 2.0 сек

sunCC без оптимизации (sunCC a.cpp): 3.2 сек
sunCC c оптимизацией (sunCC -fast a.cpp): 0.4 сек


Опция -fast в suncc анализирует окружение и подбирает набор опций компилятора для максимального быстродействия. Видно, что sunCC в режиме оптимизации дает результаты в разы лучше, чем g++. А именно — в 5 раз. Хм...

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


Давайте посмотрим, что же делает sunCC при оптимизации. Для этого необходимо использовать при компиляции опцию -g0. Эта опция сохраняет в объектном файле отладочную информацию (в том числе и комментарии компилятора), но не запрещает инлайнить функции. Для просмотра комментариев нужно использовать программу er_src, которая также поставляется с Sun Studio.

$ sunCC -g0 -fast a.cpp
$ er_src a.o

Source file: ./a.cpp
Object file: ./a.o
Load Object: ./a.o

1. int main ()

2. {
3. int c = 0;
4. int size = 10000;
5. int *a = new int[size * size];
6.

Source loop below has tag L1
Induction variable substitution performed on L1
L1 interchanged with L2


7. for (int i = 0; i < size; ++i)
8. {

Source loop below has tag L2
Induction variable substitution performed on L2
L2 interchanged with L1


9. for (int j = 0; j < size; ++j)
10. {
11. a[j * size + i] = c++;
12. }
13. }
14.
15. delete [] a;
16. return 0;
17. }

Итак, что же мы видим? Компилятор обнаружил в программе два цикла L1 и L2, которые поддаются оптимизации, о чем и сообщил в комментариях. Давайте попробуем улучшить программу, используя подсказки компилятора.

Подсказка "Induction variable substitution performed" говорит нам о том, что компилятор обнаружил индукционную переменную и произвел ее замену. Это значит, что значение какой-то переменной может быть вычислено через значения итераторов циклов. После недолгого изучения кода заменяем строку "a[j * size + i] = c++;" строкой "a[j * size + i] = i * size + j;". И прогоняем компиляцию еще раз.

Видим, что сообщение об индукционной переменной пропало, но осталось другое сообщение: "L1 interchanged with L2". Это сообщение говорит нам о том, что компилятор поменял циклы местами, то есть заменил проход по столбцам проходом по строкам матрицы. Меняем циклы местами и снова прогоняем компиляцию. И убеждаемся, что сообщения о том, что компилятор что-то оптимизировал, пропали. То есть, оптимизировать больше нечего.

После наших изменений программа приняла вот такой вид:

int main ()
{
  int c = 0;
  int size = 10000;
  int *a = new int[size * size];

  for (int j = 0; j < size; ++j)
  {
    for (int i = 0; i < size; ++i)
    {
      a[j * size + i] = i * size + j;
    }
  }

  delete [] a;
  return 0;
}

Давайте теперь замерим время выполнения программы после всех наших изменений:

g++ без оптимизации (g++ -O0 a.cpp): 1.0 сек
g++ c оптимизацией (g++ -O2 a.cpp): 0.4 сек

sunCC без оптимизации (sunCC a.cpp): 0.6 сек
sunCC c оптимизацией (sunCC -fast a.cpp): 0.4 сек


На мой взгляд, получилось просто прекрасно! :)

Подробнее почитать о комментариях компилятора Sun можно здесь: http://docs.sun.com/app/docs/doc/819-5264/afapn?a=view

1 апреля 2009 г.

Предупреждения GCC

Как я уже писал, компилятор gcc-4.3 умеет сообщать о потенциальной потере данных при преобразовании типов.

В дополнение к этому, в версии 4.3 появилось предупреждение о том, что объявление вида 'char *str = "abcd";' устарело и больше не должно использоваться. Причем предупреждение появляется даже без флагов -Wall, -Wextra и прочих. Как известно, использование в программе таких объявлений может привести к непредсказуемым последствиям. Вместо этого нужно использовать 'const char *str = "abcd";'. И это правильно.

UPD: Несмотря на дату, это не шутка :)

20 марта 2009 г.

Использование GCOV: ошибка при линковке

При сборке программы с включенными опциями для GCOV можно получить ошибку на этапе линковки следующего вида:
/usr/bin/ld: ./a.out: hidden symbol `__gcov_merge_add' in /usr/lib/gcc/i486-linux-gnu/4.1.3/libgcov.a(_gcov_merge_add.o) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output

Скорее всего причина заключается в том, что к исполняемому модулю линкуются библиотеки, которые тоже были скомпилированы с опциями -fprofile-arcs -ftest-coverage.

Простой пример, иллюстрирующий проблему.

Даны два файла:

=== a.cpp
#include <stdio.h>

extern unsigned long myfunc ();

int main (int argc, char **argv)
{
  unsigned long z = myfunc();
  printf("%08x\n", z);
  return 0;
}

=== b.cpp
#include <time.h>

unsigned long myfunc ()
{
  return time(0);
}


Из файла b.cpp делаем статическую библиотеку libmy.a, а из файла a.cpp — исполняемый модуль a.out:

g++ -c -fprofile-arcs -ftest-coverage b.cpp
g++ -shared -o libmy.a ./b.o
g++ -c -fprofile-arcs -ftest-coverage a.cpp
g++ -o a.out a.o -L. -lmy


Получаем ошибку вида "undefined reference to `__gcov_init'" — забыли подключить библиотеку libgcov.a.

Подключаем к сборке требуемую библиотеку как обычно:

g++ -c -fprofile-arcs -ftest-coverage b.cpp
g++ -shared -o libmy.a ./b.o
g++ -c -fprofile-arcs -ftest-coverage a.cpp
g++ -o a.out a.o -L. -lmy -lgcov


Вот здесь-то и получаем странную ошибку:

/usr/bin/ld: ./a.out: hidden symbol `__gcov_merge_add' in /usr/lib/gcc/i486-linux-gnu/4.1.3/libgcov.a(_gcov_merge_add.o) is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output


Исправить это просто. Нужно подключить библиотеку libgcov.a не только к сборке исполняемого модуля, но и к сборке статической библиотеки:

g++ -c -fprofile-arcs -ftest-coverage b.cpp
g++ -shared -o libmy.a ./b.o -lgcov
g++ -c -fprofile-arcs -ftest-coverage a.cpp
g++ -o a.out a.o -L. -lmy -lgcov


Вот и всё. Так нужно поступить с каждой библиотекой, исходный код которой скомпилирован с опциями -fprofile-arcs -ftest-coverage.

20 октября 2008 г.

GCC и precision loss

В процессе портирования нашего линуксового проекта на Windows обнаружилась интересная вещь: наш компилятор GCC не умеет распознавать ситуации с присвоением из long в short и им подобные. То есть, распознавать, скорее всего, умеет, а вот сообщать о них — нет.

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

int main (int argc, char **argv)
{
  unsigned long a = 0xFFFFFFFE;
  unsigned char b = a + 1;
  return 0;
}

Я, честно говоря, был немало удивлен. Специально этим вопросом не занимался, но был уверен, что такие ситуации GCC отслеживать умеет. Ан нет... Что самое интересное, большинство моих знакомых гуру тоже были в этом уверены. В нашем проекте, как и во многих других, известных мне проектах, используется GCC 4.1.2, некоторые используют 4.2. Вроде бы есть опция -Wconversion, но работает она только для fixed и floating point. В общем, подстава.

Думаю, что о важности такого предупреждения говорить не нужно. В MSVC++ эта ситуация легко отслеживается включением третьего уровня предупреждений — /W3. После портирования нашего проекта на MSVC++, мы смогли легко локализовать и исправить несколько ошибок, связанных как раз с некорректным преобразованием типов.

Но самое интересное не в этом. После длительного изучения документации по GCC, все-таки нашел :)

Итак, не прошло и 25 лет, как разработчики GCC все таки прониклись пользой отслеживания размерности типов. Начиная с версии 4.3 (первый релиз вышел в марте 2008 года, то есть, всего полгода назад) GCC умеет распознавать и сообщать о ситуациях с присваиманием из long в char и им подобных.

Опция -Wconversion, которая работала только для fixed и floating point теперь разделена на две опции -Wtraditional-conversion и -Wconversion. Подробности можно почитать здесь http://gcc.gnu.org/wiki/NewWconversion

Я проверил — на приведенный пример ругается "warning: conversion to ‘short unsigned int’ from ‘long unsigned int’ may alter its value". Аллелуйа!

Ура, товарищи! Даешь новые версии! Даешь новые баги! :)