Вот за обзор нововведений в Фортране спасибо!

Ну наконец фортран тронули.. теперь бы еще OpenACC допилили, желательно для всех карточек..

libgccjit

И давно оно в «стандартной» поставке?

Можно начинать грабить корованы без llvm? ))

libgccjit появилась в GCC 5.1 в экспериментальном статусе.

Можно начинать грабить корованы без llvm? ))

Не уверен насколько полное API у libgccjit, но судя по тому, что новые релизы мало что добавляют, должно быть довольно полным. Ну и в этом лагере люди обычно знают о том, что такое обратная совместимость, что является огромным плюсом.

либу для генерации кода libgccjit-ом по какому-нибудь «дереву» еще ни кто не сварганил?

Я не видел такого.

В принципе сопоставимы.

gcc-9.1.0.tar.xz ~67 МБ.

llvm-8.0.0.src.tar.xz + cfe-8.0.0.src.tar.xz + lld-8.0.0.src.tar.xz + compiler-rt-8.0.0.src.tar.xz + clang-tools-extra-8.0.0.src.tar.xz + lldb-8.0.0.src.tar.xz+ openmp-8.0.0.src.tar.xz ~61 МБ.

К нашей пенсии может и допилят

Я опасаюсь, если честно, что его допилят раньше.. но после того как появятся устройства превосходящие видеокарты в распараллеливании(

Всё вроде кул, я негодовал по поводу вывода ошибок в стиле кланга, но вот смотрю и хз я так и не понял можно вернуть обатно вывод что бы можно было прогонять через grep путно?

$ g++ -Wall -Wextra t.cpp -fno-diagnostics-show-caret
t.cpp: In member function ‘boxed_value& boxed_value::operator=(const boxed_value&)’:
t.cpp:21:1: warning: no return statement in function returning non-void [-Wreturn-type]
t.cpp: In function ‘int test(const shape&, const shape&)’:
t.cpp:25:23: error: no match for ‘operator*’ in ‘width(((* & s1), shape())) * height(((* & s1), shape()))’ (operand types are ‘boxed_value’ and ‘boxed_value’)
t.cpp:25:48: error: no match for ‘operator*’ in ‘width(((* & s2), shape())) * height(((* & s2), shape()))’ (operand types are ‘boxed_value’ and ‘boxed_value’)
t.cpp: In function ‘int main()’:
t.cpp:33:15: error: cannot convert ‘bool’ to ‘void*’
t.cpp:28:19: note:   initializing argument 2 of ‘void callee(int, void*, int)’
t.cpp:34:5: error: ‘printf’ was not declared in this scope
t.cpp:34:5: note: ‘printf’ is defined in header ‘<cstdio>’; did you forget to ‘#include <cstdio>’?

И это не стиль шланга, а стиль какого-то старого компилятора Паскаля.

Я имею в виду как на скрине, когда зелёненьким и красненьким идёт сноска вниз, такое я в шланге только видел и это грепать невозможно. Я лично если ошибок много привык просто через ключевое слово их фильтровать по типу, а как теперь хз. Ну в смысле всё будет видно конечно, но всё же

UDP: хотя стоп! Оно же там просто уточняется куда и что, чёт я ступил. Тогда разве что сноски кудут иногда мешать, грепать можно. Панику отменяю

Язык D версии 2.076 включён в состав GCC.

Главная новость. Вообще интересно было бы потыкать.

Важно, чтобы они в D новые версии своевременно интегрировали. А то сейчас уже 2.086 доступна, а у них до сих пор 2.076. Конечно, сейчас изменения стали не столь значительными и объём кодовой базы уже достаточно велик, но 10 версий --- это через чур.

Я и показал, что оно всё отключается добавлением -fno-diagnostics-show-caret. Это тот же gcc и тот же t.cpp, что и на скрине.

Включение теперь --- чистая формальность, поскольку gdc уже в 9 Дебиане есть и я им программы ещё в 2015 компилировал, так как получившиеся бинарники оказываются существенно производительнее, чем при использовании референсного компилятора или lldc. Главное, чтобы они новые версии достаточно оперативно интегрировали, с этим у них как раз большие проблемы были всегда. Если включение в состав gcc официально решит эту проблему, то будет здорово!

Ааа. Нуда, ступил в квадрате я.

А то сейчас уже 2.086 доступна

A-a-a!

struct A
{
    this(ref return scope A rhs) {}                        // copy constructor
    this(ref return scope const A rhs, int b = 7) {}       // copy constructor with default parameter
}

Ну блин, четыре ключевых слова подряд перед типом параметра: ref return scope const. Что они там курят?

Давно не заглядывал в D, даже нет предположения о том, что может означать return scope перед обозначением типа аргумента.

Я надеюсь, что это поспособствует увеличению популярности языка программирования D.

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

Да, если вспомнить gcj, то его судьба была печальной.

Я регулярно на нём пишу, но я тоже не знаю :) Вообще, я считал, что D — это в моей практике второй по очевидности синтаксиса язык после Питона. Но приведённый код опровергает данное утверждение. А откуда вы взяли приведённый пример?

что может означать return scope перед обозначением типа аргумента.

Предположение: имеет смысл в области видимости ворзвращаемого значения. ref return scope - ссылка в/из области видимости возвращаемого значения. Вариация на тему контроля lifetime'ов.

В документации написано:

Parameters marked as return scope that contain indirections can only escape those
indirections via the function's return value.

