[Bug other/67092] New: bootstrap failure with CFLAGS/CXXFLAGS/BOOT_CFLAGS="-O0 -g" in running genpreds

[Bug other/67092] New: bootstrap failure with CFLAGS/CXXFLAGS/BOOT_CFLAGS="-O0 -g" in running genpreds

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

            Bug ID: 67092
           Summary: bootstrap failure with
                    CFLAGS/CXXFLAGS/BOOT_CFLAGS="-O0 -g" in running
                    genpreds
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

While doing a bootstrap with CFLAGS/CXXFLAGS/BOOT_CFLAGS="-O0 -g", I run into
the following problem in stage2:
...
build/genpreds: /usr/local/tools/gcc-4.7.3/lib64/libstdc++.so.6: version
`GLIBCXX_3.4.21' not found (required by build/genpreds)
build/genpreds: /usr/local/tools/gcc-4.7.3/lib64/libstdc++.so.6: version
`CXXABI_1.3.9' not found (required by build/genpreds)
make[3]: *** [s-constrs-h] Error 1
...

While building stage2 genpreds, we link in the stage1 libstdc++ libs:
...
obj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/./prev-gcc/xg++
-Bobj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/./prev-gcc/
-Binstall/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-Bobj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-Bobj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-Iobj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-Iobj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
 -Isrc/gcc-mainline/libstdc++-v3/libsupc++
-Lobj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-Lobj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O0 -gtoggle -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 -Werror -fno-common
 -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE  -no-pie -o build/genpreds
build/genpreds.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o
build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/hash-table.o
build/read-md.o build/errors.o .././libiberty/libiberty.a
...

But while running genpreds, we use the libstdc++ from the system, or in this
case the one found in LD_LIBRARY_PATH, which doesn't provide the version that
was linked against, and genpreds fails to load.

[Bug other/67092] bootstrap failure with CFLAGS/CXXFLAGS/BOOT_CFLAGS="-O0 -g" in running genpreds

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 36106
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36106&action=edit
tentative patch

This tentative patch:
- adds -Wl,-rpath settings to make sure genpreds can find the libstdc++ it
  linked against
- runs stage2+ genpreds with empty LD_LIBRARY_PATH, to ensure that the rpath
  is not overridden.

That allows the build to progress beyond failure point.

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|bootstrap failure with      |bootstrap failure in
                   |CFLAGS/CXXFLAGS/BOOT_CFLAGS |running genpreds, libstdc++
                   |="-O0 -g" in running        |version mismatch
                   |genpreds                    |

--- Comment #2 from vries at gcc dot gnu.org ---
Also ran into it now without setting CFLAGS.

This failure is with ld 2.23.51:
...
$ ld -v
GNU ld (GNU Binutils) 2.23.51.20120829
...

With a different set of build scripts, another linker is used:
...
$ /usr/bin/ld -v
GNU ld (GNU Binutils for Ubuntu) 2.20.1-system.20100303
...
and I don't run into this problem.

I once case we end up needed libstdc++ for genpreds, in the other case, not.

In the case we end up needing it, we need these symbols:
...
$ objdump -d -a -x
obj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-gcc/build/genpreds
| grep GLIBCXX | c++filt 
    0x08922974 0x00 03 GLIBCXX_3.4
0000000000000000       F *UND*  0000000000000000             
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::c_str()
const@@GLIBCXX_3.4
0000000000000000       F *UND*  0000000000000000              operator
delete(void*)@@GLIBCXX_3.4
0000000000000000       F *UND*  0000000000000000             
std::basic_string<char, std::char_traits<char>, std::allocator<char>
>::basic_string(unsigned long, char, std::allocator<char> const&)@@GLIBCXX_3.4
0000000000000000       F *UND*  0000000000000000             
std::basic_string<char, std::char_traits<char>, std::allocator<char>
>::~basic_string()@@GLIBCXX_3.4
0000000000000000       F *UND*  0000000000000000             
std::allocator<char>::~allocator()@@GLIBCXX_3.4
0000000000000000       F *UND*  0000000000000000             
std::allocator<char>::allocator()@@GLIBCXX_3.4
0000000000000000       F *UND*  0000000000000000              operator
new(unsigned long)@@GLIBCXX_3.4
...

