3 ms·
"using the compiler the code is written in as part of the compile-edit-debug cycle, rather than having static analysis as an extra tool “on the side” (perhaps p
by olivierduval 7y ago
"using the compiler the code is written in as part of the compile-edit-debug cycle, rather than having static analysis as an extra tool “on the side” (perhaps proprietary)"
Mmmm... and why not have an external tool, part of the GCC family but with a proper API, to allow to use ANY TOOL instead of bloating GCC with one more tool that won't be usable on other compilers and will need specific maintainers, althought this field is already really complex and need a lot of different knowledges ?
For example, it could be based on intermediate code so better than just source-code or machine-code analysis...
- olivierduval 7y agoJust to be more specific: why not use the "UNIX philosophy" with a compiler to compile (translate to Intermediate Representation), an optimizer to optimize, an assembler to produce machine code from IR (with allocation registry) and so on...?
- aw1621107 7y agoIIRC in the past GCC (or maybe just some of the maintainers?) has been resistant to that kind of architecture because it makes it easier to write proprietary extensions/plugins/backends/frontends/etc. to GCC. I'm not sure whether that has changed. LLVM was designed to be a lot more modular, so it fits these use cases a lot better. In your example, you have the front ends (C, C++, Objective-C, Fortran frontends in LLVM proper, Rust, Zig, etc. as third-party front-ends) compiling to LLVM IR, opt for optimization, and different backends to generate machine code from IR.
- UncleMeat 7y agoBecause GCC is explicitly designed to be a tangled mess (as opposed to Clang/LLVM), in part because it makes it harder for groups with different beliefs about FLOSS code to repurpose it. Its a choice that has caused them to cede a lot of territory to Clang/LLVM.
- ndesaulniers 7y agoI think the major mistake was FSF refusing the objective c front end from Apple.