Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Neither GCC nor Clang are compliant with standard C++

sebsite.pw

Post reply on HN
Print view View original

41–50 of 63 posts

Re: Neither GCC nor Clang are compliant with standard C++

#41

Post by jjmarr »

edoceo wrote: post #33
t0mpr1c3 wrote: post #22

Earlier quoted context omitted.

This question strikes me as somewhat obtuse, but I will attempt an answer: NVIDIA and AMD. These are only two GPU manufacturers of any significance. (Intel is also a player, but not a major one.) They supply SDKs (drivers and libraries required for software development) for their products that support C and C++ and precious little else. There have been attempts to reverse engineer the toolchains in Rust but as I unde…

The Zig group claims that Zig can interop with C based libraries w/o too much work. It's one of the reasons I'm digging into it now. But I don't know anything about CUDA and have only done trivial Zig C tests (like my Zig code working with libpng) so far. Are their claims BS? Is Zig just not mature enough? Something else?

The CUDA/HIP APIs are mostly C-like APIs but are really C++ language extensions. e.g. you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it.

The GPU kernel code itself needs to be compiled and for CUDA that is done with the proprietary nvcc, which is clang-based. HIP is better because it's an open-source llvm backend/frontend but you'd still need to add GPU-specific support to zig/rust/whatever.

Re: Neither GCC nor Clang are compliant with standard C++

#43

Post by bee_rider »

AlotOfReading wrote: post #26
bee_rider wrote: post #21

Earlier quoted context omitted.

C will outlive all of us. C++… I don’t know it well. But I’ve heard there are a lot of different dialects, to the point where it is possible that two C++ programmers might be writing in essentially different languages. How “old” is the language, in that case?

The dialects issue is why I avoid interviewing in C++, because inevitably it turns out the interviewer has some weird view of what "C++" is and doesn't realize it. Years ago I had an interview in "C++14" that required std::optional (C++17) as implemented by a C++14 compiler with only experimental, nonstandard support. In another case, an interviewer on the LLVM team vehemently disagreed with me that you could legally…

What was the disagreement on the atomics issue?

I only know them from openMP (more of a Fortran person)… without much thought my gut says that it’d be possible to implement an atomic operation with a mutex, but sort of defeating the purpose. An atomic operation is mostly expected (intended? hoped?) to be backed by some hardware atomic instructions anyway, right?

Re: Neither GCC nor Clang are compliant with standard C++

#44

Post by jamesfinlayson »

ameliaquining wrote: post #28
ch_123 wrote: post #12

Hot take: I feel like a lot of the original value of language standards was to unite multiple proprietary implementations of compilers/runtimes/etc. from different vendors, each of which had incentives to add non standard features to attract customers and keep them locked in. This has been significantly diminished in the last decade or two now that most languages have high quality open source implementations - now yo…

I half-agree with this. People occasionally argue that, e.g., Rust won't be suitable for production use until it has two fully independent mature implementations, and I consider this a silly requirement that doesn't serve any real purpose. On the other hand, once multiple separate implementations are already in widespread use, there's immense value in working out a least common denominator of language features and st…

> On the other hand, once multiple separate implementations are already in widespread use, there's immense value in working out a least common denominator of language features and standard library APIs that work everywhere

Yeah this was what I thought. I remember Valve Software wrote a paper about cross platform development and said it was useful compiling with Visual C++ and gcc to shake out any iffy syntax that worked in one but not the other. Of course with performance-critical code and code that needs to run on consoles as well there will always be platform-specific stuff, but if you can get 99% of the code working across multiple compilers that's pretty good.

Re: Neither GCC nor Clang are compliant with standard C++

#45

Post by AlotOfReading »

bee_rider wrote: post #43
AlotOfReading wrote: post #26

Earlier quoted context omitted.

The dialects issue is why I avoid interviewing in C++, because inevitably it turns out the interviewer has some weird view of what "C++" is and doesn't realize it. Years ago I had an interview in "C++14" that required std::optional (C++17) as implemented by a C++14 compiler with only experimental, nonstandard support. In another case, an interviewer on the LLVM team vehemently disagreed with me that you could legally…

What was the disagreement on the atomics issue? I only know them from openMP (more of a Fortran person)… without much thought my gut says that it’d be possible to implement an atomic operation with a mutex, but sort of defeating the purpose. An atomic operation is mostly expected (intended? hoped?) to be backed by some hardware atomic instructions anyway, right?

They insisted that it wasn't legally possible and no one would ever do that, but std::atomic::is_lock_free [0] exists precisely because implementers were doing it. The only case that anyone was ever likely to encounter AFAIK was atomic structs >= 16 bytes on MSVC because they couldn't use cmpxchg16b for reasons.

I had been using a truly awful stdlib on an embedded platform whose implementers saw that freedom as a license to implement all atomics with mutexes. I assume it was because they couldn't be bothered to write new implementations for every platform they supported, so they'd write the basic primitives and got the rest of the implementation "for free". This isn't even close to the dumbest decision they made.

Obviously that wasn't acceptable for any real use, so I wrote up a better implementation, sent it to the vendor as a patch to save their other poor customers the effort, and used it as a one line example in a larger list on my resume that the interviewer seized on. It's not uncommon for a FAANG interview to be adversarial like that.

[0] https://en.cppreference.com/cpp/atomic/atomic/is_lock_free

Re: Neither GCC nor Clang are compliant with standard C++

#47

Post by dataflow »

kloop wrote: post #7

Give how default gcc and clang are, along with the recommendation to update the standard instead of gcc and clang, it sounds like the standard is noncompliant with standard C++ Standard in the sense of commonly used or supplied

The blog post basically said exactly this:

> IMO the blame here doesn't lie on gcc or clang; it lies on the standard. that is, the standard is wrong and should be updated to make this implementation-defined.

Re: Neither GCC nor Clang are compliant with standard C++

#48

Post by zzyxy »

jjmarr wrote: post #41
edoceo wrote: post #33

Earlier quoted context omitted.

The Zig group claims that Zig can interop with C based libraries w/o too much work. It's one of the reasons I'm digging into it now. But I don't know anything about CUDA and have only done trivial Zig C tests (like my Zig code working with libpng) so far. Are their claims BS? Is Zig just not mature enough? Something else?

The CUDA/HIP APIs are mostly C-like APIs but are really C++ language extensions. e.g. you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it. The GPU kernel code itself needs to be compiled and for CUDA that is done with the proprietary nvcc, which is clang-based. HIP is better because it's an open-source llvm backend/frontend but you'd st…

> you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it.

It all boils down to calling CUDA runtime or driver APIs. Compiler just sprinkles fairly trivial amount of syntactic sugar, and under-the-hood glue code. One can launch GPU kernel from a pure C source file compiled with gcc.

> The GPU kernel code itself needs to be compiled and for CUDA that is done with the proprietary nvcc, which is clang-based.

nvcc is not the only option. Clang itself can compile most of existing CUDA code just fine, and the rest usually needs minimal porting.

Also, nvcc is not based on clang. It may use it as the host compiler, but that's the extent of its involvement with clang. IIRC, their front-end used to be based on EDG.

> HIP is better because it's an open-source llvm backend/frontend

CUDA and HIP share most of the front-end code in clang, so CUDA compilation with clang shares the same benefits. What's missing is PTX to SASS assembler, which creates the actual GPU binary, and that part is proprietary to NVIDIA.

Re: Neither GCC nor Clang are compliant with standard C++

#49

Post by 112233 »

jdw64 wrote: post #4
gregdaniels421 wrote: post #3

Earlier quoted context omitted.

The working group said bring us a paper with the exact proposal, I haven't seen an update where someone did.

Is it because the impact of the change is too big? I mean, is that why it's hard to submit a proposal?

Last time I looked "submitting a proposal" to WG21 involved attending in person. Has something changed recently?

Re: Neither GCC nor Clang are compliant with standard C++

#50

Post by 112233 »

lallysingh wrote: post #31
leecommamichael wrote: post #6

If you're starting a new project and can afford it, please for the love of the children, use a different systems language. In so many ways Odin, Rust, Zig, whatever are better. There will be growing pains with respect to collective knowledge and performance, but they are surmountable. Context: I am a programmer and educator. I am so tired of informing people of these minutiae.

I've tried it, and no. Honestly C++ gets so many complaints partially because so many people use it. It deserves a lot of it. I just finished my work on a 2.5 yr rust project that was very low-level. The problems I had with it were that the language and library designs will always be behind the current state of the art in performance. Hardware and systems APIs change quickly, and they can shift the optimal design dec…

On embedded, your fight totally is against language and runtime. Since you cannot gave conformant freestanding C++ without exceptions, rtti and most of STL, "using c++" on embedded always turns into "using gcc" or "using clang" — their mutually compatible, but completely standards non-conformant extensions that make writing for embedded reasonable to even attempt. At that point, is the language still c++?

Meanwhile, both rust and zig will gladly compile your standalone function into standalone binary.

Post reply on HN