* [Bug other/65794] Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o'
2015-04-17 12:53 [Bug other/65794] New: Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o' gjl at gcc dot gnu.org
@ 2015-08-16 21:16 ` saper at marcincieslak dot com
2015-08-16 21:49 ` saper at marcincieslak dot com
2021-09-11 23:07 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: saper at marcincieslak dot com @ 2015-08-16 21:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65794
Marcin Cieślak <saper at marcincieslak dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |saper at marcincieslak dot com
--- Comment #1 from Marcin Cieślak <saper at marcincieslak dot com> ---
I have the same problem on solaris 2.9 using GCC:
I am using gcc 4.9.3 (compiled as a 32-bit binary) to compile gcc 4.9.3 as a
64-bit binary:
env \
BOOT_CFLAGS="-m64 -mcpu=ultrasparc3" \
BOOT_CXXFLAGS="-m64 -mcpu=ultrasparc3" \
CFLAGS="-m64 -mcpu=ultrasparc3" \
CXXFLAGS="-m64 -mcpu=ultrasparc3" \
CC=$HOME/sparcv7/bin/gcc \
CXX=$HOME/sparcv7/bin/g++ \
LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${HOME}/sparcv9/lib \
AR="/usr/ccs/bin/ar" \
RANLIB="/usr/ccs/bin/ranlib" \
AS="/usr/ccs/bin/as" \
$HOME/src/gcc-4.9.3/configure \
--prefix=$HOME/sparcv9 \
--with-gmp=$HOME/sparcv9 \
--with-mpfr=$HOME/sparcv9 \
--with-mpc=$HOME/sparcv9 \
--with-isl=$HOME/sparcv9 \
--with-cloog=$HOME/sparcv9 \
--without-gnu-as --without-gnu-ld \
--enable-languages=c,c++ --enable-obsolete \
--host=sparc64-sun-solaris2.9 \
--target=sparc64-sun-solaris2.9 \
--build=sparc-sun-solaris2.9 \
--disable-bootstrap
Failure:
make[2]: Entering directory '/home/admini/saper/build/gcc-4.9.3/gcc'
TARGET_CPU_DEFAULT="" \
HEADERS="auto-host.h ansidecl.h" DEFINES="" \
/bin/bash /home/admini/saper/src/gcc-4.9.3/gcc/mkconfig.sh config.h
TARGET_CPU_DEFAULT="TARGET_CPU_v9" \
HEADERS="options.h insn-constants.h config/sparc/default-64.h
config/sparc/biarch64.h config/vxworks-dummy.h config/sparc/sparc.h
config/dbxelf.h config/elfos.h config/sparc/sysv4.h config/sol2.h
config/sparc/sol2.h config/sol2-bi.h config/sparc/tso.h config/initfini-array.h
defaults.h" DEFINES="LIBC_GLIBC=1 LIBC_UCLIBC=2 LIBC_BIONIC=3" \
/bin/bash /home/admini/saper/src/gcc-4.9.3/gcc/mkconfig.sh tm.h
TARGET_CPU_DEFAULT="" \
HEADERS="config/sparc/sparc-protos.h config/sol2-protos.h tm-preds.h"
DEFINES="" \
/bin/bash /home/admini/saper/src/gcc-4.9.3/gcc/mkconfig.sh tm_p.h
TARGET_CPU_DEFAULT="" \
HEADERS="auto-build.h ansidecl.h" DEFINES="" \
/bin/bash /home/admini/saper/src/gcc-4.9.3/gcc/mkconfig.sh bconfig.h
make[2]: *** No rule to make target 'auto-build.h', needed by
'build/genmddeps.o'. Stop.
make[2]: Leaving directory '/home/admini/saper/build/gcc-4.9.3/gcc'
Makefile:3972: recipe for target 'all-gcc' failed
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory '/home/admini/saper/build/gcc-4.9.3'
Makefile:859: recipe for target 'all' failed
make: *** [all] Error 2
>From gcc-bugs-return-494931-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Aug 16 21:43:27 2015
Return-Path: <gcc-bugs-return-494931-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 98812 invoked by alias); 16 Aug 2015 21:43:27 -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 98784 invoked by uid 48); 16 Aug 2015 21:43:21 -0000
From: "ncm at cantrip dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset<>
Date: Sun, 16 Aug 2015 21:43:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.1.1
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ncm at cantrip dot 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: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67153-4-OmzKZRYRDy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67153-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67153-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/msg01073.txt.bz2
Content-length: 2104
https://gcc.gnu.org/bugzilla/show_bug.cgi?idg153
--- Comment #13 from ncm at cantrip dot org ---
This is essentially the entire difference between the versions of
puzzlegen-int.cc without, and with, the added "++count;" line
referenced above (modulo register assignments and branch labels)
that sidesteps the +50% pessimization:
(Asm is from "g++ -fverbose-asm -std=c++14 -O3 -Wall -S $SRC.cc" using
g++ (Debian 5.2.1-15) 5.2.1 20150808, with no instruction-set extensions
specified. Output with "-mbmi -mbmi2" has different instructions, but
they do not noticeably affect run time on Haswell i7-4770.)
@@ -793,25 +793,26 @@
.L141:
movl (%rdi), %esi # MEM[base: _244, offset: 0], word
testl %r11d, %esi # D.66634, word
jne .L138 #,
xorl %eax, %eax # tmp419
cmpl %esi, %r12d # word, seven
leaq 208(%rsp), %rcx #, tmp574
sete %al #, tmp419
movl %r12d, %edx # seven, seven
leal 1(%rax,%rax), %r8d #, D.66619
.p2align 4,,10
.p2align 3
.L140:
movl %edx, %eax # seven, D.66634
negl %eax # D.66634
andl %edx, %eax # seven, D.66622
testl %eax, %esi # D.66622, word
je .L139 #,
addl %r8d, 24(%rcx) # D.66619, MEM[base: _207, offset: 24B]
+ addl $1, %ebx #, count
.L139:
notl %eax # D.66622
subq $4, %rcx #, ivtmp.424
andl %eax, %edx # D.66622, seven
jne .L140 #,
addq $4, %rdi #, ivtmp.428
cmpq %rdi, %r10 # ivtmp.428, D.66637
jne .L141 #,
I tried a version of the program with a fixed-length loop (over
'place' in [6..0]) so that branches do not depend on results of
"rest &= ~-rest". The compiler unrolled the loop, but the program
ran at pessimized speed with or without the "++count" line.
I am very curious whether this has been reproduced on others' Haswells,
and on Ivybridge and Skylake.
^ permalink raw reply [flat|nested] 4+ messages in thread* [Bug other/65794] Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o'
2015-04-17 12:53 [Bug other/65794] New: Building crossback fails: No rule to make target `auto-build.h', needed by `build/genmddeps.o' gjl at gcc dot gnu.org
2015-08-16 21:16 ` [Bug other/65794] " saper at marcincieslak dot com
@ 2015-08-16 21:49 ` saper at marcincieslak dot com
2021-09-11 23:07 ` pinskia at gcc dot gnu.org
2 siblings, 0 replies; 4+ messages in thread
From: saper at marcincieslak dot com @ 2015-08-16 21:49 UTC (permalink / raw)
To: gcc-bugs
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 12310 bytes --]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65794
--- Comment #2 from Marcin Cieślak <saper at marcincieslak dot com> ---
Created attachment 36191
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36191&action=edit
Patch to Makefile to proceed with the build
The attached patch allowed me to continue the build. Probably this patch is not
the correct fix though.
It can be applied to Makefile.in prior to the configure stage. It looks like
"config.status" has no special knowledge of the "auto-build.h" header.
(Basically in my case the generated files - auto-host.h and auto-build.h were
identical, except for the comment in line 1)
>From gcc-bugs-return-494933-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Aug 16 22:12:14 2015
Return-Path: <gcc-bugs-return-494933-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 120206 invoked by alias); 16 Aug 2015 22:12:14 -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 120176 invoked by uid 48); 16 Aug 2015 22:12:11 -0000
From: "chengniansun at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/67243] New: Wrong Message of -Wvla for Standard ISO C90 However Emitted with -stdÁ1
Date: Sun, 16 Aug 2015 22:12:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: chengniansun 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-67243-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/msg01075.txt.bz2
Content-length: 1684
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67243
Bug ID: 67243
Summary: Wrong Message of -Wvla for Standard ISO C90 However
Emitted with -std=c11
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: chengniansun at gmail dot com
Target Milestone: ---
When I compile the code "int array[4.3];", in addition to the error, GCC also
emits a -Wvla warning saying that ISO C90 forbids this. However, I specify
-std=c11 in the command line, and IMHO this is at least an inconsistency
between errors and error messages.
$: cat t.c
int array[4.3];
$: gcc-trunk -c -Wvla -std=c11 -pedantic t.c
t.c:1:5: error: size of array ‘array’ has non-integer type
int array[4.3];
^
t.c:1:1: warning: variably modified ‘array’ at file scope
int array[4.3];
^
t.c:1:1: warning: ISO C90 forbids array ‘array’ whose size can’t be evaluated
[-Wvla]
$: gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto --disable-werror
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 6.0.0 20150815 (experimental) [trunk revision 226911] (GCC)
$:
>From gcc-bugs-return-494934-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Aug 16 22:30:25 2015
Return-Path: <gcc-bugs-return-494934-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 128233 invoked by alias); 16 Aug 2015 22:30:25 -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 128197 invoked by uid 48); 16 Aug 2015 22:30:22 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -stdÁ1
Date: Sun, 16 Aug 2015 22:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
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: bug_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-67243-4-THL74uxCKV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67243-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67243-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/msg01076.txt.bz2
Content-length: 1379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67243
Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-08-16
CC| |manu at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
It is also useless to give such warning after such error.
I'm afraid the way GCC reports most extensions is very fragile in this way. It
doesn't affect only Wvla. It would be nice to discuss/design/agree on a
canonical and future-proof way to report:
* Pure GNU extensions, not accepted by any standard.
* Features accepted by some standard but that are extensions for other
standards (like C++ style comments).
The latter requires some future-proof way of reporting:
* Extensions that are forbidden up to a particular standard.
* Extensions that were accepted but are forbidden now (not sure if there is
such case at all).
(It is kind of ironic that Clang is fair more clear pointing out when something
is a "GNU extension". In some way, Clang is doing more promotion of GNU than
GCC!)
>From gcc-bugs-return-494935-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Aug 16 22:36:44 2015
Return-Path: <gcc-bugs-return-494935-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8741 invoked by alias); 16 Aug 2015 22:36:44 -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 8710 invoked by uid 48); 16 Aug 2015 22:36:40 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/67243] Wrong Message of -Wvla for Standard ISO C90 However Emitted with -stdÁ1
Date: Sun, 16 Aug 2015 22:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
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-67243-4-Rf9QfyFw8y@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67243-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67243-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/msg01077.txt.bz2
Content-length: 447
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67243
--- Comment #2 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Moreover, since VLAs are not an extension in C99, the text of Wvla is wrong
always for -std=c99.
void square(int num) {
int array[num];
}
With -std=c99 -Wpedantic there is no warning.
With -std=c99 -Wvla, it mentions ISO C90, which is irrelevant.
Clang just says: "variable length array used"
>From gcc-bugs-return-494936-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Aug 16 23:25:10 2015
Return-Path: <gcc-bugs-return-494936-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 48403 invoked by alias); 16 Aug 2015 23:25: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 48373 invoked by uid 48); 16 Aug 2015 23:25:05 -0000
From: "ncm at cantrip dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/67153] [5/6 Regression] integer optimizations 53% slower than std::bitset<>
Date: Sun, 16 Aug 2015 23:25:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.1.1
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ncm at cantrip dot 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: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-67153-4-WHyEPFcRE1@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-67153-4@http.gcc.gnu.org/bugzilla/>
References: <bug-67153-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/msg01078.txt.bz2
Content-length: 848
https://gcc.gnu.org/bugzilla/show_bug.cgi?idg153
--- Comment #14 from ncm at cantrip dot org ---
A notable difference between g++-4.9 output and g++-5 output is that,
while both hoist the "(word == seven)" comparison out of the innermost
loop, gcc-4.9 splits inner loop into two versions, one that increments
scores by 3 and another that increments by 1, where g++-5 saves 3 or 1
into a register and uses the same inner loop for both cases.
Rewriting the critical loop
- to run with separate inner loops
- does not slow down the fast g++-4.9-compiled program, but
- fails to speed up the slow g++-5-compiled program.
- to precompute a 1 or 3 increment, with one inner loop for both cases
- does slow down the previously fast g++-4.9-compiled program, and
- does not change the speed of the slow g++-5-compiled program
^ permalink raw reply [flat|nested] 4+ messages in thread