Софт-Портал

Gcc Compiler Windows

Рейтинг: 4.3/5.0 (665 проголосовавших)

Категория: Linux

Описание

GNU Compiler Collection (GCC) - Свободный софт

GNU Compiler Collection (GCC) | автор: admin | 28 апреля 2015 |


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

GNU C Compiler был так назван когда он обрабатывал только один язык, GCC 1.0 был выпущен в 1987. В декабре этого же года он был расширен до компиляции C++. Позже были разработаны фронт-энды для Objective-C, Objective-C++, Fortran, Java, Ada, Go и других языков.
GCC портирован на самые разные процессорные архитектуры и широко используется для разработки свободных и коммерческих программ. GCC также доступен на большинстве встраиваемых платформ, в том числе на Symbian (так называемый GCCE ), AMCC и Freescale Power Architecture -based chips. GCC также может собирать программы для игровых консолей PlayStation и Dreamcast.

Будучи официальным компилятором операционной системы GNU, GCC был принят в качестве стандартного компилятора многими другими современными Unix-подобными операционными системами, в том числе GNU/Linux и BSD, хотя FreeBSD движется к LLVM. Также доступны версии для Microsoft Windows и других систем.

Дизайн GNU Compiler Collection (GCC)


Внешний дизайн GCC следует соглашениям UNIX. Пользователь вызывает программу-драйвер конкретного языка (gcc для C, g++ для C++ и т.д.), который интерпретирует аргументы командной строки, вызывает актуальный компилятор, запускает ассемблер на выводе и опционально запускает компоновщик.
Каждый компилятор языка это отдельная программа, которая считывает исходный код и выводит машинный код. Все они имеют общую внутреннюю структуру. Front-end языка анализирует исходный код этого языка и производит абстрактное синтаксическое дерево ("дерево" для краткости). Компиляторы с разных языков работают по принципу front-end, т.е. транслируют в некий общий промежуточный "язык GENERIC", который затем единым для всех исходных языков back-end компилятором преобразуется в конечную форму. Эта фраза об этом. Методы оптимизации компиляции и статического анализа кода (такие как FORTIFY_SOURCE, директива компилятора, которая пытается обнаружить переполнение буфера) применяются к коду. Они работают в нескольких представлениях, в архитектурно-независимом GIMPLE и архитектурно зависимом RTL. Затем производится машинный код с использованием специальных архитектурных шаблонов на основе алгоритмов Джека Дэвидсона и Криса Фрейзера.

GCC написан в основном на C за исключением частей на Ada. В комплект входят стандартные библиотеки для Ada, C++ и Java, код которых написан на этих же языках. На некоторых платформах в комплект входят также библиотеки времени выполнения низкого уровня, libgcc, написанный в сочетании с машинно-независимым C и специфическим процессорным кодом, предназначенным в основном для обработки арифметических операций, которые целевой процессор не может выполнять непосредственно.

В мае 2010 года руководящий комитет GCC принял решение разрешить использование компилятора C++ для компиляции GCC. Этот компилятор был предназначен для C плюс подмножество функций из C ++. Когда это приняли, разработчики GCC смогли использовать деструкторы и общие возможности C++.
В августе 2012 года руководящий комитет GCC объявил что GCC теперь использует компилятор C++ в качестве языка реализации. Это означает что для сборки GCC из исходников, требуется компилятор C++ который понимает стандарт ISO/IEC C++03.

Front ends


Каждый front end использует парсер для получения синтаксического дерева абстракций данного исходника. Из-за абстрактного синтаксического дерева, исходные файлы любого поддерживаемого языка могут быть обработаны одним и тем же front end. GCC начал использовать LALR-анализаторы, но постепенно перешел к написанным от руки рекурсивно-спускающимся парсерам для C++ в 2004 году, C и Objective-C в 2006 году. В настоящее время все front end использую рекурсивно-спускающиеся парсеры.
До недавнего времени, древовидное представление программы не было полностью зависимым от целевого процессора. Смыслом дерева было несколько отличаться для front end разных языков и front end могут предоставлять свои собственные деревья кодов. Это было упрощено с введением GENERIC и GIMPLE, двух новых языково-независимых форм, которые были введены с появлением GCC 4.0. GENERIC более сложный и основан на промежуточной реализации GCC 3.x Java front end's. GIMPLE является упрощенным GENERIC, в котором различные конструкции упрощенны. C. C++ и Java front ends производят GENERIC непосредственно в front end. Другие front end вместо этого имеют различные промежуточные представления после парсинга и преобразования их в GENERIC. В любом случае, так называемый "gimplifier" затем преобразует их в более сложную форму в простую SSA -based GIMPLE форму, общий языком для большого количества мощных языков и и не зависящих от архитектурных глобальных (функция "область видимости") оптимизации.

