Новости о LLVM для Windows

[zone19]

Не могу описать как я счастлив, что этот день, наконец, наступит.

[NeoCode]

Шикарная новость; еще бы к этому делу подключить компанию Digia, чтобы они предоставляли официальные сборки Qt не только под msvc и mingw(mingw64 в будущем?), но и под llvm/clang, и обеспечила поддержку clang в Qt Creator.

[timurrrr]

Возможно, я не совсем понимаю чего именно Вы хотите, но по идее отдельной сборки/поддержки для clang не потребуется, так как clang как раз и старается быть настолько совместимым с msvc, чтобы лишних телодвижений не требовалось :)

[Lol4t0]

Будем надеяться, что clang все-таки стремится быть совместимым со стандартом, а не со студией :)

Совместимость с MSVC, наверное, предполагается на уровне ABI.

[leanid]

Мне одному кажется, что это странная идея пытаться сделать совместимость с msvc — abi с clang? Да и вообще куда более перспективно качать QtCreator как ide для с++.

[Lol4t0]

Она не странная — оно, конечно, полезно и упрощает жизнь. И дело тут не в IDE, а в том, что многие проекты и библиотеки на Windows оффициально собираются студией (тот же firefox собрать mingw — нетривиальная задача). Другое дело, говорить что отсутствие поддержки MSVC C++ ABI равнозначно отсутствию поддержки платформы — странно.

[int19h]

А в чем странность? На линуксе уже давно есть стандартный C++ ABI, и это хорошо. Под виндой его, к сожалению, нет, но по факту 90% кода собирается MSVC, поэтому он и является де факто стандартом.

[leanid]

Возможно я просто не понимаю, но у разных версий msvc — разные библиотеки времени выполнения, и поэтому как не старайся, но не получится собрать библиотеку одним msvc и в таком виде вместе с заголовками раздавать людям, придется собирать под разные версии 7.0 — 12.0. А под линуксом у меня есть возможность всегда пересобрать компилятор и все инструменты поэтому даже если бы и не было бинарной совместимости, это можно было преодолеть, а вот с закрытым компилятором msvc, нужно надеяться что ms его не изменит настолько что новая версия будет не с чем не совместима.

[int19h]

Получится, если библиотека в заголовках не использует типы из стандартной библиотеки C++.

Надо сказать, что VC++ ABI на самом деле довольно-таки стабилен — так исторически сложилось, что этим пользуются многие люди, используя его между DLL'ками. И просто так вдруг ломать его никто не будет.

А если в рамках этого проекта его официально задокументируют и версионируют — так это будет совсем замечательно.

[akaStiX]

Кто быстрее — МС выпустит студию с полной поддержкой С++11 или LLVM портируют под винду?

[Lol4t0]

Странные какие-то новости. Llvm уже давно можно было под Windows собрать. Даже на хабре статья была.

А что за проблемы совместимости Clang и LLD (компоновщик LLVM) с native C++ кодом? Это о чем вообще?

[timurrrr]

Если что-то можно собрать, то это не значит, что оно работает, верно?

Раньше можно было использовать только Itanium C++ ABI (вроде mingw, насколько я понимаю). Использование скомпилированных для msvc библиотек с C++ным интерфейсом (и «стандартным» виндовым ABI) было невозможным.

[Lol4t0]

С++ Mingw тоже не совместим с С++ ABI студии, ничего особо страшного в этом нет. С-ABI и COM работают.

[timurrrr]

С++ Mingw тоже не совместим с С++ ABI студии, ничего особо страшного в этом нет.

Всяко бывает, в каких-то проектах интерфейсы между библиотеками протянуты C++ные.

С-ABI и COM работают.

Что Вы подразумеваете под C-ABI? Например, передача и возврат POD структур по значению в Itanium ABI и msvc организованы по-разному. Да и сам layout структур, кажется, тоже разный (просто передачей по указателю не обойтись).

[Lol4t0]

Передача и возврат POD структур вообще регламентируются соглашениями вызова.

Itanium ABI вообще описывает С++ ABI, он даже называется так целиком: Itanium C++ ABI.

[timurrrr]

На практике, такое теоретическое разделение не совсем пригодно. Один и тот же cdecl на Windows под mingw и msvc реализован по разному.

[Lol4t0]

Ну вот специально проверил — все работает:

>cat tst.h tst.c main.c
struct Data
{
        char * s;
        int x;
        double y;
        char z;
};

struct Data get_data(int x, char z);

#include "tst.h"


struct Data get_data(int x, char z)
{
        struct Data d;
        d.x = x;
        d.y = (double)(x)/2;
        d.z = z;
        d.s = "hello, world";
        return d;
}

#include "tst.h"
#include <stdio.h>

int main()
{
        struct Data d ;
        d = get_data(5, 'a');
        printf("%s, %i, %lf, %c\n", d.s, d.x, d.y, d.z);
        return 0;
}
>cl tst.c -c
Microsoft (R) C/C++ Optimizing Compiler Version 17.00.51106.1 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

tst.c

>gcc main.c tst.obj
Warning: .drectve `/DEFAULTLIB:"LIBCMT" /DEFAULTLIB:"OLDNAMES" ' unrecognized

>a.exe
hello, world, 5, 2.500000, a

[timurrrr]

Попробуйте
struct S { int x, y; };
и
struct S { int x, y, z; };

[timurrrr]

И там кажется для наглядности наоборот нужно, чтобы get_data компилировалась gcc/mingw/clang

[Lol4t0]

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

[Lol4t0]

Все хорошо. А что должно было произойти?

[timurrrr]

Увы, у меня сейчас под рукой нет винды и mingw.
Попробуйте воспроизвести с gcc llvm.org/PR15556?

[Lol4t0]

Не воспроизводится.

[timurrrr]

Как насчёт такого?

$ for F in *.{h,c}; do echo "/*** $F ***/"; cat $F; echo; done

/*** h.h ***/
struct S {
  double f;
};

struct S f(void);

/*** c.c ***/
#include "h.h"

int main(void) {
  struct S s = f();
  printf("s.f = %lf\n", s.f);
  return (s.f != 42.0);
}

/*** m.c ***/
#include "h.h"

struct S f(void) {
  struct S ret;
  ret.f = 42.0;
  return ret;
}

Под CL всё ок:

$ (cl -nologo -O2 -c -Foc.obj c.c && cl -nologo -Fec.exe -O2 m.c c.obj) >/dev/null && ./c.exe ; echo $?
s.f = 42.000000
0

CL + MinGW — увы:

$ cl -nologo -O2 -c -Foc.obj c.c >/dev/null && C:/mingw/bin/gcc -O2 m.c c.obj 2>/dev/null && ./a.exe ; echo $?
s.f = 0.000000
1

[naum]

Уточните, а что именно не работало? По-моему LLVM и clang с обвязкой инструментов без проблем собирались в студии и фурчали. Сам в работе использую только libclang/libllvm, без тулчайнов, обе собраны в VS2010 без проблем, весь необходимый функционал под виндой работает. В статье толком не описано, к сожалению. С lld проблемы были, емнип, т.к. без заморок собрать свой первый бинарник не мог, пришлось чем-то заменять (вроде из fpc брал линкер и что-то еще).

[sys_int64]

На счет LLD интересно, пробовал юзать его, но ничего не вышло :(

[timurrrr]

Давно пробовали? Там недавно серьёзные подвижки были.

[sys_int64]

год назад, это хорошо, сейчас может снова попробую )))

[Gorthauer87]

Да уж, а то я уже отчаялся ждать constexpr в студии, но при этом хочется иметь доступ к новым C++ либам, которого никогда не сможет быть с mingw+gcc

[fshp]

Что за странная мода оформлять перевод как обычный топик?

[timurrrr]

Пардон, видимо проглядел в правилах?..

В каком-то смысле это не совсем перевод, так как я сам являюсь активным участником данного процесса и могу ответить на некоторые вопросы в комментариях; просто вместо того чтобы придумывать свой велосипед текст, я решил перевести краткий и ёмкий пост Chandler'а. Надеюсь, это частично искупает мою вину.

[andreishe]

Сегодня, кстати, был последний день Going Native 2013, где в т.ч. Chandler выступал. Показывал весьма неплохую диагностику кода в clang.
Записи выступлений: channel9.msdn.com/Events/GoingNative/2013

[timurrrr]

Записи выступлений: channel9.msdn.com/Events/GoingNative/2013

К сожалению, там пока появились только видео первого дня.

[timurrrr]

Появилось видео Chandler'а!
channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons