Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?
On 30/04/19 22:48, Jeff Law wrote: > On 4/30/19 11:24 AM, Matthew Malcomson wrote: >> On 30/04/19 18:01, Jeff Law wrote: >>> On 4/30/19 10:48 AM, Matthew Malcomson wrote: Hi Jeff, On 30/04/19 16:29, Jeff Law wrote: > On 1/4/19 9:03 AM, Matthew Malcomson wrote: >> Hi there, >> >> I'm trying to figure out precisely what NOTE_INSN_FUNCTION_BEG means and >> hoping someone here knows. > It doesn't mean very much anymore. I believe it was used to > distinguish between stuff like copying incoming arguments into pseudos > and real user code. > > However, in a world with instruction scheduling and other code motion it > just doesn't have much use because it's so imprecise, particularly as we > get deeper into the RTL pipeline. > Ah, I guess an imprecise marker probably needs an imprecise definition ;-) >> > Well, the question I'd ask is precisely what are you trying to mark? I'm wanting to mark the first instruction from "user code". I'm trying to fix PR88432, where gdb puts the breakpoint from the "start" command in the wrong place. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88432 Gdb breaks on the second debug line entry in a function, which in practice is the instruction directly after NOTE_INSN_FUNCTION_BEG. The "fuzzy" definition from gccint.info didn't seem to explain what was to happen with compiler inserted code that was not part of the prologue, and this was what I was hoping to nail down. When looking, it seemed the note was being used in three slightly different ways (I went into more information in the cover letter of my [RFC] patch https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00543.html ), and I was hoping to get a precise definition so I could decide what approach to take. >>> ISTM that we should place the stack protector bits before the >>> NOTE_INSN_FUNCTION_BEG. At least in the non-optimizing compile case >>> that should make the right thing happen. >>> >>> Jeff >>> >> >> Yeah, unfortunately I saw that moving that note would break some other >> places -- where the note is used as a marker for where to insert some >> other code. >> >> The one I can remember (sort of) was that asan stack protection code is >> inserted just before "parm_birth_insn" (which is >> NOTE_INSN_FUNCTION_BEG), and that needs to be done before the non-local >> goto save area as per the solution for bugzilla 88186. >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81186 >> >> That was why I ended up suggesting multiple notes -- it's currently >> trying to satisfy more than one criteria and they're not quite compatible. > Well, we obviously have to keep arg setup, asan, stack protector and > nonlocal stuff in the same relative order, but I believe they should all > ultimately land before the NOTE_INSN_FUNCTION_BEG. THe question is how > to make that happen :-) > It's pretty easy if we can replace the uses of NOTE_INSN_FUNCTION_BEG with another note: In order to satisfy how it's used in `final_start_function_1`, `sjlj_emit_function_enter` in except.c and the nonlocal stuff I could add a differently named note at the current position. Then I could move NOTE_INSN_FUNCTION_BEG to after everything automatically added since it's then only used by the debug information. How would you feel about a modification of my RFC patch https://gcc.gnu.org/ml/gcc-patches/2019-01/msg00543.html , where the uses of the suggested NOTE_INSN_DEBUG_FUNCTION_BEG are satisfied by NOTE_INSN_FUNCTION_BEG and a new NOTE_INSN_VAR_END where the current NOTE_INSN_FUNCTION_BEG is?
Re: ICE with precompiled headers (GCC 8.1)
On Tue, 2019-04-30 at 09:43 -0400, Paul Smith wrote: > Here's the thing: I added the "-MD -MF foo.d" options to the PCH file > compile (I wanted to get a manifest of which files were included in the > PCH file). Without those options I cannot reproduce this at all (in a > number of tries). With those options it happens most of the time on > some systems (but again, never on my local system). I have made more discoveries. In the compiler invocation that is ICEing, if I remove the -fpch-deps option then it no longer ICEs (with the same PCH file that ICEd before!) I can remove/add that option to my .cpp compile line, and it ICEs with it and works without it, no other changes. But again, it works fine on my system always. So there's _sometimes_ something odd inside the PCH file which is triggered by the source file compilation adding -fpch-deps. FWIW, here's the compile line I use to generate the PCH: g++ ...opts... -MD -MF dir/foo.h.d -o dir/foo.h.gch -x c++-header foo.h And here's the compile line I use to compile source code: g++ ...opts... -fpch-deps -fpch-preprocess -Winvalid-pch \ -iquote"dir" --include=foo.h Adding/removing -fpch-preprocess doesn't seem to matter. It's only the -fpch-deps option during the compile, combined with the -MD/-MF options when creating the PCH file, that seems to trigger the ICE. > Unfortunately my GCC is heavily optimized and stripped so backtraces > are useless. I will generate a debuggable GCC and see if I can get > more info on the ICE. I have created a GCC with debug enabled so I'll see what I find.
Re: Second GCC 9.1 Release Candidate available from gcc.gnu.org
On 4/30/19 8:12 AM, Jakub Jelinek wrote: The second release candidate for GCC 9.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190430/ ftp://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190430 and shortly its mirrors. It has been generated from SVN revision 270689. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 9.1 on Friday, May 3rd. All looks good on powerpc64. Bootstrap built and tested on powerpc64 power 7 and power 8 BE and power 8 and power 9 LE. -- -Bill Seurer
Re: Second GCC 9.1 Release Candidate available from gcc.gnu.org
Hi Jakub, > On 30 Apr 2019, at 14:12, Jakub Jelinek wrote: > > The second release candidate for GCC 9.1 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190430/ > ftp://gcc.gnu.org/pub/gcc/snapshots/9.0.1-RC-20190430 > > and shortly its mirrors. It has been generated from SVN revision 270689. powerpc-apple-darwin9 i686-apple-darwin10 x86_64-apple-darwin10 x86_64-apple-darwin14 x86_64-apple-darwin16 Have been boostrapped and tested using GCC as the bootstrap compiler (incl. Ada) x86_64-apple-darwin18 has been boostrapped using xc10.2 command line tools and SDK (no Ada). x86_64-apple-darwin18 bootstrap using GCC succeeded (incl. Ada), but testing is not complete yet. test results: https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg00103.html https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg00104.html https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg00106.html https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg00107.html https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg00108.html https://gcc.gnu.org/ml/gcc-testresults/2019-05/msg00109.html thanks Iain
Re: ICE with precompiled headers (GCC 8.1)
On Wed, 2019-05-01 at 09:35 -0400, Paul Smith wrote: > > Unfortunately my GCC is heavily optimized and stripped so backtraces > > are useless. I will generate a debuggable GCC and see if I can get > > more info on the ICE. > > I have created a GCC with debug enabled so I'll see what I find. I was able to reproduce this ICE quite readily with my debuggable GCC 8.1.0. Here's the failure: : internal compiler error: Segmentation fault 0x9cae61 crash_signal /work/src/cc/gcc-8.1.0/gcc/toplev.c:325 0x1293778 apply_vpath /work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:127 0x1293acc deps_add_dep(deps*, char const*) /work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:258 0x1293fe3 deps_restore(deps*, _IO_FILE*, char const*) /work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:432 0x129535b cpp_read_state(cpp_reader*, char const*, _IO_FILE*, save_macro_data*) /work/src/cc/gcc-8.1.0/libcpp/pch.c:884 0x596d59 c_common_read_pch(cpp_reader*, char const*, int, char const*) /work/src/cc/gcc-8.1.0/gcc/c-family/c-pch.c:373 0x12872fe should_stack_file /work/src/cc/gcc-8.1.0/libcpp/files.c:814 0x12874f1 _cpp_stack_file /work/src/cc/gcc-8.1.0/libcpp/files.c:900 0x12876a7 _cpp_stack_include /work/src/cc/gcc-8.1.0/libcpp/files.c:1049 0x1287b22 cpp_push_include(cpp_reader*, char const*) /work/src/cc/gcc-8.1.0/libcpp/files.c:1484 0x5943ec push_command_line_include /work/src/cc/gcc-8.1.0/gcc/c-family/c-opts.c:1483 0x594615 c_finish_options /work/src/cc/gcc-8.1.0/gcc/c-family/c-opts.c:1452 0x5963a2 c_common_parse_file() /work/src/cc/gcc-8.1.0/gcc/c-family/c-opts.c:1126 Unsurprisingly the problem is that the "deps" data member in cpp_reader* is null: #0 apply_vpath (d=d@entry=0x0, t=t@entry=0x2174860 "/src/foo_pch.h") at /work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:127 #1 0x01293acd in deps_add_dep (d=d@entry=0x0, t=t@entry=0x2174860 "/src/foo_pch.h") at /work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:258 #2 0x01293fe4 in deps_restore (deps=0x0, fd=fd@entry=0x2171750, self=self@entry=0x2106810 "/src/obj/foo_pch.h.gch") at /work/src/cc/gcc-8.1.0/libcpp/mkdeps.c:432 #3 0x0129535c in cpp_read_state (r=r@entry=0x20f4d60, name=name@entry=0x2106810 "/src/obj/foo_pch.h.gch", f=f@entry=0x2171750, data=0x210bce0) at /work/src/cc/gcc-8.1.0/libcpp/pch.c:884 I have no idea whether the problem is that it should never be possible for "deps" to be null, or whether the problem is that we're not checking for that possibility when we should be. I'm building the current GCC 9.0.1 prerelease to see if I can reproduce it there. Once again removing -fpch-deps solves the problem. I can only assume that without that flag we never bother to walk the deps data member at all.
glibc-2.2{8,9} multiarch build failure on x86_64 with gcc 9
gcc 9 when configured for fortran installs ISO_Fortran_Binding.h in gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include For x86_64's 32-bit architecture support, this creates a subdirectory named 'include' inside $(libsubdir)/32 which didn't use to exist in gcc 8. glibc's configure script, when configured with --with-headers=, uses the following logic to guess at gcc's internal include directories. This failes on gcc 9 because with -m32 now we will get $(gfor_cdir) as the return for -print-file-name=include, instead of the real directory that contains all the include files, $(libsubdir)/include. The result is that SYSINCLUDES is incorrectly defined and the rest of the build fails due to missing standard include files, eg stddef.h etc. # if using special system headers, find out the compiler's sekrit # header directory and add that to the list. NOTE: Only does the right # thing on a system that doesn't need fixincludes. (Not presently a problem.) if test -n "$sysheaders"; then SYSINCLUDES=-nostdinc for d in include include-fixed; do i=`$CC -print-file-name="$d"` && test "x$i" != x && test "x$i" != "x$d" && SYSINCLUDES="$SYSINCLUDES -isystem $i" done SYSINCLUDES="$SYSINCLUDES \ -isystem `echo $sysheaders | sed 's/:/ -isystem /g'`" if test -n "$CXX"; then CXX_SYSINCLUDES= for cxxheaders in `$CXX -v -S -x c++ /dev/null -o /dev/null 2>&1 \ | sed -n -e '1,/#include/d' -e 's/^ \(\/.*\/[cg]++\)/\1/p'`; do test "x$cxxheaders" != x && CXX_SYSINCLUDES="$CXX_SYSINCLUDES -isystem $cxxheaders" done fi fi AC_SUBST(SYSINCLUDES) AC_SUBST(CXX_SYSINCLUDES) I'm not sure if this is a gcc bug or a glibc bug? Should libgfortran install in the MULTISUBDIR? That's the only include file that goes in there, and it is installing the same include file in all of them, so this seems unnecessary. glibc's configure fragment above also looks extremely fragile though, the CXX_SYSINCLUDES version looks a little more robust, should something similar be done for SYSINCLUDES?
Re: glibc-2.2{8,9} multiarch build failure on x86_64 with gcc 9
gcc 9 when configured for fortran installs ISO_Fortran_Binding.h in gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include For x86_64's 32-bit architecture support, this creates a subdirectory named 'include' inside $(libsubdir)/32 which didn't use to exist in gcc 8. glibc's configure script, when configured with --with-headers=, uses the following logic to guess at gcc's internal include directories. This failes on gcc 9 because with -m32 now we will get $(gfor_cdir) as the return for -print-file-name=include, instead of the real directory that contains all the include files, $(libsubdir)/include. The result is that SYSINCLUDES is incorrectly defined and the rest of the build fails due to missing standard include files, eg stddef.h etc. # if using special system headers, find out the compiler's sekrit # header directory and add that to the list. NOTE: Only does the right # thing on a system that doesn't need fixincludes. (Not presently a problem.) if test -n "$sysheaders"; then SYSINCLUDES=-nostdinc for d in include include-fixed; do i=`$CC -print-file-name="$d"` && test "x$i" != x && test "x$i" != "x$d" && SYSINCLUDES="$SYSINCLUDES -isystem $i" done SYSINCLUDES="$SYSINCLUDES \ -isystem `echo $sysheaders | sed 's/:/ -isystem /g'`" if test -n "$CXX"; then CXX_SYSINCLUDES= for cxxheaders in `$CXX -v -S -x c++ /dev/null -o /dev/null 2>&1 \ | sed -n -e '1,/#include/d' -e 's/^ \(\/.*\/[cg]++\)/\1/p'`; do test "x$cxxheaders" != x && CXX_SYSINCLUDES="$CXX_SYSINCLUDES -isystem $cxxheaders" done fi fi AC_SUBST(SYSINCLUDES) AC_SUBST(CXX_SYSINCLUDES) I'm not sure if this is a gcc bug or a glibc bug? Should libgfortran install in the MULTISUBDIR? That's the only include file that goes in there, and it is installing the same include file in all of them, so this seems unnecessary. glibc's configure fragment above also looks extremely fragile though, the CXX_SYSINCLUDES version looks a little more robust, should something similar be done for SYSINCLUDES? (Fix return address in email)
Re: glibc-2.2{8,9} multiarch build failure on x86_64 with gcc 9
On 5/1/19 2:24 PM, Arvind Sankar wrote: gcc 9 when configured for fortran installs ISO_Fortran_Binding.h in gfor_cdir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include For x86_64's 32-bit architecture support, this creates a subdirectory named 'include' inside $(libsubdir)/32 which didn't use to exist in gcc 8. This doesn't seem correct. I would have expected the header to exist under the target name, for example: /usr/lib/gcc/i686-redhat-linux/9/include/ISO_Fortran_binding.h This way it doesn't conflict with other uses. Perhaps there is enough variability in the way you build, package, and install this that it can break in some configurations. I think the gcc community needs to comment on this. -- Cheers, Carlos.
Re: glibc-2.2{8,9} multiarch build failure on x86_64 with gcc 9
On Wed, May 01, 2019 at 02:36:10PM -0400, Carlos O'Donell wrote: > On 5/1/19 2:24 PM, Arvind Sankar wrote: > > gcc 9 when configured for fortran installs ISO_Fortran_Binding.h in > > gfor_cdir = > > $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include > > For x86_64's 32-bit architecture support, this creates a subdirectory named > > 'include' > > inside $(libsubdir)/32 which didn't use to exist in gcc 8. > This doesn't seem correct. > > I would have expected the header to exist under the target name, for example: > > /usr/lib/gcc/i686-redhat-linux/9/include/ISO_Fortran_binding.h > > This way it doesn't conflict with other uses. > > Perhaps there is enough variability in the way you build, package, and > install this > that it can break in some configurations. > > I think the gcc community needs to comment on this. > > -- > Cheers, > Carlos. To be clear, it does exist there as well (I think because the native arch has an empty MULTISUBDIR. The breakage happens because it _also_ exists under .../9/32/include.
Re: glibc-2.2{8,9} multiarch build failure on x86_64 with gcc 9
On Wed, May 01, 2019 at 02:48:30PM -0400, Arvind Sankar wrote: > On Wed, May 01, 2019 at 02:36:10PM -0400, Carlos O'Donell wrote: > > On 5/1/19 2:24 PM, Arvind Sankar wrote: > > > gcc 9 when configured for fortran installs ISO_Fortran_Binding.h in > > > gfor_cdir = > > > $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/include > > > For x86_64's 32-bit architecture support, this creates a subdirectory > > > named 'include' > > > inside $(libsubdir)/32 which didn't use to exist in gcc 8. > > This doesn't seem correct. > > > > I would have expected the header to exist under the target name, for > > example: > > > > /usr/lib/gcc/i686-redhat-linux/9/include/ISO_Fortran_binding.h > > > > This way it doesn't conflict with other uses. > > > > Perhaps there is enough variability in the way you build, package, and > > install this > > that it can break in some configurations. > > > > I think the gcc community needs to comment on this. > > > > -- > > Cheers, > > Carlos. > > To be clear, it does exist there as well (I think because the native arch has > an > empty MULTISUBDIR. The breakage happens because it _also_ exists under > .../9/32/include. Including Paul -- looks like the file gets installed in different places in fortran-dev branch vs trunk?
Re: What is the precise definition of NOTE_INSN_FUNCTION_BEG?
On Tue, Apr 30, 2019 at 03:48:02PM -0600, Jeff Law wrote: > On 4/30/19 11:24 AM, Matthew Malcomson wrote: > > That was why I ended up suggesting multiple notes -- it's currently > > trying to satisfy more than one criteria and they're not quite compatible. > Well, we obviously have to keep arg setup, asan, stack protector and > nonlocal stuff in the same relative order, but I believe they should all > ultimately land before the NOTE_INSN_FUNCTION_BEG. THe question is how > to make that happen :-) The current meaning of NOTE_INSN_FUNCTION_BEG is /* Indicate the beginning of the function body, as opposed to parm setup. */ emit_note (NOTE_INSN_FUNCTION_BEG); (function.c), and half of the things that use the note think that everything before it is argument setup, and nothing after it is. Just adding extra notes isn't enough afaics; some surgery is needed. Segher
Re: ICE with precompiled headers (GCC 8.1)
I was able to reproduce this with GCC 9.0.1 20190430 as well. It appears that adding -MD to the PCH build sometimes causes the "deps" data in the PCH file to be empty, but this is never noticed unless you use the -fpch-deps option on the source compile line: if you don't do this then nothing in GCC will try to access that pointer. I feel like I've hit the end of what I can do with tracking this down, so I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90306 Although I couldn't create a repro case, I can reproduce it here on some systems so if someone wants me to investigate further I'm happy to do that: please provide some pointers/advice for debugging. On Wed, 2019-05-01 at 10:56 -0400, Paul Smith wrote: > On Wed, 2019-05-01 at 09:35 -0400, Paul Smith wrote: > > > Unfortunately my GCC is heavily optimized and stripped so backtraces > > > are useless. I will generate a debuggable GCC and see if I can get > > > more info on the ICE. > > > > I have created a GCC with debug enabled so I'll see what I find. > > I was able to reproduce this ICE quite readily with my debuggable GCC > 8.1.0. Here's the failure:
