Indeed, a potential quagmire.
The 3 products you mention have some unique characteristics and possible answers. I'll address each one.
Bugzilla (and problem management / tracking in general). For this, I would do a very simple validation. Show you have installed it according to documentation, document (under doc control) the customizations / site adaptations you made (noting how they are done within expected use), and walk some issues through the cycle, especially focusing on your customizations / adaptations. Now the unique thing here is that change records are quality records and thus Part 11 comes into play. Bugzilla, to the best of my knowledge, can't be made to be fully Part 11 compliant (exacerbated by the fact that it's open source software) so to get around this, I would recommend that once an issue is closed, a copy of the report be printed and saved as the official quality record. There's plenty of debate about how the "true" record is still electronic (and is certainly so during the life of the issue) but this approach has been at least accepted in the past (which is not a guarantee, of course).
For Subversion, I would take a similar tack and do a validation using your process. Show it's installed per recommendations (IQ). Show how changes are controlled (check out, check in) using your process and how builds are constructed using your process. I presume subversion has a way to tag the build configuration so be sure to show that. The unique thing here is that the software in subversion is not really the final product - the binaries out of the compiler are; however, since it's such a critical control point, I would beef up the OQ part just to show that proper controls are in place. Show, for example, that if someone makes an unauthorized change, how it's likely to be caught. That's probably the biggest issue with versioning systems.
Finally, for the gnu compiler, let's just say it's quite impossible (IMO) to validate a compiler. The tack we've always taken is that you compile your source and do a complete validation of the built software; thus, by default, the compiler is working as expected. Issues from a compiler error would likely be obvious or would be likely caught in product testing. You should do a decent IQ and focus on known issues with the compiler. Analyze the known issues and if any are determined to likely impact your product, user training to avoid or watch for such issues is a good approach.
Sorry for the long post but the answer is complex and compounded by the types of software you cite. Hope this helps.