На чем написан gcc

Unix как IDE: Компиляция

Под Unix существует множество компиляторов и интерпретаторов, но здесь мы будем обсуждать лишь gcc как средство компиляции C-кода, и коротко коснемся использования perl в качестве примера интерпретатора.

GCC — это набор компиляторов, обладающий очень почтенным возрастом и распространяемый под лицензией GPL. Он известен как инструмент работы с программами на C и C++. Свободная лицензия и повсеместная распространенность на Unix-подобных системах стали залогом его неизменной популярности, хотя есть и более современные альтернативы, использующие инфраструктуру LLVM, такие как Clang.

Основной исполняемый файл gcc лучше представлять не как компилятор в привычном понимании, а слой абстракции над множеством отдельных инструментов программирования, выполняющих парсинг кода, компиляцию, линковку и другие действия. Это значит, что с его помощью можно не просто получить работающий бинарник из кода на C, но детально исследовать все шаги этого сложного процесса, и при необходимости подстроить его под свои нужды.

Здесь я не буду обсуждать использование make-файлов, хотя они наверняка понадобятся для любого проекта сложнее, чем в один файл. Make-файлов я коснусь в следующей статье о средствах автоматизации сборки.

Компиляция и сборка объектного кода

Объектный код компилируется вот такой командой:

Если код верен, будет создан нелинкованный двоичный объектный файл под именем example.o в текущей папке, или выведены сообщения о проблемах. Заглянуть внутрь полученного файла и увидеть его содержимое на языке ассемблера можно так:

Как вариант, можно попросить gcc сразу показать итоговый ассемблерный код при помощи параметра -S:

Вывод ассемблерного кода может быть полезно совместить с выводом самого исходника, чего можно добиться, набрав:

Препроцессор

Препроцессор C (cpp) обычно используется для подключения заголовочных файлов и определения макросов. Это стандартная часть процесса компиляции gcc, но можно просмотреть генерируемый им код, вызвав cpp напрямую:

Исходный код будет выведен в конечном виде, готовым к компиляции, с замененными макросами и подстановкой включаемых внешних файлов.

Связывание объектов

Один или несколько объектных файлов могут быть связаны в соответствующий исполняемый файл:

Компиляция, сборка и связывание

Все вышеперечисленное может быть выполнено в один шаг при помощи команды:

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

Включение внешних файлов и связывание

Файлы C и заголовочные файлы могу быть явно включены в компиляцию при помощи параметра -l:

Аналогично, если код нужно динамически связать с уже скомпилированной системной библиотекой, доступной в одной из системных папок ( /lib или /usr/lib ), например, ncurses, этого можно добиться использованием ключа -l:

Если в процессе компиляции внешних связей много, имеет смысл внести их в переменные окружения:

Кстати, Makefile затем и создан, чтобы избавить нас от беспокойства о таких мелочах.

План компиляции

Чтобы посмотреть подробности внутренней кухни gcc, можно добавить ключ -v, и план компиляции будет выведен в стандартный поток вывода ошибок:

Если нет нужды генерировать объектные или исполняемые файлы, то для аккуратности можно использовать -###:

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

Расширенный вывод сообщений об ошибках

Существует возможность добавить ключи -Wall и/или -pedantic, чтобы gcc предупреждал нас о случаях, которые не обязательно являются ошибками, но могут ими быть:

Удобно включать такие опции в Makefile или в определении makeprg для Vim, так как они отлично сочетаются с окном quickfix, и помогают писать читабельный, совместимый и безошибочный код.

Профилирование процесса компиляции

Вы можете включить опцию -time, чтобы gcc отображал в тексте вывода время выполения каждого из шагов:

Оптимизация

Подобно любой команде Bash, все это можно вызывать прямо из Vim:

Интерпретаторы

Подход к интерпретируемому коду в Unix-системах иной. В своих примерах я буду использовать Perl, но те же принципы применимы для кода, например, на Python или Ruby.

Inline-код

Можно строку Perl-кода прямо на исполнение интерпретатору любым из перечисленных ниже способов Первый, наверное, самый простой и общеупотребительный способ работы с Perl; второй использует синтаксис heredoc, а третий — это классический конвейер Unix.

Конечно, в будничной жизни мы храним код в файле, который можно вызвать прямо вот так:

Можно проверить синтаксис кода без его выполнения с помощью ключа -c:

Порой хочется использовать скрипт подобно любому исполняемому бинарнику, не беспокоясь о том, что он из себя представляет. Для этого в скрипт добавляют первой строкой так называемый «shebang«, указывающий путь к интерпретатору, которому следует передать на исполнение данный файл.

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

Затем файл можно вызывать напрямую, без указания интерпретатора:

Вся эта кухня так здорово работает, что многие стандартные утилиты Linux-систем, такие как adduser, в действительности являются скриптами на Perl или Python.

В следующей публикации я расскажу о методах работы с make для сборки проектов, сравнимых с привычными IDE.

Источник

GNU Compiler Collection, первые шаги

Эта заметка призвана на простых примерах познакомить начинающего nix-разработчика с инструментами GNU, в частности с компилятором GCC.

С его помощью мы и создадим простейшую программу. По большому счету все, как обычно. Заводим специальную папку, в которой будет размещаться проект.
Создаем в ней файл с именем: hello.c
Открываем файл в любом текстовом редакторе и пишем простейший код:

#include
int main(void)
<
printf(«Hello world!»);
return(0);
>

Сохраняем файл и выполняем команду: gcc hello.c

В созданной нами папке появился новый файл — a.out, это название присваивается по умолчанию, если специально не задано другого.

И радуемся в связи с первой написанной программой в линуксе!

Идем далее. При запуске исполняемого файла, если мы укажем только его название, система будет искать его в каталогах /usr/bin и /usr/local/bin, и, естественно, не найдет. Первый из них предназначен для размещения стабильных версий программ, как правило, входящих в дистрибутив Linux. Второй – для программ, устанавливаемых самим пользователем (за стабильность которых никто не ручается). По умолчанию, при сборке программы, устанавливаются в каталог /usr/local/bin.

Флаги используемые при компиляции

Название получаемого файла такое же, но компилятор изменяет расширение .c на .o (но указать можно и вручную).

Флаг -x используем, если создаётся объектный файл из исходника, уже обработанного препроцессором (например такого, какой мы получили выше), мы должны обязательно указать явно, что компилируемый файл является файлом исходного кода, обработанный препроцессором, и имеющий теги препроцессора. В противном случае он будет обрабатываться, как обычный файл C++, без учёта тегов препроцессора, а значит связь с объявленными функциями не будет устанавливаться.

Для чего нужна вся эта возня с промежуточными этапами?
Программы редко состоят из одного файла. Как правило исходных файлов несколько, и они объединены в проект. И в некоторых исключительных случаях программу приходится компоновать из нескольких частей, написанных, возможно, на разных языках. В этом случае приходится запускать компиляторы разных языков, чтобы каждый получил объектный файл из своего исходника, а затем уже эти полученные объектные файлы компоновать в исполняемую программу.

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

GNU Compiler Collection

Содержание

Обзор

В настоящее время GCC поддерживается группой программистов со всего мира. GCC является лидером по количеству процессоров и операционных систем, которые он поддерживает.

Будучи официальным компилятором системы GNU, GCC также является главным компилятором для сборки ряда других операционных систем; среди них — различные варианты Linux и Berkeley Software Distribution|BSD, а также ReactOS, Mac OS X, OpenSolaris, NeXTSTEP, BeOS и Haiku.

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

Языки

