I have the following code in c:
unsigned int a = 60; /* 60 = 0011 1100 */ int c = 0; c = ~a; /*-61 = 1100 0011 */ printf("c = ~a = %d\n", c ); c = a << 2; /* 240 = 1111 0000 */ printf("c = a << 2 = %d\n", c ); The first output is -61 while the second one is 240. Why the first printf computes the two's complement of 1100 0011 while the second one just converts 1111 0000 to its decimal equivalent?
You have assumed that an int is only 8 bits wide. This is probably not the case on your system, which is likely to use 16 or 32 bits for int.
In the first example, all the bits are inverted. This is actually a straight inversion, not two's complement:
1111 1111 1111 1111 1111 1111 1100 0011 (32-bit) 1111 1111 1100 0011 (16-bit) In the second example, when you shift it left by 2, the highest-order bit is still zero. You have misled yourself by depicting the numbers as 8 bits in your comments.
0000 0000 0000 0000 0000 0000 1111 0000 (32-bit) 0000 0000 1111 0000 (16-bit) 
Try to avoid doing bitwise operations with signed integers -- often it'll lead you into undefined behavior.
The situation here is that you're taking unsigned values and assigning them to a signed variable. For ~60 this is undefined behavior. You see it as -61 because the bit pattern ~60 is also the two's-complement representation of -61. On the other hand 60 << 2 comes out correct because 240 has the same representation both as a signed and unsigned integer.
~1 is 11111110 (sign extended for word size); that is -2. ~60 is -61. Reconsider your downvote? (Also, other downvoter please comment?)
cwould have a value of1111 1111 1111 1111 1111 1111 1100 0011.~complements all the bits, not just those you list in the first line.~a = 11111111 11111111 11111111 11000011, buta << 2 = 00000000 00000000 00000000 11110000.c, the value being printed, is declared as signed, and the%format code is for signed printing, socis naturally interpreted as a signed 2's complement number.