gcc3 and gcc4 for nios in Altera 10.0

[Altera_Forum]

I've just downloaded the gcc sources (gcc3 and gcc4) for Altera 10.0 from the Altera ftp site. 

 AFAICT the gcc3 sources are identical to those from the 9.1 release (except that the version and build number have both been set to zero).  The gcc4 sources don't seem to contain my patches, however I can't actually build the 'gas' in binutils-2.17 because the gcc I'm using (Debian 4.3.2-1.1) detects a real buffer overrun! (I've tried a patch).  From the diffs of the nios2.c and nios2.md it looks as though they've made 2 rather unwanted changes that will need patching out by anyone trying to build a very small embedded system:  1) The jump table for switch statements looks as though it is being put into the .code segment (not the .rodata segment). On systems where all code and data is in tightly coupled memory this isn't wanted - this will be a slow avalon bus xfer, and the slave access to the code memory need not otherwise be enabled. Ideally this data could be in its own section - the linker script can then assign it to an appropriate memory region. In my case I'd like to get a shorter jump table sequence by using 'gp' relative addressing!  2) gp relative addressing seems to have been disabled for external data items (some comment about them not necessarily being defined in the .sdata section in the other file).  I think this will apply even for definitions like: extern uint32_t *mtp2_cmd_isr section(.sbss); which is very fubar. Possibly it might make sense to not default to putting small extern data into the .sdata segment.

[Altera_Forum]

As well as the bug in gas/app.c line 561 (change UNGET('\n'); to *fromend++ = '\n'; ) , the regexp that validates the installed version of 'makeinfo' needs fixing to detect that 4.11 >= 4.2! 

Adding 4\.1[0-9] into the '|' pattern of the regexp seems to work. (line 3615 of gcc-4.1/configure and line 6121 of binutils-2.17/configure, or search for 'MAKEINFO.*--version').  And I can confirm the two unwanted changes apply. Not to mention a call to memcpy() appearing!

[Altera_Forum]

FWIW all my patches to gcc applied ok. 

However the generated code is significantly worse than that from gcc3. I haven't looked at exactly what has happened, but my hdlc code loop has gone from 149 clocks to 175 - about 17% degradation, this isn't a good sign!