[devel] Dramatic g++4.4 speed regression (was: g++4.3 vs g++4.4)

[devel] Dramatic g++4.4 speed regression (was: g++4.3 vs g++4.4)

[Victor Forsyuk]

2010/1/17 Boris Savelev <boris@altlinux.org>:
> У меня есть пакет q4wine (
> http://git.altlinux.org/people/boris/packages/q4wine.git ) и у одного
> файла ( ./src/q4wine-gui/wizard.cpp ) возникает проблема при
> компиляции в hasher c g++4.4.
> Проблема заключается в том что процесс
> /usr/libexec/gcc/i586-alt-linux/4.4.2/cc1plus грузит процессор на 100%
> но при этом ничего полезного не генерит ('as' которому должно лететь
> что-то по pipe от cc1plus висит в ожидании на read() по strace). В
> итоге сборка отваливается по hasher time-out.

Проблема, очевидно, аналогична наблюдаемой при сборке fwbuilder.
Думаю, что и здесь сборка не зависает и, если дать компилятору
достаточно времени, когда нибудь завершится.

> При использовании g++4.3 такой проблемы нет.

Да. Регрессия наступила в одной из сборок g++4.4.

> Не знаю что еще добавить, но вроде такая проблема была не только у меня. Что можете
> посоветовать?

Будем вешать багу на gcc4.4-c++. Тяжелую. Я раздумываю между major и
blocker. Регрессию можно без преувеличения охарактеризовать как
катастрофическую.

Вот так собирался fwbuilder 3.0.7 при помощи нашего gcc4.4-c++-4.4.2
(синхронизированного, кстати, с FedoraCore'вским 4.4.2-20):
8378.43user 64.38system 2:08:21elapsed 109%CPU (0avgtext+0avgdata 0maxresident)k

А вот время сборки gcc4.3-c++-4.3.2:
964.41user 66.88system 9:19.92elapsed 184%CPU (0avgtext+0avgdata 0maxresident)k

Ничего так регрессия в скорости компиляции - на порядок!

Я общался на эту тему с Вадимом Курляндом (автором fwbuilder). У него
на Федоре никаких проблем с компиляцией нет (те же 10 минут на сборку
всей программы). Последняя Fedora на которой он строил - это Fedora
Core 12. Компилятор там
"gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC)".

Первая неудачная пересборка fwbuilder была, по-видимому, 9 ноября. Во
всяком случае так датирован первый отчет об этом. Обычно такие отчеты
я не удаляю, но даже если вдруг - в любом случае это был компилятор
synced with FC 4.4.2-7.

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

Re: [devel] Dramatic g++4.4 speed regression (was: g++4.3 vs g++4.4)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

On Tue, Jan 19, 2010 at 06:59:12PM +0200, Victor Forsyuk wrote:
[...]
> Первая неудачная пересборка fwbuilder была, по-видимому, 9 ноября. Во
> всяком случае так датирован первый отчет об этом. Обычно такие отчеты
> я не удаляю, но даже если вдруг - в любом случае это был компилятор
> synced with FC 4.4.2-7.
> 
> Поскольку у Вадима на федоровском 4.4.2-7 проблем нет, то
> напрашивается вывод, что причина регресии в альтовских патчах...

Скорее в разных опциях компилятора.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Dramatic g++4.4 speed regression (was: g++4.3 vs g++4.4)

[Victor Forsyuk]

2010/1/19 Dmitry V. Levin <ldv@altlinux.org>:
> On Tue, Jan 19, 2010 at 06:59:12PM +0200, Victor Forsyuk wrote:
> [...]
>> Первая неудачная пересборка fwbuilder была, по-видимому, 9 ноября. Во
>> всяком случае так датирован первый отчет об этом. Обычно такие отчеты
>> я не удаляю, но даже если вдруг - в любом случае это был компилятор
>> synced with FC 4.4.2-7.
>>
>> Поскольку у Вадима на федоровском 4.4.2-7 проблем нет, то
>> напрашивается вывод, что причина регресии в альтовских патчах...
>
> Скорее в разных опциях компилятора.

%optflags? Или имелось в виду другое?

Re: [devel] Dramatic g++4.4 speed regression (was: g++4.3 vs g++4.4)

[Kirill A. Shutemov]

2010/1/19 Victor Forsyuk <force@altlinux.org>:
> 2010/1/17 Boris Savelev <boris@altlinux.org>:
>> У меня есть пакет q4wine (
>> http://git.altlinux.org/people/boris/packages/q4wine.git ) и у одного
>> файла ( ./src/q4wine-gui/wizard.cpp ) возникает проблема при
>> компиляции в hasher c g++4.4.
>> Проблема заключается в том что процесс
>> /usr/libexec/gcc/i586-alt-linux/4.4.2/cc1plus грузит процессор на 100%
>> но при этом ничего полезного не генерит ('as' которому должно лететь
>> что-то по pipe от cc1plus висит в ожидании на read() по strace). В
>> итоге сборка отваливается по hasher time-out.
>
> Проблема, очевидно, аналогична наблюдаемой при сборке fwbuilder.
> Думаю, что и здесь сборка не зависает и, если дать компилятору
> достаточно времени, когда нибудь завершится.
>
>> При использовании g++4.3 такой проблемы нет.
>
> Да. Регрессия наступила в одной из сборок g++4.4.
>
>> Не знаю что еще добавить, но вроде такая проблема была не только у меня. Что можете
>> посоветовать?
>
> Будем вешать багу на gcc4.4-c++. Тяжелую. Я раздумываю между major и
> blocker. Регрессию можно без преувеличения охарактеризовать как
> катастрофическую.
>
> Вот так собирался fwbuilder 3.0.7 при помощи нашего gcc4.4-c++-4.4.2
> (синхронизированного, кстати, с FedoraCore'вским 4.4.2-20):
> 8378.43user 64.38system 2:08:21elapsed 109%CPU (0avgtext+0avgdata 0maxresident)k
>
> А вот время сборки gcc4.3-c++-4.3.2:
> 964.41user 66.88system 9:19.92elapsed 184%CPU (0avgtext+0avgdata 0maxresident)k
>
> Ничего так регрессия в скорости компиляции - на порядок!
>
> Я общался на эту тему с Вадимом Курляндом (автором fwbuilder). У него
> на Федоре никаких проблем с компиляцией нет (те же 10 минут на сборку
> всей программы). Последняя Fedora на которой он строил - это Fedora
> Core 12. Компилятор там
> "gcc version 4.4.2 20091027 (Red Hat 4.4.2-7) (GCC)".
>
> Первая неудачная пересборка fwbuilder была, по-видимому, 9 ноября. Во
> всяком случае так датирован первый отчет об этом. Обычно такие отчеты
> я не удаляю, но даже если вдруг - в любом случае это был компилятор
> synced with FC 4.4.2-7.
>
> Поскольку у Вадима на федоровском 4.4.2-7 проблем нет, то
> напрашивается вывод, что причина регресии в альтовских патчах...

Я попробую разобраться.

Как hotfix можете добавить -fomit-frame-pointer в флаги компиляции
или убрать -g. Вроде помогает.

Re: [devel] Dramatic g++4.4 speed regression (was: g++4.3 vs g++4.4)

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 730 bytes --]

On Wed, Jan 20, 2010 at 12:33:28AM +0200, Kirill A. Shutemov wrote:
> 2010/1/19 Victor Forsyuk <force@altlinux.org>:
[...]
> > Первая неудачная пересборка fwbuilder была, по-видимому, 9 ноября. Во
> > всяком случае так датирован первый отчет об этом. Обычно такие отчеты
> > я не удаляю, но даже если вдруг - в любом случае это был компилятор
> > synced with FC 4.4.2-7.
> >
> > Поскольку у Вадима на федоровском 4.4.2-7 проблем нет, то
> > напрашивается вывод, что причина регресии в альтовских патчах...
> 
> Я попробую разобраться.
> 
> Как hotfix можете добавить -fomit-frame-pointer в флаги компиляции
> или убрать -g. Вроде помогает.

Если там используется -g, то претензии не принимаются. :)


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Dramatic g++4.4 -g speed regression

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1422 bytes --]

On Wed, Jan 20, 2010 at 02:02:44AM +0300, Dmitry V. Levin wrote:
> On Wed, Jan 20, 2010 at 12:33:28AM +0200, Kirill A. Shutemov wrote:
> > 2010/1/19 Victor Forsyuk <force@altlinux.org>:
> [...]
> > > Первая неудачная пересборка fwbuilder была, по-видимому, 9 ноября. Во
> > > всяком случае так датирован первый отчет об этом. Обычно такие отчеты
> > > я не удаляю, но даже если вдруг - в любом случае это был компилятор
> > > synced with FC 4.4.2-7.
> > >
> > > Поскольку у Вадима на федоровском 4.4.2-7 проблем нет, то
> > > напрашивается вывод, что причина регресии в альтовских патчах...
> > 
> > Я попробую разобраться.
> > 
> > Как hotfix можете добавить -fomit-frame-pointer в флаги компиляции
> > или убрать -g. Вроде помогает.
> 
> Если там используется -g, то претензии не принимаются. :)

