LINUX.ORG.RU

Обновления компиляторов C, C+, Fortran

 , , , ,


1

10

В конце прошлого начале этого года ряд компаний по традиции обновили своикроссплатформенные компиляторы и дополнительные инструменты, прежде всего для распараллеливания вычислений, для разработки на языках C, C++ и Fortran (в обязательном порядке):

PGI 2020.1. Community Edition версия компилятора выходит пару раз в год и по условиям лицензии ей разрешается пользоваться год с момента выхода. Текущая такая версия PGI CE 19.10.

Intel Parallel Studio XE 2020.

Absoft Pro Fortran 2020 - для разработки только на Fortran.

NAG Fortran Compiller 7.0.

AOCC 2.1 - набор компиляторов на основе llvm 9.0 (clang, flang) с патчами от AMD. Предположу, что в состав входит flang на основе старого проекта, а не переименованный f18, который собираются включить в поставку llvm 11, если снова не опоздают.

Во всех, где это возможно, заявлена полная поддержка C++17, местами продолжили добавлять/обновлять начальную поддержку C++20 и Fortran 2018.

★★★★★

Ответ на: комментарий от RazrFalcon

А потом оказывается что ваш код не собирается MSVC, ибо у них вечно какие-то странные реализации стандарта.

Рекомендую изучить табличку: https://en.cppreference.com/w/cpp/compiler_support

MSVC имеет лучшую поддержку С++ вплоть до С++17, отсутствует лишь aligned_alloc, и то лишь потому что это вина стандартной библиотеки С…

Код не собирается если он затачивался на gcc вместо стандарта плюсов. С поддержкой именно стандартов у MSVC всё замечательно, по крайней мере в текущей версии VS 2019

fsb4000 ★★★★★
()
Ответ на: комментарий от fsb4000

отсутствует лишь aligned_alloc, и то лишь потому что это вина стандартной библиотеки С…

А вот здесь поподробнее. Опять Сишечка Майкрософту в штаны насрала?

anonymous
()
Ответ на: комментарий от RazrFalcon

Но истерику закатил не я…

Я вам еще раз повторяю - не нужно хамить. В тред залезли вы со своей якобы «критикой». Я всего лишь написал что в D удобно работать с другими языками. Без сравнения с другими языками, а просто в контексте того, что из D можно использовать библиотеки из других языков. В D есть поддержка С, С++, Obj-C, Python, R, сейчас стадии активного завершения идут работы по поддержке Java и Webassembly. Эта поддержка заключается как просто в библиотеках, так и поддержке со стороны компилятора и библиотеки времени выполнения. Вот и весь смысл моего поста. Еще раз повторяю, я просто написал, что в D есть поддержка других без сравнения с другими языкам. Имея в виду, что для небольших научных исследовательских задач D подходит сам по себе, плюс есть возможность использовать уже существующие библиотеки. А вы начали спрашивать чем это лучше других языков. И получается что это вы начали орать и истерить, что D не подходит. А теперь сравните содержательность моих постов и содержательность ваших. И прекратите лажать. Я не занимаюсь продажей языка. Я лишь подсказал человеку, что есть возможность использовать D для небольших исследовательских задач. Привел примеры как D используют для решения задач в области гидродинамики. Постарался дать человеку информацию, чтобы ему было легче принять решения нужно ему это или нет. При этом мне и в голову не придет проводить какой-то сравнительный анализ, дать развернутые ответы на всевозможные мелочи и т.д. Человек задал вопрос, получил на него некий ответ. Он уже и в теме то не отписывается. Лишь вы только засоряете тему переходя на личности, потому что по сути вам сказать то и нечего.

yetanother ★★
()
Ответ на: комментарий от anonymous

А вот здесь поподробнее. Опять Сишечка Майкрософту в штаны насрала?

Есть функция https://en.cppreference.com/w/cpp/memory/c/aligned_alloc

Память выделенная этой функцией должна освобождаться функцией free.

Microsoft сказала что не может сделать такую функцию в С++, потому что тогда нужно менять поведение функции free и ломать ABI.

Вот короче их ответ на вопрос когда они сделают alligned_alloc:

aligned_alloc() will probably never be implemented, as C11 specified it in a way that’s incompatible with our implementation (namely, that free() must be able to handle highly aligned allocations).

Если что в Microsoft есть функции _aligned_malloc и _aligned_free так что написать свою кросскомпиляторную обёртку несложно.

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от fsb4000

MSVC имеет лучшую поддержку С++ вплоть до С++17