GENERIC и GIMPLE


GENERIC это промежуточное представление языка, используемое в качестве среднего звена во время компиляции исходного кода в двоичный файл. Подмножество, называемое GIMPLE, предназначено для всех front end GCC. Среднее звено GCC делает анализ и оптимизацию всего кода, работая независимо как от языка компиляции так и от целевой архитектуры начиная с GENERIC представления и расширяя его до Register Transfer Language (RTL). GENERIC представление содержит только подмножество императивных конструкций программирования, оптимизированных по среднему звену. При переводе исходного кода GIMPLE, сложные выражения делятся на трёхадресный код при помощи временных переменных. Это представление было предложено компилятором McCAT compiler для упрощения анализа и оптимизации в императивных программ.

Оптимизация


Оптимизация может происходить на любом этапе компиляции. Однако большая часть оптимизации выполняется до синтаксического и семантического анализа в front end и до генерации кода в back end. Таким образом, общее, хотя несколько противоречивое имя этого этапа компиляции - "среднее звено".
Точный набор GCC оптимизации меняется от версии к версии, но включает в себе такие стандартные алгоритмы: оптимизация цикла, удаление общих подвыражений, jump threading, инструкции планирования и так далее. RTL-оптимизация имеет меньшее значение с добавлением глобальных SSA-based оптимизаций на GIMPLE дереве, так как объём RTL-оптимизации более ограничен и имеет меньше выскокоуровневой информации.
Некоторые из этих оптимизаций, выполняемых на этом уровне включают устранение мертвого кода, исключение избыточных частей, глобальная нумерация значений, sparse conditional constant propagation и scalar replacement of aggregates. Выполняются массивы зависимых оптимизаций: автоматическая векторизация и автоматическое распараллеливание. Profile-guided optimization (PGO) также возможно.

Back end


Поведение back end GCC частично определяется макросами препроцессора и функциями специфическими для целевой архитектуры, например для определения байтов, размера слова и соглашении о вызове. front part back end использует их чтобы помочь решить генерацию RTL, поэтому несмотря на RTL, GCC является номинально процессорно-независимым, исходная последовательность абстрактных инструкций уже адаптирована к цели. В любой момент, фактические инструкции RTL, образующие представление программы должны соответствовать описанию машины целевой архитектуры.
Файл описания машины содержит RTL-шаблоны, наряду с ограничениями операнд и фрагментами кода для вывода окончательной сборки. Ограничения указывают что определённый RTL-шаблон может применяться только (например) к определённым аппаратным регистрам или (например) позволять операнду смещения накладывать ограничения размера (например, 12, 16, 24. битные смещения и т.д.). Во время генерации RTL, ограничения для данной целевой архитектуры проверяются. Во время генерации RTL, ограничения для данной целевой архитектуры проверяются. Для того чтобы выдать данную фрагмент RTL, он должен соответствовать одному (или более) шаблонов RTL в файл описания машины и соответствовать ограничениям этого шаблона; в противном случае, было бы невозможно преобразовать конечный RTL в машинный код.
К концу компиляции, действительный RTL сводится к строгой форме, в которой каждая команда относится к реальным машинным регистрам и шаблонам из файла описания целевой машины. Формирование строгого RTL является сложной задачей. Важным шагом является распределение регистров, где выбраны реальные аппаратные регистры на замену изначально присвоенных псевдо-регистров. Это сопровождается фазами перезагрузки. Любые псевдо-регистры, которые не были изначально назначены реальным аппаратным регистрам являются "пролитыми" в стёк и для выполнения этого пролива генерируется RTL. Кроме этого, смещения которые слишком велики для того чтобы поместится в фактической инструкции, должны быть разбиты и заменены RTL-последовательностями, которые будут подчинятся ограничению смещения. На заключительном этапе, машинный код собирается вызовом небольших фрагментов кода, связанных с каждым шаблоном для создания реальных инструкций из набора архитектурных команд, используя финальные регистры, смещения and/or addresses into the string is performed. Фрагменты ассемблерной генерации могут быть короткими блоками C-кода, выполняющими некоторую дополнительную работу, но в конечном итоге возвращающими строку содержащую правильный ассемблерный код.

Особенности GCC


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

Языки


Выпуск 4.6 включает front-ends для C (gcc), C++ (g++), Objective-C, Objective-C++, Fortran (gfortran), Java (gcj), Ada (GNAT), and Go (gccgo).[38] Also available, but not in standard are Pascal (gpc), Mercury, Modula-2, Modula-3, PL/I, D (gdc) и VHDL (ghdl). Также поддерживается популярный стандарт распаралеливания программ OpenMP. Начиная с версии 5.1, есть предварительная поддержка OpenACC.
До версии 4.0 front-end языка Fortran был g77, который поддерживает только FORTRAN77. В более поздних версиях, g77 заменили на GNU Fortran (сохраняющий большую часть расширений g77), который поддерживает Fortran 95 и большую часть Fortran 2003 и Fortran 2008. Front-qnd для CHILL был удалён по причине отсутствия поддержки. Через некоторые экспериментальные ветки доступна поддержка GCC UPC compilerfor Unified Parallel C.