Шутки шутками, но без -g, который зачем-то добавляет qmake, fwbuilder
собирается за разумное время:
687.48user 40.21system 12:16.51elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+8172274minor)pagefaults 0swaps

--- fwbuilder.spec
+++ fwbuilder.spec
@@ -86,6 +86,9 @@ Policy compiler for Cisco routers/firewalls.
 
 %build
 %configure --with-templatedir=%_datadir/%name
+find -type f -name Makefile -print0 |
+	xargs -r0 fgrep -lZ ' -g ' -- |
+	xargs -r0 sed -i 's/ -g / /g' --
 %make_build
 
 %install

Интересно, добавляет ли федорин qmake -g?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Dramatic g++4.4 speed regression (was: g++4.3 vs g++4.4)

[Boris Savelev]

>
> Если там используется -g, то претензии не принимаются. :)

убирание '-g' помогло. Спасибо.
Но как-то не правильно это-(

-- 
Boris

Re: [devel] Dramatic g++4.4 -g speed regression

[Sergey V Turchin]

[-- Attachment #1.1: Type: Text/Plain, Size: 287 bytes --]

On Wednesday 20 January 2010, Dmitry V. Levin wrote:

[...]
> Интересно, добавляет ли федорин qmake -g?
Если не патчат, должен, т.к. это конкретно указано (см. аттач)

-- 
Regards, Sergey, ALT Linux, http://www.altlinux.ru/
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #1.2: qmake.inc.in.patch --]
[-- Type: text/x-patch, Size: 403 bytes --]

--- qmake.inc.in~	2009-09-18 23:28:40 +0400
+++ qmake.inc.in	2010-01-20 14:50:20 +0300
@@ -58,7 +58,7 @@ unix {
 
         PKGLOCALEDIR = $$res.path/locale
 
-        CONFIG += warn_on debug
+        CONFIG += warn_on
         QMAKE_CFLAGS_DEBUG += -Wno-unused-parameter
         QMAKE_CFLAGS_RELEASE += -Wno-unused-parameter
         QMAKE_CXXFLAGS_DEBUG += -Wno-unused-parameter @CXXFLAGS@

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Dramatic g++4.4 speed regression (was: g++4.3 vs g++4.4)

[Victor Forsyuk]

2010/1/20 Kirill A. Shutemov <kirill@shutemov.name>:
>>
>> Поскольку у Вадима на федоровском 4.4.2-7 проблем нет, то
>> напрашивается вывод, что причина регресии в альтовских патчах...
>
> Я попробую разобраться.
>
> Как hotfix можете добавить -fomit-frame-pointer в флаги компиляции
> или убрать -g. Вроде помогает.

Подтверждаю, помогает!

При убирании -g пакет у меня собирается за 8:16 - это самый быстрый результат.

Если оставить -g, но при этом добавить -fomit-frame-pointer, то
собирается за 9:46 - вполне разумный оверхед.

Re: [devel] Dramatic g++4.4 -g speed regression

[Victor Forsyuk]

2010/1/20 Dmitry V. Levin <ldv@altlinux.org>:
>> > Как hotfix можете добавить -fomit-frame-pointer в флаги компиляции
>> > или убрать -g. Вроде помогает.
>>
>> Если там используется -g, то претензии не принимаются. :)
>
> Шутки шутками, но без -g, который зачем-то добавляет qmake, fwbuilder
> собирается за разумное время:
> 687.48user 40.21system 12:16.51elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k
> 0inputs+0outputs (0major+8172274minor)pagefaults 0swaps

>
> Интересно, добавляет ли федорин qmake -g?

Жду ответа от Вадима. И если у него -g не добавлялось я попросил
проверить, что произойдет при добавлении этой опции.
Если те же проблемы, то это epic fail апстрима, а не баги нашей сборки gcc.

Re: [devel] Dramatic g++4.4 -g speed regression

[Sergey V Turchin]

[-- Attachment #1: Type: Text/Plain, Size: 616 bytes --]

On Wednesday 20 January 2010, Victor Forsyuk wrote:

[...]
> Жду ответа от Вадима. И если у него -g не добавлялось я попросил
> проверить, что произойдет при добавлении этой опции.
> Если те же проблемы, то это epic fail апстрима, а не баги нашей
>  сборки gcc.
Я прикрепил в соседнем письме патч, после применения которого -g не 
добаляется. Он вполне очевиден.
Т.е. у Вадима -g может не добавляться без патчей только если Qt в 
федоре неправильно себя ведет или у него другая версия fwbuilder.

-- 
Regards, Sergey, ALT Linux, http://www.altlinux.ru/
http://stinkfoot.org:11371/pks/lookup?op=get&search=0x1C2A3F08

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Dramatic g++4.4 -g speed regression

[Igor Zubkov]

20 января 2010 г. 3:57 пользователь Dmitry V. Levin написал:
> Интересно, добавляет ли федорин qmake -g?

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

-- 
Igor Zubkov
http://hi.im/ice

Re: [devel] Dramatic g++4.4 speed regression (was: g++4.3 vs g++4.4)

[Victor Forsyuk]

2010/1/20 Dmitry V. Levin <ldv@altlinux.org>:
> On Wed, Jan 20, 2010 at 12:33:28AM +0200, Kirill A. Shutemov wrote:
>> 2010/1/19 Victor Forsyuk <force@altlinux.org>:
> [...]
>> > Первая неудачная пересборка fwbuilder была, по-видимому, 9 ноября. Во
>> > всяком случае так датирован первый отчет об этом. Обычно такие отчеты
>> > я не удаляю, но даже если вдруг - в любом случае это был компилятор
>> > synced with FC 4.4.2-7.
>> >
>> > Поскольку у Вадима на федоровском 4.4.2-7 проблем нет, то
>> > напрашивается вывод, что причина регресии в альтовских патчах...
>>
>> Я попробую разобраться.
>>
>> Как hotfix можете добавить -fomit-frame-pointer в флаги компиляции
>> или убрать -g. Вроде помогает.
>
> Если там используется -g, то претензии не принимаются. :)

Шутки шутками, но претензии принять придется - это баг нашей сборки, а
не апстрима gcc. Компилятор из FC12 спокойно справляется с кодом
fwbuilder с опцией "-g" и при отсутствии "-fomit-frame-pointer". Я
попросил Вадима показать строку вызова компилятора, вот она:

2009-11-29 20:51:02,307 [fc12] build-rpm.py:227 INFO /usr/bin/ccache
/usr/bin/distcc g++ -c -m32 -pipe -g -Wno-unused-parameter -O2 -g
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i686 -mtune=generic
-fasynchronous-unwind-tables -Wall -W -D_REENTRANT -DQT_GUI_LIB
-DQT_NETWORK_LIB -DQT_CORE_LIB -I/usr/lib/qt4/mkspecs/linux-g++-32 -I.
-I/usr/include/QtCore -I/usr/include/QtNetwork -I/usr/include/QtGui
-I/usr/include -I.. -I../.. -I/usr/include/fwb-3
-I/usr/include/libxml2 -I../../src -I.moc -I.ui -o
.obj/moc_NetworkDialogIPv6.o .moc/moc_NetworkDialogIPv6.cpp

Re: [devel] Dramatic g++4.4 -g speed regression

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2513 bytes --]

On Thu, Jan 21, 2010 at 02:32:29PM +0200, Victor Forsyuk wrote:
> 2010/1/20 Dmitry V. Levin <ldv@altlinux.org>:
> > On Wed, Jan 20, 2010 at 12:33:28AM +0200, Kirill A. Shutemov wrote:
> >> 2010/1/19 Victor Forsyuk <force@altlinux.org>:
> > [...]
> >> > Первая неудачная пересборка fwbuilder была, по-видимому, 9 ноября. Во
> >> > всяком случае так датирован первый отчет об этом. Обычно такие отчеты
> >> > я не удаляю, но даже если вдруг - в любом случае это был компилятор
> >> > synced with FC 4.4.2-7.
> >> >
> >> > Поскольку у Вадима на федоровском 4.4.2-7 проблем нет, то
> >> > напрашивается вывод, что причина регресии в альтовских патчах...
> >>
> >> Я попробую разобраться.
> >>
> >> Как hotfix можете добавить -fomit-frame-pointer в флаги компиляции
> >> или убрать -g. Вроде помогает.
> >
> > Если там используется -g, то претензии не принимаются. :)
> 
> Шутки шутками, но претензии принять придется - это баг нашей сборки, а
> не апстрима gcc. Компилятор из FC12 спокойно справляется с кодом
> fwbuilder с опцией "-g" и при отсутствии "-fomit-frame-pointer". Я
> попросил Вадима показать строку вызова компилятора, вот она:

