Bug 66801 - [6 Regression] gcc miscompiled during PGO/LTO bootstrap
Summary: [6 Regression] gcc miscompiled during PGO/LTO bootstrap
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 6.0
: P3 normal
Target Milestone: 6.0
Assignee: Richard Biener
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-08 07:44 UTC by Markus Trippelsdorf
Modified: 2015-08-12 08:58 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2015-07-08 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Trippelsdorf 2015-07-08 07:44:09 UTC
On ppc64le gcc gets miscompiled during stagefeedback phase:

 % /home/trippels/gcc_build_dir_/./gcc/xgcc --version
[1]    53644 segmentation fault (core dumped)  /home/trippels/gcc_build_dir_/./gcc/xgcc --version

 % ../gcc/configure --with-cpu=power8 --disable-libstdcxx-pch --disable-libvtv --disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp --disable-werror --disable-multilib --enable-languages=c,c++ --enable-checking=release --with-build-config=bootstrap-lto
 % make -j120 BOOT_CFLAGS="-mcpu=power8 -O3 -pipe" STAGE1_CFLAGS="-mcpu=power8 -O3 -pipe" CFLAGS_FOR_TARGET="-mcpu=power8 -O3 -pipe" CXXFLAGS_FOR_TARGET="-mcpu=power8 -O3 -pipe" profiledbootstrap
Comment 1 Markus Trippelsdorf 2015-07-08 09:38:12 UTC
Started with r225504.
Comment 2 Markus Trippelsdorf 2015-07-08 10:23:57 UTC
Also happens on x86_64.
Comment 3 Richard Biener 2015-07-08 11:13:47 UTC
Hmpf.  Can't see why it should - I suppose the only "questionable" hunk _may_ be