Архитектура


Процессорные архитектуры в версии 4.3:
Alpha,ARM, AVR, Blackfin, Epiphany (GCC 4.8), H8/300, HC12, IA-32 (x86), IA-64 (Intel Itanium), MIPS, Motorola 68000, PA-RISC, PDP-11, PowerPC, R8C / M16C / M32C, SPARC, SPU, SuperH
System/390 / zSeries, VAX, x86-64.

Менее известные процессоры, поддерживаемые в стандартном выпуске:
68HC11, A29K, CR16, C6x, D30V, DSP16xx, ETRAX CRIS, FR-30, FR-V, intel i960, IP2000, M32R, MCORE, MIL-STD-1750A, MMIX, MN10200, MN10300, Motorola 88000, NS32K, ROMP, RL78, Stormy16, V850, Xtensa.

Процессоры поддерживаемые отдельно от FSF версии:
Cortus APS3, ARC, AVR32, C166 and C167, D10V, EISC, eSi-RISC, Hexagon, LatticeMico32, LatticeMico8, MeP, MicroBlaze, Motorola 6809, MSP430, NEC SX architecture, Nios II and Nios, OpenRISC, PDP-10, PIC24/dsPIC, PIC32.

gcj Java compiler ориентируется на целевую архитектуру или на Java Virtual Machine's Java bytecode. При переориентации GCC на новую платформу, часто используется раскрутка компилятора.

Лицензия:
GNU GPL 3 + с НКУ Runtime Library Exception
Операционные системы:
GNU/Linux Windows BSD Android MAC Solaris DOS HAIKU OS/2
Интерфейс консольный
Язык программирования:
C++

Сайт проекта Дргугие программы:

Gcc compiler windows:

  • скачать
  • скачать
  • Другие статьи, обзоры программ, новости

    GNU Compiler Collection

    GNU Compiler Collection

    Изначально названный GNU C Compiler поддерживал только язык Си. Позднее GCC был расширен для компиляции исходных кодов на таких языках программирования, как C++. Objective-C. Java. Фортран и Ada.

    С версии 4.2.2 GCC перешёл на лицензию GPLv3.

    Обзор

    Начало GCC было положено Ричардом Столлманом. который реализовал первый вариант GCC в 1985 году на нестандартном и непереносимом диалекте языка Паскаль ; позднее компилятор был переписан на языке Си Леонардом Тауэром (англ.   Leonard H. Tower Jr. ) и Ричардом Столлманом [1] и выпущен в 1987 году [2] как компилятор для проекта GNU, который сам по себе являлся свободным программным обеспечением. Разработка GCC курируется Free Software Foundation. [3]

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

    Будучи официальным компилятором системы GNU. GCC также является главным компилятором для сборки ряда других операционных систем; среди них — различные варианты Linux и 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.

    Архитектуры

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

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

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

    Структура

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

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

    До версии 4.7.2 GCC был почти полностью написан на Си. хотя значительная часть front-end для Ады написана на Аде. С версии 2012-08-14 разработка переведена на язык C++.

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

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

    • Valgrind для поиска утечек памяти
    • GNU Profiler (Шаблон:Translation ) используется для того, чтобы определить, сколько времени уходит на выполнение той или иной части программы, как часто вызываются те или иные процедуры; для использования gprof необходимо компилировать программу со специальными опциями для включения «профилирования».
    • gcov для анализа покрытия
    Лицензия

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

    Критика

    Некоторые разработчики OpenBSD. например Тео де Раадт и Отто Мурбек (Otto Moerbeek ), критикуют GCC. называя его «громоздким, глючным, медленным и генерирующим плохой код». [7] По причине такого критического отношения, а также из-за довольно ограничивающей (по сравнению с BSD) лицензии GPL, под которой выпущена коллекция компиляторов, была предпринята попытка заменить в NetBSD и OpenBSD GCC другими компиляторами, например, PCC [8]. Аналогичная работа по замене GCC на Clang ведется в FreeBSD [9].

    См. также Примечания Литература
    • Артур Гриффитс GCC. Настольная книга пользователей, программистов и системных администраторов. — Диасофт, 2004. — С. 624. — ISBN 966-7992-34-9 .
    Ссылки
    • Официальный сайт GCC .
    • Building and Testing gcc/glibc cross toolchains.
    • From Source to Binary: The Inner Workings of GCC . Overview and explanation of gcc’s internal structure in Red Hat Magazine.
    • Dev-C++ — интегрированная среда, включающая в себя компилятор MinGW .
    • Code::Blocks — ещё одна интегрированная среда разработки + компилятор MinGW.
    • Производительность компиляторов C++ .
    • Сравнительный анализ компиляторов GCC и Sun Studio на примере SPEC CPU 2006 .
    • GCC на Ohloh .

    Компилятор GCC

    Компилятор GCC

    GСС - это свободно доступный оптимизирующий компилятор для языков C, C++.

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

    Файлы с расширением .cc или .C рассматриваются, как файлы на языке C++, файлы с расширением .c как программы на языке C, а файлы c расширением .o считаются объектными.

    Чтобы откомпилировать исходный код C++, находящийся в файле F.cc. и создать объектный файл F.o. необходимо выполнить команду:

    Опция –c означает «только компиляция».

    Чтобы скомпоновать один или несколько объектных файлов, полученных из исходного кода - F1.o. F2.o. - в единый исполняемый файл F. необходимо ввести команду:

    gcc -o F F1.o F2.o

    Опция -o задает имя исполняемого файла.

    Можно совместить два этапа обработки - компиляцию и компоновку - в один общий этап с помощью команды:

    gcc -o F <compile-and-link-options> F1.cc. -lg++ <other-libraries>

    <compile-and-link –options> - возможные дополнительные опции компиляции и компоновки. Опция –lg++ указывает на необходимость подключить стандартную библиотеку языка С++, <other-libraries> - возможные дополнительные библиотеки.
    После компоновки будет создан исполняемый файл F, который можно запустить с помощью команды ./F <arguments>. Строка <arguments> определяет аргументы командной строки Вашей программы.
    В процессе компоновки очень часто приходится использовать библиотеки. Библиотекой называют набор объектных файлов, сгруппированных в единый файл и проиндексированных. Когда команда компоновки обнаруживает некоторую библиотеку в списке объектных файлов для компоновки, она проверяет, содержат ли уже скомпонованные объектные файлы вызовы для функций, определенных в одном из файлов библиотек. Если такие функции найдены, соответствующие вызовы связываются с кодом объектного файла из библиотеки. Библиотеки могут быть подключены с помощью опции вида -lname. В этом случае в стандартных каталогах, таких как /lib. /usr/lib, /usr/local/lib будет проведен поиск библиотеки в файле с именем libname.a. Библиотеки должны быть перечислены после исходных или объектных файлов, содержащих вызовы к соответствующим функциям.

    Среди множества опций компиляции и компоновки наиболее часто употребляются следующие:

    Приложения - Эффективное использование GNU Make

    Приложение A. Редактирование make-файлов в разных операционных системами

    Если, наряду с операционной системой Linux, вы работаете с операционными системами фирмы Microsoft (DOS, Windows), то при редактировании make-файлов в разных системах могут возникнуть определенные трудности.

    Проблема состоит в том, что принятый в Unix-подобных операционных системах формат хранения текстовых файлов, несколько отличается от формата DOS/Windows. В Unix каждая строка текстового файла заканчивается символом "перевод строки" (код 0x0A). В DOS и Windows текстовые строки разделяются парой символов - "возврат каретки", "перевод строки" (0x0D, 0x0A).

    Linux-версия программы GNU Make будет нормально работать с make-файлами, написанными в среде Linux. Версия утилиты GNU Make для Windows также будет нормально работать с make-файлами, подготовленными в среде Windows. Проблема возникнет лишь в том случае, если попытаться обработать Linux-версией программы GNU Make текстовой файл, подготовленный в среде DOS или Windows. Подобная ситуация может возникнуть "нечаянно" - достаточно лишь "сохранить" make-файл для среды Linux в текстовом редакторе DOS/Windows, чтобы он оказался "испорчен".

    В отличие от компилятора GCC, который просто игнорирует символы "возврат каретки", GNU Make рассматривает их как "обычные" символы, которые вполне могут быть частью имени. В результате все слова, находящиеся в конце строк, искажаются, так как сзади к ним добавляется невидимый символ "возврат каретки". В следующем примере имя файла TextLine.o будет искажено (его длина будет составлять одиннадцать символов из-за невидимого "возврата строки"):

    Разумеется, на диске не найдется файла с таким "странным" именем и make-файл будет работать неверно. Дело осложняется еще и тем, что выдаваемые на экран диагностические сообщения также искажаются (при выводе на экран символ "возврат каретки" возвращает курсор в начало строки) и зачастую представляют собой лишь бессмысленные "обрывки" слов.

    Описанную проблему можно решить разными способами. Организационный метод решения - никогда не пытаться редактировать make-файл, находясь в "чужеродной" для него среде. Другой возможный подход - "принудительно" удалять из make-файла символы "возврат каретки" (либо "вручную" - текстовым редактором, либо с помощью подходящей программы).

    Приложение B. Организация иерархии каталогов в сложных проектах Для сложных проектов, состоящих из большого количества файлов, я предпочитаю более сложную организацию каталогов, чем та, которая приводилась в качестве примера в разделе 1.7. "Разнесение разных версий программы по отдельным директориям". Основная идея заключается в том, чтобы файлы с разным "назначением" помещались в разные каталоги. В моих проектах дерево каталогов выглядит примерно так:
    • имя_проекта /
      • bin /
        • linux_debug /
        • linux_release /
        • windows_debug /
        • windows_release /
      • doc /
        • README.txt
      • project /
        • Makefile
        • make_debug
        • make_release
      • src /

    В каталог bin помещаются результаты компиляции - объектные и исполняемые файлы, библиотеки и тому подобное. Этот каталог можно "безболезненно" удалить - при следующей компиляции он будет автоматически создан заново. В этом каталоге каждая из возможных конфигураций программы имеет свою отдельную директорию. Как правило, я делаю четыре конфигурации программы - для каждой из двух операционных систем (Linux и Windows) имеется отладочная и рабочая версии программы.

    В директорию doc я помещаю различные текстовые файлы - документацию, замечания, список ошибок и тому подобное. Здесь же располагается и файл README.txt.

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

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

    Вот пример make-файла, который работает с подобной структурой директорий проекта:

    Список директорий, где располагаются файлы с исходными текстами (source_dirs), задается относительно каталога src. Вот как выглядит командный файл, собирающий отладочную версию программы:

    Командный файл, собирающий рабочую версию программы выглядит аналогично:

    Приложение C. Компилятор GCC

    GNU Compiler Collection (GCC) - это семейство компиляторов с языков C, C++ и Object-C, которые объединены общей технологией и распространяются в рамках проекта GNU. Домашняя страничка компилятора находится по адресу www.gnu.org/software/gcc/gcc.html

    Этот компилятор является "стандартным" средством для компиляции всех программ, входящих в проект GNU. GCC также является основным компилятором операционной системы Linux - с его помощью компилируется ядро системы.

    Компилятор GCC развивается весьма динамично - программа улучшается, исправляются обнаруженные ошибки, добавляются новые возможности. Всегда желательно знать с какой версией компиляторы вы в данный момент работаете. Возможно, что эта версия еще не поддерживает нужные вам возможности или содержит ошибки, которые могут повлиять на работоспособность компилируемой программы. Узнать версию компилятора GCC можно с помощью ключа -v:

    "Стандартным" средством для отладки программ, скомпилированных компилятором GCC, является отладчик GDB. Этот отладчик свободно распространяется в рамках проекта GNU. Домашняя страничка отладчика находится по адресу www.gnu.org/software/gdb/gdb.html.

    Для подготовки отладочной версии программы с помощью компилятора GCC, достаточно отключить оптимизацию и включить генерацию отладочной информации. Для этого я использую следующие опции компиляции:

    Генерировать отладочную информацию

    Отладчик GDB имеет текстовой интерфейс командной строки. Мне этот интерфейс кажется не очень удобными, поэтому я пользуюсь графической оболочкой DataDisplayDebugger (DDD). Эта оболочка является надстройкой над "текстовыми" отладчиками, реализующей для них удобный графический интерфейс. Программа DDD также входит в проект GNU. Ее домашняя страничка находится по адресу www.gnu.org/software/ddd. DataDisplayDebugger работает в среде X-Windows.

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

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

    Ключ Назначение -O3 Максимальная оптимизация -fomit-frame-pointer Не использовать указатель на стековый фрейм. Аналогичен флажку -Oy компилятора Visual-C. Компилятор будет адресовать переменные в стеке с помощью регистра ESP а регистр EBP "высвобождается" для использования в качестве регистра общего назначения. -mcpu=pentium Оптимизировать код для процессора Pentium (однако программа по прежнему будет работать даже на i386)

    Если вы используете механизм исключений (exceptions) языка C++. то при компиляции должна быть включена соответствующая опция:

    Ключ компиляции Назначение -fexceptions Включить поддержку механизма исключительных ситуаций языка C++

    Статическая и динамическая компоновка

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

    Часто бывает полезным иметь ассемблерный листинг кода, генерируемого компилятором. С помощью такого листинга можно:
    • Посмотреть, как те или иные опции оптимизации отражаются на генерируемом коде
    • Посмотреть, каким образом компилятор обрабатывает те или иные конструкции языка программирования
    • Выявлять ошибки, связанные с неправильной работой кодогенерации в компиляторе
    • Узнать, какие в точности опции были включены при компиляции программы

    Для получения ассемблерного листинга, я использую следующие опции компилятора GCC:

    Ключ компиляции Назначение -S Остановиться после стадии компиляции, перед стадией ассемблирования. -fverbose-asm Генерировать дополнительные комментарии в ассемблерном листинге. Какие именно "дополнительные комментарии" будут помещены в текст листинга, зависит от версии компилятора.

    Обратите внимание на то, что указание флажка -S просто "останавливает" компилятор после фазы генерации ассемблерного листинга, то есть процесс компиляции прерывается. Как следствие - процесс сборки программы и процесс генерации ассемблерных листингов "несовместимы" между собой. Можно либо получать листинги, либо собирать программу, но не то и другое одновременно. Для получения листингов я обычно создаю отдельный командный файл, который среди прочих опций компиляции содержит флажки -S и -fverbose-asm.

    Весьма полезная возможность компилятора - помещать в листинг список всех опций компиляции, которые были включены в данный момент. Дело в том, что включение одних опций (например -O3) может "автоматически" приводить к включению других опций, а документация к GCC не всегда точна в описании подобных зависимостей. Некоторые версии GCC всегда помещают в листинг список используемых опций, другие версии делают это только при наличии флажка -fverbose-asm.

    Переназначение ошибок в файл

    По умолчанию, компилятор GCC выдает ошибки в стандартный поток сообщений об ошибках (файл с дескриптором 2). Иногда это не очень удобно - сообщения об ошибках могут быть очень длинными подробными а "прокрутка" экрана назад не всегда доступна. Поэтому я обычно перенаправляю сообщения компилятора в файл. Этот файл потом можно просмотреть любым стандартным средством. Вот, например, как может выглядеть правило для компиляции исходных текстов:

    Компилятор GCC обрабатывает программу за несколько проходов, помещая промежуточные результаты компиляции во временные файлы. Процесс компиляцию можно ускорить, если воспользоваться опцией pipe. При включении этой опции, различные этапы компиляции начинают "общаться" между собой не через временные файлы, а через каналы обмена (pipes).

    Тексты с символом "возврат каретки"

    В отличие от утилиты GNU Make. компилятор GCC вполне "лояльно" относится к наличию символов "возврат каретки" в компилируемых текстах - такие символы попросту игнорируются. Поэтому, проблем при компиляции исходных текстов, подготовленных в среде DOS/Windows, возникнуть не должно.

    Приложение D. "Гипотический" проект - текстовой редактор

    В первой главе "Моя методика использования GNU Make " в качестве примера рассматривается "гипотический" проект - текстовой редактор. Он состоит из трех файлов с исходным текстом на языке C++ (main.cpp. Editor.cpp и TextLine.cpp ), а также трех заголовочных файлов (main.h. Editor.h, TextLine.h ). Ниже приведены листинги этих файлов.

    Файл main.cpp. Файл main.h. Файл Editor.cpp. Файл Editor.h: Файл TextLine.cpp. Файл TextLine.h.

    Скачать GCC

    Для скачивания без ожидания требуется регистрация.

    ISBN: 966-7992-34-9
    Формат: DjVu, Отсканированные страницы
    Год выпуска: 2004
    Автор: Артур Гриффитс
    Жанр: Программирование
    Издательство: ДиаСофт
    Количество страниц: 609
    Описание: GCC - основной компилятор проекта GNU. Он поддерживает набор всех наиболее используемых языков программирования и обеспечивает перенос программ на десятки аппаратных платформ. Все свободно распространяемое программное обеспечение, включая и компиляторы, на том или ином уровне основываются на GCC. В книге даются подробные сведения о получении, конфигурировании, установке и тестированию компилятора. Представлено построение кросс-компилятора и создание встраиваемых систем, детально описывается компиляция программ на языках C, C++, Objective-C, Fortran, Java и Ada. А также сочетание в одной программе нескольких языков программирования и включение в нее частей, написанных на ассемблере или языках системного уровня. В этой книге можно найти практически любые сведения, достаточные не только для разрешения ваших проблем, но и для участия в разработке и поддержке самого компилятора GCC. Книга будет полезна: программистам-разработчикам и руководителям программных проектов; администраторам и системным программистам, которым приходится заниматься переносом программного обеспечения и приложений; пользователям, заинтересованным в использовании программ с открытым исходным кодом.

    СКАЧАТЬ GCC. Компилятор GNU. Полное руководство БЕСПЛАТНО

    Вы сейчас просматриваете файл GCC. Компилятор GNU. Полное руководство. Данный файл находится в категории Литература. Чтобы увидеть другие файлы из этой категории, перейдите по этой ссылке: Литература . Для того чтобы скачать GCC. Компилятор GNU. Полное руководство нажмите на кнопку СКАЧАТЬ ниже. Надеемся вам понравился файл GCC. Компилятор GNU. Полное руководство и пригодился. По всем вопросам обращайтесь на форуме или к администарции.

    Порядок вывода комментариев:

    Qt 4

    Замечания по компиляторам

    Данная страница содержит информацию о компиляторах C++ и инструментах, используемых для сборки Qt на различных платформах.

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

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

    Поддерживаемые возможности

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

    GCC GCC под Windows (MinGW)

    Мы тестировали Qt с этим компилятором на Windows XP. Минимальная поддерживаемая версия MinGW:

    • GCC 3.4.2
    • MinGW runtime 3.7
    • win32api 3.2
    • binutils 2.15.91
    • mingw32-make 3.80.0-3

    Замечание: Для пользователей бинарного пакета MinGW: Этот пакет теперь основан на MinGW 4.4. Установщик более не предлагает вам скачать MinGW, но наоборот предлагает использовать версию MinGW, которая уже установлена на вашей машине. Вы только сообщите установщику в каком каталоге установлен MinGW. Если вы еще не установили MinGW 4.4, вы можете скачать архив .zip с нашего ftp-сервера. Этот архив предоставит исправления для MinGW и поддержку отсутствующих API, За подробностями обращайтесь к каталогу _patches в архиве.

    Замечание: Установка MinGW необходима только для сборки бинарного пакета вместо запуска предварительно скомпилированных бинарных файлов, которые находятся в пакете.

    GCC 4.0.0

    Выпущенный пакет компилятора содержит несколько ошибок, которые приводят к ошибкам компиляции. Мы рекомендуем использовать gcc 4.0.1 или старше, или использовать свежий срез CVS ветки gcc 4.0. Версия gcc 4.0.0, которая идет вместе с Mac OS X 10.4 "Tiger", работает с Qt для Mac OS X.

    HP-UX

    Платформа hpux-g++ тестировалась с gcc 3.4.3.

    Solaris

    Пожалуйста, используйте GCC 3.4.2 или более свежую.

    Mac OS X

    Пожалуйста, используйте последний GCC 3.3 от Apple или свежие версии GCC 3. gcc 3.3, который поставляется вместе с Xcode 1.5, генерирует код с дефектом. Используйте исправление GCC 3.3 от ноября 2004, доступное в Apple .

    GCC 3.4.6 (Debian 3.4.6-5) на AMD64 (x86_64)

    При создании релиз-сборки этот компилятор компилирует с ошибкой некоторые части Qt. Имеется несколько методов обхода:

    1. Используйте отладочную сборку.
    2. Для каждой встретившейся ошибки компиляции перекомплируйте файл без опции -O2.
    3. Добавьте -fno-gcse в QMAKE_CXXFLAGS_RELEASE .
    HP ANSI C++ (aCC)

    Платформы hpux-acc-32 и hpux-acc-64 тестировались с aCC A.03.57. Платформы hpuxi-acc-32 и hpuxi-acc-64 тестировались с aCC A.06.10.

    Intel C++ Compiler

    Qt поддерживает компилятор Intel C++ и для Windows и для Linux. Однако, имеется несколько проблем под Linux (смотрите следующий раздел).

    Intel C++ Compiler для Linux

    В настоящее время Nokia тестирует следующие компиляторы:

    • Intel(R) C++ Compiler для приложений, запускаемых на IA-32, версия 10.1 Build 20080602 Package ID: l_cc_p_10.1.017
    • Intel(R) C++ Compiler для приложений, запускаемых на Intel(R) 64, версия 10.1 Build 20080602 Package ID: l_cc_p_10.1.017

    В настоящее время мы не тестируем компилятор IA-64 (Itanium).

    Известные проблемы с Intel C++ Compiler для Linux
    • Поддержка предварительно скомпилированных заголовков не работает в версии 10.0.025 и более старых. Для этих компиляторов вы должны сконфигурировать Qt с опцией -no-pch. Поддержка предварительно скомпилированных заголовков работает в версии 10.0.026 и более поздних.
    • В версии 10.0.026 для Intel 64 известна ошибка компиляции qmake при создании релиз-сборки. Пока конфигурируйте Qt с опцией -debug. Версия 10.1.008 и более поздние могут компилировать qmake в режиме релиза.
    • Для версий с 10.1.008 по 10.1.015 для IA-32 и Intel 64 известен фатальный сбой с сообщением "(0): internal error: 0_47021" при компиляции QtXmlPatterns. QtWebKit и Designer в режиме релиза. Версия 10.1.017 компилирует эти модули в режиме релиза правильно.
    Intel C++ Compiler (Windows, Altix)

    Qt 4 был успешно протестирован с:

    • Windows - Intel(R) C++ Compiler для 32-битных приложений, Version 9.1.040.
    • Altix - Intel(R) C++ Itanium(R) Compiler для приложений базирующихся на Itanium(R) версия 8.1 Build 20050406 Package ID: l_cc_pc_8.1.030

    В настоящее время тестируются компилятор Intel только для 32-битных версий Windows.

    MIPSpro (IRIX)

    IRIX - неподдерживаемая платформа. За подробностями обращайтесь к странице Поддерживаемые платформы и он-лайновой странице Qt Software Политика поддержки платформ .

    Qt 4.4.x требуется MIPSpro версии 7.4.2m.

    Обратите внимание на то, что MIPSpro версии 7.4.4m в настоящее время не поддерживается, так как в ней имеется несколько проблем, которые еще не исправлены. Мы рекомендуем использовать для разработки Qt версию 7.4.2m. Однако, пожалуйста обратите внимание на неподдерживаемый статус этой платформы.

    Forte Developer / Sun Studio (Solaris) Sun Studio

    Qt тестировалась с использованием Sun Studio 12 (Sun CC 5.9). Перейдите на страницу Sun Studio Patches на веб-сайте Sun, чтобы скачать последние исправления для вашего компилятора Sun.

    Пожалуйста, обратите внимание на то, что Qt 4.6 требовательна в своих требованиях к STL и что стандартная реализация STL, используемая Sun CC, не удовлетворяет этим требованиям. Это не влияет на бинарную совместимость и вы можете продолжать использовать STL в вашем коде, но функции Qt совместимости с STL будут блокированы.

    Sun CC поставляется со вторичной реализацией STL (называется stlport4), которая соответствует стандартам и может быть использована Qt. Вы можете разрешить это передав опцию -library=stlport4 компилятору. Обратите внимание на то, что это не скажется на бинарной совместимости Qt, но может повредить другим библиотекам и программам, использующим STL.

    Sun WorkShop 5.0

    Sun WorkShop 5.0 не поддерживается с Qt 4.

    Visual Studio (Windows)

    Вы делали большую часть разработки под Windows на Windows XP, используя Microsoft Visual Studio .NET 2005 и Visual Studio 2008 (как 32-, так и 64-битные версии).

    Qt работает с Visual Studio 2005 Standard Edition, Professional Edition и Team System Edition.

    Мы также тестировали Qt 4 на Windows XP с Visual Studio .NET и Visual Studio 2003.

    Для того, чтобы использовать Qt с Visual Studio 2005/2008 Express Edition вам необходимо скачать и установить Platform SDK. Из-за ограничений в Express Edition мы не смогли установить Qt Visual Studio Integration. Вам нужно использовать наши инструменты командной строки для сборки приложений Qt с помощью этой редакции.

    Visual C++ Linker не понимает имена файлов с пробелами (такие как C:\Program files\Qt\ ), поэтому переместите её в другое место, или явно установите путь; например:

    Если вы встретите странные проблемы с использованием специальных флагов, модифицирующих выравнивание структуры и членов объединения (таких как /Zp2 ), тогда вам нужно также перекомпилировать Qt с флагами, установленными для приложения.

    Если вы используете Visual Studio .NET (2002) Standard Edition, вы должны использовать предоставляемые бинарные пакеты Qt, а не пакеты исходного кода. Так как Standard Edition не оптимизирует компилируемый код, ваша скомпилированная версия Qt будет выполняться квазиоптимально с усреднением по скорости.

    В Visual Studio 2005 Service Pack 1 была внесена ошибка, из-за которой не компилируется Qt, что было исправлено заплаткой, доступной в Microsoft. Для получения дополнительной информации смотрите статью в Базе знаний .

    IBM xlC (AIX)

    Утилита makeC++SharedLib должна быть в вашей переменной PATH и соответствовать сборке разделяемых библиотек. Из Красной книги IBM C and C++ Application Development on AIX :

    • "Второй шаг - используйте команду makeC++SharedLib для создания разделяемого объекта. Команда имеет много необязательных аргументов, но в простейшей форме может использована как изложено ниже:"
    • "Полный путь к команде не рекомендуется; однако, чтобы обойти это добавьте каталог, в котором находится ваша переменная окружения PATH. Команда находится в /usr/vacpp/bin directory вместе с VisualAge C++ Professional for AIX, Version 5 compiler."
    VisualAge C++ для AIX, версия 6.0 GCCE (Symbian)

    GCCE нельзя использовать для компиляции библиотек Qt для платформы Symbian, но GCCE поддерживается при компиляции приложений Qt для платформы Symbian.