Это не та строка.  Сборка виснет на другом файле (DiscoveryDruid.cpp),
который использует заголовки из других пакетов:

g++ -c -pipe -g -Wno-unused-parameter -pipe -Wall -O2 -march=i586 -mtune=i686 -Wall -W -D_REENTRANT -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtGui -I/usr/include/qt4 -I.. -I../.. -I/usr/include/fwb-3 -I/usr/include/libxml2 -I../../src -I.moc -I.ui -o .obj/DiscoveryDruid.o DiscoveryDruid.cpp
DiscoveryDruid.cpp: In member function 'libfwbuilder::InetAddr DiscoveryDruid::getSeedHostAddress()':
DiscoveryDruid.cpp:817: warning: format not a string literal and no format arguments
DiscoveryDruid.cpp:828: warning: format not a string literal and no format arguments
DiscoveryDruid.cpp: In member function 'void DiscoveryDruid::loadDataFromCrawler()':
DiscoveryDruid.cpp:1425: warning: format not a string literal and no format arguments
DiscoveryDruid.cpp:1434: warning: format not a string literal and no format arguments
DiscoveryDruid.cpp:1458: warning: format not a string literal and no format arguments

[...]
> .obj/moc_NetworkDialogIPv6.o .moc/moc_NetworkDialogIPv6.cpp

