Why is everyone itching to get off of GCC? Or is it all just posturing, to get GCC to work harder now that it has competition?
Even if everyone doesn't switch, having more than one widely used open-source C compiler would be healthy. If anything, it allows some non-portable code to be found and fixed. Also, competition is healthy. The different compiler developers can choose to focus on specific areas of improvement (e.g. compile speed vs executable speed) rather than a one-size-fits-all approach.
Rebuild of the Debian archive with clang
51–55 of 55 posts
Re: Rebuild of the Debian archive with clang
#52Earlier quoted context omitted.
GCC is becoming larger and more unmaintainable with each release. Competition in this space has been pretty sorely lacking for quite some time. The OpenBSD folks are also pushing PCC as a GCC alternative. It'll be nice to have a BSD-licenced GCC equivalent for distribution with FreeBSD/OpenBSD, too. Clang also has REALLY great error messages compared to GCC. It will tell you exactly where you forgot a comma, semicolo…
Well Clang/LLVM is also becoming larger with each release. As for GCC becoming more 'unmaintainable', can you point me to anything supporting that notion? It's certainly not unmaintainable now as proven by them regularly releasing new improved versions which serve as the de facto compiler toolchain for open source systems. Also when speaking of GCC and how old and full of cruft it is, you need to realize that it's co…
Afraid? I expect that these companies have spent serious money on lawyers to figure out whether GPL 3 was acceptable for them before committing to it.
Also, Mac OS supports OpenCL (http://en.wikipedia.org/wiki/OpenCL). One could argue that that makes the compiler more a part of the OS than "just another application that runs on it". If they used GPL code there, a perceived risk could be that they could be forced to make their OS GPL.
Re: Rebuild of the Debian archive with clang
#53Would be really interested to see what caused those segfaults! But the link in the table just goes to the table.
Building libgtkada.so.2.14.2
cd obj-shared; x86_64-linux-gnu-gcc -shared -fPIC -Wl,--as-needed \
-o libgtkada.so.2.14.2 -Wl,-soname,libgtkada.so.2.14.2 glib*.o gdk*.o \
gtk*.o pango*.o misc.o misc_broken.o -lgtk-x11-2.0 -lgdk-x11-2.0 \
-latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 \
-lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype \
-lfontconfig -lgobject-2.0 -lgmodule-2.0 \
-lgthread-2.0 -lrt -lglib-2.0 -lgnat -lX11
Segmentation fault
In this case it looks like the compiler is crashing when invoking the linker (I'm assuming that x86_64-linux-gnu-gcc has been aliased to clang).The others: http://clang.debian.net/status.php?version=3.0&key=SEG_F...
Re: Rebuild of the Debian archive with clang
#54Earlier quoted context omitted.
If you put basic standard compliance aside, it also strips down the errors from arguable code to horrifying coding practice. http://clang.debian.net/status.php?version=3.0&key=VARIA... http://clang.debian.net/status.php?version=3.0&key=NON-P...
Really I never got the argument for disallowing variable-length arrays at the end of a C structure. I completely agree with disallowing non-PoD variable-length arrays as well as variable-length arrays in the middle of a structure though.
Another few cool things: If elements "know about themselves" (have a size element or a vtable etc etc) you can make stacks and queues without the need for a separate index.
There are also a few things you can probably only do in ASM: Say you have an "array" of objects "inheriting" from a common base (with sizes depending on their type) and all you ever want to do with them is iterate over them calling virtual functions on them. A nice way to do it would be to keep the iteration logic at the end of the virtual functions (which know about the sizes of their respective objects) and do something that smells a little like tail-call-elimination, maybe with a sentinel object on the end to wrap things up nicely. To get the best bang for your buck you'd need an architecture that isn't preachy about the stack or calling conventions, of course, but it still might be worth doing for a laugh.
Erm, I guess this wasn't too clear. In some pseudocode below:
virtual void Factorial::process_and_print() {
//processing logic:
this->n *= (++this->i);
print(this->n);
//iteration logic:
this += sizeof(Factorial);
this->process(); //must do TCO
}
virtual void Message::process_and_print() {
//processing logic:
print(this->message);
//iteration logic:
this += sizeof(Message);//message stored by pointer
this->process();
}
virtual void Sentinel::process() {
//iteration logic:
return;
}
funnyArray fa;
fa.add(Factorial(1));
fa.add(Message("hello"));
fa.add(Sentinel());
fa.run(process); //prints something like "1hello"
I guess you'd mostly want the iteration logic and the sentinel to be taken care of by the language/library, too, but that's probably not worth thinking about unless there's actually a real use-case for something like this...Re: Rebuild of the Debian archive with clang
#55This is seriously amazing and will, certainly, improve all the codebases involved. Sylvestre and the others involved deserve a lot of good karma for this. Going a step further, wouldn't it be great if all packages had automated tests that could easily be run on the 91% of the packages that were successfully built?
Thanks. I appreciate ! :)