В версии 4.1.1 (выпущенной 24 мая 2006 года стандартный компилятор включал в себя front-end’ы для языков:

Front end для CHILL был добавлен ранее, но из-за недостаточной поддержки был исключён из набора. До выхода версии 4.0 front-end’ом для Fortran был G77, который поддерживал лишь FORTRAN 77. В новых версиях G77 был исключён в пользу нового GFortran frontend, который поддерживает Fortran 95.

Также существуют front-end’ы для Паскаль (язык программирования)|Pascal, D, Modula-2, Modula-3, Mercury, VHDL и PL/I.

Архитектуры

Список поддерживаемых GCC (для версии 4.3) процессоров включает в себя:

Менее известные процессоры, поддерживаемые в стандартном релизе:

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

Структура

Внешний интерфейс GCC является стандартом для компиляторов на платформе UNIX. Пользователь вызывает управляющую программу, которая называется gcc. Она интерпретирует аргументы командной строки, определяет и запускает для каждого входного файла свои компиляторы нужного языка, запускает, если необходимо, ассемблер и компоновщик.

Компилятор каждого языка является отдельной программой, которая получает исходный текст и порождает вывод на язык ассемблера|языке ассемблера. Все компиляторы имеют общую внутреннюю структуру: front end, который производит синтаксический разбор и порождает абстрактное синтаксическое дерево, и back end, который конвертирует дерево в Register Transfer Language (RTL), выполняет различные оптимизации, затем порождает программу на языке ассемблера, используя архитектурно-зависимое сопоставление с образцом.

Отладка программ, скомпилированных с помощью GCC

Главным инструментом для отладки программ, скомпилированных с помощью GCC, является GNU Debugger (gdb). Существуют также узкоспециализированные средства для отладки:

Лицензия

GCC версии 4.2.1 стал последним релизом, выпущенным под GNU General Public License версии 2. Все последующие версии лицензируются по [[GNU General Public License#GPL v3|GPL версии 3].

Критика

Обзор GCC 4.8

С выпуском GCC 4.8.0 разработчики набора компиляторов GNU Compiler Collection завершили переход на C++ в реализации GCC. Работа по переводу кодовой базы на C++ продолжалась c 2008 года, и теперь подошла к концу. Миграция на C++ означает, что теперь для сборки GCC из исходников обязательно требуется компилятор С++ 2003. Ричард Столлман написал первый вариант GCC в 1985 году на непереносимом диалекте языка Паскаль. В 1987 году компилятор был переписан на языке Си, и в таком виде существовал до 2013 года.В новой версии GCC 4.8 улучшена производительность, реализован новый уровень оптимизации –Og для сверхбыстрой компиляции почти без оптимизаций. Добавлены детектор ошибок в памяти Address Sanitizer от компании Google и детектор гонок данных Thread Sanitizer, который обнаруживает совместный доступ к одним и тем же данным из различных нитей многопоточного приложения. Более подробно о нововведениях см. release notes.Детектор Address Sanitizer можно использовать на платформах Linux (IA-32, x86-64, x32, PowerPC, PowerPC64) и Darwin (x86-64), при этом скорость работы программы замедляется примерно в два раза.Детектор Thread Sanitizer замедляет скорость примерно в 10 раз.Кроме того, в GCC 4.8 улучшена поддержка C++11 и появилась поддержка архитектуры AArch64(ARM64), присутствующей в процессорах с набором команд ARMv8, хотя на рынке пока нет устройств с таким набором команд.GCC — официальный компилятор системы GNU, он также является главным компилятором для ряда других операционных систем, в том числе разных вариантов Linux и BSD, Mac OS X, ReactOS, BeOS и проч. Подробнее о причинах миграции на C++ и конкретно о внесённых изменениях см. в GCC Wiki: C++ Conversion. Вкратце, причина в популярности языка C++ и более чистом коде на «плюсах».

К счастью, переход на C++ практически не отразился на производительности компиляторов GCC. [Источник 2]

Установка GCC на Debian Linux

Источник

Компиляция и компоновка с помощью GNU Compiler Collection (GCC)

В состав GCC входят:

В состав GCC не входят:

Тем не менее, они необходимы для компиляции программ на Си, ввиду чего будут рассмотрены наряду с инструментами GCC. Команда запуска GCC для языка Си в общем виде выглядит следующим образом:

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

Схема трансляции программ написанных на Си

Трансляция программы состоит из следующих этапов:

Препроцессирование.

Трансляция в ассемблер.

Ассемблирование.

Компоновка.

Компоновщик получает на вход набор объектных файлов, соответствующим единицам трансляции, составляющим программу, подключает к ним стандартную библиотеку языка Си и библиотеки, указанные пользователем, и на выходе получает исполняемую программу.

Запуск транслятора gcc

Рассмотрим основные возможности транслятора GNU Си. В командной строке задаётся список файлов для обработки. Какие операции необходимо выполнить с файлами – зависит от суффикса имен файлов. Возможные суффиксы перечислены в таблице ниже. Если имя файла имеет нераспознанный суффикс, это имя передаётся компоновщику

Действия по трансляции файла определяются для каждого указанного в командной строке файла индивидуально. Например, если в командной строке указаны имена файлов 1.c и 2.o, то для первого файла будут выполнены все шаги трансляции, а для второго – только компоновка. Исполняемый файл будет содержать результат трансляции первого файла, скомпонованный со вторым файлом и стандартными библиотеками.

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

Например, командная строка

транслирует два файла на языке Си, объединяя их в одну программу с именем 1.

Использование стандартных библиотек языка Си

В языках Си и Си++ библиотеки состоят из двух частей:

Заголовочных файлов, содержащих объявления типов данных, констант, прототипов функций и внешних переменных, которые подключаются к исходным файлам на этапе препроцессирования, формируя единицы трансляции.

Заголовочные файлы стандартной библиотеки находятся в каталоге /usr/include и его подкаталогах, например, /usr/include/stdio.h или /usr/include/sys/types.h. Программа-драйвер gcc автоматически добавляет этот каталог в список для поиска заголовочных файлов, поэтому каталог /usr/include не нужно задавать в опции –I.

Файлы динамических библиотек размещаются в каталоге /lib или /usr/lib, а файлы статических библиотек – в каталоге /usr/lib. Они задаются автоматически и опция –L для них не нужна. Файл динамической библиотеки языка Си называется libc.so и полный путь к нему – /lib/libc.so.

Таким образом, если выписать явно пути и библиотеки, задаваемые при компиляции программы на Си с помощью gcc неявно, мы получим примерно следующую командную строку:

Компоновка программы

Если исполняемая программа компонуется из нескольких единиц трансляции, компоновщик использует свои правила видимости имён, которые приведены ниже:

Последнее правило можно продемонстрировать на следующем примере. Предположим, что в трёх файлах определена переменная var следующим образом:

Если все три единицы компиляции объединяются в одну программу, то переменная var каждого из трёх файлов будет располагаться по одному и тому же адресу, и каждая из трёх функций будет работать, по сути, с общей переменной. Чтобы предотвратить такое слияние переменных можно использовать явную инициализацию переменной var, тогда компоновщик выдаст сообщение об ошибке как показано ниже.

Видимость глобальных переменных при компоновке можно также регулировать с помощью спецификаторов класса памяти extern и static. Спецификатор extern запрещает компилятору выделять память под переменную в данном модуле. Спецификатор static локализует область видимости переменной единицей трансляции, в которой она определена.

Программы из нескольких единиц трансляции

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

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

Чем больше переменных объявлено в единице компиляции с классом памяти static вместо класса памяти по умолчанию, тем лучше. Программа может быть легче модифицирована, если доступ к данным всегда происходит с помощью вызовов функций. Чем меньше «чужих» переменных использует некоторая единица компиляции, тем она проще для понимания.

В заголовочном файле помещаются макроопределения и типы данных, являющиеся интерфейсом данной единицы компиляции, то есть необходимые для использования функций и переменных этой единицы компиляции. С классом памяти extern помещаются необходимые переменные и прототипы функций, объявленные в соответствующей единице компиляции.

В заголовочный файл никогда не помещаются определения переменных с классом памяти, отличным от класса extern, и тела функций. В заголовочный файл никогда не помещаются прототипы функций с классом памяти static. Если некоторый тип или константа используются только в теле какой-либо функций и не требуется для корректного использования функциональности данной единицы компиляции другими модулями, этот тип или константа также не помещаются в заголовочный файл.

Источник

На чём пишут компиляторы?

На чем пишут презентационные диски?
Подскажите ПЛИЗЗЗ на чем обычно пишут презентационные диски. Причем нужно что-нибудь такое что.

В чем пишут на C?
Ребят, в какой системе программирования пишут на чистом C?

На чем пишут приложения
Вот и суть, на чем пишкт приложения дл айос? и если я хочу написать, то смогу протестить на свое.

. объясняю на пальцах для одаренных :

Только вместо ожидаемого кода самого компила по ссылке предлагаются примеры фрагментов компилируемых программ.

Добавлено через 1 минуту
Причём, gcc у меня установлен, но как заглянуть в его исходник, я всё равно не понимаю.

Только вместо ожидаемого кода самого компила по ссылке предлагаются примеры фрагментов компилируемых программ.

Причём, gcc у меня установлен, но как заглянуть в его исходник, я всё равно не понимаю.

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

Здесь исходника самого компила тоже не видно.

Добавлено через 1 минуту

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

GCC: Anonymous read-only SVN access

Our SVN source repository is available read-only to the public at large. That way you can pick up any version (including releases) of GCC that is in our repository.

Our web pages are still maintained via CVS, and can be accessed using the directions for our CVS setup.

In addition you can browse our SVN history online.
Using the SVN repository

Assuming you have version 1.0.0 and higher of Subversion installed, you can check out the GCC sources using the following command:

svn checkout svn://gcc.gnu.org/svn/gcc/trunk SomeLocalDir

If you are behind a firewall that does not allow the svn protocol through, you can replace svn:// with http://. You may also need to modify your subversion servers file (

/.subversion/servers) to set http-proxy-host and http-proxy-port. You should only use the http protocol if the svn protocol does not work; the http protocol has a higher server overhead associated with it and will be slower.

There is more information about Subversion specifically for GCC in the GCC Wiki.
Generated files

Our source tree contains a number of files that are generated from other source files by build tools such as Bison, Autoconf, and Gperf. Bison is now required when using SVN to access our sources, but all other generated files are included in the source tree so that GCC can be built without these build tools. The SVN checkout and update operations do not insure that the timestamps of generated files are later than those of the files they are generated from. The script contrib/gcc_update updates the timestamps for all these generated files. See the comments in that script for instructions on running it.

GCC’s build system (in particular Make) uses file timestamps to determine if a generated file needs to be updated by running a particular build tool. Because of this, GCC’s build system may believe that a generated file needs regenerating even though its source has not changed, and require a particular build tool to rebuild that generated file. If the appropriate build tool is installed on your system, then this will not be a problem. If you do not intend to make changes to the source, you can avoid installing these build tools by running contrib/gcc_update.

There has been some discussion of removing these generated files from GCC’s SVN source tree (there is no discussion of removing them from the released source tarballs). If that happens then building GCC from the SVN source tree would require installing the above mentioned build tools. Installing these build tools is not particularly difficult, but can be time consuming especially if you only occasionally install GCC on a particular system.

The build tools that GCC uses are all available from the GNU Project (see http://www.gnu.org), are often already available on many systems, and can often be found already built for some systems. A partial list of these build tools is: Autoconf, Bison, Xgettext, Automake, and Gperf.
Conflicts when using svn update

It is not uncommon to get svn conflict messages for some generated files when updating your local sources from the SVN repository. Typically such conflicts occur with autoconf generated files.

As long as you haven’t been making modifications to the generated files or the generator files, it is safe to delete the offending file, then run svn update again to get a new copy.
Branches and Tags

A branch called branchname can be checked out with the following command:

svn co svn://gcc.gnu.org/svn/gcc/branches/branchname gcc

(The release branch of the latest version of GCC x.y is named gcc-x_y-branch.)

Similarly a tag called tagname can be checked out with the following command:

svn co svn://gcc.gnu.org/svn/gcc/tags/tagname gcc

(For recent releases, the SVN tag for GCC X.Y.Z is of the form gcc_X_Y_Z_release.)

The following list provides some representative examples:

* gcc-4_3-branch
* gcc_4_3_4_release
* gcc_4_3_3_release
* gcc_4_3_2_release
* gcc_4_3_1_release
* gcc_4_3_0_release
* gcc-3_4-branch
* gcc_3_4_3_release
* gcc_3_4_2_release
* gcc_3_4_1_release
* gcc_3_4_0_release

To get a list of available branches, use the command:

svn ls svn://gcc.gnu.org/svn/gcc/branches

cygwin-improvements
This branch is intended as a development and proving grounds for fixes and enhancements specifically to the Cygwin port of the compiler, although some of these may touch slightly on MinGW targets as well. It is maintained by Dave Korn and open to contributions from any interested party; please tag patches with «[cygwin-improvements]» in the title line and post them to the GCC Patches list with a Cc: to that address.

These branches are maintained by organizations distributing GCC. No changes should be made to those branches without the explicit permission of the distributing organization. The branch name should be prefixed with the initials of the distributing organization.

Inactive Development Branches

dfp-branch
edge-vector-branch
cp-parser-branch
cp-parser-branch-2
pch-branch
gcc-3_4-basic-improvements-branch
mips-3_4-rewrite-branch
dfa-branch
gcj-abi-2-dev-branch
gcj-eclipse-branch
tree-ssa-20020619-branch
csl-sol210-branch (Solaris 2.10 AMD64 support)
gomp-20050608-branch
gomp-3_0-branch
fixed-point
gimple-tuples-branch
c-4_5-branch
alias-improvements
cond-optab
var-tracking-assignments*-branch
mem-ref2
These branches have been merged into the mainline.
apple-ppc-branch
This branch was for various improvements in use at Apple and to coordinate work with others. This branch was maintained by the folks at Apple. It has been superseded by apple-local-200502-branch.
stree-branch
This branch was for improving compilation speed and reducing memory use by representing declarations as small flat data structures whenever possible, lazily expanding them into full trees when necessary. This branch was being maintained by Matt Austern, Robert Bowdidge, Geoff Keating, and Mike Stump. Patches were marked with the tag [stree] in the subject line.
compile-server-branch
This branch was aimed at improving compile speed by caching work done between compilations. The work saved is mainly related to header file processing. This branch was maintained by Mike Stump and Per Bothner. Patches were marked with the tag [cs] in the subject line.
libobjc-branch
The branch is aimed to clean up libobjc and make it run on Darwin. Patches should be marked with the tag [libobjc-branch] in the subject line. Patches can be approved by Andrew Pinski

and Benjamin Kosnik were maintaining this branch. It is no longer maintained.
function-specific-branch
This branch is for development of adding function specific options to GCC. See the GCC wiki for a more detailed project description. Patches should be marked with the tag [function-specific] in the subject line. The branch has been merged into GCC 4.4.
lto-streamer
This was a sub-branch of the lto branch. It was intended for unstable work related to the conversion from DWARF encoding to GIMPLE streamer. It is no longer maintained.
plugin
This branch contains work for a plugin infrastructure in GCC to enable additional checking work. This branch is maintained by Eric Christopher echristo@gmail.com and will be merged with mainline from time to time. Patches will be marked with the tag [plugin] in the subject line.
condate-branch
The purpose of this branch is to develop a language for checking control flow graph properties. The code of this branch has not been merged in trunk.
miro-branch
The purpose of this branch is to develop an improved Mudflap with referent objects. The code of this branch has not been merged in trunk.
var-mappings-branch
This branch is for improving debug information based on tracking multiple variables per computed value. The branch is maintained by Richard Guenther and Michael Matz. Patches should be marked with the tag [varmap] in the subject line.
mem-ref
This branch is for lowering the GIMPLE IL for memory accesses to a flat representation. See the GCC wiki for a more detailed project description. The branch is maintained by Richard Guenther. Patches should be marked with the tag [mem-ref] in the subject line.
gcc-in-cxx
This branch was for converting GCC to be written in C++. The branch was maintained by Ian Lance Taylor.
ibm/power7-tmp
This branch was used to stage patches for Power7 (PowerPC ISA 2.06) from the development branch to the mainline. The branch was maintained by Michael Meissner, meissner@linux.vnet.ibm.com.
lto
This branch implemented link-time optimization.
named-addr-spaces-branch
This branch was the development branch to add named address space support for architectures that have multiple address spaces. The CELL/spu architecture adds an __ea keyword to describe extended memory in the host chip address space instead of the local CELL/spu address space. The branch was created by Ben Elliston, modified by Michael Meissner and eventually maintained by Ulrich Weigand. All changes from this branch were merged into mainline.
named-addr-4_3-branch
The goal of this branch was to backport the changes from the named-addr-spaces-branch to a GCC 4.3 tree. This branch was maintained by Michael Meissner. This branch was merged from gcc-4_3-branch.
split
For development of stack splitting, as described on the GCC wiki. This branch was maintained by Ian Lance Taylor. All changes were merged into mainline.
boehms-gc
The goal of this branch was to test Boehm’s GC feasibility as the garbage collector for GCC proper. This was a part of Google Summer of Code project, described in detail at http://gcc.gnu.org/wiki/Garbage_collection_tuning. The branch was maintained by Laurynas Biveinis.

For questions related to the use of GCC, please consult these web pages and the GCC manuals. If that fails, the gcc-help@gcc.gnu.org mailing list might help. Comments on these web pages and the development of GCC are welcome on our developer list at gcc@gcc.gnu.org. All of our lists have public archives.

Copyright (C) Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

These pages are maintained by the GCC team. Last modified 2011-04-15.

Источник