Live data from Hacker News

Rebuild of the Debian archive with clang

clang.debian.net

51–55 of 55 posts

Re: Rebuild of the Debian archive with clang

#51
post #32
post #25

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.

Fully agreed, having two open source, free compiler toolchains with which you can fully build your software stack beats having to rely on just one. And like you said competition is always good. Of course that is why it's better if both compilers continue to flourish, which is what I'm hoping/expecting will be the case.

Re: Rebuild of the Debian archive with clang

#52
post #26

Earlier 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…

"the notion that companies would be afraid of GCC strikes me as odd given that we have Red Hat, IBM, Google, CodeSourcery, Suse etc employing full-time GCC developers."

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

#53

Would be really interested to see what caused those segfaults! But the link in the table just goes to the table.

Here's one from one of the logs (http://clang.debian.net/logs/2012-01-12/libgtkada2_2.14.2-5_...):

  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

#54
post #28

Earlier 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.

I'm not altogether sure about VLAs' place in C itself, but they (along with contiguous storage of heterogeneous data) are neat ideas that let you do a few things cleverly. I think the usual example is a linked list of strings. Done the "normal" way each string will cause two cache misses - one for the string data, and one for the list node. If you're super unlucky you might get three cache misses (one for the node, one for the string object, one for the string data...). Done this way you only get one cache miss, which is pretty good and better than any other language will give you.

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

#55
post #9

This 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 ! :)

Thank you.
Post reply on HN