This is the mail archive of the gdb-testers@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: gcc/sdbout.c and char parameters


> I believe that gcc already says that the parameter has type `char' if
> you compile without optimization.  Is this what you are seeing?

Yes, you are right.

> I also believe that gcc will say the parameter has type `int' when optimizing,
> but that there is no practical way to fix this in the sdbout format.  Is
> this the only thing you are complaining about?

Yes, but I always compile with optimization :).

> 	E.g., look at the code generated for the following small testcase, 
> 	In both the `ansi' and the `kr' functions, to build a `short' from the `char'
> 	parameter, one does a sign-extension of the `char' parameter, not a
> 	truncation of the promoted `int' parameter.
> 
> If you look at the RTL dumps, you can see that the parameter is an int, that
> gets truncated to a char, and then sign-extended to a short.  Gcc believes
> that the value being passed in is an int, it just isn't taking advantage of
> this fact to generate faster code.

No, Gcc knows that the value passed is a char, but padded to fit the size of
an int. If those functions were called with something not in the range of
values for a char, it must discard the extraneous bits.

> Gcc is instead generating more portable
> code.

Gcc generates the right code.  If it did not truncate the pseudo-int,
the result would be wrong.

> I believe that you will get the faster code if a port defines
> PROMOTE_FUNCTION_ARG, but this will result in subtle incompatible ABI changes
> which is why it is not the default.  I believe that the changes you suggest
> would cause gcc to emit incorrect debug info for ports that do define this
> macro unless we explicitly checked for it.  There may also be other
> complications.

That's something for egcs, than.

Philippe