On 10/3/19 5:25 PM, Jakub Jelinek wrote:
> On Thu, Oct 03, 2019 at 03:17:47PM +0000, Bernd Edlinger wrote:
>> Hi,
>>
>> this fixes -Wshadow=local warnings in the RTL_FLAG_CHECKx macros,
>> which happen when this macro is used recursively in a macro
>> argument. The __typeof (RTX) const _rtx in the inner macro
>> expansions shadows the outer macro expansions.
>>
>> So reworked the macro to not use statement expressions but
>> use templates instead. Since the 7-argument overload is not
>> used anywhere removed RTL_FLAG_CHECK7 for now.
>
> What effect does this have on the cc1/cc1plus .text sizes?
r276457:
with patch, --enable-languages=all --enable-checking=yes,rtl
$ size gcc/cc1
text data bss dec hex filename
35117708 50984 1388192 36556884 22dd054 gcc/cc1
$ size gcc/cc1plus
text data bss dec hex filename
37871569 54640 1391936 39318145 257f281 gcc/cc1plus
unpatched, --enable-languages=all --enable-checking=yes,rtl
$ size gcc/cc1
text data bss dec hex filename
36972031 50984 1388192 38411207 24a1bc7 gcc/cc1
$ size gcc/cc1plus
text data bss dec hex filename
39725980 54640 1391936 41172556 2743e4c gcc/cc1plus
I am a bit surprised, that the patch gives smaller code. I used not the original
Version of this patch, but the one based on Richard's suggestion.
> Does this affect debuggability of --enable-checking=yes,rtl compilers?
> I mean, often when we replace some macros with inlines step in GDB
> becomes a bigger nightmare, having to go through tons of inline frames.
> gdbinit.in has a lengthy list of inlines to skip in rtl.h, shouldn't this be
> added to that list? Not 100% sure how well it will work on rtl checking
> vs. non-rtl checking builds.
>
I don't see a big problem here. If I type "s" in gdb it jumps to the check
function and the next s jumps back, adding skip instructions in gdbinit.in
does not seem to have any effect for me, but the debug is not that uncomfortable
anyway.
Interesting is that gdb also jumps in the check function when I press n.
That is also Independent of the gdbinit.in, seems to be a bug due to inlining
code from another line than the original macro, but nothing terrilby bad.
Bernd.