+      /* Visit the statement only if its block is marked executable.
+         If it is not executable then it will be visited when we simulate
+        all statements in the block as soon as an incoming edge gets
+        marked executable.  */
+      if (!bitmap_bit_p (executable_blocks, bb->index))
+       {
+         if (dump_file && (dump_flags & TDF_DETAILS))
+           {
+             fprintf (dump_file, "\nDropping statement from SSA worklist: ");
+             print_gimple_stmt (dump_file, stmt, 0, dump_flags);
+           }
+         continue;
...
+      simulate_stmt (stmt);
 
-      /* PHI nodes are always visited, regardless of whether or not
-        the destination block is executable.  Otherwise, visit the
-        statement only if its block is marked executable.  */
-      if (gimple_code (stmt) == GIMPLE_PHI
-         || bitmap_bit_p (executable_blocks, bb->index))
-       simulate_stmt (stmt);
+      return true;

Thus, does the following fix it? (I'd have to try reproducing it first)

Index: gcc/tree-ssa-propagate.c
===================================================================
--- gcc/tree-ssa-propagate.c    (revision 225534)
+++ gcc/tree-ssa-propagate.c    (working copy)
@@ -444,7 +444,8 @@ process_ssa_edge_worklist (vec<gimple> *
          If it is not executable then it will be visited when we simulate
         all statements in the block as soon as an incoming edge gets
         marked executable.  */
-      if (!bitmap_bit_p (executable_blocks, bb->index))
+      if (gimple_code (stmt) != GIMPLE_PHI
+         && !bitmap_bit_p (executable_blocks, bb->index))
        {
          if (dump_file && (dump_flags & TDF_DETAILS))
            {

not that I have an idea _why_ it should fix something.
Comment 4 Markus Trippelsdorf 2015-07-08 11:41:41 UTC
The patch doesn't help, unfortunately.

By the way compiling gimple-match.c with -fprofile-generate takes
almost 4 minutes on gcc112.
Comment 5 rguenther@suse.de 2015-07-08 11:43:12 UTC
On Wed, 8 Jul 2015, trippels at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66801
> 
> --- Comment #4 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
> The patch doesn't help, unfortunately.

Ok, then we're hitting a latent bug which is exposed by different
(better) iteration order :(

> By the way compiling gimple-match.c with -fprofile-generate takes
> almost 4 minutes on gcc112.

Yeah, I know.
Comment 6 Richard Biener 2015-07-08 12:22:52 UTC
Ok, so the only code-gen difference possible is due to match.pd patterns
applying/not applying because of the changed iteration order making lattice
values final at different times.

Thus I suspect a latent bug in a match.pd pattern.  Which means to possibly
"bisect" those?

I'm now first trying to reproduce.
Comment 7 Richard Biener 2015-07-08 12:35:00 UTC
Oh, and FDO also effectively enables most -O3 optimizations of course.  After
reproducing FDO/LTO I'll try FDO only and bootstrap-O3 ... fingers crossing ;)
Comment 8 Richard Biener 2015-07-08 14:22:12 UTC
Ok, I can't reproduce it on x86_64 with

--enable-languages=c --disable-multilib --with-build-config=bootstrap-lto --disable-werror

make -j8 profiledbootstrap

on r225546.
Comment 9 Richard Biener 2015-07-08 14:22:44 UTC
Ah, you used release checking...  damn.
Comment 10 Markus Trippelsdorf 2015-07-08 14:25:40 UTC
(In reply to Richard Biener from comment #9)
> Ah, you used release checking...  damn.

Also note the various FLAGS that I use in comment0. 
Both PGO and LTO are needed. 
PGO alone is fine, LTO alone is fine and bootstrap-O3 alone is also fine.
Comment 11 Markus Trippelsdorf 2015-07-08 15:06:01 UTC
../gcc/configure --disable-libstdcxx-pch --disable-libvtv --disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp --disable-werror --disable-multilib --enable-languages=c,c++ --enable-checking=release --with-build-config="bootstrap-lto bootstrap-O3"

make profiledbootstrap

is enough to reproduce. 
(gimple-match.c takes over 15 minutes to compile with this config).
Comment 12 Richard Biener 2015-07-09 07:37:25 UTC
Also fails for HJ https://gcc.gnu.org/ml/gcc-regression/2015-07/msg00224.html,
from what I can see it's plain LTO/FDO bootstrap (but with checking enabled
and multilibs).

I suppose using LTO really means the bug might be hard to trigger.

Now trying your config.
Comment 13 Markus Trippelsdorf 2015-07-09 08:31:55 UTC
(In reply to Richard Biener from comment #12)
> Also fails for HJ
> https://gcc.gnu.org/ml/gcc-regression/2015-07/msg00224.html,
> from what I can see it's plain LTO/FDO bootstrap (but with checking enabled
> and multilibs).

H.J.'s config was failing before r225504 went in, so it must be a 
different issue: https://gcc.gnu.org/ml/gcc-regression/2015-07/msg00014.html
Comment 14 Richard Biener 2015-07-09 08:44:07 UTC
Hmpf, bootstrap passed on x86_64-linux with

/space/rguenther/src/svn/trunk2/configure --disable-libstdcxx-pch --disable-libvtv --disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp --disable-werror --disable-multilib --enable-languages=c,c++ --enable-checking=release --with-build-config=bootstrap-lto bootstrap-O3
make -j12 profiledbootstrap

(r225542)
Comment 15 Markus Trippelsdorf 2015-07-09 10:27:22 UTC
For x86_64 additional --with-arch=native (sandybridge) is needed during configuration.
Comment 16 Richard Biener 2015-07-09 11:15:08 UTC
So, if it is related to vectorization (if I ever get to reproduce it I'll try -fno-tree-vectorize) then it might be the

/* If arg0 is derived from the address of an object or function, we may
   be able to fold this expression using the object or function's
   alignment.  */
(simplify
 (bit_and (convert? @0) INTEGER_CST@1)
 (if (POINTER_TYPE_P (TREE_TYPE (@0))
      && tree_nop_conversion_p (type, TREE_TYPE (@0)))
  (with
   {
     unsigned int align;
     unsigned HOST_WIDE_INT bitpos;
     get_pointer_alignment_1 (@0, &align, &bitpos);
   }
   (if (wi::ltu_p (@1, align / BITS_PER_UNIT))
    { wide_int_to_tree (type, wi::bit_and (@1, bitpos / BITS_PER_UNIT)); }))))

pattern somehow going wild (from triggering within CCP itself?).  Thus as
third step I'll try disabling that one.
Comment 17 Markus Trippelsdorf 2015-07-09 12:20:47 UTC
Nothing helps; neither -fno-ipa-cp-alignment, nor -fno-tree-vectorize,
nor disabling the pattern above.
Comment 18 Markus Trippelsdorf 2015-07-12 09:07:41 UTC
 % gdb --args /home/trippels/gcc_build_dir_/./gcc/xgcc --version
Reading symbols from /home/trippels/gcc_build_dir_/./gcc/xgcc...done.
(gdb) run
Starting program: /home/trippels/gcc_build_dir_/gcc/xgcc --version

Program received signal SIGSEGV, Segmentation fault.
pp_format (pp=0x0, text=0x3fffffffe390) at ../../gcc/gcc/pretty-print.c:282
282       output_buffer *buffer = pp_buffer (pp);
(gdb) bt
#0  pp_format (pp=0x0, text=0x3fffffffe390) at ../../gcc/gcc/pretty-print.c:282
#1  0x000000001002f02c in diagnostic_report_diagnostic (context=0x101aa6e0 <_ZL25global_diagnostic_context.lto_priv.201>, diagnostic=0x3fffffffe390)
    at ../../gcc/gcc/diagnostic.c:915
#2  0x000000001000b768 in internal_error(char const*, ...) (gmsgid=0x10136620 "in %s, at %s:%d") at ../../gcc/gcc/diagnostic.c:1272
#3  0x000000001000b6f4 in fancy_abort(char const*, int, char const*) (file=<optimized out>, line=<optimized out>, function=<optimized out>)
    at ../../gcc/gcc/diagnostic.c:1340
#4  0x0000000010027174 in prune_options (decoded_options_count=0x3fffffffe6b0, decoded_options=0x3fffffffe6a8) at ../../gcc/gcc/opts-common.c:848
#5  decode_cmdline_options_to_array(unsigned int, char const**, unsigned int, cl_decoded_option**, unsigned int*) [clone .constprop.43] (argc=<optimized out>, 
    argv=0x3fffffffeba8, decoded_options=0x3fffffffe6a8, decoded_options_count=0x3fffffffe6b0, lang_mask=524288) at ../../gcc/gcc/opts-common.c:794
#6  0x00000000100211d0 in decode_argv (argv=0x3fffffffeba8, argc=2, this=0x3fffffffe6a0) at ../../gcc/gcc/gcc.c:7015
#7  main (argv=<optimized out>, argc=<optimized out>, this=0x3fffffffe6a0) at ../../gcc/gcc/gcc.c:6950
#8  main (argc=<optimized out>, argv=0x3fffffffeba8) at ../../gcc/gcc/gcc-main.c:45
Comment 19 Markus Trippelsdorf 2015-07-12 10:24:36 UTC
Looks like -fbranch-probabilities is causing the issue.
It it gcc.o that gets miscompiled.

The following works (adding -fno-branch-probabilities):

trippels@gcc2-power8 gcc % /home/trippels/gcc_build_dir_/./prev-gcc/xg++ -B/home/trippels/gcc_build_dir_/./prev-gcc/ -B/usr/local/powerpc64le-unknown-linux-gnu/bin/ -nostdinc++ -B/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/trippels/gcc/libstdc++-v3/libsupc++ -L/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -fno-PIE -c -DSTANDARD_STARTFILE_PREFIX=\"../../../\" -DSTANDARD_EXEC_PREFIX=\"/usr/local/lib/gcc/\" -DSTANDARD_LIBEXEC_PREFIX=\"/usr/local/libexec/gcc/\" -DDEFAULT_TARGET_VERSION=\"6.0.0\" -DDEFAULT_REAL_TARGET_MACHINE=\"powerpc64le-unknown-linux-gnu\" -DDEFAULT_TARGET_MACHINE=\"powerpc64le-unknown-linux-gnu\" -DSTANDARD_BINDIR_PREFIX=\"/usr/local/bin/\" -DTOOLDIR_BASE_PREFIX=\"../../../../\" -DACCEL_DIR_SUFFIX=\"\" -DENABLE_SHARED_LIBGCC -DCONFIGURE_SPECS="\"\"" -O3 -g -flto=jobserver -frandom-seed=1 -fprofile-use -fno-branch-probabilities -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o gcc.o -MT gcc.o -MMD -MP -MF ./.deps/gcc.TPo ../../gcc/gcc/gcc.c 

trippels@gcc2-power8 gcc % /home/trippels/gcc_build_dir_/./prev-gcc/xg++ -B/home/trippels/gcc_build_dir_/./prev-gcc/ -B/usr/local/powerpc64le-unknown-linux-gnu/bin/ -nostdinc++ -B/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/trippels/gcc/libstdc++-v3/libsupc++ -L/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/trippels/gcc_build_dir_/prev-powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -no-pie -O3 -g -flto=32 -frandom-seed=1 -fprofile-use -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc -o xgcc gcc.o gcc-main.o ggc-none.o c/gccspec.o driver-rs6000.o libcommon-target.a libcommon.a ../libcpp/libcpp.a ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
/usr/include/sys/resource.h:50:12: warning: type of ‘getrlimit’ does not match original declaration [-Wlto-type-mismatch]
 extern int getrlimit (__rlimit_resource_t __resource,
            ^
/usr/include/sys/resource.h:50:12: note: type mismatch in parameter 1
 extern int getrlimit (__rlimit_resource_t __resource,
            ^
/usr/include/sys/resource.h:42:13: note: type ‘__rlimit_resource_t’ should match type ‘__rlimit_resource_t’
 typedef int __rlimit_resource_t;
             ^
/usr/include/sys/resource.h:38:32: note: the incompatible type is defined here
 typedef enum __rlimit_resource __rlimit_resource_t;
                                ^
/usr/include/sys/resource.h:50:12: note: ‘getrlimit’ was previously declared here
 extern int getrlimit (__rlimit_resource_t __resource,
            ^
/usr/include/sys/resource.h:69:12: warning: type of ‘setrlimit’ does not match original declaration [-Wlto-type-mismatch]
 extern int setrlimit (__rlimit_resource_t __resource,
            ^
/usr/include/sys/resource.h:69:12: note: type mismatch in parameter 1
 extern int setrlimit (__rlimit_resource_t __resource,
            ^
/usr/include/sys/resource.h:42:13: note: type ‘__rlimit_resource_t’ should match type ‘__rlimit_resource_t’
 typedef int __rlimit_resource_t;
             ^
/usr/include/sys/resource.h:38:32: note: the incompatible type is defined here
 typedef enum __rlimit_resource __rlimit_resource_t;
                                ^
/usr/include/sys/resource.h:69:12: note: ‘setrlimit’ was previously declared here
 extern int setrlimit (__rlimit_resource_t __resource,
            ^

trippels@gcc2-power8 gcc % /home/trippels/gcc_build_dir_/./gcc/xgcc --version
xgcc (GCC) 6.0.0 20150712 (experimental)
Comment 20 Markus Trippelsdorf 2015-08-12 08:58:11 UTC
Cannot reproduce the issue anymore. Closing.