Готово же! GCC 4.7.0 (frozen for release)

Какие его нововведения?

Заголовок прочел как «Говно же!»

http://gcc.gnu.org/gcc-4.7/changes.html

Могу сделать (с субъективно самыми важными фичами) чейнджлог на русском, если нужно (для новости, например, это точно придётся). А так да, как обычно, на gcc.gnu.org есть огромный чейнджлог.

Заголовок прочел как «Говно же!»

Ты слишком параноидально пытался найти в чужих Ш обилие Г, и этим самым испортил себе глаза.

Вы что, я не любитель. На телефоне кино смотрел

Сделайте, буду премного благодарен.

Может ты лучше новость напишешь?

http://gcc.gnu.org/gcc-4.7/cxx0x_status.html

Minimal support for garbage collection and reachability-based leak detection — No

Ололо

Дэвтим GCC говорит, что не раньше апреля объявят о релизе и выпустят «оффициальные®» тарболлы (а не снэпшоты). Ну в общем, пока о релизе делать новость рано.

Есть же BDW-GC... Хотя они его не адоптят почему-то, там старый Boehm только.

Ну вот...
Мир пересобирать...

Его еще не скоро, наверное, размаскируют. А так да, пересобирать...(

Заголовок прочел как «Говно же!»

LLVM forever!

Ура! Ждём, пока он будет стабильным и включен в релиз AgiliaLinux 9.0.

std::thread так толком и не поддерживается?

link-time optimization (LTO) improvements:

Improved scalability and reduced memory usage. Link time optimization of Firefox now requires 3GB of RAM on a 64-bit system, while over 8GB was needed previously. Linking time has been improved, too. The serial stage of linking Firefox has been sped up by about a factor of 10.

это лютый вин. (если конечно использование для линковки 3G ОЗУ вообще можно назвать вином)

Вот за что стоит сказать спасибо фраерфоксу: своим говнокодом они вынуждают разработчиков оптимизировать компиляторы =)

странно, у меня памяти 2гига, а ФФ собирается всегда нормально. т.е я теперь должен считать, что он у меня плохо оптимизированный, если памяти не хватало ?

64-bit system

?

А вообще да, firefox такой firefox.

GCC готов для десктопа?

A string length optimization pass has been added. It attempts to track string lengths and optimize various standard C string functions like strlen, strchr, strcpy, strcat, stpcpy and their _FORTIFY_SOURCE counterparts into faster alternatives. This pass is enabled by default at -O2 or above, unless optimizing for size, and can be disabled by the -fno-optimize-strlen option. The pass can e.g. optimize

char *bar (const char *a)
{
  size_t l = strlen (a) + 2;
  char *p = malloc (l); if (p == NULL) return p;
  strcpy (p, a); strcat (p, "/"); return p;
}
      

into:

char *bar (const char *a)
{
  size_t tmp = strlen (a);
  char *p = malloc (tmp + 2); if (p == NULL) return p;
  memcpy (p, a, tmp); memcpy (p + tmp, "/", 2); return p;
}
      

or for hosted compilations where stpcpy is available in the runtime and headers provide its prototype, e.g.

void foo (char *a, const char *b, const char *c, const char *d)
{
  strcpy (a, b); strcat (a, c); strcat (a, d);
}
      

can be optimized into:

void foo (char *a, const char *b, const char *c, const char *d)
{
  strcpy (stpcpy (stpcpy (a, b), c), d);
}

Весело.

странно, у меня памяти 2гига, а ФФ собирается всегда нормально.

На 64 битах с включённым LTO?

а зачем? я не гентушник.

Дай соус своей аватарки пожалуйста :)

http://dl.dropbox.com/u/970716/Картинки/Тёлачки 1/-34175620_276664216.jpg

да, у меня 64 бит

ты хочешь сказать, что включение оптимизации увеличивает потребление памяти в разы ?

Потребление памяти при компиляции - да, возможно.