It's default automake behaviour. You can override it in various ways, for example, by passing CFLAGS in command line.

The problem about arguments you've described is a sequence of optimization, not the error in compiler. It just puts some params on register, making it hard to retrieve their actual values.

Nickolay,
    Maybe you have misunderstood; this is a serious issue, the fact that
one object file's function gets called with different arguments than
the arguments that we're provided from another object file always results
in unexpected behaviour (and its damn hard to nail when your running
after a segfault but you're really experiencing a compiler mis-hap).

This means that when compiling glade; depending on your binutils/gcc,
toolchain & environment; if you dont set CFLAGS by hand at configure
time you might get segfaults and unexpected behaviour; that is
definitly a bug and is unacceptable.

Is there anyway you know that I can override this behaviour at a
higher level ? can I do this in a safe & portable way from
the autogen.sh or configure.in file so that compiler flags are 
fixed also in a resulting package of `make dist' ?

Sorry for misunderstanding Tristan.

Do I understand correctly that you are calling functions with different set of parametrs in glade code? In that case it's nothing about compiler optimization and you certainly should not force -O0. Instead you should fix the code where it happens. Can you show the place in glade sources about that?

I wish that I could remember exactly where it has occured, I was using
gcc 2.95.3 last time I saw this bug (and have been compiling with only -g
since then; assuming that comiling with -O2 without -g would work fine
too).

I'm not sure what exactly you mean by "different set of parametrs" so
let me illustrate the problem that occurred:

    o Having some strange segfaults... trapping in gdb.
    o Segfaulting inside glade_property_class_somefunction () that
      was called from glade_widget_somefunction ().
    o In gdb; either the argument values were "not available" or were
      noticably skewed.
    o Didn't trust gdb; went on to print all the arguments in
      glade_property_class_somefunction() and all the arguments
      in glade_widget_somefunction() before invoking
      glade_property_class_somefunction().

      After printing with g_print(); I was assured that glade-widget.c 
      was indeed providing the correct arguments, but glade-property-class.c
      was recieving them skewed (like recieving twice the first arg
      and never the second).

Do you think its possible that I was using some unsupported form
of C code to invoke the function from another object ?
(from memory; the all the arguments were pointer to GObject derivatives
or to GValue or to const GValue)

Note also that I've ran into the same problem (also using gcc 2.95.3)
in another large project in the past (and noticed that I was optimizing
and adding profiler information at the same time); thats why I was so 
quick to write it off as a "problem with my gcc options".

My fear now is that if I close this bug, some people with older
compilers will still get this bug, or will only get this bug after
modifying some code.

Can anyone speak for the "safeness" of combining the "-O2" & "-g"
compiler flags ?

Sorry once again, please do whatever you want. 

About actual problem, it may be caused by stack memory corruption, not linking/compiling problems. In that case you'll can get arbitrary arguments. Of course, they will depend on -g and -O2, but this dependance is a side-effect, not a cause. That is why I was confused by this bug title and description.

I may be wrong, but almost all Fedora is built with -g -O2 since it's default automake settings. I wonder if they had problems with it.

I see your point,
   it could definitly be some kind of stack corruption that
was already resident but only caused segfaults when compiling
with `-O2 -g'.

Unfortunately this goes so far back that I'm not even going to
try to reproduce the crashes; so I think the practicle thing to
do is leave this open as an incedent purly for future reference
(if this happens again I think it will help).

It still bothers me that I've seen this happen in another project
where compiling with either -O2 *or* -g fixed the problem, also with
the same compiler... it still also strikes me as odd to ask the
compiler to optimize the code & add profiling information (which
"should work", just sounds like asking for trouble).

/me lives with his unsolved mysteries

well its happened again.

After Juan commits shortly... it will be unsafe to combine -O2 and -g
while building glade3 on my host (gcc-4.0.2/Linux-2.6.12-9).

The problem is that glade-gtk.c calls glade_base_editor_new()
(from glade-base-editor.c) and everything compiles fine...
then when it comes to calling the actual function, I get a wild
stack pointer instead.

Any ideas ?

Same here. I'm using gcc-4.1.1. I compiled glade-3 from CVS with the default CFLAGS ( which is -O2 I believe ). When I cut something and paste it into a GtkHPaned, I *always* get a segfault. If I recompile glade-3 with the CFLAGS "-g" I can cut / paste into GtkHPaned widgets to my heart's content :)

Backtrace was generated from '/usr/local/bin/glade-3'

Using host libthread_db library "/lib/libthread_db.so.1".
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.
[Thread debugging using libthread_db enabled]
[New Thread -1219250512 (LWP 17399)]
0xffffe410 in __kernel_vsyscall ()

+ Trace 69318