| Message ID | 46e52372-6559-da67-6f90-074a80e6deae@mentor.com |
|---|---|
| State | New |
| Headers | show |
| Series | [nvptx,committed] Disable -gstatement-frontiers for nvptx | expand |
On Dec 27, 2017, Tom de Vries <Tom_deVries@mentor.com> wrote: > .loc file_index line_number column_position > so this causes ptxas errors when compiling something for nvptx with > -g, which breaks the nvptx build. What do the errors look like? I ask because the patches that actually change the generated debug info, adding view to .loc lines when the assembler supports them, are yet to be installed, in the patches that introduces LVUs. No significant changes have been made to dwarf2out in the SFN patchset so far. Furthermore, even with the LVU patch, .loc directives with view numbers would only be used if the assembler is detected as supporting them at compiler build time.
On 12/29/2017 05:12 AM, Alexandre Oliva wrote: > On Dec 27, 2017, Tom de Vries <Tom_deVries@mentor.com> wrote: > >> .loc file_index line_number column_position > >> so this causes ptxas errors when compiling something for nvptx with >> -g, which breaks the nvptx build. > > What do the errors look like? > The nvptx-none build breaks in libgcc: ... configure:3706: error: in `/home/vries/nvptx/mainkernel-2/build-gcc/nvptx-none/libgcc': configure:3709: error: cannot compute suffix of object files: cannot compile ... For this conftest.c: ... #define PACKAGE_NAME "GNU C Runtime Library" #define PACKAGE_TARNAME "libgcc" #define PACKAGE_VERSION "1.0" #define PACKAGE_STRING "GNU C Runtime Library 1.0" #define PACKAGE_BUGREPORT "" #define PACKAGE_URL "http://www.gnu.org/software/libgcc/" /* end confdefs.h. */ int main () { ; return 0; } ... We get this error: ... $ build-gcc/gcc/xgcc -Bbuild-gcc/gcc -c -g -O2 conftest.c ptxas conftest.o, line 17; fatal : Parsing error near 'st': syntax error ptxas fatal : Ptx assembly aborted due to errors nvptx-as: ptxas returned 255 exit status ... By using -Wa,--no-verify, we can see the ptxas input: ... $ cat -n conftest.o ... 15 mov.u32 %value,0; 16 .loc 1 15 1 is_stmt 0 17 st.param.u32 [%value_out],%value; 18 ret; 19 } ... With -gno-statement-frontiers, we have this instead: ... ... 13 mov.u32 %value,0; 14 .loc 1 15 1 15 st.param.u32 [%value_out],%value; 16 ret; 17 } ... and ptxas is able to parse the input. > I ask because the patches that actually change the generated debug info, > adding view to .loc lines when the assembler supports them, are yet to > be installed, in the patches that introduces LVUs. No significant > changes have been made to dwarf2out in the SFN patchset so far. > > Furthermore, even with the LVU patch, .loc directives with view numbers > would only be used if the assembler is detected as supporting them at > compiler build time. > If you point me to the location of a configure test that is supposed to file, I can try to find out why it passes. Thanks, - Tom
On Dec 29, 2017, Tom de Vries <Tom_deVries@mentor.com> wrote: > On 12/29/2017 05:12 AM, Alexandre Oliva wrote: >> On Dec 27, 2017, Tom de Vries <Tom_deVries@mentor.com> wrote: >> >>> .loc file_index line_number column_position >> >>> so this causes ptxas errors when compiling something for nvptx with >>> -g, which breaks the nvptx build. >> >> What do the errors look like? > 16 .loc 1 15 1 is_stmt 0 Oh, is_stmt is not a new assembler feature, nor is it one that's introduced by SFN, but SFN does indeed get GCC to exercise it in cases it didn't before, and that completely escaped me when I was surprised by your previous email. Thanks for the data, it clears it all up for me. > If you point me to the location of a configure test that is supposed > to file, I can try to find out why it passes. Thanks, even the configure test for '.loc ... view' support is in the LVU patch yet to be reviewed and installed. Now, perhaps it would be wise to introduce a test for is_stmt support in .loc directives, now that we know there are assemblers that don't support it.
On 12/31/2017 09:04 PM, Alexandre Oliva wrote: > On Dec 29, 2017, Tom de Vries <Tom_deVries@mentor.com> wrote: > >> On 12/29/2017 05:12 AM, Alexandre Oliva wrote: >>> On Dec 27, 2017, Tom de Vries <Tom_deVries@mentor.com> wrote: >>> >>>> .loc file_index line_number column_position >>> >>>> so this causes ptxas errors when compiling something for nvptx with >>>> -g, which breaks the nvptx build. >>> >>> What do the errors look like? > >> 16 .loc 1 15 1 is_stmt 0 > > Oh, is_stmt is not a new assembler feature, nor is it one that's > introduced by SFN, but SFN does indeed get GCC to exercise it in cases > it didn't before, and that completely escaped me when I was surprised by > your previous email. Thanks for the data, it clears it all up for me. > >> If you point me to the location of a configure test that is supposed >> to file, I can try to find out why it passes. > > Thanks, even the configure test for '.loc ... view' support is in the > LVU patch yet to be reviewed and installed. > > Now, perhaps it would be wise to introduce a test for is_stmt support in > .loc directives, now that we know there are assemblers that don't > support it. > Filed: PR83788 - Add .loc is_stmt support test ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83788 ). Thanks, - Tom
Disable -gstatement-frontiers for nvptx 2017-12-27 Tom de Vries <tom@codesourcery.com> * config/nvptx/nvptx.c (nvptx_option_override): Disable -gstatement-frontiers. --- gcc/config/nvptx/nvptx.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/gcc/config/nvptx/nvptx.c b/gcc/config/nvptx/nvptx.c index cce0a55..e024570 100644 --- a/gcc/config/nvptx/nvptx.c +++ b/gcc/config/nvptx/nvptx.c @@ -177,6 +177,8 @@ nvptx_option_override (void) if (!global_options_set.x_flag_toplevel_reorder) flag_toplevel_reorder = 1; + debug_nonbind_markers_p = 0; + /* Set flag_no_common, unless explicitly disabled. We fake common using .weak, and that's not entirely accurate, so avoid it unless forced. */