Если верить вашей же табличке, то поддержка C++17 у них такая же как и у всех.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Не помню, чтобы они позиционировали свой компилятор, как специализированный на Си.

grem ★★★★★
() автор топика
Ответ на: комментарий от fsb4000

Какой ужас. gcc поддерживает на одну фичу меньше. msvc впереди планеты всей!

RazrFalcon ★★★★★
()
Последнее исправление: RazrFalcon (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

Выше уже упоминалось, что использовать C++ без C - нереально.

Кем? Покрытие c++ не означает полное покрытие c11.

И многие из сишных проектов на C11.

Даже если принять на веру это голословное утверждение, то причём тут компилятор от microsoft?

grem ★★★★★
() автор топика
Ответ на: комментарий от grem

Есть проект на C++. Он использует C11 либу. Как мне его собрать через MSVC? С и C++ идут в тандеме. Нельзя поддерживать C++ без C.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Если ты не замечал, то у всех компаний предоставляющих компиляторы, компиляторы C и C++ - отдельные исполняемые файлы и это, надо полагать, не просто так.

Есть проект на C++. Он использует C11 либу. Как мне его собрать через MSVC?

Понятия не имею. MSVC не предоставляет, насколько я помню, отдельный компилятор C, поэтому поддержку C11 они никогда и не обещали и ожидать её немного странно. Поэтому ещё более странно брать для сборки чего-то неподходящие для этого инструменты.

С и C++ идут в тандеме. Нельзя поддерживать C++ без C.

Вот свои фантазии не надо тут.

grem ★★★★★
() автор топика
Ответ на: комментарий от grem

Какие ещё фантазии? Любой мало-мальский C++ проект так или иначе зависит от C. А значит его тоже нужно чем-то собирать.

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Завязывай с троллингом тупостью. Стандарты C++ не обеспечивают полной совместимости со стандартами C и реализаций всех фич второго. И ты не можешь этого не знать.

Но если ты так уверен, то попробуй собрать какой-нибудь пример с использованием «_Genetic» компилятором C++: clang++ очень удивится, например.

А значит его тоже нужно чем-то собирать.

Компилятором C?

Или OpenBLAS зависящий от BLAS и LAPACK надо собирать тоже компилятором C++? Ну удачи.

grem ★★★★★
() автор топика
Ответ на: комментарий от stasolog

Да всё верно, можно использовать clang C компилятор, но стандартная библиотека останется от Microsoft, а там нет всяких threads.h и stdatomic.h, но вроде все С99 инклюды есть.

Если реально есть проблема, что нужно собрать какой-то С++ проект, который использует С11 либу, то можно собрать эту либу с помощью mingw-w64 и использовать дальше в MSVC проекте.

У mingw и MSVC только плюсовое ABI разное, C ABI одинаковое, так что сишными либами можно обмениваться.

fsb4000 ★★★★★
()
Ответ на: комментарий от RazrFalcon

В расте нет динамической линковки. Поэтому и проблемы такой нет.

А если код совсем не писать, так вообще проблем не будет

annulen ★★★★★
()
Ответ на: комментарий от grem

Компилятором C?

То есть вместо С компилятора MSVC используем другой С компилятор? Очень продуктивно.

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Вместо компилятора C++ использовать компилятор C и неважно что за реализация компилятора C++: я привёл пример, где это просто необходимо. Не притворяйся идиотом. В таких случаях используются библиотеки.

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

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

grem ★★★★★
() автор топика
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от RazrFalcon

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

grem ★★★★★
() автор топика
Ответ на: комментарий от stasolog

Разве их кто то использовал?

Mesa использует, но у них своя обертка над pthreads и win32.

goto-vlad
()
Ответ на: комментарий от stasolog

если хотели получить максимальную совместимость с другими системами то нет.

Если просто написать что-то на стандартном С, то да.

Но писать переносимый код можно, просто добавлять условие есть threads.h ? если нет, то использовать врапперы:

  1. https://github.com/tinycthread/tinycthread

  2. Или как уже сказали выше, можно использовать враппер из mesa(там Boost Software License, Version 1.0): https://cgit.freedesktop.org/mesa/mesa/tree/include/c11

fsb4000 ★★★★★
()
Ответ на: комментарий от RazrFalcon

Конечно, конечно. Куда мне до опыта успешной сборки кода содержащего фичи о которых компилятор ничего не знает.

grem ★★★★★
() автор топика
Ответ на: комментарий от RazrFalcon

Ну вы же лжете наглым образом. Вам прекрасно известно, что в D поддержка сишного кода намного лучше чем в том же Расте. Так что про преимущество D в этом плане никакого 4.2 нет. А вы просто делаете вбросы. Или вы будете отрицать очевидное?

yetanother ★★
()
Ответ на: комментарий от RazrFalcon

Вот пример возможностей D в плане взаимодействия с другими языками.

This repository is an example of using D's powerful metaprogramming features to enable calling C code from Python without having to write any code at all.

Обращаю внимание, что ни одной строчки кода ни на C, ни на Питоне писать не нужно. И только 4(!) строчки на D. Причем три из этих строчек это имена файлов на С и Питоне. И это будет работать и для других языков.

Вот и покажите, как такую функциональность можно реализовать на другом языке - и получите ответ, в чем преимущество D.

yetanother ★★
()
Ответ на: комментарий от yetanother

Вам прекрасно известно, что в D поддержка сишного кода намного лучше чем в том же Расте.

С чего бы это? Я с D никогда не работал. Чем поддержка Си в нём лучше?

RazrFalcon ★★★★★
()
Ответ на: комментарий от yetanother

Я правильно понимаю, что они генерируют биндинги на этапе компиляции? Это конечно здорово, но я могу вызвать bindgen в build.rs, всё те же 4-е строчки, получить тот же самый результат.

Или оно каким-то образом оборачивает сишные в идиоматический D код?

RazrFalcon ★★★★★
()
Ответ на: комментарий от RazrFalcon

Я с D никогда не работал

О, замечательный пример «не читал, но осуждаю». Так, а как вы обсуждаете язык, с которым никогда не работали?

Чем поддержка Си в нём лучше?

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

Более того, в D вы можете работать и с плюсовым кодом включая шаблоны(!), там не 100% поддержка, но тем не менее. Раст, насколько я знаю, плюсовый код вообще не может использовать.

yetanother ★★
()
Ответ на: комментарий от RazrFalcon

Или оно каким-то образом оборачивает сишные в идиоматический D код?

This.

И не просто оборачивает, но и автоматически формирует врапперы для других языков типа Питона и Сишарпа.

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

yetanother ★★
()
Ответ на: комментарий от yetanother

Ок. Ну вот есть сишная функция, которая принимает список файлов:

void process_files(const char **files, int size);

Как мне её вызвать из D, если у меня файлы в vector<string>?

RazrFalcon ★★★★★
()
Ответ на: комментарий от yetanother

Нет конечно. Пока что никаких преимуществ я не увидел.

RazrFalcon ★★★★★
()
Ответ на: комментарий от eao197

На мой взгляд, главная проблема Rust-а – это слишком агресивные упоротые Rust-оманы. Которые производят столько шума, что непонятно, есть ли вообще в Rust-сообществе нормальные люди.

Помню у одного языка с двумя плюсами на конце такая же проблема была лет 15 - 20 назад :)

anonymous
()
Ответ на: комментарий от yugr

Похоже это тренд в современных языках, та же засада с Go…

С++ трудно назвать современным, но у у него та же проблема, ABI нет и любая динамическая линковка или через Си или через платформозависимые вещи (например COM в windows).

anonymous
()
Ответ на: комментарий от annulen

А если код совсем не писать, так вообще проблем не будет

Из языков в этом треде только у си (и возможно у фортрана) нет проблем с динамической линковкой, остальные в этом плюс минус с большими проблемами, С++ и Rust практически одинаково нет ABI, у D еще к их проблемам еще добавляется рантайм с GC.

anonymous
()
Ответ на: комментарий от anonymous

У фортрана нет проблем, он совместим с сишкой по ABI

annulen ★★★★★
()
Ответ на: комментарий от anonymous

У C++ есть Itanium ABI который уже много лет как де-факто стандарт

annulen ★★★★★
()
Ответ на: комментарий от yetanother

В отличие от плюсов и Раста у D как раз нет проблем с ABI, поскольку он стандартный.

Интересно, а давно стандартизировали? Помню раньше надо было сильно приседать с инициализацией GC при динамической линковке.

anonymous
()
Ответ на: комментарий от anonymous

Интересно, а давно стандартизировали?

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

Помню раньше надо было сильно приседать с инициализацией GC при динамической линковке.

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

yetanother ★★
()
Ответ на: комментарий от eao197

Тут дело такое… Если компилятор один, и вся разработка по сути в одних руках, то и проблем таких может и не возникнуть.

anonymous
()
Ответ на: комментарий от anonymous

а может и возникнуть.

попробуй собери код написанный на swift 3, например компилятором swift 5.

Очень уродский язык этот swift с полным забиванием на совместимость…

fsb4000 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.