Imho, dev tool validation, and especially compiler validation, is relevant for very, very, very, critical software.
Perhaps it makes sense for a small subset of embedded sw used in class III MD, like pacemakers. Likewise it makes senses in automotive or airborne systems where sw failure equals dozens of casualities.
Engineers in theses disciplines take time reading the assembly code generated by the compiler. Amongst other code verification techniques.
About compilers:
Validating a compiler is not an easy task. There is a symposium dedicated to code generation in Orlando FL. In 2011, Xavier Leroy presented the results of his team about C compiler validation. Here:
http://www.cgo.org/cgo2011/Xavier_Leroy.pdf
Looks quite readable at the beginning but becomes quickly very difficult. Just have a look at this presentation to see the complexity of real compiler validation.
There are also commercial compiler validation products which contain thousands of tests cases to verify compilers compliance to C language standards. They are extremely expensive. Because they contain a huge history of tests added day by day by their manufacturers.
So imagine validating an IDE like visual studio. A perfect nonsense! Or a perfectly uncomplete task!
That's why unless you work on very critical MD, it's better to spend time testing the MD software, like sagai said. If there is a bug in the compiler then the generated code will be buggey as well.
To leave this discussion open: why shouldn't we validate processors as well? Remember the fdiv error in Intel pentium 4 instruction set.
@kimovitch: to answer your comment, there is no requirement to have a dev tool validated.