Jump table alignment (2.95.2 versus 3.2.3)

Jump table alignment (2.95.2 versus 3.2.3)

[Richard Russell]

Hello,

I have recently 'upgraded' to 3.2.3 from 2.95.2 (MinGW version)
and I am trying to get it to produce code no larger than its
predecessor.  Even with the -Os option it is still generating
object modules somewhat larger than before, and close examination
shows that this is because jump table (dispatch table) entries
are now aligned on 16-byte boundaries rather than 4-bytes with
2.95.2. With large tables this wastes quite a lot of space.

Is there an option which will force gcc 3.2.3 to use 4-byte or
8-byte alignment for jump table entries ?

Richard.
http://www.rtrussell.co.uk/

Jump table alignment (2.95.2 versus 3.2.3)

[Richard Russell]

Further to my previous message, the plot thickens.  The 'jump tables'
which have changed their alignment between 2.95.2 and 3.2.3 appear
not to be present in any of the source modules output from gcc, but
are present in the .exe file created by the linker.  Perhaps they are
part of some Windows-specific code introduced by the -mwindows option.
If it helps pin this down, here are hex dumps of the relevant parts
of the executables (just the first few table entries):

Built using MinGW 2.92.2 on a Windows 95 platform:

010E00  00 01 00 00 00 E8 8E FF-FF FF C9 C3 FF 25 3C 44
010E10  41 00 90 90 FF 25 44 44-41 00 90 90 FF 25 78 44
010E20  41 00 90 90 FF 25 64 44-41 00 90 90 FF 25 40 44
010E30  41 00 90 90 FF 25 60 44-41 00 90 90 FF 25 7C 44

Built using MinGW 3.2.3 on a Windows XP platform:

010B00  FF 25 24 54 41 00 90 90-00 00 00 00 00 00 00 00
010B10  FF 25 30 54 41 00 90 90-00 00 00 00 00 00 00 00
010B20  FF 25 2C 54 41 00 90 90-00 00 00 00 00 00 00 00
010B30  FF 25 28 54 41 00 90 90-00 00 00 00 00 00 00 00

It's those extra blocks of eight 00s which are causing the increase
in the file size.  What are these tables doing, and why has the
alignment changed ?  Maybe I should be addressing this question to
the MinGW people.

Richard.
http://www.rtrussell.co.uk/