AFAICT, there are no uses of these symbols.

I think that by inserting some c++ code in genpreds.c, we should be able to
trigger this reliably, independent of ld version.

Updating summary.

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-08-02
     Ever confirmed|0                           |1

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> ---
Only build/genpreds in stage1 should be linked with libstdc++.so.6.
Why are build/genpreds in stage2 and stage2 linked with libstdc++.so.6?

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

--- Comment #4 from vries at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #3)
> Only build/genpreds in stage1 should be linked with libstdc++.so.6.

Why?

> Why are build/genpreds in stage2 and stage2 linked with libstdc++.so.6?

AFAICT, the -L bits here in src/Makefile.in:
...
POSTSTAGE1_CXX_EXPORT = \
        CXX='$(CXX)'; export CXX; \
        CXX_FOR_BUILD='$(CXX_FOR_BUILD)'; export CXX_FOR_BUILD;
@if target-libstdc++-v3-bootstrap
# Override the above if we're bootstrapping C++.
POSTSTAGE1_CXX_EXPORT = \
        CXX="$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/prev-gcc/xg++$(exeext) \
          -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ -nostdinc++ \
          -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \
          -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs \
          `if $(LEAN); then echo ' -isystem '; else echo ' -I';
fi`$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \
          `if $(LEAN); then echo ' -isystem '; else echo ' -I';
fi`$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \
          `if $(LEAN); then echo ' -isystem '; else echo ' -I';