Вообще, я считал, что D — это в моей практике второй по очевидности синтаксиса язык после Питона. Но приведённый код опровергает данное утверждение.

D был простым и понятным во времена D1. Но после пришествия Александреску D2 понесся в неведомые дали с невероятной скоростью :)

А откуда вы взяли приведённый пример?

Так это же из анонса версии 2.086: https://dlang.org/changelog/2.086.0.html#copy_constructor

Я тоже заметил, что Александреску намутил там много чего. Часть по делу, а часть — нет. В частности, слишком много ключевых слов для идентификаторов.

Ну вот и хорошо, что он над D изгаляется. Хороший полигон для C++ных нововведений. За один только if constexpr можно большое спасибо сказать (хотя в плюсах можно было бы и помощнее if constexpr сделать).

Ну вот вам-то может и лучше, а нам, кто на D пишет, приходится приспосабливаться.

2 раза перепроверил, что речь о GCC, а не о Clang.

Молодец дедушка! Еще покажет молодым!

gccjit

Я думал оно мертво 0w0

Так и не понял (в руководстве к gfortran не нашёл), что они имели ввиду под

• Type parameter inquiry via str%len and a%kind has been implemented.

Хороший повод для изучения D %)

Кстати, gcc9, gcd еще в Arch даже не завезли, поэтому кто хочет попробоватьm, но компилировать лень, может скачать архивы slackware-current, распаковать + смержить их, и запустить командой:

LD_LIBRARY_PATH=lib64/ ./bin/gdc

• GCC: http://mirror.yandex.ru/slackware/slackware64-current/slackware64/d/gcc-9.1.0...
• MPFR: http://mirror.yandex.ru/slackware/slackware64-current/slackware64/l/mpfr-4.0....
• GDC: http://mirror.yandex.ru/slackware/slackware64-current/slackware64/d/gcc-gdc-9...

В генту завезли дня 2-3 назад, уже мир перекомпилял (не собрались avidemux* и qtcore).

Похоже, что вместо len(str) можно будет писать str%len.

Да, на лителарах не работает правда.

Странно, почему не вместо len_trim(str), но может и так.

Страшно представить, что возвращает a%kind, учитывая, что одну точность представления можно описать несколькими способами, для которых этот вызов скорее всего не сработает.

И а чём плюс таких, похоже непереносимым, вызовов? О_о

Я попробовал мир FreeBSD 12-STABLE пересобрать только что ответвившимся GCC10-devel (это фактически GCC9.1, который ещё не портировали). Естественно, без сборки всего того, что не нужно на десктопе. Столкнулся с многочисленными ошибками компиляции системной libc, в частности, с интегрированным в неё кодом ICONV. Отключил и это в src.conf, повторил - всё равно простыня ошибок вылезла. Раньше, с GCC8 удавалось с минимальными правками собрать работающую базовую систему и почти все установленные пакеты.

Я при переезде с 7.4 на 8.2 (и почти сразу на 8.3) пересобирал только libtool и после удаления старых версий делал revdep-rebuild. 9.1 собрал только с целью проверить сборку и тесты поддерживаемых мной пакетов.

Только что пересобрал dev-qt/qtcore-5.12.3 с помощью gcc-9.1.0, всё нормально собралось. Также на днях ядро 5.1.0 им собирал и glibc-2.28-r6, тоже без проблем.

Строки в Фортране — это вообще большое место. Шаг влево, шаг вправо — расстрел. Именно из-за необходимости интенсивно работать со строками я частенько стал писать код на D. И ещё потому, то для линковки с фортрановскими либами, которые почти все реализованы на 77 диалекте, нужно писать очень много кода внутри, вводя и расставляя все служебные переменные.

Только что пересобрал dev-qt/qtcore-5.12.3 с помощью gcc-9.1.0, всё нормально собралось.

Вполне верю, но у меня qt стабильный: qtcore-5.11.3-r2.

Знаю, что больное, но не больнее чем в Си.

Есть библиотека StringiFor, которая реализует python-подобные операции со строками в Фортране. Её разработчик занимается задачами газовой динамики, судя по профилю. Я хотел опакетить библиотеку для gentoo, даже набросок ebuild был, собирающий её, но всё никак не потормошу как следует её разработчика на предмет запуска тестов после сборки на основе make (не все тесты, кажется прописаны). Он в основном использует свою собственную систему сборки для проектов на Фортране, опакечивать которую и тянуть как зависимость у меня пока желания нет.

Я 10 лет назад написал свою небольшую библиотеку для работы со строками и чтения двумерных массивов, до сих использую. Но всё это всё равно костыли.

я тя умоляю)))))))))))))) прям заржал.

Смех без причины…

www.linux.org.ru/people/linuxpc/profile

Блокирован 12.05.19 19:13:33, модератором Dimez по причине: Троллинг тупостью

В кои-то веки Dimez хоть что-то полезное сделал...

Ору

А где исходник примера из новости пощупать можно?

А где исходник примера из новости пощупать можно?

https://wandbox.org/permlink/gJpBGoUlya7SaOxq

Благодарствую.

Решил потыкать немного D, после новости. Руки только щас дошли. Почитал пару страниц на сайте, тыкнул первый попавшийся пример https://dlang.org/library/std/stdio/file.readf.html - пример не скомпилялся, закрыл сайт.

Думаю, надо смотреть документацию для v2.076.