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] |
> 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