Отладка процесса оптимизации кода в GCC

Картинка для привлечения внимания!

Собственно, встал ребром вопрос - как искать и фиксить проблемы, возникающие на этапе оптимизации кода by GCC, т.е. в процессе AST -> SSA (+ оптимизация) ->RTL трансформаций?
Портированный GCC прошел большую-пребольшую пачку тестов, но 14 штук стали непреодолимой преградой. В жизни не портировал компилятор с самодельным backend`ом - буду рад любой ссылке на малейший кусочек информации по проблеме. Референсы на знающих людей тоже подойдут (Столмана не предлагать :)).

И снова, и снова, и снова - GCC

Многие (жаль, что не все) программисты, которые используют С++, знают, что нельзя память, выделенную malloc`ом освобождать через delete.
Ну не то, чтобы запрещенно было (в стандарте как всегда прописано - undefined behavior)... Ну не то, чтоб не работало - под VS 2005/2008 прекрасно бегал такой кусок кода (жаль, не могу познакомиться с автором). Да вот незадача - при компилировании такой лажи GCC 2.95.2 компилятор выдаёт невнятное сообщение и тихонько замолкает.
Убил полдня на вот такую "да_это_же_все_знают" хрень.

Программерское чтиво

"Сделать сложно - просто, сделать просто - сложно" (c) G.W.

Внимание! Пост проплачен здравым смыслом

Я перекопал достаточное количество чужого кода и думал что видел если не всё, то многое :)

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

call_mngr_cbs_t call_mngr_cbs = {
    play_signal: play_signal_cb,
    start_signal: start_signal_cb,
    stop_signal: stop_signal_cb,
    update_display: display_update_cb,
    dialstring_is_complete: dialstring_is_complete_cb,
    dialstring_to_addr: dialstring_to_addr_map_cb,
    prepare_connection: line_connection_prepare_cb,
    create_connection: line_connection_create_cb,
    start_connection: line_connection_start_cb,
    stop_connection: line_connection_stop_cb,
    modify_connection: line_connection_modify_cb,
    destroy_connection: line_connection_destroy_cb,
    set_endpoint_context: line_connection_context_create,
    free_endpoint_context: line_connection_context_destruct,
    is_state: is_state_cb,
    enum_codecs: enum_codecs_cb
};

Пишу я в основном на С++ (дзен-буддизм Си приходит ко мне не всегда), пришлось подумать секунд 10 что это за хрень :): мозг прошел через все шаги типа "Ой - Фигасе - Ну и нафиг это".

Для тех, кому лень включать мозг - ответ: инициализатор структур в С, в данном случае инициализирует члены структуры указателями на функции. Таких приспособлений в коде пачка, разобраться что и откуда вызывается - проблематично. Не пишите такой код, иначе вас настигнет кара - я гарантирую это :).
ИМХО, после того как все фичи Фортрана заклёпками приштопают к С, сам язык можно будет спокойно положить на полку и заменить на С++.

Компиляторы бывают разные

И вновь продолжается бой :). Очередная мобильная платформа, новые спеки, новый компилятор и очередной порт STL.

Ничто не предвещало беды: ни убогая поддержка шаблонов (поубивал бы тех, кто отключает поддержу default parameters), ни время компиляции (15 минут - не предел, этот монстр еще и 1.5 гига ОЗУ кушает при этом), ни отсутствие документации (и правильно, закрытую платформу да без доки точно никто не осилит). Проблема нарисовалась при переносе старой самописной библиотечки шаблонных полезностей. Итак, имеем вот такую штуку (досталась в наследство со времен царя Гороха и кочевала по проектам чёрт знает сколько):

struct DeletePtr_t
{
public:
template
void operator()(const Ptr* const &toDel) const
{
delete toDel;
}

template
void operator()(Ptr* &toDel)
{
delete toDel;
toDel = NULL;
}
};

Такой "замысловатой" конструкции компилятор не осилил, как не осилил он и выдать хоть какую-нить информацию, в том числе где навернулся и почему. Разработчики компилятора решили просто: навернулись ну и хрен "Error 2" с ним, посему, крепко выругавшись задумавшись, методом половинного деления и было найдено место преступления.
Код был проверен набором онлайн-компиляторов и скомпилился без проблем. Проблемы у существующего компилятора возникаю здесь:

void operator()(const Ptr* const &toDel) const

при этом следующие варианты работают без проблем

void operator()(Ptr* const &toDel) const
void operator()(const int* const &toDel) const

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

П.С. Как бы прикрутить подсветку и форматирование кода? Очень неудобно...