.moc/moc_NetworkDialogIPv6.cpp это генерат, он может отличаться,
сравнивать его пока не очень интересно.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Dramatic g++4.4 -g speed regression

[Victor Forsyuk]

2010/1/21 Dmitry V. Levin <ldv@altlinux.org>:
>>
>> Шутки шутками, но претензии принять придется - это баг нашей сборки, а
>> не апстрима gcc. Компилятор из FC12 спокойно справляется с кодом
>> fwbuilder с опцией "-g" и при отсутствии "-fomit-frame-pointer". Я
>> попросил Вадима показать строку вызова компилятора, вот она:
>
> Это не та строка.  Сборка виснет на другом файле (DiscoveryDruid.cpp),
> который использует заголовки из других пакетов:

OK, на контрольный вопрос я получил ответ:

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

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

Re: [devel] Dramatic g++4.4 -g speed regression

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

On Thu, Jan 21, 2010 at 07:18:32PM +0200, Victor Forsyuk wrote:
> >>
> >> Шутки шутками, но претензии принять придется - это баг нашей сборки, а
> >> не апстрима gcc. Компилятор из FC12 спокойно справляется с кодом
> >> fwbuilder с опцией "-g" и при отсутствии "-fomit-frame-pointer". Я
> >> попросил Вадима показать строку вызова компилятора, вот она:
> >
> > Это не та строка.  Сборка виснет на другом файле (DiscoveryDruid.cpp),
> > который использует заголовки из других пакетов:
> 
> OK, на контрольный вопрос я получил ответ:
> 
> "опции задаются глобальной переменной в Makefile так что они все
> одинаковые для всех модулей. Makefile строится автоматически, так что
> если опция появляется для одного модуля, то она появится и для
> другого"
> 
> Так что это бага не в апстриме. Возможно у нас приложен неудачный
> патч, либо неудачно сложился како-то набор патчей.

