Verifying fixes in GCC 3.1 (and 3.1.1/3.2) from GCC 3.0.4, C++, Binutils, ABI?

["Mike Kasprzak" <mike dot kasprzak at dicecanada dot com>]

Hi there,

I'm about to upgrade my toolchain to GCC 3.1 (since 3.1.1/3.2 isn't
available yet) and snapshot (20020715) to hopefully remedy some illogical
issues that have popped up recently in my project.  I've been using a Cygwin
hosted ARM cross compiler built from GCC 3.0.4, Binutils 2.11.2 (yes I know,
also out of date), and Newlib 1.9.0 (also pretty old, I know).  I'd like to
just verify some things that been fixed since then in either the upcoming
release/the next one.  I've been following the discussions regarding the ABI
fixes and 3.11/3.2, which is what has convinced me to post.  Also if there
is patch not being included in 3.1.1/3.2 that would help me out, pointing me
in the right direction would be greatly appreciated.  In case the size of
this message spooks any people away, short 1 liner replies telling me
something is fixed in x.xx.x would be very helpful as well.  If this should
even go on the bugs list, please, tell me so.

I am going to use the latest Binutils and Newlib, perhaps those fix some my
current problem (see #1).  Once again, I'm mainly looking for "hey, thats
fixed in 3.1" type responses, or "yeah, thats a known bug in progress", but
detailed responses are greatly apreciated as well. :)

First I'll give a rough idea the features I'm using:
- C++
- templates
- many nested inlined methods of classes
- large inlined functions (-finline-limit=5000)
- 5 command line defines (in the broken case, -DLOCALIZED, etc...)
- lots of macros ( #define ... )
- ARM 7TDMI CPU (supports THUMB)
- branching to ARM code from C++ thumb code

(1)
First is my most recent problem (with the linker).  I'm not totally sure if
this is just the linkers fault (2.11.2), but from what I can tell it seems
to point to it.  I'll surely find out after I have built 2.12.x.  The
problem starts with this error:

g++.exe *** fork: can't reserve memory for stack 0x40000 - 0x240000, Win32
error 487
16 [main] g++ 1208 sync_with_child: child 456(0x124) died before
initialization with status code 0x1
396 [main] g++ 1208 sync_with_child: *** child state waiting for longjmp
Followed by 10 some odd similar errors.  Now things have ran perfectly for
months up until now.  What I've added recently is an extra command line
#define (bringing my total up to 5. I did see mention of something to do
with -D's fixed in the GCC 3.1.1 release notes draft).  I've also added many
more global symbols (possibly even double or triple what I had before),
ifndef/else/endif's to my makefiles and many #ifndef/#else/#endif's to C++
source files and header files.

(2)
I've found a strange work around to this problem, but I'm not totally sure
what it is.  I have many inlined methods of classes.  Some of these inline
other inlined methods from itself and related classes.  As well, there are
some very large (after macro's expand) inlined methods that I upped
"-finline-limit" to 5000 so it could optimize them out to a few opcodes
(assuming the optimizer can optimize explicit arguments (rather than as a
variable) and "if" blocks).  The problem occurs when I have quite a large
function, and I simply call a whole bunch of functions and do some logic and
looping (if blah { for something { do! } }).  It appears something extra or
something missed is thrown/not on the stack, which results in my code
branching randomly somewhere and crashing.  To remedy this, I clean up my
code ( hehehe ) by taking some of my more complicated parts of this function
and put them into smaller functions.

Now some things to note (which may or may not be related).  My target ARM
chip supports both THUMB and ARM modes (for those who don't know the ARM
chip, it has a full 32bit wide instruction set and a reduced 16bit wide
instruction set).  All my C++ code is generated as Thumb (the 16bit set),
yet I am calling a function that in turn branches to code in ARM (the 32bit
set), and tracing the problem back seemed to lay blame on this function that
branched to ARM code.  But as I said, by simply reducing the amount of
calls, loops, logic in the function, it would fix the problem.

(3)
This is very much like #2.  Just another case.  I have a simple inlined
method of a class that does some range checking, incrementing, and returns a
pointer to a structure (often the return is ignored).  In some cases, I
would use this function as an argument to a similar function.  Problem here
is it would generate bad code or possibly no code, and would not work.  No
crashing or mean lost PC/SP, just she didn't work.  Funny enough, remedy'd
the problem by creating an equal function (that it can't inline).  I ran
into this problem when I ran GCC 3.0.2 as well.

So finally, has something major been fixed in/or is know about whatever
handles inlining functions?  Or is *this* what all this talk about the
broken ABI is about (that 3.2 should fix.  As you can probably tell, I'm not
too familiar with what the ABI problem deep down is).

(4)
This one is possibly an ARM problem.  I saw this in both 3.0.2 and 3.0.4 (I
skipped 3.0.3).  I've ran into some complex loops/logic that would sometimes
have the compiler generate bad THUMB opcodes that the assembler couldn't
assemble (cause they're illegal).  Such as one (found this one a lot),
request to do some operation to register 8 (considered a 'high' register in
thumb mode, meaning it has limited functionality).  This did happen a lot
less when I switched from 3.0.2 to 3.0.4.  I don't presently have code that
reproduces this since, my infamous fix from before seemed to work (move it
or the logic in to a smaller function and call it).  Because of that, it
makes me think its the inlining again.  I ran into another one recently
where it generated an illegal operation with register 5 and the Stack
Pointer (register 13), but that one vanished after I corrected a logic
error.  Once again, I apologize for not having a sample, since I hadn't
planned on posted when I saw that one.

(5)
This one was another observation from 5-6 months ago.  Could be ARM related
bug.  While writing some ARM assembly functions (in a separate .s file), I
found I was able to branch to some of them, no problem, from my C++ code.
But other functions would crash (lose PC somehow).  This was with 3.0.2.  I
as well haven't touched my assembly code for a while.  Just wondering if
between 3.0.2 to present, if there has been some fixes or if there's some
known problem with branching (long branching mind you) to ARM from thumb (in
C++ code), or if that was just me (or my good friend the inline bug).


That's about all I can remember.  I appreciate any help, suggestions, etc...
anyone has.

Thanks, again.
--
Mike Kasprzak