fi`$$s/libstdc++-v3/libsupc++ \
          -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \
          -L$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs"; \
          export CXX; \
        CXX_FOR_BUILD="$$CXX"; export CXX_FOR_BUILD;
@endif target-libstdc++-v3-bootstrap
...

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to vries from comment #4)
> (In reply to H.J. Lu from comment #3)
> > Only build/genpreds in stage1 should be linked with libstdc++.so.6.
> 
> Why?

Top level configure.ac has

[stage1_ldflags=
 # In stage 1, default to linking libstdc++ and libgcc statically with GCC
 # if supported.  But if the user explicitly specified the libraries to use,
 # trust that they are doing what they want.
 if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then
   stage1_ldflags="-static-libstdc++ -static-libgcc"
 fi])
AC_SUBST(stage1_ldflags)

Why doesn't it work for you?

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #5)
> (In reply to vries from comment #4)
> > (In reply to H.J. Lu from comment #3)
> > > Only build/genpreds in stage1 should be linked with libstdc++.so.6.
> > 
> > Why?
> 
> Top level configure.ac has
> 
> [stage1_ldflags=
>  # In stage 1, default to linking libstdc++ and libgcc statically with GCC
>  # if supported.  But if the user explicitly specified the libraries to use,
>  # trust that they are doing what they want.
>  if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then
>    stage1_ldflags="-static-libstdc++ -static-libgcc"
>  fi])
> AC_SUBST(stage1_ldflags)
> 
> Why doesn't it work for you?

AFAIU, this question has the premise that something is going wrong in stage1,
which is not the case in this PR, it's about stage2. So I'm not sure how to
answer this question.

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

--- Comment #7 from vries at gcc dot gnu.org ---
(In reply to vries from comment #6)
> (In reply to H.J. Lu from comment #5)
> > (In reply to vries from comment #4)
> > > (In reply to H.J. Lu from comment #3)
> > > > Only build/genpreds in stage1 should be linked with libstdc++.so.6.
> > > 
> > > Why?
> > 
> > Top level configure.ac has
> > 
> > [stage1_ldflags=
> >  # In stage 1, default to linking libstdc++ and libgcc statically with GCC
> >  # if supported.  But if the user explicitly specified the libraries to use,
> >  # trust that they are doing what they want.
> >  if test "$stage1_libs" = "" -a "$have_static_libs" = yes; then
> >    stage1_ldflags="-static-libstdc++ -static-libgcc"
> >  fi])
> > AC_SUBST(stage1_ldflags)
> > 
> > Why doesn't it work for you?
> 
> AFAIU, this question has the premise that something is going wrong in
> stage1, which is not the case in this PR, it's about stage2. So I'm not sure
> how to answer this question.

OK, I think I got your point (the posted code was stage1 related, but there is
similar code for poststage1). The question is why we're linking with dynamic
instead of static libstdc++ in stage2.

I start to suspect it's related to this configure bit:
...
--with-host-libstdcxx=-L/usr/local/tools/gcc-4.7.3/lib64 -static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm
...

This causes poststage1_libs to be set, which causes poststage1_ldflags to be
empty, rather than the default "-static-libstdc++ -static-libgcc".

So, on one hand, in the build/genpreds link line, we do not use
poststage1_libs. OTOH, we do use poststage1_ldflags, but that's empty now.

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

--- Comment #8 from vries at gcc dot gnu.org ---
(In reply to vries from comment #7)
> I start to suspect it's related to this configure bit:
> ...
> --with-host-libstdcxx=-L/usr/local/tools/gcc-4.7.3/lib64 -static-libgcc
> -Wl,-Bstatic,-lstdc++,-Bdynamic -lm
> ...
> 

full configure:
...
Using built-in specs.
COLLECT_GCC=./obj/gcc-mainline-0-x86_64-unknown-linux-gnu-x86_64-unknown-linux-gnu/prev-gcc/xgcc
Target: x86_64-unknown-linux-gnu
Configured with: src/gcc-mainline/configure --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
--enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch
--disable-multilib --with-gnu-as --with-gnu-ld --enable-languages=c,c++
--enable-shared --enable-lto --disable-nls --prefix=install
--with-gmp=obj/pkg-mainline-0-x86_64-unknown-linux-gnu/fsf-mainline-0-x86_64-unknown-linux-gnu.extras/host-libs-x86_64-unknown-linux-gnu/usr
--with-mpfr=obj/pkg-mainline-0-x86_64-unknown-linux-gnu/fsf-mainline-0-x86_64-unknown-linux-gnu.extras/host-libs-x86_64-unknown-linux-gnu/usr
--with-mpc=obj/pkg-mainline-0-x86_64-unknown-linux-gnu/fsf-mainline-0-x86_64-unknown-linux-gnu.extras/host-libs-x86_64-unknown-linux-gnu/usr
--with-host-libstdcxx='-L/usr/local/tools/gcc-4.7.3/lib64 -static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-isl=obj/pkg-mainline-0-x86_64-unknown-linux-gnu/fsf-mainline-0-x86_64-unknown-linux-gnu.extras/host-libs-x86_64-unknown-linux-gnu/usr
--enable-libgomp --enable-libitm --enable-libatomic --disable-libssp
--with-build-time-tools=install/x86_64-unknown-linux-gnu/bin
--with-build-time-tools=install/x86_64-unknown-linux-gnu/bin SED=sed
Thread model: posix
gcc version 6.0.0 20150801 (experimental) (GCC) 
...

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

--- Comment #10 from vries at gcc dot gnu.org ---
Looking at the description of with-host-libstdcxx:
...
--with-host-libstdcxx=linker-args
If you are linking with a static copy of PPL, you can use this option to
specify how the linker should find the standard C++ library used internally by
PPL. Typical values of linker-args might be ‘-lstdc++’ or
‘-Wl,-Bstatic,-lstdc++,-Bdynamic -lm’. If you are linking with a shared copy of
PPL, you probably do not need this option; shared library dependencies will
cause the linker to search for the standard C++ library automatically. 
...

We no longer support building with PPL (
https://gcc.gnu.org/ml/gcc-patches/2012-06/msg01773.html ), so this doc item
probably needs to be updated.
>From gcc-bugs-return-493914-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Aug 03 08:10:33 2015
Return-Path: <gcc-bugs-return-493914-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7296 invoked by alias); 3 Aug 2015 08:10:33 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7248 invoked by uid 48); 3 Aug 2015 08:10:29 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch
Date: Mon, 03 Aug 2015 08:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: WAITING
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67092-4-FXyTspdHuV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67092-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67092-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg00056.txt.bz2
Content-length: 1051

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

--- Comment #11 from vries at gcc dot gnu.org ---
(In reply to vries from comment #10)
> Looking at the description of with-host-libstdcxx:
> ...
> --with-host-libstdcxx=linker-args
> If you are linking with a static copy of PPL, you can use this option to
> specify how the linker should find the standard C++ library used internally
> by PPL. Typical values of linker-args might be ‘-lstdc++’ or
> ‘-Wl,-Bstatic,-lstdc++,-Bdynamic -lm’. If you are linking with a shared copy
> of PPL, you probably do not need this option; shared library dependencies
> will cause the linker to search for the standard C++ library automatically. 
> ...
> 
> We no longer support building with PPL (
> https://gcc.gnu.org/ml/gcc-patches/2012-06/msg01773.html ), so this doc item
> probably needs to be updated.

--with-host-libstdcxx=linker-args
Sets default value for --with-stage1-libs and --with-boot-libs. Sets default
value for --with-boot-ldflags to empty.
>From gcc-bugs-return-493915-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Aug 03 08:21:16 2015
Return-Path: <gcc-bugs-return-493915-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 38234 invoked by alias); 3 Aug 2015 08:21:16 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 38175 invoked by uid 48); 3 Aug 2015 08:21:12 -0000
From: "ubizjak at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/67089] [4.8/4.9/5/6 Regression] Integer overflow checks not optimized on x86/x86_64
Date: Mon, 03 Aug 2015 08:21:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.2.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: ubizjak at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67089-4-EYDMs7C7cT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67089-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67089-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg00057.txt.bz2
Content-length: 3016

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67089

--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
(In reply to Mike from comment #0)
> Starting from 4.8.3, gcc does not optimize integer overflow and underflow
> checks inserting a redundant cmp instruction in both 32-bit and 64-bit
> modes. Having git-bisected the revisions, I found out r204088 (by pr58779)
> had added such behavior.

It was removed for a reason, as explained in the referred PR.

> ------------ gcc-4.8.3 -O1 ------------
> sub(unsigned int, unsigned int):
>     movl    %edi, %eax
>     subl    %esi, %eax
>     cmpl    %eax, %edi  /* absolutely redundant */
>     jnb .L4
>     subq    $8, %rsp
>     call    underflow()
> .L4:
>     rep ret
> ---------------------------------------

The sequence is actually:

(insn 7 4 8 2 (parallel [
            (set (reg/v:SI 87 [ r ])
                (minus:SI (reg/v:SI 89 [ a ])
                    (reg/v:SI 90 [ b ])))
            (clobber (reg:CC 17 flags))
        ]) pr67089.c:4 259 {*subsi_1}
     (expr_list:REG_DEAD (reg/v:SI 90 [ b ])
        (expr_list:REG_UNUSED (reg:CC 17 flags)
            (nil))))
(insn 8 7 9 2 (set (reg:CC 17 flags)
        (compare:CC (reg/v:SI 89 [ a ])
            (reg/v:SI 87 [ r ]))) pr67089.c:5 7 {*cmpsi_1}
     (expr_list:REG_DEAD (reg/v:SI 89 [ a ])
        (nil)))
(jump_insn 9 8 10 2 (set (pc)
        (if_then_else (geu (reg:CC 17 flags)
                (const_int 0 [0]))
            (label_ref 13)
            (pc))) pr67089.c:5 609 {*jcc_1}
     (expr_list:REG_DEAD (reg:CC 17 flags)
        (int_list:REG_BR_PROB 9996 (nil)))
 -> 13)

and combine tries to simplify this sequence with:

Trying 7 -> 8:
Failed to match this instruction:
(parallel [
        (set (reg:CC 17 flags)
            (compare:CC (minus:SI (reg/v:SI 89 [ a ])
                    (reg/v:SI 90 [ b ]))
                (reg/v:SI 89 [ a ])))
        (set (reg/v:SI 87 [ r ])
            (minus:SI (reg/v:SI 89 [ a ])
                (reg/v:SI 90 [ b ])))
    ])

and further to:

Trying 7, 8 -> 9:
Failed to match this instruction:
(parallel [
        (set (pc)
            (if_then_else (leu (minus:SI (reg/v:SI 89 [ a ])
                        (reg/v:SI 90 [ b ]))
                    (reg/v:SI 89 [ a ]))
                (label_ref 13)
                (pc)))
        (set (reg/v:SI 87 [ r ])
            (minus:SI (reg/v:SI 89 [ a ])
                (reg/v:SI 90 [ b ])))
    ])

LEU condition was created from GEU as the operands in (insn 8) were swapped. As
can be seen from config/i386.c, ix86_cc_mode, LEU can't be implemented using
only Carry flag:

    case GTU:                   /* CF=0 & ZF=0 */
    case LEU:                   /* CF=1 | ZF=1 */
      return CCmode;

The removed code compensated this with *reversion* of the flag check, e.g. the
same condition was emitted for LEU with CCCmode as for GEU (and in a similar
for GTU in CCCmode vs. LTU, as was the case in PR58779).

We shouldn't do this, and it reflected in PR58779.
>From gcc-bugs-return-493916-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Aug 03 08:36:43 2015
Return-Path: <gcc-bugs-return-493916-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 118545 invoked by alias); 3 Aug 2015 08:36:42 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 118493 invoked by uid 48); 3 Aug 2015 08:36:37 -0000
From: "glaubitz at physik dot fu-berlin.de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs
Date: Mon, 03 Aug 2015 08:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glaubitz at physik dot fu-berlin.de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67002-4-B1ELpFgOXX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67002-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67002-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg00058.txt.bz2
Content-length: 1910

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg002

--- Comment #12 from John Paul Adrian Glaubitz <glaubitz at physik dot fu-berlin.de> ---
Update:

Michael Karcher, who previously helped smashing some bugs in gcc for the SH
target, had a go at this and he discovered that the difference between stage2
and stage3 is the -gtoggle switch. And, indeed, triggering this switch is
responsible for the diff:

root@tirpitz:/home/mkarcher> diff -u s2/real-stage2.o s3/real-stage3.o
root@tirpitz:/home/mkarcher> diff -u s2/real-stage2.o s3-notoggle/real-stage3.o
Binary files s2/real-stage2.o and s3-notoggle/real-stage3.o differ
root@tirpitz:/home/mkarcher>

He generated a lot of debug output during build with "-fdump-tree-all" and
"-da":

gccroot=/home/glaubitz/gcc-5-test_5.2.1-12/gcc-5-5.2.1
gccbuild=$gccroot/build
$gccbuild/stage1-gcc/xg++ \
  -B$gccbuild/stage1-gcc/ \
  -B/usr/sh4-linux-gnu/bin/ -nostdinc++ \
  -B$gccbuild/stage1-sh4-linux-gnu/libstdc++-v3/src/.libs \
  -B$gccbuild/stage1-sh4-linux-gnu/libstdc++-v3/libsupc++/.libs  \
  -I$gccbuild/stage1-sh4-linux-gnu/libstdc++-v3/include/sh4-linux-gnu \
  -I$gccbuild/stage1-sh4-linux-gnu/libstdc++-v3/include \
  -I$gccroot/src/libstdc++-v3/libsupc++ \
  -c -g -O2 -gtoggle -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$gccbuild/stage2-gcc -I$gccroot/src/gcc -I$gccroot/src/include
-I$gccroot/src/libcpp/include  \
  -I$gccroot/src/libdecnumber -I$gccroot/src/libdecnumber/dpd
-I$gccbuild/libdecnumber \
  -I$gccroot/src/libbacktrace \
  -da -fdump-tree-all \
  -o real-stage2.o $gccroot/src/gcc/real.c

I'm collecting all the dumped output now and will upload. I will follow up with
a download link quickly.

Adrian

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

--- Comment #12 from vries at gcc dot gnu.org ---
(In reply to vries from comment #11)
> (In reply to vries from comment #10)
> > Looking at the description of with-host-libstdcxx:
> > ...
> > --with-host-libstdcxx=linker-args
> > If you are linking with a static copy of PPL, you can use this option to
> > specify how the linker should find the standard C++ library used internally
> > by PPL. Typical values of linker-args might be ‘-lstdc++’ or
> > ‘-Wl,-Bstatic,-lstdc++,-Bdynamic -lm’. If you are linking with a shared copy
> > of PPL, you probably do not need this option; shared library dependencies
> > will cause the linker to search for the standard C++ library automatically. 
> > ...
> > 
> > We no longer support building with PPL (
> > https://gcc.gnu.org/ml/gcc-patches/2012-06/msg01773.html ), so this doc item
> > probably needs to be updated.
> 
> --with-host-libstdcxx=linker-args
> Sets default value for --with-stage1-libs and --with-boot-libs. Sets default
> value for --with-boot-ldflags to empty.

Filed seperate PR67099 - Documentation --with-host-libstdcxx is outdated,
mentions ppl .
>From gcc-bugs-return-493926-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Aug 03 10:20:10 2015
Return-Path: <gcc-bugs-return-493926-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 74264 invoked by alias); 3 Aug 2015 10:20:09 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 74240 invoked by uid 48); 3 Aug 2015 10:20:06 -0000
From: "vries at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug other/67099] Documentation --with-host-libstdcxx is outdated, mentions ppl
Date: Mon, 03 Aug 2015 10:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: other
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: documentation
X-Bugzilla-Severity: trivial
X-Bugzilla-Who: vries at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67099-4-UzGLvUGPo7@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67099-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67099-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-08/txt/msg00068.txt.bz2
Content-length: 418

https://gcc.gnu.org/bugzilla/show_bug.cgi?idg099

--- Comment #1 from vries at gcc dot gnu.org ---
And given PR67098 - Documentation --with-stage1-ldflags does not mention
default -static-libstdc++ -static-libgcc, even better is:
...
--with-host-libstdcxx=linker-args
Sets default value for --with-stage1-libs and --with-boot-libs. Sets default
value for --with-stage1-ldflags and --with-boot-ldflags to empty.
...

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
I think we can no longer reliably support host libstdc++ as includes are not
picked up from its location and GCC is C++ now.

I suggest to remove that entirely.

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

--- Comment #14 from vries at gcc dot gnu.org ---
https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00603.html

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

--- Comment #15 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed Aug 12 15:13:35 2015
New Revision: 226819

URL: https://gcc.gnu.org/viewcvs?rev=226819&root=gcc&view=rev
Log:
Remove --with-host-libstdcxx

2015-08-12  Tom de Vries  <tom@codesourcery.com>

        PR other/67092
        PR other/67098
        * configure.ac: Remove --with_host_libstdcxx support.
        * configure: Regenerate.

        * doc/install.texi: Remove --with_host_libstdcxx item.  Update
        --with-stage1-libs, --with-boot-ldflags and --with-boot-libs items
        accordingly.  Mention default for --with-stage1-ldflags.

Modified:
    trunk/ChangeLog
    trunk/configure
    trunk/configure.ac
    trunk/gcc/ChangeLog
    trunk/gcc/doc/install.texi

[Bug other/67092] bootstrap failure in running genpreds, libstdc++ version mismatch

[vries at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67092

vries at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|---                         |FIXED

--- Comment #16 from vries at gcc dot gnu.org ---
Committed patch that removes configure option --with-host-libstdcxx. Marking
resolved-fixed.