На какой из вовлеченных в эту историю пакетов?  Похоже что пора переходить
к сравнению результата обработки DiscoveryDruid.cpp препроцессором, вывода
g++ -dumpspecs и прочим интересным деталям.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [devel] Dramatic g++4.4 -g speed regression

[Victor Forsyuk]

2010/1/21 Dmitry V. Levin <ldv@altlinux.org>:
>> > Это не та строка.  Сборка виснет на другом файле (DiscoveryDruid.cpp),
>> > который использует заголовки из других пакетов:
>>
>> OK, на контрольный вопрос я получил ответ:
>>
>> "опции задаются глобальной переменной в Makefile так что они все
>> одинаковые для всех модулей. Makefile строится автоматически, так что
>> если опция появляется для одного модуля, то она появится и для
>> другого"
>>
>> Так что это бага не в апстриме. Возможно у нас приложен неудачный
>> патч, либо неудачно сложился како-то набор патчей.
>
> На какой из вовлеченных в эту историю пакетов?

На gcc4.4. Других вовлеченных пакетов не наблюдаю.

>  Похоже что пора переходить
> к сравнению результата обработки DiscoveryDruid.cpp препроцессором, вывода
> g++ -dumpspecs и прочим интересным деталям.

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

Re: [devel] Dramatic g++4.4 -g speed regression

[Kirill A. Shutemov]

2010/1/22 Victor Forsyuk <force@altlinux.org>:
> 2010/1/21 Dmitry V. Levin <ldv@altlinux.org>:
>>> > Это не та строка.  Сборка виснет на другом файле (DiscoveryDruid.cpp),
>>> > который использует заголовки из других пакетов:
>>>
>>> OK, на контрольный вопрос я получил ответ:
>>>
>>> "опции задаются глобальной переменной в Makefile так что они все
>>> одинаковые для всех модулей. Makefile строится автоматически, так что
>>> если опция появляется для одного модуля, то она появится и для
>>> другого"
>>>
>>> Так что это бага не в апстриме. Возможно у нас приложен неудачный
>>> патч, либо неудачно сложился како-то набор патчей.
>>
>> На какой из вовлеченных в эту историю пакетов?
>
> На gcc4.4. Других вовлеченных пакетов не наблюдаю.
>
>>  Похоже что пора переходить
>> к сравнению результата обработки DiscoveryDruid.cpp препроцессором, вывода
>> g++ -dumpspecs и прочим интересным деталям.
>
> Или идти с другого конца и смотреть нет ли чего в обсуждениях и
> ченжлогах апстрима. Или откатом к предыдущим сборкам сизифного gcc
> найти ту, в которой баги не было и сравнивать патчи...

Fixed in gcc-4.4.3-alt1.