[Bug driver/92170] New: Incorrect function names output when using -fstack-usage on C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92170
Bug ID: 92170
Summary: Incorrect function names output when using
-fstack-usage on C++
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: austinpmorton at gmail dot com
Target Milestone: ---
Created attachment 47075
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47075&action=edit
example source
When test.cc is compiled as follows:
g++ -c -fstack-usage test.cc
test.su contents appears as follows:
test.cc:12:34: 16 static
test.cc:12:34:static void::_FUN(void*) 24 static
test.cc:12:34:::operator void (*)(void*)() const 16 static
test.cc:8:11:)>::fptr_t) [with RetT = void; ArgTs = {}] 16 static
test.cc:20:12:void __static_initialization_and_destruction_0(int, int) 48
static
test.cc:20:12:cc) 16 static
expected test.su contents as follows:
test.cc:12:26: 16 static
test.cc:12:26:static void::_FUN(void*) 24 static
test.cc:12:26:::operator void (*)(void*)() const 16 static
test.cc:8:11:function_ref::function_ref(function_ref::fptr_t) [with RetT = void;
ArgTs = {}] 16 static
test.cc:20:12:void __static_initialization_and_destruction_0(int, int) 48
static
test.cc:20:12:(static initializers for test.cc) 16 static
This appears to be caused by code in output_stack_usage in toplev.c searching
for "." in the function name and only outputting after that point.
It is unclear to me what the intent was originally, but it dates back to the
original stack usage support commit (990495a75cd7).
I achieved the expected output shown above by applying the below patch to
disable the checks:
diff --git a/gcc/toplev.c b/gcc/toplev.c
index 1c7002f5c37..a0b6cefd2d1 100644
--- a/gcc/toplev.c
+++ b/gcc/toplev.c
@@ -981,6 +981,7 @@ output_stack_usage (void)
= strchr (IDENTIFIER_POINTER (DECL_NAME (current_function_decl)), '.');
const char *name
= lang_hooks.decl_printable_name (current_function_decl, 2);
+#if 0
if (suffix)
{
const char *dot = strchr (name, '.');
@@ -996,6 +997,7 @@ output_stack_usage (void)
if (dot)
name = dot + 1;
}
+#endif
fprintf (stack_usage_file,
"%s:%d:%d:%s\t" HOST_WIDE_INT_PRINT_DEC"\t%s\n",
[Bug driver/92170] Incorrect function names output when using -fstack-usage on C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92170 --- Comment #3 from Austin Morton --- Created attachment 47078 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47078&action=edit workaround patch
[Bug driver/92170] Incorrect function names output when using -fstack-usage on C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92170 --- Comment #2 from Austin Morton --- Created attachment 47077 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47077&action=edit expected su output
[Bug driver/92170] Incorrect function names output when using -fstack-usage on C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92170 --- Comment #1 from Austin Morton --- Created attachment 47076 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47076&action=edit current su output
[Bug middle-end/92170] Incorrect function names output when using -fstack-usage on C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92170 --- Comment #5 from Austin Morton --- Of course, I only provided it to show how I was generating the "expected" results. I wasn't sure what the purpose of splitting at "." was (in particular since I think of GCC as a C/C++ compiler and the "." would not normally appear in qualified names as a separator). With the context that this is something specific for Ada, I think maybe the correct thing to do would be to make this filtering a language hook that can be customized to do the right thing for each language.
[Bug middle-end/92170] Incorrect function names output when using -fstack-usage on C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92170 --- Comment #7 from Austin Morton --- As I said, the code made no sense to me in the context of C/C++ qualified names - the comment didn't clarify that this bit of code was concerned with Ada qualified names. Printing the fully qualified name is exactly what my patch does (although obviously it doesn't remove the disabled code). For C/C++ this change would be non-breaking since in all cases the output was either correct and fully qualified already, or just outright broken. For Ada this would presumably be a breaking change? Hence why I suggested making a language hook to specify the behavior per-language. Maybe a breaking change here is not something you are concerned with, in which case it would definitely be simpler to just unconditionally print the fully qualified name.
[Bug preprocessor/85487] New: Support '#pragma region' and '#pragma endregion' to allow code folding with Visual Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85487 Bug ID: 85487 Summary: Support '#pragma region' and '#pragma endregion' to allow code folding with Visual Studio Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: austinpmorton at gmail dot com Target Milestone: --- #pragma region is a feature introduced by Microsoft in order to allow manual grouping and folding of code within Visual Studio. It is entirely ignored by the compiler. Clang has supported this feature since 2012 when in MSVC compatibility mode, and enabled it across the board 3 months ago. As it stands, you cannot use #pragma region within GCC without disabling unknown pragma warnings, which is not advisable. I propose GCC adopt "#pragma region" and "#pragma endregion" in order to alleviate these issues. Because the pragma has no purpose at compile time, the implementation would be trivial. Microsoft Documentation on the feature: https://docs.microsoft.com/en-us/cpp/preprocessor/region-endregion LLVM change which enabled pragma region across the board: https://reviews.llvm.org/D42248 Example usage and resulting compiler output: https://godbolt.org/g/uJv6u4
[Bug inline-asm/85593] New: GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 Bug ID: 85593 Summary: GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: austinpmorton at gmail dot com Target Milestone: --- Created attachment 44048 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44048&action=edit example code triggering bug When calling a naked function declared in the same translation unit which includes inline assembly that modifies registers which are not preserved across function calls according to the arm abi (R0-R3), GCC 5+ can incorrectly allocate these registers for local variables in the caller and expect them to persist between function calls. * -O2 must be enabled to observe this behavior. * the function must be declared in the same translation unit, if declared extern gcc correctly allocates preserved registers for its locals * GCC 4.6.4 correctly allocates R4 in the example code given * GCC 5.4, and all higher versions tested incorrectly allocates R3 in the example code given * I have built a clean copy of GCC trunk and observed this issue as well note: this issue is present on all arm triplets I have tested, not just arm-none-eabi. compile bug.c with the following options to observe the bug arm-none-eabi-gcc -O2 -DBUG -S bug.c -o - compile bug.c with the following options to observe the correct behavior with an extern declaration arm-none-eabi-gcc -O2 -S bug.c -o - note that in the non-working compiler versions gcc attempts to load a value from r3 between calls to test2, whereas in the working compiler versions gcc will produce identical code save for using r4. for convenience sake, here is the example shown in working vs nonworking compiler versions on godbolt: https://godbolt.org/g/kMSn8W
[Bug target/85593] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 --- Comment #2 from Austin Morton --- Where is this limitation documented? The GCC documentation on the naked function attribute makes no mention of such a caveat: https://gcc.gnu.org/onlinedocs/gcc/ARM-Function-Attributes.html See here for real world usage that triggers this issue: https://git.kernel.org/pub/scm/bluetooth/sbc.git/tree/sbc/sbc_primitives_armv6.c Note that I am not the original author of the above code, just someone who ran into issues attempting to use it on gcc newer than 4.x In this specific case it is simple enough to fix by pushing r3, but it seemed like a bug with the compiler, considering the behavior changed between major releases. If this is indeed an issue with the code itself and not the compiler, that is fine, but it should certainly be documented that naked functions are not meant to be called directly.
[Bug target/85593] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 --- Comment #4 from Austin Morton --- In my particular case I was able to work around the issue by removing the naked attribute and using extended assembly with a clobbers list. The resulting code is nearly identical (allowing GCC to generate the correct pro/epilog instead of hand writing it), and gcc correctly allocates R4 instead of R3. This still feels like a bug in GCC. In the example I gave, if you compiled the naked function in a separate C file and linked them it would generate the correct code. The issue is that GCC is able to "see" the naked function and is performing optimizations that it shouldn't as a result. I believe that GCC should treat naked functions as opaque as far as optimizations are concerned. At the very least, there should be a note about this kind of issue included in the documentation of the naked attribute.
[Bug target/85593] [6,7,8,9 Regression] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 --- Comment #7 from Austin Morton --- I will certainly give writing a patch a try - but I will disclaim up front that because there is a viable workaround for the issue I was having (patch below [1]), this issue is "resolved" as far as my employer is concerned. Nevertheless, I will attempt to tackle this on a weekend out of curiosity (never had a reason to dig around in compiler guts before). [1] https://marc.info/?l=linux-bluetooth&m=152535913710490&w=2
[Bug target/85593] [6/7/8/9 Regression] GCC on ARM allocates R3 for local variable when calling naked function with O2 optimizations enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85593 --- Comment #9 from Austin Morton --- Apologies for letting this sit so long. I spent an afternoon digging through some of the mentioned functions trying to familiarize myself with everything but I didn't make it further than that. That was a few months ago at this point. I don't think I have the time to go back at this point - it's probably better left to someone already familiar with the compiler. Thanks, Austin
[Bug c/85487] Support '#pragma region' and '#pragma endregion' to allow code folding with Visual Studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85487
--- Comment #5 from Austin Morton ---
(In reply to Jonathan Wakely from comment #3)
> The docs raise some questions.
>
> They say that a #pragma region must be ended by a #pragma endregion. Should
> the compiler check that and issue a diagnostic otherwise?
>
> What is the form of the optional "name" that follows #pragma region?
>
> What if #pragma endregion is followed by preprocessor tokens, not just a
> comment?
>
> If we don't care about validating anything, it's easy to make GCC completely
> ignore those pragmas:
>
> --- a/gcc/c-family/c-pragma.cc
> +++ b/gcc/c-family/c-pragma.cc
> @@ -1218,6 +1218,15 @@ handle_pragma_message (cpp_reader *ARG_UNUSED(dummy))
> TREE_STRING_POINTER (message));
> }
>
> +/* Ignore a no-op pragma that GCC recognizes, but which has no effect. */
> +static void
> +handle_pragma_ignore (cpp_reader *)
> +{
> + tree x;
> + while (pragma_lex (&x) != CPP_EOF)
> +/* Ignore the rest of the line. */;
> +}
> +
> /* Mark whether the current location is valid for a STDC pragma. */
>
> static bool valid_location_for_stdc_pragma;
> @@ -1633,6 +1642,9 @@ init_pragma (void)
>c_register_pragma ("GCC", "pop_options", handle_pragma_pop_options);
>c_register_pragma ("GCC", "reset_options", handle_pragma_reset_options);
>
> + c_register_pragma (0, "region", handle_pragma_ignore);
> + c_register_pragma (0, "endregion", handle_pragma_ignore);
> +
>c_register_pragma ("STDC", "FLOAT_CONST_DECIMAL64",
> handle_pragma_float_const_decimal64);
>
>
>
> This needs tests though.
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553182.html
I sent a patch to do exactly that in 2020 and it was not accepted.
This seems like a very easy win.
Both major competitors to GCC (clang and MSVC) implement this pragma exactly
like in my patch (by completely ignoring it).
As it stands today, this is plainly a deficiency in GCC when compared to its
competition.
