Sorry for digging up this old thread, but a few remarks (it shows that you have never been a member of the TIGCC Team!):
Lionel Debroux (./2) :
Also noteworthy is the fact that support for generic m68k COFF was removed from GCC in GCC 4.4: http://gcc.gnu.org/gcc-4.4/changes.html , so ELF is the way forward for GCC 4.6+.
Both the generic m68k and generic COFF support is still there, so readding the m68k-coff pieces to GCC shouldn't be hard. It's a bigger problem with GNU as, where non-BFD_ASSEMBLER support was removed, and m68k-coff was never ported to BFD_ASSEMBLER. So one would have to try enabling BFD_ASSEMBLER and seeing what breaks. Several other COFF targets use it. But at least the custom TIGCC changes would have to be ported to the BFD_ASSEMBLER code branches. But it should also be possible to use a newer GCC with an older GNU as.
I think the much bigger effort will be to deal with the various changes in the core of GCC which break our patches, at least that has always been the main source of work when porting the TIGCC patch to a newer GCC. Sometimes, I was forced to revert the upstream changes, sometimes to readd removed functions in parallel to the new ones, sometimes to rewrite the TIGCC changes (almost) from scratch against the new code.
With good linker scripts, we can think that ELF could do the job 
IMHO, ELF can do the job if and only if support can be added to ld-tigcc, including all the special ld-tigcc features. Unlike the original poster, I do not believe that a generic toolchain is suitable at all.
So, now to the notes on your patch analysis:
* fiddling with default attributes: gcc/attribs.c, gcc/c-common.c, gcc/c-common.h, gcc/c-decl.c, gcc/c-lang.c, gcc/c-tree.h, gcc/langhooks-def.h, gcc/langhooks.h, gcc/system.h
This is needed because the new way to handle the default attributes in current upstream GCC relies on the builtin functions, which we don't use for various reasons (reliance on stdio features we don't have, wrong floating-point format etc.). So I had to readd the old code which supported default attributes for non-builtin functions. It's basically just a reversion of an upstream patch(set).
* changes to the GCC built-in functions, among which is __builtin_ER_throw: gcc/builtin-attrs.def, gcc/builtins.c, gcc/builtins.def
See above why we do the removals. We add __builtin_ER_throw because it is the cleanest way to support ER_throw (and GCC didn't have __builtin_unreachable back then; these days, we could use a macro with an asm and a __builtin_unreachable();, which would produce basically the same intermediate representation as __builtin_ER_throw, which just generates an asm and a "barrier" (i.e. a "this is unreachable")).
* SMAP II BCD support: gcc/c-cppbuiltin.c, gcc/c-format.c, gcc/combine.c, gcc/config/m68k/m68k.md, gcc/config/m68k/m68k-modes.def, gcc/config/m68k/predicates.md, gcc/config/smapbcd.h, gcc/config.gcc, gcc/convert.c, probably gcc/c-pretty-print.c, gcc/dwarf2out.c, gcc/emit-rtl.c, probably gcc/explow.c, gcc/expr.c, gcc/final.c, gcc/fold-const.c, gcc/genmodes.c, gcc/machmode.def, gcc/optabs.c, gcc/output.h, gcc/print-rtl.c, gcc/print-tree.c, gcc/real.c, gcc/real.h, gcc/rtlanal.c, gcc/simplify-rtx.c, gcc/tree.c, gcc/tree-pretty-print.c, gcc/varasm.c
Yes, the c-pretty-print.c (first hunk) and explow.c changes are part of it. The main part is a complete rewrite of floating-point handling to work on BCD numbers even internally (to avoid rounding errors from conversion), see especially real.c. And a fairly invasive part is support for unpadded 10-bit numbers (BFmode), a non-multiple-of-4, which GCC didn't support at all.
* changes related to forward or backslashes in paths: gcc/c-incpath.c, gcc/toplev.c
That's really part of the W32 changes.
* multi-line strings: probably gcc/c-lex.c, probably gcc/c-ppoutput.c, libcpp/internal.h, libcpp/lex.c
Yes, the c-lex.c and c-ppoutput.c changes are part of this.
* default to not initializing the BSS section: gcc/common.opt
Actually, this should say "default to not putting zero-initialized variables into the BSS section". This is a backwards-compatibility and consistency change:
int x=0;puts
x into the data section (in particular, will retain the value if the program is not archived nor compressed) (as opposed to the BSS section which is the upstream default), same as:
int x=1;(but of course with a different initializer) whereas:
int x;will put the data into the BSS section, allocated at runtime and usually initialized to 0 (unless this is disabled at linker level) (same as upstream).
Note: With
-mno-bss,
x will always be put in the data section, i.e.
int x; will behave exactly like
int x=0;.
Another note: This has the paradoxical effect that, with the default options,
int x; actually guarantees that
x is zero at program startup, whereas
int x=0; does not! But it is the only behavior that makes sense from both a compatibility and a consistency standpoint. And the upstream default behavior makes
int x=0; behave the same as
int x;, which does not allow specifying the equivalent of
int x=0; at all.
* debugging support: maybe gcc/config/dbxcoff.h, gcc/config/m68k/m68k.c, gcc/dwarf2.h, gcc/dwarf2out.c, gcc/toplev.c, gcc/varasm.c* OPTIMIZE_ROM_CALLs: gcc/config/m68k/m68k.c
Yes, the dbxcoff.h change is related to debugging support, but in the deprecated COFF-native format (as opposed to DWARF 2 or even Stabs), so I think it could probably just be dropped.
* no long branches: gcc/config/m68k/m68k.c + external patcher (with a "FIXME: should be moved to GCC")
Yes, IMHO, that'd better be done directly inside GCC, but it's more work to do that way (a lot of places inside GCC to patch).
* platform-specific changes such as greater optimization, or different printf/scanf/memset/etc., or peepholes: gcc/c-format.c, gcc/config/m68k/m68k.c, gcc/config/m68k/m68k.h, gcc/config/m68k/m68k.md, gcc/config/m68k/m68k-none.h, gcc/config/m68k/m68k.opt, gcc/config/m68k/m68k-ti.h, gcc/config/m68k/predicates.md, gcc/expr.c, gcc/opts.c, gcc/postreload.c, gcc/stmt.c, gcc/tree-object-size.c
I think this category could use splitting.
(Some others maybe too, but this one in particular.)
* changes to default warnings: gcc/c-decl.c -> what with "Each undeclared identifier is reported only once" ?
Sebastian removed that "feature" because it confuses the IDE.
* gcc/c-pretty-print.c -> what's the second hunk ?
It processes ({…}) expressions in the statement printer, as used in the
_rom_call macros, so you get warnings like "Too many arguments to function '*(*200u + 1656u)'" (for
ClrScr(1)) rather than "Too many arguments to function 'statement expression'".
* reference the TIGCC infrastructure which does not make public the bug report content: gcc/diagnostic.c, gcc/version.c
The "which does not make public the bug report content" is very much off-topic here. (FWIW, there are hardly any bugs reported through that form in the first place these days anyway.) And of course, referencing the correct downstream bug form, in addition to obviously making sense, is actually a request by upstream GCC.
I could put up a Trac for TIGCC on CalcForge (I've been considering it), but I'm not sure it's even worth it anymore.
* a warn_unused_result-related change: gcc/gimplify.c
No warning if the unused result is cast to void. It's stupid to warn if the programmer explicitly asked not to.
* a patch related to using hard register variables as an asm input: gcc/loop.c
Enforces that the register variable is actually in the register it's supposed to be in when hitting an asm. IMHO a bugfix!
* gcc/sdbout.c -> ?
Changes absolute lines to relative lines, related to the dbxcoff.h change discussed above. Both these changes were done to allow the old "parser" to more easily find the source lines to patch into the generated assembly code. I think this change is obsolete now that the "parser" is gone (replaced by proper debugging support), and that it can therefore be removed.
* inlining-related fix: gcc/tree-inline.c
This goes along with a change to c-typeck.c (the #if 0 added). See
http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00683.html for the discussion. Basically, the problem was that casting a function pointer to a different function pointer type could crash the inliner if the function got inlined, and the upstream "fix" to the problem was to make it an error (well, a warning and a generated call to
abort();, because the standard doesn't allow making it a compile-time error) to cast a function pointer this way, which is both unnecessary and backwards-incompatible. It particularly breaks things in TIGCC due to the short vs. int mess among other issues. So I reverted that "fix" and instead applied the original proposed patch for the crash, which actually fixes the problem.
* a change without comments in gcc/tree-ssa-ccp.c
This just disables the whole
ccp_fold_builtin function, it's part of the builtin function removal. (I added this when porting the TIGCC patch to GCC 4.0, with "gcc/tree-ssa-ccp.c (ccp_fold_builtin): Do nothing." as the changelog entry, as looking up the date (which I did add as a comment) in the changelog would have told you. And it isn't particularly hard to figure out what happens when I #if 0 the whole function and replace it with a "return NULL_TREE;".
As for why I did it, see the discussion about builtins further up.)
* pragma poison (why ?): libcpp/directives.c
Backwards compatibility.
git / svn blame is unhelpful, need to look up in the Changelog and commit history...
That's what the changelog is for.
Known bugs (besides being a nightmare to port forward to newer GCC versions, and not being directly portable above GCC 4.4):
* http://tichessteamhq.yuku.com/topic/4793 : in CALLBACK functions, a5 is not reinitialized to __jmp_tbl, which can yield a crash.
- N3buk4dn3zz4r: "I managed to find the reason for this special error: Using #define OPTIMIZE_ROM_CALLS causes this code to crash(who knows why?), if this option is not set, the above code should work pretty well."
- Lionel: "When OPTIMIZE_ROM_CALLS is defined, the startup code initializes the a5 processor register to the address of the ROM_CALL table, and the rest of the program uses that to read the addresses of ROM_CALLs.However, AMS uses a5 for its own purposes in a number of functions. When AMS calls back into your program, the value of a5 can be different from what the program expects. Any CALLBACK or interrupt handler function
This is actually incorrect, there's a special hack for OPTIMIZE_ROM_CALLS and interrupt handlers (as I had already pointed out in my reply back then!). (It checks if %a5 is a global register variable, and if yes, it asks the preprocessor if OPTIMIZE_ROM_CALLS is defined (to double-check), and if still yes, it adds a
move.l 0xc8,%a5 to the special interrupt handler prolog.)
using a5 (or, in general, any global register variable) without having reinitialized it to the expected value will trigger one of the processor exceptions when trying to call TE_handleEvent.
There are at least two fixes to the problem:
* some inline ASM for reinitializing a5;
* using F-Line ROM_CALLs, with an internal emulator if you want your program to run on AMS <= 2.03 without requiring your users to install some form of F-Line ROM_CALL handler. F-Line ROM_CALLs are smaller than optimized ROM_CALLs (potentially large savings on programs containing many ROM_CALLs), but have some overhead in the call/return sequence (not that it matters much in practice)."
- Kevin: "To fix this properly, we need to have CALLBACK expand to a dedicated GCC attribute, add that attribute to GCC, and then add a similar hack to GCC's config/m68k/m68k.c to what we already have for interrupt handlers (__attribute__((interrupt_handler))), search for OPTIMIZE_ROM_CALLS in the TIGCC patch or the TIGCC-patched config/m68k/m68k.c."(it's not just OPTIMIZE_ROM_CALLS, Kevin - all global register variables are affected by this infrequent problem, i.e. -freg-relative-a<n> and other user-defined global register variables are affected, though we can't do much for the latter
That's exactly my point, "we can't do much for the latter", OPTIMIZE_ROM_CALLS is the only case which we can make work with a special hack.
).