#GCC
Today's `gcc` bug is a follow-up to exhausted argument count related to `COLLECT_GCC_OPTIONS` variable: https://gcc.gnu.org/PR111527
We need safe streets for all in Glasgow: https://www.change.org/p/provide-safe-roads-for-all-in-glasgow #Glasgow #SafeStreets #GCC #ActiveTravel
Some gcc background operation clogs my CPU #2204 #gcc
Is the #Linux world witnessing the preparations for another disruption event? A lot of exciting, innovative, new technology is looking for an outlet. #linuxkernel #opensource #opensourcesoftware #rust #rustlang #wasm #gcc #llvm #gnu
https://www.linkedin.com/pulse/next-linux-disruption-david-edelsohn
gcc error on Ubuntu 22.04 #2004 #2204 #gcc
Did not see `gcc` bugs for almost a month.
Today's `gcc` bug is an infinite recursion in a `gimple_zero_one_valued_p()` predicate: https://gcc.gnu.org/PR111435
@Tanuki These utilities are all small side projects for a single developer. Writing a modern shell is barely within reach, and fully replacing #GCC would require a huge investment, even if you start from #LLVM.
I heard that Google and Apple have pulled resources from #Clang a few years ago, and that's why #Cpp support seems to be falling behind GCC:
https://en.cppreference.com/w/cpp/compiler_support/23
Ubuntu on wsl always "fails to fetch" whenever I'm trying to download to it. How can i fix this? #updates #dns #windowssubsystemforlinux #gcc
@PeterSommerlad It does.
In this particular case, MSVC rejects one version of invalid code and incorrectly accepts the other. And I even totally understand why: the Modules TS had a different grammar.
Both Clang and gcc are even worse: they accept *both* ill-formed variants. And they don't have the "legacy" excuse.
@argv_minus_one @retronianne and even the #GNUtils are replaceable - and that is a good thing.
In fact if #clang / #LLVM support would be where it should be, I'd even ditch #GCC for OS/1337...
ld: library not found for -lgsl #compiling #gcc
there was
no way to guarantee that more than one cache line was simultaneously in the
cache. Thus anything ATOMIC is restricted to a single cache line.
This also lead to my SAF (advanced synchronization facility) at AMD that
I have further refined into ESM (Exotic...method) that allows up to 8
cache lines to participate in an ATOMIC event, with guarantees of forward
progress, and ways to avoid future interference. One of which has the
property that it converts a BigO( n**3 ) problem into a BigO( 3 ) problem
{yes there is no n in the second BigO number}.
Say a timer goes off and the OS enables K threads, each of these threads
accesses the front of the work queue and all see interference, on the
second pass they also all see interference, but go out and ask why they
are seeing interference. This time they all get back a unique number, and
can use this unique number to access the work queue without interference.
This problem is intertwined with the cache coherence protocol, bus protocol,
and bisection bandwidth of the "bus". So it cannot be managed by the processor
at a fundamental level. Besides, does any GBOoO processor want to sit in a
loop asking
====
It's a sequence of atomic operations, none of
which should ever fail, but some of which might be delayed, and there
would be a potential benefit to signaling the application that a delay
larger than some determined value exists, and the application can be
signaled so it can decide what to do when the resource is not immediately
available. In other cases where it just needs to take place at some
point, then the pauses on each core to attain a full lock on the re-
sources mean it will be slower, but still fulfill the needs of the app.
And in the case of these multiple single atomic operations executed in
succession, they also would never fail unless there is some need for them
to be executed sequentially without delays. And I'm still considering a
possible way to implement that design, so that the full multi-transaction
can be done atomically through a protocol that indicates how many trans-
actions are in flight, which locks down resources for that duration,
taking a hit on all cores' performance, but ensuring fully atomic op-
eration when needed.
#riscv only has a single (64-bit) load/store-reservation
capability, the semantics of which is that the SC succeeds if and
only if there was no other SMP core / hardware-thread that requested
the exact same memory address in the intervening time. it is
intended that a loop occur around this testing of the return result
from SC, retrying the LR/SC batch until it succeeds.
the question therefore came up, well, is it reasonable to have
multiple consecutive LR instructions make multiple cache-line
reservations, followed by multiple consecutive SC instructions?
and for the semantics to be "all-or-nothing" on a global basis.
i.e. a sequence of LR reservations are made, and if another
SMP core / hardware thread makes a reservation on *any* of that
batch, then *all* LRs are invalidated (not just the one).
the same looping would therefore be required: it would just be
the case that several memory addresses in completely different
locations could be reserved simultaneously.
i would be interested to hear peoples' thoughts on whether this
is practical to implement, and, more importantly, if it would
actually be useful.
in particular, the fact that now *multiple* things happen inside
the multi-LR, multi-SC loop has me concerned, as i do not have
enough experience in algorithms to say if that is a problem
a multi-LR/SC, that intrinsic could reasonably be
expected to have an augmented equivalent that, instead of a single
memory address, takes an array of memory addresses.
as long as the same array of addresses is passed into both the LR and
to the SC, the specification is adhered to.
LR/SC allows the program to *detect* if anything
(specifically, another SMP core or hardware-thread) *interfered* with
the updates, such that *after* the updates have been carried out and
the interference [guaranteed to have been] detected, the operation
may be repeated again and again until such time as it is detected that
no interference occurred.
the single-LR/SC case been successfully implemented by multiple RISC-V
vendors, and it does have full, proven, working compiler support in
#gcc, as well as libc6 (glibc) support.
so the question is: can a multi-LR/SC with multiple memory reservations
just like mitch's 66000 ISA work as well?
in the riscv linux kernel as well as the supervisor-mode riscv
unit tests, such a context switch is done in a traditional way of
saving all registers onto an [altered] stack (and other state). the
unit test code is a lot simpler than a full OS-style context-switch:
https://github.com/riscv/riscv-test-env/blob/master/v/entry.S
https://groups.google.com/g/comp.arch/c/QVl3c9vVDj0/m/DHOi0PDEAQAJ?pli=1
My inner “clean” coder is very happy to see that making an already small function even smaller made it x4 faster because GCC started to inline it (“Other lessons learned” section).
On the other hand this is something I wouldn’t have expected and it horrifies me.
https://codingnest.com/the-little-things-the-missing-performance-in-std-vector/
@alexr If some "irrelevant" bits in some pointers used by the compiler at runtime change the compiled code, that's some strange compiler bug. Not that they're unheard of, sure, but I now see your question boils down to whether using the #FreeBSD kernel instead of #Linux would trigger bugs in #GCC.
Again, checking this would be a *huge* amount of work. You might think you could at least compare the object-code files easily, but even these are influenced by library headers, they might pull in types with sizes changed between versions, they might even use conditional compilation based on library versions, etc (and yes, that's all "changed compiler input").
To really do this check reliably, you'd have to create the exact same toolchain and used libraries on both systems.
I'll rather focus on getting more software to build/work, so I can finally test some closed-source software... time is limited 😉
So, You Want to Use C++ Modules … Cross-Platform? – by @DanielaKEngert – C++ on Sea 2023
https://www.youtube.com/watch?v=DJTEUFRslbI
#clang #cpp #cppmodules #gcc #MSBuild #programming
I never wrote Assembly in my life, but tonight (for some reason) I thought of disassembling simple C code snippets with Ghidra. So, I started with a hello world and was very surprised to find a much more extensive and complex result compared to my original assembly (obtained with GCC).
I mean, it's a Hello World!
Assigning your copyright to the FSF helps defend the GPL and keep software free. Thanks to Gene Goykhman, Sergey Alexandrovich Bugaev, Wang Diancheng, Warren Thomas Everett Wilkinson, and Xinyuan Zhang for assigning their copyright to the FSF! #GNU #Emacs #glibc #GDB #GNUstep #GNUHurd #GNUMach #GCC Learn more at https://u.fsf.org/3ht #CopyrightAssignments
Why is this bus error occurring when reading through a shared memory object? #kernel #2204 #gcc #memoryusage #shm
The new #GCC: Convergence and strategic competition - @gulf @iran
https://gulfstateanalytics.com/the-new-gcc-convergence-and-strategic-competition/
I love that they put "usually" in this sentence:
"Humans usually are not as good writing machine code as they are at writing Fortran"
--
About GNU Fortran
https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gfortran/About-GNU-Fortran.html
Added these symlinks.
#glibc needs some "convincing" to install *everything* to /usr, but it works.
It solves the issue on #aarch64 and #i386 (which both install the program interpreter to /lib by default).
It does NOT solve the issue on #amd64, where the program interpreter is installed to /lib64, but *something* during #GCC build insists on finding it in /usr/lib instead. 🤯
Trying a hack with a hardlink now (after learning that glibc's ldconfig just deletes symlinks to the program interpreter).
And I still have NO idea where these errors regarding the ELF program interpreter come from when building #gcc and its libstdc++. They do NOT appear in the build log, they are somehow just spit to the controlling terminal of #poudriere. And I didn't find anything not working in these packages so far ... 🤯
Compilers Mastodon, does anyone know of examples where major C compilers exploit UB of misaligned loads/stores to produce silent misbehavior?
That's excluding
- Generating instructions that trap if misaligned (e.g. x86 movdqa), because that's not silent.
- Exploiting code that does more than just making misaligned loads/stores, such as calling __builtin_assume_aligned.
(cc @regehr... hmm, who else should I cc. I wish Mastodon had search. #compilers #llvm #gcc)
Today's `gcc` bug https://gcc.gnu.org/PR111051 is a case where `gcc` stopped recognizing some `avx2` primitives on `avx512` code (all on `highway-1.0.6` code again):
#include <immintrin.h>
#pragma GCC target("avx512vl,avx512dq")
void bug(__m256i i) {
volatile auto v1 = _mm256_cvtepi64_pd(i);
}
and failed as `error: inlining failed in call to 'always_inline' '__m256d _mm256_setzero_pd()': target specific option mismatch`
Today's `gcc` bug is https://gcc.gnu.org/PR111048 where `gcc` generated wrong code for `highway-1.0.6` library in `-mavx2` mode.
When handling the following loop:
u8 in_lanes[32];
for (unsigned i = 0; i < 32; i += 2) {
in_lanes[i + 0] = 0;
in_lanes[i + 1] = ((u8)0xff) >> (i & 7);
}
`gcc` broke `i =12` iteration and instead of `i[13] = 0xf;` (`0xff >> 4`) stored something like `i[13] = 0xef;` there.
This idea of instantiating C++ templates with std::variant turns out to be more complicated than I thought once compiler optimizations are enabled, but function attributes provide the fix. The example code now looks like this. Full write up here: https://indii.org/blog/revisited-combinatorial-instantiation-of-templates-with-std-variant/ #cpp #cplusplus #programming #clang #gcc
![Example C++ code:
#include <variant>
#if __has_attribute(noipa)
#define KEEP __attribute__((used,retain,noipa))
#else
#define KEEP __attribute__((used,retain,noinline))
#endif
template<class T, class U>
KEEP void test(T x, U y) {
//
}
KEEP static void instantiate() {
std::variant<double,float,int> x, y;
std::visit([]<typename T, typename U>(T x, U y) {
if constexpr (!std::is_same_v<T,U>) {
test(x, y);
}
}, x, y);
}](https://s3.eu-central-2.wasabisys.com/mastodonworld/cache/media_attachments/files/110/902/518/402/704/231/small/ab6d2937578b578a.png)
How often do you have to build #GCC to have a *native* version for #Linux when building on #FreeBSD?
The answer is: 3 times. First a minimal cross-version without #glibc, required to actually *build* glibc. Then, a "full" cross-version using that glibc. And finally, using this full cross-version, the *native* version.
How often do you have to build GCC to find and fix issues in your FreeBSD ports for these 3 stages? The answer is: *countless* times. And it really takes time to build 😞
@thindil That's what I assume as well, once I'm done with the toolchain, architecture-specific differences should be rare (if encountered at all). 🙏
Just finished the cross-version of #glibc for all archs. Two more (#binutils and #gcc) to go for the FULL cross-toolchain. That will be the goal for today, the native toolchain maybe tomorrow 😎
Well ... no, building with #gcc didn't help.
Turns out the issue were #ELF relocation types. I have no idea why #Linux needs them *just* to build the headers (which is all I need for #Linuxulator, cause the actual #kernel will *still* be #FreeBSD), but yep, one type is named slightly differently: R_X86_64_JUMP_SLOT on Linux, R_X86_64_JMP_SLOT on FreeBSD. It has the same value, 7, so for now I just hardcoded it in the port Makefile for the Linux headers. 🙈 (hey, it works 🤷♂️)
Trying to get this to the other archs supported by #FreeBSD's #Linuxulator (amd64 and i386), I'm hitting yet another wall: #Linux headers fail to build there. Oh freakin hell, I expected to do quite some adaptions to support all 3 archs, but I didn't expect it to fail at *this* stage 🤯
Already tried to understand what happens in Linux' build system. Well, it's not exactly easy to understand 🙄
Shot in the dark, trying it with #gcc (instead of the base #clang) now... (which will take a while cause my test machine has to *build* this gcc first, bah ....)
🍂 Haiku OS support upstreamed into GCC ➥ @osnews
#HaikuOS #GCC #Opensource https://www.osnews.com/story/136649/haiku-os-support-upstreamed-into-gcc/
Today's `gcc` bug is https://gcc.gnu.org/PR111009 where `gcc` generates wrong code for `linux/perf` tool. Latest `gcc-13` release is also affected.
There `gcc` removed required NULL pointer checks. It is somehow tickled by the fact that pointer is dereferenced later (-O3, loop and -fno-strict-overflow):
struct dso * dso = NULL;
// should exit here
if (!dso) return 1;
int *a = &dso->maj;
// SIGSEGVs
if (!(a && *a)) __dso_id__cmp_();
`gcc` just removes `if (!dso) return 1;`.
Indeed, sanity-checking the new #Linux-native #GCC for #FreeBSD's #Linuxulator shows it works perfectly fine at least for C, and using static #libgcc (because I removed the libgcc_s.so file, should really be packaged separately) 🥳
So, to complete the toolchain, next steps will be separate ports for libgcc and libstdc++, should be possible to build these with this native gcc, we will see!
Another little update on this endeavor .. native #Linux #GCC for #FreeBSD's #Linuxulator finally builds! 🥳
Still needs some "love" in detail (like, correct path for man files).
And also, I have to find a way to package #libgcc separately, cause most software built for Linux using GCC will need it, and it doesn't make sense that everything pulls in the whole GCC as a dependency ...
Well, maybe tomorrow then 🙈
We have #glibc, #zlib, #binutils, #gmp, #mpfr and #mpc ... in theory everything needed to build a full-featured native #gcc for C and C++. Oh wow. Now, trying to create *this* port 😎
Edit: My hope is that with the --sysroot option (set to ${LINUXBASE}), this new toolchain will only ever look for libraries inside ${LINUXBASE}, avoiding weird build issues you might get when using the existing linux-c7-devtools port. Well, I'm not sure I fully understand this --sysroot magic 🙈
I'm carefully optimistic now again 😎
After first building very basic/limited "-bootstrap" versions of binutils and gcc into a separate prefix, it seems I could finally build a complete #GNU cross (#FreeBSD -> #Linux) toolchain, including #binutils, #glibc and #gcc (with libstdc++). This final cross gcc at least passed the most basic sanity check -- it successfully compiles an empty program 🙈
Now doing a bit of cleanup and then trying whether this beast is able to build the *real* (native) glibc for a new #Linuxulator userland 😎
@thindil Oh there *is* binary compatibility for sure. The #Linux kernel typically doesn't break its userspace-facing #ABI. #Glibc and #GCC's libstdc++ use symbol versioning to provide backwards compatibility.
The issue starts with all the other libs, there's no standard for some "base" GNU/Linux system. That's where all these (IMHO damn broken) ideas like #AppImage, #Flatpak etc come from. Of course, you could just link statically instead, seems people don't get that any more 🙈
Anyways, quite some binary #Linux software will work "anywhere" as long as the required libs are not too old (looking e.g. at browsers...). And having a #Linuxulator userland built from source *should* enable you to just add ports for missing libraries. Well, in theory 🙈
@thindil I can certainly use #FreeBSD "tools" (gmake, bison, gettext, whatever) for building this cross-toolchain. But indeed, for libraries, they need to be built targeting #Linux. And because #GCC with the full feature set needs e.g.#glibc when targeting Linux, but then you need GCC to *build* glibc, I need at least some "bootstrapping" ports. It's really a mess.
Once I have a full-featured cross GCC targeting Linux ready, I'll stop for a while to party 😂
Designing a formal Security Policy for #GCC. FYI Fuzzing GCC and DoS GCC are not considered security vulnerabilities, sorry.
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626529.html
GNU Spotlight with Amin Bandali: Ten new GNU releases in the last month including #GCC, #GPG #Parallel, #Tramp, and more. Full details: https://www.fsf.org/blogs/community/july-gnu-spotlight-with-amin-bandali-ten-new-gnu-releases Big thanks to @bandali0 @bandali, all the devs, and other contributors! #GNUSpotlight
A book on compilers. Free for personal use:
I would also like to share Compiling with Continuations, but it's not free available.
Interesting #C problem…
Any way to flag the following contrived scenario as a conversion warning in #gcc?
ssize_t result = -1;
if (result > sizeof(result)) printf(“-1 is bigger\n”);
In my testing of the various -Wconversion options, none will flag this as a possible problem. Comparing an int and an unsigned int does not seem to be caught but assigning one to the other is in all my testing.
Unable to link C source code with ADA static library (Error: libnewapi.a(unit1.o):unit1.adb:undefined reference to `__gnat_rcheck_CE_Overflow_Check') https://stackoverflow.com/questions/76738346/unable-to-link-c-source-code-with-ada-static-library-error-libnewapi-aunit1-o #ada #programming #linker-errors #gnat #gcc #ada #c
@gamingonlinux This is why Distributions like #AlpineLinux and #ChimeraLinux / @chimera_linux actively remove & replace #GNUtils and work to get #Linux built by #LLVM / #Clang instead of #GCC...
Even I do want to yeet tools out of my workflow...
But @ncommander went into the details re: #RMS!
https://www.youtube.com/watch?v=R2SKenHRhMg
I guess now that I'm figuring out this platform I should do an #introduction
I'm a #pagan #witch and #druid who just married my husband, @CaptainSharky, late last year. We also have two rescue #cats. My pronouns are she/her and I have a #history degree and work as a substitute teacher. I'm also a #barbershop #chorus singer (though I'm on break from that right now) and a #501st volunteer costumer.
My spouse and I regularly attend conventions and enjoy #anime #cosplay #videogames #gaming #boardgames #dnd #jeeping #hiking and #zumba. I also enjoy #manhwa #manga #reading #curlyhair care and #weightlifting. I'm also a #furry!
I consider myself a #gaulishpolytheist, French-American Folk Practitioner, and #cottagewitch. I'm an #AODA (Ancient Order of Druids in America) Candidate, a #GCC (Gnostic Celtic Church) Novitiate, and an #ADFdruidry (A Druid Fellowship) member.
#witchcraft #folkwitch #frenchfolkwitch #paganism #druidry #teaching #education #costuming #colorado #starwars
📸 CW: direct eye contact, prop weapon
#TIL that #LLVM could have been merged into #GCC under a #GPL license.
Tbh everyone who is serious about #copyleft / #FOSS should learn from the fatal mistake that was the anti-modular-GCC stance of RMS, lest history be repeated.
https://www.phoronix.com/news/MTU4MzE
via: https://news.ycombinator.com/item?id=26535789
GNU Spotlight with Amin Bandali: Twelve new GNU releases in the last month, including #GCC, #GnuPG, #R, and more. Full details: https://u.fsf.org/400 Big thanks to @bandali0 @bandali, all the devs, and other contributors!
A new #blog post appears!
Can we build all ten #GCC language frontends on #OpenBSD?
https://briancallahan.net/blog/20230626.html
#compiler #compilers #language #languages #unix #linux #freebsd #netbsd #dragonflybsd #llvm #clang #programming #programminglanguage #programminglanguages #ada #c #go #golang #fortran #rust #d #dlang
#GCC adopts a Code of Conduct
@marcan this reminds me how #Linux also was the first #OS to run on #Itanium and how the #GCC is even the best compiler for that architecture - even better than #Intel's own!
https://www.youtube.com/watch?v=3oxrybkd7Mo
But yeah, the only thing that would make @AsahiLinux even faster on #AppleSilicon would be if compiling stuff would be done entirely in RAM wherever possible, leveraging 10x->1000x more IOPS and lower latency.
#GCC 🤝 #DaVinciResolve
Builds 100-200 Mb output by 4+ hours
i have a number of #zines in progress about the great garbage continuum: the great cosmic flow of garbage, where things move from being "materials" to "useful" to "junk" to "gross" and then onward..
we are all in the great garbage continuum. the relationship b/w the cycle of life & the gcc is very complex.
anyway, i keep getting more zine ideas about it, like "with all projects, start them with the understanding that you'll eventually have to clean it up."
i have a number of #zines in progress about the great garbage continuum: the great cosmic flow of garbage, where things move from being "materials" to "useful" to "junk" to "gross" and then onward..
we are all in the great garbage continuum. the relationship b/w the cycle of life & the gcc is very complex.
anyway, i keep getting more zine ideas about it, like "with all projects, start them with the understanding that you'll eventually have to clean it up."
The tale of -mrtd in GCC and Clang
.@openSUSE #Tumbleweed Begins Rolling Out @gnutools #GCC 13
https://www.phoronix.com/news/openSUSE-Tumbleweed-GCC-13
Original tweet : https://twitter.com/phoronix/status/1639073663960973322
A wild #blog post appeared!
Did you know that #GCC just added Modula-2 and #Rust frontends to mainline? Come with me as I explore how well they work on #OpenBSD. (Spoiler: excellently out-of-the-box.)
As an added bonus, there are instructions in the blog post for how you can get your own GCC with Modula-2 and Rust on your own OpenBSD machine. Just a quick pkg_add away!
https://briancallahan.net/blog/20221219.html
#compiler #compilers #opensource #freesoftware #FOSS #FLOSS #OSS #FreeBSD #NetBSD #DragonFlyBSD #BSD #Unix #Linux
My first commit (written with antoyo) was merged in GCC! \o/
It allows us to continue improving the GCC backend for the Rust compiler (https://github.com/rust-lang/rustc_codegen_gcc/) without needing a custom libgccjit version. :)
https://github.com/gcc-mirror/gcc/commit/d2e782cb99c3116c389d6a9565678c4ffe267777
Wow, #gcc documentation is live with #sphinx #furo. 😍 https://gcc.gnu.org/onlinedocs/gcc/