Elektrine
Log in Register

#gcc

10 posts · Last used 3d

Back to Timeline
In reply to
@JdeBP@mastodonapp.uk · 4d ago
@jperkin@federate.me.uk I'm not sure that this is the best fix. Since C++2011, there's been a template for std::log in that takes an integral type argument and so is the best match without ambiguity. https://cplusplus.com/reference/cmath/log/ vide libstdc++ https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/c_global/cmath;hb=HEAD#l322 and libc++ https://github.com/llvm/llvm-project/blob/main/libcxx/include/__math/logarithms.h#L35 Illumos's C++ support in isn't up to date with respect to C++ 2011 (unsurprisingly) and a fix that would actually improve and modernize the C++ support seems to be to add these templates for log and whatnot, in some fashion, with appropriate C++ version and type guards, to head/iso/math_iso.h where all of the other C++1998 overloads already are. That would remove ambiguity for both log(1) and std::log(1). #CPlusPlus #Illumos #gcc #clang
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 4d ago
@jperkin@federate.me.uk If I had an #Illumos system to do such work on, I probably could. Your patch is breaking the uniform way that the library is designed, over a whole load of headers. In this design, all of the overloads are declared inside namespace std in some iso/*_iso.h header, which headers like and and so forth then pull into the global namespace with using declarations. Ironically, it's a far more full-on C++ way of doing things because it's even declaring the C library functions in namespace std, but with "C" linkage. namespace std gets 1 "C" linkage overload and 2 "C++" linkage overloads for the various functions. #CPlusPlus #gcc #clang
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 4d ago
@jperkin@federate.me.uk Retaining that uniform, clean, system involves adding the stuff that's needed for more modern C++ anyway into the right iso/math_iso.h header. If I were doing that, head/iso/math_iso.h would gain something like template inline typename __illumos::__enable_if<__illumos::__is_integral<_T>::__value, double>::__type log(_T __v) { return log(static_cast(__v)); } inside namespace std, and #include at the top. There'd be an head/iso/type_traits.h with the well-known implementation of enable_if<> as __illumos::__enable_if<> and a suitable implementation of __illumos::__is_integral<> instantiated as appropriate. #CPlusPlus #gcc #clang #Illumos
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 4d ago
@jperkin@federate.me.uk All that said, the big question to answer is whether there is still in use an #Illumos C++ compiler that does not use either GNU libstdc++ or LLVM libc++. (Likely yes if a compiler bootstrap uses C++ before it has its own library built.) Because the inlined "C++" linkage stuff declared by the Illumos library has a fallback to other inline functions if using libstdc++ or libc++, the very easiest patch of all would seem to be just conditionally compile out (only) the extern "C++" {} block of head/iso/math_iso.h when either _LIBCPP_VERSION or __GLIBCXX__ is defined. That way, anything building with libstdc++ or libc++ doesn't get the Illumos "C++" linkage overloads as overloads in the global namespace, and only gets the 1 "C" linkage overload. #CPlusPlus #gcc #clang
0
0
0
In reply to
@JdeBP@mastodonapp.uk · 3d ago
@jperkin@federate.me.uk You've missed two important bits. Your initial approach didn't test for _LIBCPP_VERSION or __GLIBCXX__. Your initial approach rather compiled all of this out except for one specific compiler. What I just described, in contrast, compiles everything in for all compilers except when libstdc++ or libc++ are used. It's library-sensitive, not compiler-sensitive. Because there's a stage at least in the GCC bootstrap where it is building itself with the pre-supplied compiler and library. In this mode, one does *not* want the #Illumos headers to have their C++ parts conditionally compiled out. One rather wants them to be fully natively functional the same as they are now. I also said *only* the extern "C++" {} block. Your initial approach went far beyond that and compiled out the declarations of a whole bunch of "C" linkage stuff. #CPlusPlus #gcc #clang
0
0
0
@analytics@social.vir.group · Apr 08, 2026
🟡 Drone Attack | 7/10 🇰🇼 🇮🇷 Iranian drones attack Kuwait Kuwait's army intercepted 28 Iranian drones targeting the country, with some hitting oil facilities and power plants, causing significant damage. The attacks occurred despite the announced ceasefire. 💬 SENTINEL: Продовження атак після оголошення перемир'я свідчить про складний процес доведення наказів до всіх підрозділів. #Kuwait #Iran #Drones #GCC
0
0
0
@Areeb_Soo_Yasir@mastodon.areebyasir.com · Mar 31, 2026
Much of the #Gulf #GCC is now doing #remote #online learning owing to the war and reminiscent of #COVID times. Hopefully using a proper #LMS such as #Moodle like my company at #techrich uses for its #it #docker courses at https://training.techrich.hk https://www.khaleejtimes.com/uae/education/schools-return-to-in-person-classes-under-review
0
0
0
@askubuntu__dup_31630@ubuntu.social · Feb 28, 2026
Integrate gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0 #kernel #2404 #vmware #gcc https://askubuntu.com/q/1564446/612
0
0
0
@askubuntu__dup_31630@ubuntu.social · Feb 28, 2026
integrate gcc-13 (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0 #2404 #vmware #gcc https://askubuntu.com/q/1564446/612
0
0
0
In reply to
@JdeBP__dup_33984@mastodonapp.uk · Feb 11, 2026
@davefischer@hachyderm.io I'm guessing that that was Ritter's Heirloom vi. https://mastodonapp.uk/@JdeBP/116052015020764901 There are discussions in an Arch Linux forum of its package being removed because it hadn't changed in two decades and the (GNU flavoured) C language had. It's in the #FreeBSD ports collection; and several people have independently come up with the Makefile patch that gets it to build on Debian Linux. https://freshports.org/editors/2bsd-vi/ #vi #retrocomputing #ComputerHistory #gcc #ArchLinux
Quoting
JdeBP @JdeBP__dup_33984@mastodonapp.uk
On #Illumos, Jov vi is in /usr/src/cmd/vi: https://github.com/illumos/illumos-gate/tree/master/usr/src/cmd/vi On #OpenBSD, Bostic #nvi is in /usr/src/usr.bin/vi/vi; #NetBSD having it in /usr/src/external/bsd/nvi; and #FreeBSD in /usr/src/contrib/nvi: https://github.com/freebsd/freebsd-src/tree/main/contrib/nvi FreeBSD has an nvi2 in ports: https://freshports.org/editors/nvi2/ OpenBSD has elvis in ports: https://github.com/openbsd/ports/blob/master/editors/elvis/pkg/DESCR Ritter's Heirloom vi is on SourceForge: https://ex-vi.sourceforge.net STEVIE was posted to comp.sources.unix in 1988: https://sources.vsta.org/comp.sources.unix/volume15/stevie/ Unfortunately, Sven Guckes's vi Clones WWW site was never completed with some of this, notably lacking Heirloom vi, for example. https://guckes.net/vi/clones.html But it does mention oft-overlooked commercial clones such as Watcom's vi, a from-scratch implementation started in 1983 that is also now source-available: https://github.com/open-watcom/owp4v1copy/tree/master/bld/vi #vi #retrocomputing #ComputerHistory #STEVIE #elvis #VIM #NeoVIM #Watcom #OpenWatcom
Open quoted post
1
0
0

You've seen all posts