[analog31]

But doesn't PIC use GCC too?

Disclaimer: I'm a long time PIC user, going all the way back to the PIC16C84. Long before anything like Arduino came out, I always found Microchip's documentation to be much easier to crack. Of course, I admit to a certain amount of mental inertia and familiarity with the platform as well.

[neltnerb]

I had to get a proprietary crippled third-party compiler to do anything on a PIC12 in C.

The PIC16 at the time at least definitely didn't have GCC support, I recall having to boot Windows to compile my code for it. Pretty sure that's still the case.

[analog31]

As I understand it, the architecture of the 8-bit PIC chips were not "C friendly," and still use a crippled proprietary compiler. I programmed those beasts in assembly. There were enough other advantages for me, such as EEPROM/Flash program memory and peripherals that I could wrap my head around.

The 16- and 32-bit chips are more mainstream, and after using their proprietary compiler for a while, they switched over to GCC. Now from my standpoint, it's still "their" GCC, in that I download and use their tools. And there are some features that you still have to pay for such as optimization. I'm certainly not in love with those aspects, but it's good enough for me to wait it out until something else comes along that's compelling enough for me to switch. Folks have demonstrated building their own GCC toolchain for PIC, but I haven't bothered.

Somebody without my mental inertia and legacy projects might make a different choice.

My uses aren't critical enough to require considering the smallest, cheapest parts, so I simply avoid the 8-bit chips.

[cellularmitosis]

Does it? The whole reason I chose AVR back in the day was the gcc port. http://www.ladyada.net/library/picvsavr.html

[Nullabillity]

My class just used chipKIT boards (Arduinos with PIC32s inside), and the official tools seem to be based on a forked GCC 4.5. For the labs we used a build of GCC 4.9 that the school had prepared, which also worked fine.