[Bug middle-end/36359] missed optimization in some cases with PRE VRP and other passes combined together
--- Comment #21 from bunk at stusta dot de 2009-01-25 22:00 --- (In reply to comment #20) > The testcase from #17 does not reproduce the issue for me with recent GCC 4.3. This bug is a regression in gcc 4.4, it was AFAIK never present in gcc 4.3. Haven't tried more recent gcc versions, but I'm still seeing it with the 20090107-1 gcc-snapshot package (that is the SVN trunk). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug middle-end/36359] missed optimization in some cases with PRE VRP and other passes combined together
--- Comment #22 from bunk at stusta dot de 2009-01-25 22:05 --- Check my comments #10 and #11 and the definition of ilog2() in http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/log2.h;h=25b808631cd92c50d10cf6a31b2d9b9942b62ac9;hb=bce7f793daec3e65ec5c5705d2457b81fe7b5725 and you'll understand why I said 8 months ago "gcc has a bug regarding __builtin_constant_p()". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug middle-end/36359] missed optimization in some cases with PRE VRP and other passes combined together
--- Comment #24 from bunk at stusta dot de 2009-01-26 00:49 --- (In reply to comment #23) > It doesn't reproduce for me with 4.4 either. Maybe this is a dup of PR38789? Seems so: I've confirmed that the 4.4-20090109 snapshot is broken, and the 4.4-20090123 snapshot is fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug testsuite/25605] New: 5 testsuite failures: gcc.dg/cleanup-*, gcc.dg/vect/pr20122.c
I'm getting the following testsuite failures on a Debian unstable in both 4.0.2
and a today's checkout from the 4.1 branch:
<-- snip -->
...
Running /TMP/test/gcc/gcc/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/cleanup-10.c execution test
FAIL: gcc.dg/cleanup-11.c execution test
FAIL: gcc.dg/cleanup-8.c execution test
FAIL: gcc.dg/cleanup-9.c execution test
Running /TMP/test/gcc/gcc/gcc/testsuite/gcc.dg/format/format.exp ...
...
Running /TMP/test/gcc/gcc/gcc/testsuite/gcc.dg/vect/vect.exp ...
FAIL: gcc.dg/vect/pr20122.c scan-tree-dump-times vectorized 1 loops 2
Running /TMP/test/gcc/gcc/gcc/testsuite/gcc.dg/vmx/vmx.exp ...
...
<-- snip -->
--
Summary: 5 testsuite failures: gcc.dg/cleanup-*,
gcc.dg/vect/pr20122.c
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25605
[Bug testsuite/25606] New: XPASS'es in the 4.1 branch
I'm getting the following XPASS'es with a current checkout from the 4.1 branch:
<-- snip -->
...
Running /TMP/test/gcc/gcc/gcc/testsuite/gcc.dg/cpp/cpp.exp ...
XPASS: gcc.dg/cpp/cmdlne-dI-M.c scan-file
(^|\\n)cmdlne-dI-M.*:[^\\n]*cmdlne-dI-M.c
XPASS: gcc.dg/cpp/cmdlne-dM-M.c scan-file
(^|\\n)cmdlne-dM-M[^\\n]*:[^\\n]*cmdlne-dM-M.c
Running /TMP/test/gcc/gcc/gcc/testsuite/gcc.dg/cpp/trad/trad.exp ...
...
Running /TMP/test/gcc/gcc/gcc/testsuite/g++.dg/dg.exp ...
XPASS: g++.dg/tree-ssa/pr14814.C scan-tree-dump-times &this 0
Running /TMP/test/gcc/gcc/gcc/testsuite/g++.dg/gcov/gcov.exp ...
...
Running /TMP/test/gcc/gcc/libstdc++-v3/testsuite/libstdc++-dg/normal.exp ...
XPASS: 26_numerics/cmath/c99_classification_macros_c.cc (test for excess
errors)
...
<-- snip -->
--
Summary: XPASS'es in the 4.1 branch
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25606
[Bug testsuite/25605] 5 testsuite failures: gcc.dg/cleanup-*, gcc.dg/vect/pr20122.c
--- Comment #3 from bunk at stusta dot de 2005-12-30 22:04 --- (In reply to comment #2) > Also other people don't get the (In reply to comment #1) Looking through the test results posted for 4.0 and 4.1 to http://lists.debian.org/debian-gcc/ (which are a superset of the one's I'm seeing, but Debian isn't using unmodified gcc sources and compiling for i486), it seems I'm not the only one getting them on Debian unstable. References: http://lists.debian.org/debian-gcc/2005/12/msg00077.html http://lists.debian.org/debian-gcc/2005/12/msg00223.html > > Also I doubt that "gcc.dg/vect/pr20122.c" is an important failure. > > Oh, it is only on 4.0.x that failure is: > > http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg01578.html ??? This test result doesn't show a FAIL of gcc.dg/vect/pr20122.c. And as I said in my bug report, I'm seeing all of these 5 FAIL's in _both_ 4.0.2 and the 4.1 branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25605
[Bug testsuite/25605] 5 testsuite failures: gcc.dg/cleanup-*, gcc.dg/vect/pr20122.c
--- Comment #5 from bunk at stusta dot de 2005-12-30 22:17 --- (In reply to comment #4) > Don't report debian bugs to the FSF GCC, report them to first. Please READ bug reports before closing them. As I said in comment #3, I DO USE UNMODIFIED GCC 4.0.2 SOURCES FROM ftp.gnu.org AND AN UNMODIFIED SNAPSHOT FROM THE 4.1 BRANCH IN YOUR SVN. No there's no problem with my Caps Lock key, but it seems less bold statements didn't work. -- bunk at stusta dot de changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25605
[Bug testsuite/25605] 5 testsuite failures: gcc.dg/cleanup-*, gcc.dg/vect/pr20122.c
--- Comment #7 from bunk at stusta dot de 2005-12-30 22:34 --- (In reply to comment #6) > Only gcc.dg/vect/pr20122.c is a semi real bug and it is just a testsuite bug > and I don't see it on the 4.1 branch at all: > http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg01577.html > http://gcc.gnu.org/ml/gcc-testresults/2005-12/msg01568.html > > Only on the 4.0.3 branch. Whatever influences it, I do see it on the 4.1 branch, too. > So this is another won't fix bug. I was under the naive impression that the gcc testsuite shouldn't contain any failures. But I've now learned my lesson that this was wrong, and running the testsuite as a user doesn't make any sense. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25605
[Bug bootstrap/28949] New: [4.2 regression] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES.
I did:
../configure --target=arm-linux --prefix=/usr/local/DIR/gcc-arm- svn20060904
--enable-languages=c --with-as=/usr/local/bin/arm-linux-as
--with-ld=/usr/local/bin/arm-linux-ld --without-headers --disable-shared
--disable-multilib --enable-threads=single --disable-nls --disable-libmudflap
--disable-libssp
make
error message:
<-- snip -->
...
checking for pid_t... no
checking for library containing strerror... configure: error: Link tests are
not
allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-target-libiberty] Error 1
make[1]: Leaving directory `/TMP/svn/gcc/build-arm'
make: *** [all] Error 2
<-- snip -->
The error is not specific for the arm target, I'm also getting it for several
other targets.
--
Summary: [4.2 regression] configure-target-libiberty: Link tests
are not
allowed after GCC_NO_EXECUTABLES.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-linux-gnu (and several others)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
[Bug bootstrap/28949] [4.2 regression] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES.
--- Comment #1 from bunk at stusta dot de 2006-09-04 15:34 --- Created an attachment (id=12185) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12185&action=view) configure log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
[Bug bootstrap/28949] [4.2 regression] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES.
--- Comment #2 from bunk at stusta dot de 2006-09-04 15:34 --- Created an attachment (id=12186) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12186&action=view) make log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
[Bug bootstrap/28949] [4.2 regression] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #4 from bunk at stusta dot de 2006-09-04 16:27 --- Created an attachment (id=12187) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12187&action=view) arm-linux/libiberty/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
[Bug bootstrap/28949] [4.2 regression] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #5 from bunk at stusta dot de 2006-09-04 16:46 --- I can reproduce it trying to build a cross compiler for a powerpc64-linux- target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
[Bug bootstrap/28962] New: [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails
cd /TMP/build-gcc-svn20060906-powerpc64
/TMP/gcc-svn20060906/configure --target=powerpc64-linux
--prefix=/usr/local/DIR/gcc-powerpc64-svn20060906 --enable-languages=c
--with-as=/usr/local/bin/powerpc64-linux-as
--with-ld=/usr/local/bin/powerpc64-linux-ld --disable-shared
--enable-threads=single --disable-multilib
make
results in:
<-- snip -->
...
make[2]: Leaving directory `/TMP/build-gcc-svn20060906-powerpc64/gcc'
Checking multilib configuration for libmudflap...
mkdir -p -- powerpc64-linux/libmudflap
Configuring in powerpc64-linux/libmudflap
configure: creating cache ./config.cache
checking build system type... i686-pc-linux-gnu
checking host system type... powerpc64-unknown-linux-gnu
checking target system type... powerpc64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for powerpc64-linux-strip... powerpc64-linux-strip
checking for --enable-version-specific-runtime-libs... no
checking whether to enable maintainer-specific portions of Makefiles... no
checking for powerpc64-linux-gcc...
/TMP/build-gcc-svn20060906-powerpc64/./gcc/x
gcc -B/TMP/build-gcc-svn20060906-powerpc64/./gcc/
-B/usr/local/DIR/gcc-powerpc64
-svn20060906/powerpc64-linux/bin/
-B/usr/local/DIR/gcc-powerpc64-svn20060906/pow
erpc64-linux/lib/ -isystem
/usr/local/DIR/gcc-powerpc64-svn20060906/powerpc64-li
nux/include -isystem
/usr/local/DIR/gcc-powerpc64-svn20060906/powerpc64-linux/sy
s-include
checking for C compiler default output file name... configure: error: C
compiler
cannot create executables
See `config.log' for more details.
make[1]: *** [configure-target-libmudflap] Error 1
make[1]: Leaving directory `/TMP/build-gcc-svn20060906-powerpc64'
make: *** [all] Error 2
<-- snip -->
I can workaround this issue with "--disable-libmudflap --disable-libssp".
--
Summary: [4.0/4.1/4.2 regression] building a cross compiler with
--disable-multilib fails
Product: gcc
Version: 4.0.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu (and several others)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug bootstrap/28962] [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails
--- Comment #1 from bunk at stusta dot de 2006-09-06 14:13 --- Created an attachment (id=12197) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12197&action=view) configure log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug bootstrap/28962] [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails
--- Comment #2 from bunk at stusta dot de 2006-09-06 14:13 --- Created an attachment (id=12198) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12198&action=view) make log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug bootstrap/28962] [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails
--- Comment #3 from bunk at stusta dot de 2006-09-06 14:15 --- Created an attachment (id=12199) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12199&action=view) powerpc64-linux/libmudflap/config.log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug bootstrap/28962] [4.0/4.1/4.2 regression] building a cross compiler with --disable-multilib fails
--- Comment #4 from bunk at stusta dot de 2006-09-06 14:19 --- Note: "checking host system type... powerpc64-unknown-linux-gnu" is obviously wrong -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug bootstrap/28962] building a cross compiler with --disable-multilib fails
--- Comment #7 from bunk at stusta dot de 2006-09-06 17:22 --- I don't have a glibc for this target. But this might be where my problems are coming from: I am able to compile gcc 4.1.1 for at about a dozen targets without having any libc for these targets present. And the resulting compilers work fine for my purposes (cross-compiling Linux kernels). But the configure options I had to figure out for doing this seem to indicate that this is a working but not documented setup. It seems sending a bug report for part of this wasn't the right solution. Is there a good reason why gcc can't officially support being built without a libc by either figuring out that there's no libc itself or by offering some kind of --i-do-not-have-a-libc option to configure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28962
[Bug bootstrap/28949] configure-target-libiberty: Link tests are not allowed after GCC_NO_EXECUTABLES
--- Comment #7 from bunk at stusta dot de 2006-09-10 22:42 --- It works up to 4.1 but does no longer work in 4.2. If your point is that I don't have a libc for the target installed: Is there any point in the documentation I missed that should have told me this worked only accidentally in gcc <= 4.1? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28949
[Bug c/32772] New: [4.3 Regression] error: found real variable when subvariables should have appeared
I got the following compile error when trying to compile Linux kernel
2.6.22-rc6-mm1 with a recent gcc SVN snapshot:
$ /usr/local/DIR/gcc-svn20070715/bin/gcc -Wp,-MD,mm/.page_alloc.o.d -nostdinc
-isystem /usr/local/DIR/gcc-svn20070715/lib/gcc/i686-pc-linux-gnu/4.3.0/include
-D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Werror-implicit-function-declaration -Os
-pipe -msoft-float -mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2
-march=athlon -ffreestanding -maccumulate-outgoing-args -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -Iinclude/asm-i386/mach-generic
-Iinclude/asm-i386/mach-default -fno-omit-frame-pointer
-fno-optimize-sibling-calls -fasynchronous-unwind-tables -fno-stack-protector
-Wdeclaration-after-statement -Wno-pointer-sign-D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(page_alloc)"
-D"KBUILD_MODNAME=KBUILD_STR(page_alloc)" -c -o mm/page_alloc.o
mm/page_alloc.c: In function â__build_all_zonelistsâ:
mm/page_alloc.c:2381: error: found real variable when subvariables should have
appeared
while verifying SSA_NAME used_mask_87 in statement
# node_2_cpu_mask_468 = VDEF
# node_data_469 = VDEF
# zone_reclaim_mode_470 = VDEF
# policy_zone_471 = VDEF
# node_load_472 = VDEF
# node_order_473 = VDEF
# used_mask_87 = VDEF
# tmp_474 = VDEF
# SFT.3392_475 = VDEF
# SFT.3393_476 = VDEF
# SMT.3398_196 = VDEF
D.24412_7->node_zonelists[i.600_23].zlcache_ptr = zlc_26;
...
--
Summary: [4.3 Regression] error: found real variable when
subvariables should have appeared
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32772
[Bug c/32772] [4.3 Regression] error: found real variable when subvariables should have appeared
--- Comment #1 from bunk at stusta dot de 2007-07-15 23:56 --- Created an attachment (id=13917) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13917&action=view) complete error messages -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32772
[Bug c/32772] [4.3 Regression] error: found real variable when subvariables should have appeared
--- Comment #2 from bunk at stusta dot de 2007-07-15 23:59 --- Created an attachment (id=13918) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13918&action=view) preprocessed code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32772
[Bug c/32796] New: internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in int_fits_type_p
$ /usr/local/DIR/gcc-svn20070717/bin/gcc -Wp,-MD,drivers/kvm/.mmu.o.d
-nostdinc -isystem
/usr/local/DIR/gcc-svn20070717/lib/gcc/i686-pc-linux-gnu/4.3.0/include
-D__KERNEL__ -Iinclude -include include/linux/autoconf.h -Wall -Wundef
-Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -O1 -pipe -msoft-float -mregparm=3
-freg-struct-return -mpreferred-stack-boundary=2 -march=athlon -ffreestanding
-maccumulate-outgoing-args -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1
-Iinclude/asm-i386/mach-generic -Iinclude/asm-i386/mach-default
-fno-omit-frame-pointer -fno-optimize-sibling-calls
-fasynchronous-unwind-tables -fno-stack-protector
-Wdeclaration-after-statement -Wno-pointer-sign-D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(mmu)" -D"KBUILD_MODNAME=KBUILD_STR(kvm)" -c -o
drivers/kvm/mmu.o drivers/kvm/mmu.c
drivers/kvm/mmu.c: In function ânonpaging_mapâ:
drivers/kvm/mmu.c:831: internal compiler error: tree check: expected
integer_type or enumeral_type or boolean_type or real_type, have pointer_type
in int_fits_type_p, at tree.c:6198
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: internal compiler error: tree check: expected
integer_type or enumeral_type or boolean_type or
real_type, have pointer_type in int_fits_type_p
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32796
[Bug c/32796] [4.3 Regression] internal compiler error: tree check: expected integer_type or enumeral_type or boolean_type or real_type, have pointer_type in int_fits_type_p
--- Comment #1 from bunk at stusta dot de 2007-07-17 18:05 --- Created an attachment (id=13933) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13933&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32796
[Bug c/37014] internal compiler error: in expand_expr_real_1, at expr.c:8760
--- Comment #1 from bunk at stusta dot de 2008-08-05 15:56 --- Stephen Rothwell reported that he also saw it on powerpc. I verified the bug on powerpc with the following gcc versions: - 4.2.4 - 4.3, latest svn - 4.4, latest svn 4.1.2 is fine. -- bunk at stusta dot de changed: What|Removed |Added CC||bunk at stusta dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37014
[Bug c/37014] internal compiler error: in expand_expr_real_1, at expr.c:8760
--- Comment #2 from bunk at stusta dot de 2008-08-05 15:59 --- Created an attachment (id=16025) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16025&action=view) hw.i.gz $ powerpc64-linux-gcc --version powerpc64-linux-gcc (GCC) 4.4.0 20080805 (experimental) Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ powerpc64-linux-gcc -O1 hw.i /TMP/git/linux-next/drivers/net/wireless/ath9k/hw.c: In function 'ath9k_hw_9280_spur_mitigate': /TMP/git/linux-next/drivers/net/wireless/ath9k/hw.c:4660: internal compiler error: in expand_expr_real_1, at expr.c:9176 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. $ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37014
[Bug other/35419] New: [4.3/4.4 Regression] bfin libgcc build error
... # If the gcc directory specifies which extra parts to # build for this target, and the libgcc configuration also # specifies, make sure they match. This can be removed # when the gcc directory no longer holds libgcc configuration; # it is useful when migrating a target. Configuration mismatch! Extra parts from gcc directory: crtbegin.o crtend.o crti.o crtn.o Extra parts from libgcc: crtbegin.o crtbeginS.o crtbeginT.o crtend.o crtendS.o exit 1 make[2]: *** [libgcc-extra-parts] Error 1 make[2]: Leaving directory `/tmp/build-gcc-4.3.0-RC-20080222-bfin/bfin-linux/libgcc' -- Summary: [4.3/4.4 Regression] bfin libgcc build error Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bunk at stusta dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: bfin-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35419
[Bug other/35454] New: [4.3/4.4 Regression] m68k: internal compiler error: in find_reloads, at reload.c:3744
This bug might be related to bug 32424 (why do you have a testsuite when
reports of ICEs when running it get completely ignored?), but I can't judge
whether it's really the same:
$ m68k-linux-gcc -Wp,-MD,fs/udf/.truncate.o.d -nostdinc -isystem
/usr/local/DIR/gcc-m68k-4.3.0-RC-20080301/lib/gcc/m68k-linux/4.3.0/include
-D__KERNEL__ -Iinclude -Iinclude2
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/include -include
include/linux/autoconf.h -I/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf
-Ifs/udf -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -Os -fno-stack-protector
-fno-strength-reduce -ffixed-a2 -fomit-frame-pointer
-Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(truncate)" -D"KBUILD_MODNAME=KBUILD_STR(udf)" -c
-o fs/udf/truncate.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/truncate.c -save-temps
/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/truncate.c: In function
'udf_truncate_tail_extent':
/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/truncate.c:123: error: unable
to generate reloads for:
(insn:QI 59 168 60 10
/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/truncate.c:98 (parallel [
(set (cc0)
(compare (reg:DI 2 %d2 [54])
(reg:DI 0 %d0 [orig:56 .s_blocksize+-4 ] [56])))
(clobber (reg:DI 57))
]) 12 {*m68k.md:521} (expr_list:REG_DEAD (reg:DI 0 %d0 [orig:56
.s_blocksize+-4 ] [56])
(expr_list:REG_DEAD (reg:DI 2 %d2 [54])
(expr_list:REG_UNUSED (reg:DI 57)
(nil)
/home/bunk/linux/kernel-2.6/git/linux-2.6/fs/udf/truncate.c:123: internal
compiler error: in find_reloads, at reload.c:3744
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
--
Summary: [4.3/4.4 Regression] m68k: internal compiler error: in
find_reloads, at reload.c:3744
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35454
[Bug other/35454] [4.3/4.4 Regression] m68k: internal compiler error: in find_reloads, at reload.c:3744
--- Comment #1 from bunk at stusta dot de 2008-03-04 07:19 --- Created an attachment (id=15257) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15257&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35454
[Bug other/35455] New: [4.1/4.2/4.3/4.4 Regression] h8300: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:10984
$ h8300-linux-gcc -Wp,-MD,fs/.read_write.o.d -nostdinc -isystem /usr/local/DIR/gcc-h8300-4.3.0-RC-20080301/lib/gcc/h8300-elf/4.3.0/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/bunk/linux/kernel-2.6/git/linux-2.6/include -include include/linux/autoconf.h -I/home/bunk/linux/kernel-2.6/git/linux-2.6/fs -Ifs -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -fno-stack-protector -mh -mint32 -fno-builtin -g -D__linux__ -DUTS_SYSNAME=\"uClinux\" -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(read_write)" -D"KBUILD_MODNAME=KBUILD_STR(read_write)" -c -o fs/read_write.o /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/read_write.c /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/read_write.c: In function 'sys_pwrite64': /home/bunk/linux/kernel-2.6/git/linux-2.6/fs/read_write.c:427: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:10984 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- Summary: [4.1/4.2/4.3/4.4 Regression] h8300: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:10984 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bunk at stusta dot de GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: h8300-unknown-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35455
[Bug other/35455] [4.1/4.2/4.3/4.4 Regression] h8300: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:10984
--- Comment #1 from bunk at stusta dot de 2008-03-04 07:45 --- Created an attachment (id=15258) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15258&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35455
[Bug c/35609] New: [4.3/4.4 Regression] bogus "is used uninitialized in this function" warning
<-- snip -->
$ cat test.c
int foo, bar;
void decode_reloc(int reloc, int *is_alt)
{
if (reloc >= 20)
*is_alt = 1;
else if (reloc >= 10)
*is_alt = 0;
}
void testfunc()
{
int alt_reloc;
decode_reloc(foo, &alt_reloc);
if (alt_reloc)
bar = 42;
}
$ gcc -O2 -Wall -c test.c
test.c: In function âtestfuncâ:
test.c:17: warning: âalt_relocâ is used uninitialized in this function
$
<-- snip -->
A "may be used uninitialized in this function" warning might be appropriate
here, but gcc seems to wrongly think it can prove "alt_reloc" was for sure
uninitialized here.
--
Summary: [4.3/4.4 Regression] bogus "is used uninitialized in
this function" warning
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35609
[Bug other/35618] New: [4.3/4.4 regression] ICE in cgraph_estimate_size_after_inlining, at ipa-inline.c:188
$ gcc -Wp,-MD,kernel/.sched.o.d -nostdinc -isystem
/usr/lib/gcc/i486-linux-gnu/4.3.1/include -D__KERNEL__ -Iinclude -Iinclude2
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/include -include
include/linux/autoconf.h -I/home/bunk/linux/kernel-2.6/git/linux-2.6/kernel
-Ikernel -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -Os -fno-stack-protector
-D__arch_um__ -DSUBARCH=\"i386\"
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/um/include -Iarch/um/include
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/um/include
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/um/include/skas
-Dvmap=kernel_vmap -Din6addr_loopback=kernel_in6addr_loopback
-Din6addr_any=kernel_in6addr_any -march=i686 -mpreferred-stack-boundary=2
-ffreestanding -D_LARGEFILE64_SOURCE -Derrno=kernel_errno
-Dsigprocmask=kernel_sigprocmask -Dmktime=kernel_mktime -fno-unit-at-a-time
-fno-omit-frame-pointer -fno-optimize-sibling-calls -g
-Wdeclaration-after-statement -Wno-pointer-sign -fno-omit-frame-pointer
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(sched)"
-D"KBUILD_MODNAME=KBUILD_STR(sched)" -c -o kernel/sched.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/kernel/sched.c
In file included from
/home/bunk/linux/kernel-2.6/git/linux-2.6/kernel/sched.c:1213:
/home/bunk/linux/kernel-2.6/git/linux-2.6/kernel/sched_idletask.c: In function
âcheck_preempt_curr_idleâ:
/home/bunk/linux/kernel-2.6/git/linux-2.6/kernel/sched_idletask.c:20: internal
compiler error: in cgraph_estimate_size_after_inlining, at ipa-inline.c:188
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
$ gcc --version
gcc (Debian 4.3.0-1) 4.3.1 20080309 (prerelease)
--
Summary: [4.3/4.4 regression] ICE in
cgraph_estimate_size_after_inlining, at ipa-inline.c:188
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35618
[Bug other/35618] [4.3/4.4 regression] ICE in cgraph_estimate_size_after_inlining, at ipa-inline.c:188
--- Comment #1 from bunk at stusta dot de 2008-03-17 19:11 --- Created an attachment (id=15337) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15337&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35618
[Bug other/35618] [4.3/4.4 regression] ICE in cgraph_estimate_size_after_inlining, at ipa-inline.c:188
--- Comment #3 from bunk at stusta dot de 2008-03-17 19:23 --- That's the UML kernel, and it was added there quite some time ago. I do not know whether that might be dropped or whether it might still result in increased stack usage with gcc 4.3, but IMHO as long as gcc offers this option it shouldn't cause an ICE. -- bunk at stusta dot de changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35618
[Bug other/35618] [4.3/4.4 regression] ICE in cgraph_estimate_size_after_inlining, at ipa-inline.c:188
--- Comment #5 from bunk at stusta dot de 2008-03-25 19:24 --- The flags I used are in my bug description. It seems "-Os -fno-unit-at-a-time" are the minimum flags required for reproducing it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35618
[Bug other/35618] [4.3 regression] ICE in cgraph_estimate_size_after_inlining, at ipa-inline.c:188
--- Comment #7 from bunk at stusta dot de 2008-03-26 13:54 --- Bug seems to be no longer present with svn HEAD. Bug is still present in 4.3 as of 4.3-20080320. -- bunk at stusta dot de changed: What|Removed |Added Status|WAITING |UNCONFIRMED Summary|[4.3/4.4 regression] ICE in |[4.3 regression] ICE in |cgraph_estimate_size_after_i|cgraph_estimate_size_after_i |nlining, at ipa-inline.c:188|nlining, at ipa-inline.c:188 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35618
[Bug c/89723] New: Bogus maybe-uninitialized warning with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89723
Bug ID: 89723
Summary: Bogus maybe-uninitialized warning with -Og
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bunk at stusta dot de
Target Milestone: ---
gcc seems to disable this warning when building without optimization, but it is
enabled with -Og:
$ cat test.c
typedef struct node234_Tag node234;
struct node234_Tag {
node234 *parent;
node234 *kids[4];
int counts[4];
};
int add234_internal(node234 *r, void *e, int index) {
node234 *n;
int ki;
if (r == 0) {
return 0;
}
n = r;
while (n) {
if (index <= n->counts[0]) {
ki = 0;
} else if (index -= n->counts[0] + 1, index <= n->counts[1]) {
ki = 1;
} else
return 0;
if (!n->kids[ki])
break;
n = n->kids[ki];
}
return ki;
}
$ gcc -c -O0 -Wall -Werror test.c
$ gcc -c -O1 -Wall -Werror test.c
$ gcc -c -Og -Wall -Werror test.c
test.c: In function ‘add234_internal’:
test.c:11:9: error: ‘ki’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
int ki;
^~
cc1: all warnings being treated as errors
$
Some upstream software builds with -Werror, which makes this a real problem
when building a whole distribution like Yocto with -Og for debugging purposes.
This can be reproduced on amd64 with all gcc versions supporting -Og from 4.8
to a recent gcc 9 snapshot.
[Bug c/86835] New: [8/9 Regression] Bogus "is used uninitialized" warning with -ffast-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86835
Bug ID: 86835
Summary: [8/9 Regression] Bogus "is used uninitialized" warning
with -ffast-math
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bunk at stusta dot de
Target Milestone: ---
From https://bugs.debian.org/897876
$ cat test.c
#include
void
evallogisticML(const double *x, const int n,
double *params, double *fvec, double **fjac)
{
inti;
double a, b, amxb, /* exp_xmab,*/ cosh_amxb, nd, xi, diff;
a = params[0];
b = params[1];
nd = (double) n;
fvec[0] = fvec[1] = fjac[0][0] = fjac[1][0] = fjac[0][1] = fjac[1][1] =
0.0;
for (i = 0; i < n; ++i)
{
xi = x[i];
/* xmab = (x[i] - a) / b; */
diff = a - xi;
amxb = diff / b;
cosh_amxb = cosh(amxb);
fvec[0] += tanh(amxb/2.0); /* good */
fvec[1] += diff * tanh(amxb/2.0); /* good */
fjac[0][0] += (1.0 / (1.0 + cosh(amxb))); /* good */
fjac[0][1] += (diff / (1.0 + cosh_amxb)); /* good */
fjac[1][0] += (diff + b * sinh(amxb)) / (1.0 + cosh_amxb); /* good */
fjac[1][1] += diff * diff / (1.0 + cosh_amxb); /* good */
}
fvec[0] = fvec[0]; /* good */
fvec[1] -= (b * nd); /* good */
fjac[0][0] /= b; /* good */
fjac[0][1] /= b*b; /* good */
fjac[1][0] /= b; /* good */
fjac[1][1] = -fjac[1][1]/(b*b) - nd; /* good */
}
$ gcc-7 -O1 -ffast-math -Wall -c test.c
$ gcc-8 -O1 -ffast-math -Wall -c test.c
test.c: In function 'evallogisticML':
test.c:4:1: warning: 'reciptmp.6' is used uninitialized in this function
[-Wuninitialized]
evallogisticML(const double *x, const int n,
^~
$ /usr/lib/gcc-snapshot/bin/gcc -O1 -ffast-math -Wall -c test.c
test.c: In function 'evallogisticML':
test.c:4:1: warning: 'reciptmp.6' is used uninitialized in this function
[-Wuninitialized]
evallogisticML(const double *x, const int n,
^~
$ gcc-8 --version
gcc-8 (Debian 8.2.0-2) 8.2.0
...
$ /usr/lib/gcc-snapshot/bin/gcc --version
gcc (Debian 20180721-1) 9.0.0 20180721 (experimental) [trunk revision 262917]
8.2.0-2 is r263045 from the gcc-8-branch.
[Bug c/87049] New: __clear_cache() prototype confusion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87049
Bug ID: 87049
Summary: __clear_cache() prototype confusion
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bunk at stusta dot de
Target Milestone: ---
$ cat test.cc
extern "C" void __clear_cache(char *beg, char *end);
$ g++-5 -c test.cc
test.cc:1:51: warning: new declaration 'void __clear_cache(char*, char*)'
ambiguates built-in declaration 'void __clear_cache(void*, void*)'
extern "C" void __clear_cache(char *beg, char *end);
^
$ g++-7 -c test.cc
test.cc:1:17: warning: new declaration 'void __clear_cache(char*, char*)'
ambiguates built-in declaration 'void __clear_cache(void*, void*)'
[-Wbuiltin-declaration-mismatch]
extern "C" void __clear_cache(char *beg, char *end);
^
$ g++-8 -c test.cc
test.cc:1:17: error: new declaration 'void __clear_cache(char*, char*)'
ambiguates built-in declaration 'void __clear_cache(void*, void*)'
[-fpermissive]
extern "C" void __clear_cache(char *beg, char *end);
^
$
The bug is not that g++ became more strict, the bug is that the built-in
declaration differs from the documented declaration.
Relevant part of the gcc sources:
gcc/builtins.def:DEF_EXT_LIB_BUILTIN(BUILT_IN_CLEAR_CACHE, "__clear_cache",
BT_FN_VOID_PTR_PTR, ATTR_NOTHROW_LEAF_LIST)
gcc/doc/extend.texi:@deftypefn {Built-in Function} void __builtin___clear_cache
(char *@var{begin}, char *@var{end})
libgcc/libgcc2.h:extern void __clear_cache (char *, char *);
Doesn't seem to be a new issue:
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20130513/079828.html
[Bug testsuite/23400] [4.1 Regression] "make check" fixinclude failure
-- What|Removed |Added Known to work||4.0.1 Summary|"make check" fixinclude |[4.1 Regression] "make |failure |check" fixinclude failure http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23400
[Bug bootstrap/24246] New: [4.1 Regression] bootstrap fails in gcc/tree-ssa-structalias.c
<-- snip -->
...
stage1/xgcc -Bstage1/ -B/TMP/test/gcc/install/i686-pc-linux-gnu/bin/ -c -O2
-g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Wmissing-format-attribute -Werror -fno-common
-DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
-I../../gcc/../libcpp/include ../../gcc/tree-ssa-structalias.c -o
tree-ssa-structalias.o
cc1: warnings being treated as errors
../../gcc/tree-ssa-structalias.c: In function 'check_for_overlaps':
../../gcc/tree-ssa-structalias.c:3036: warning: comparison between signed and
unsigned
make[2]: *** [tree-ssa-structalias.o] Error 1
make[2]: Leaving directory `/TMP/test/gcc/gcc/build/gcc'
make[1]: *** [stage2_build] Error 2
make[1]: Leaving directory `/TMP/test/gcc/gcc/build/gcc'
make: *** [bootstrap] Error 2
<-- snip -->
The offending change is:
2005-10-06 Daniel Berlin <[EMAIL PROTECTED]>
Fix PR tree-optimization/22488
* tree-ssa-structalias.c (check_for_overlaps): New function.
(create_variable_info_for): Use it.
--
Summary: [4.1 Regression] bootstrap fails in gcc/tree-ssa-
structalias.c
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: blocker
Priority: P1
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24246
[Bug c/81841] New: i386: weird gcc -C error when including math.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81841 Bug ID: 81841 Summary: i386: weird gcc -C error when including math.h Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bunk at stusta dot de Target Milestone: --- $ cat test.c #include $ gcc -m64 -c -C test.c -O0 $ gcc -m64 -c -C test.c -O1 $ gcc -m32 -c -C test.c -O0 $ gcc -m32 -c -C test.c -O1 In file included from /usr/include/math.h:472:0, from test.c:1: /usr/include/bits/mathinline.h: In function ‘floor’: /usr/include/bits/mathinline.h:746:1: error: expected ‘:’ or ‘)’ before string constant __inline_mathcodeNP (floor, __x, \ ^ /usr/include/bits/mathinline.h: In function ‘floorf’: /usr/include/bits/mathinline.h:746:1: error: expected ‘:’ or ‘)’ before string constant __inline_mathcodeNP (floor, __x, \ ^ /usr/include/bits/mathinline.h: In function ‘floorl’: /usr/include/bits/mathinline.h:746:1: error: expected ‘:’ or ‘)’ before string constant __inline_mathcodeNP (floor, __x, \ ^ /usr/include/bits/mathinline.h: In function ‘ceil’: /usr/include/bits/mathinline.h:764:1: error: expected ‘:’ or ‘)’ before string constant __inline_mathcodeNP (ceil, __x, \ ^ /usr/include/bits/mathinline.h: In function ‘ceilf’: /usr/include/bits/mathinline.h:764:1: error: expected ‘:’ or ‘)’ before string constant __inline_mathcodeNP (ceil, __x, \ ^ /usr/include/bits/mathinline.h: In function ‘ceill’: /usr/include/bits/mathinline.h:764:1: error: expected ‘:’ or ‘)’ before string constant __inline_mathcodeNP (ceil, __x, \ ^ $ gcc -m32 -c test.c -O1 $ gcc -m32 -c -C test.c -O1 -save-temps $ gcc -m32 -c -C test.i -O1 $ Reproduced with both the Debian package of 6.3.0 in Debian stable and the Debian package of 7.1.0 in Debian unstable, in both cases glibc 2.24 is used.
[Bug c/81876] New: [7 Regression] bogus -Wstrict-overflow warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81876
Bug ID: 81876
Summary: [7 Regression] bogus -Wstrict-overflow warning with
-O3
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: bunk at stusta dot de
Target Milestone: ---
Testcase based on an xbubble build error on Debian:
$ cat test.c
struct _Bubble {
int color;
};
typedef struct _Bubble * Bubble;
typedef enum {
EAST=0,
NORTH_EAST,
NORTH_WEST,
WEST,
SOUTH_WEST,
SOUTH_EAST
} Quadrant;
struct _CellArray {
Bubble cell[(8 * 12)];
int first_row;
};
typedef struct _CellArray * CellArray;
void cell_array_lower( CellArray ca ) {
int i;
for ( i = ( ca->first_row*8 ); i < ( ca->first_row*8 ) + 8; i++ )
ca->cell[i] = ((void *)0);
}
$ gcc-6 -O2 -Wall -Werror -c test.c
$ gcc-6 -O3 -Wall -Werror -c test.c
$ gcc -O2 -Wall -Werror -c test.c
$ gcc -O3 -Wall -Werror -c test.c
test.c: In function ‘cell_array_lower’:
test.c:25:17: error: assuming signed overflow does not occur when assuming that
(X + c) >= X is always true [-Werror=strict-overflow]
ca->cell[i] = ((void *)0);
^
cc1: all warnings being treated as errors
$
It works when replacing the "+ 8" in the loop condition with a variable whose
value is not known at compile time.
[Bug rtl-optimization/78580] [6 Regression] Segfault in gcc with multilib (-m32) and -ffixed-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78580 Adrian Bunk changed: What|Removed |Added CC||bunk at stusta dot de --- Comment #8 from Adrian Bunk --- Could you also fix this in the gcc 6 branch? This is a gcc 6 regression that is part of the reason why gprolog in Debian cannot be compiled with gcc 6 on i686. Thanks
[Bug c/82364] New: [7 Regression] Enormous memory usage when building on 32bit i386 with >= -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364 Bug ID: 82364 Summary: [7 Regression] Enormous memory usage when building on 32bit i386 with >= -O1 Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bunk at stusta dot de Target Milestone: --- Created attachment 42263 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42263&action=edit piglit-util-gl-enum-gen.i piglit fails to build on 32bit i386 in Debian unstable, the problem is: $ /usr/bin/time -f "%M" gcc-6 piglit-util-gl-enum-gen.i -c -O0 40364 $ /usr/bin/time -f "%M" gcc-6 piglit-util-gl-enum-gen.i -c -O1 54460 $ /usr/bin/time -f "%M" gcc-6 piglit-util-gl-enum-gen.i -c -O2 79688 $ /usr/bin/time -f "%M" gcc-6 piglit-util-gl-enum-gen.i -c -O3 79904 $ /usr/bin/time -f "%M" gcc-7 piglit-util-gl-enum-gen.i -c -O0 41732 $ /usr/bin/time -f "%M" gcc-7 piglit-util-gl-enum-gen.i -c -O1 679260 $ /usr/bin/time -f "%M" gcc-7 piglit-util-gl-enum-gen.i -c -O2 cc1: out of memory allocating 396567608 bytes after a total of 3083091968 bytes Command exited with non-zero status 1 3476008 $ /usr/bin/time -f "%M" /usr/lib/gcc-snapshot/bin/gcc piglit-util-gl-enum-gen.i -c -O0 42044 $ /usr/bin/time -f "%M" /usr/lib/gcc-snapshot/bin/gcc piglit-util-gl-enum-gen.i -c -O1 51152 $ /usr/bin/time -f "%M" /usr/lib/gcc-snapshot/bin/gcc piglit-util-gl-enum-gen.i -c -O2 83636 $ /usr/bin/time -f "%M" /usr/lib/gcc-snapshot/bin/gcc piglit-util-gl-enum-gen.i -c -O3 83668 $ gcc-6 --version gcc-6 (Debian 6.4.0-7) 6.4.0 20170920 ... $ gcc-7 --version gcc-7 (Debian 7.2.0-7) 7.2.0 ... $ /usr/lib/gcc-snapshot/bin/gcc --version gcc (Debian 20170923-1) 8.0.0 20170923 (experimental) [trunk revision 253114] ... $ 7.2.0-7 is based on SVN 20170923 (r253114) from the gcc-7-branch. Building on 64bit amd64 with -m32 has a normal memory usage (98 MB).
[Bug middle-end/82364] [7 Regression] Enormous memory usage when building for 32bit i386 with >= -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82364 Adrian Bunk changed: What|Removed |Added Summary|[7 Regression] Enormous |[7 Regression] Enormous |memory usage when building |memory usage when building |on 32bit i386 with >= -O1 |for 32bit i386 with >= -O1 --- Comment #2 from Adrian Bunk --- (In reply to Richard Biener from comment #1) > Can you provide output of the compile command with -v appended so we can see > the different default flags passed for both the 32bit compile and the 64bit > -m32 compile? Thanks for asking, looking at the output I realized that I made the stupid mistake of running gcc 6 in the 64bit -m32 compile. The 64bit -m32 compile succeeds with gcc-7, but it actually has 5.5 GB memory usage.
[Bug fortran/83021] [7 Regression] gfortran segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83021 Adrian Bunk changed: What|Removed |Added CC||bunk at stusta dot de --- Comment #5 from Adrian Bunk --- Created attachment 42636 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42636&action=edit Correct testcase Sorry, I missed that one of the files was binary. Correct testcase is now attached. $ gfortran local_field.f90 global_field.f90 -fcoarray=lib global_field.f90:126:0: lhs%values(:) = rhs%state() internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $
[Bug c/83100] New: [8 Regression] powerpc: internal compiler error: in get_variable_section, at varasm.c:1150 with -fdata-sections
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83100 Bug ID: 83100 Summary: [8 Regression] powerpc: internal compiler error: in get_variable_section, at varasm.c:1150 with -fdata-sections Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: bunk at stusta dot de Target Milestone: --- Created attachment 42676 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42676&action=edit preprocessed source (from nss-3.34) $ gcc-7 -c -O1 -fdata-sections pkix_errpaths.i $ gcc-8 -c -O1 -fdata-sections pkix_errpaths.i pkix_errpaths.c:102:1: internal compiler error: in get_variable_section, at varasm.c:1150 } ^ Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $ gcc-8 --version gcc-8 (Debian 8-20171108-1) 8.0.0 20171108 (experimental) [trunk revision 254551] ... Works with -O0, ICE with >= -O1. Reproduced on 64bit little endian and 32bit big endian powerpc.
[Bug middle-end/81876] [7 Regression] bogus -Wstrict-overflow warning with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81876 --- Comment #6 from Adrian Bunk --- (In reply to Jeffrey A. Law from comment #4) > WRT locations/diagnostics for things like ldist where GCC conjures up code > that has little resemblance to what the user wrote. It's a real issue once > we issue the warning -- the user has no clue what it meant. > > On the other hand those warnings (particularly those that result from ldist) > are highlighting real issues. Bogus user code, poor optimization, even > under-specified language from ISO. Examples of all can be found in BZ. If in doubt, don't issue any warning to the user. As far as I am aware, the testcase in this bug does not warrant any warning in that line - even "comparison is always true" would be wrong. If a warning option sometimes generates bogus warnings for issues not present in the code, the only reasonable option for a user would be to always disable this warning.
[Bug other/18367] [4.1 Regression] make check fails with fixinclude problem
--- Additional Comments From bunk at stusta dot de 2005-07-28 23:11 --- I'm still getting the error from comment 2 with HEAD last updated a few hours ago. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18367
[Bug testsuite/23400] New: "make check" fixinclude failure
With a current HEAD CVS checkout:
<-- snip -->
...
Fixed: X11/ShellP.h
Fixed: X11/Xmu.h
Fixed: Xm/BaseClassI.h
Fixed: Xm/Traversal.h
cmp: EOF on string.h
*** string.h2005-08-15 16:47:11.0 +0200
--- /TMP/test/gcc/gcc/fixincludes/tests/base/string.h 2005-08-15
14:32:57.0 +0200
***
*** 10,13
#ifndef _STRING_INCLUDED
#define _STRING_INCLUDED
#include
! #endif /* _STRING_INCLUDED */
\ No newline at end of file
--- 10,13
#ifndef _STRING_INCLUDED
#define _STRING_INCLUDED
#include
! #endif /* _STRING_INCLUDED */
There were fixinclude test FAILURES
make[1]: *** [check] Error 1
make[1]: Leaving directory `/TMP/test/gcc/gcc/build/fixincludes'
make: *** [check-fixincludes] Error 2
<-- snip -->
--
Summary: "make check" fixinclude failure
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23400
[Bug c/23402] New: error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
This is a compile error when trying to compile the file kernel/audit.c from the
Linux kernel 2.6.13-rc5-mm1 with a current CVS HEAD gcc.
I've removed many of the compiler flags that were present at the original
compilation. What triggers this problem is switching from -O0 (no problem) to
-O1 (see below).
<-- snip -->
...
$ /TMP/test/gcc/install/bin/gcc -m32 -Wp,-MD,kernel/.audit.o.d -nostdinc
-isystem /TMP/test/gcc/install/lib/gcc/i686-pc-linux-gnu/4.1.0/include
-D__KERNEL__ -Iinclude -O1 -save-temps -Iinclude/asm-i386/mach-default
-Wno-pointer-sign-DKBUILD_BASENAME=audit -DKBUILD_MODNAME=audit -c -o
kernel/audit.o kernel/audit.c
kernel/audit.c: In function 'audit_init':
kernel/audit.c:518: error: statement makes a memory store, but has no V_MAY_DEFS
nor V_MUST_DEFS
# VUSE ;
audit_skb_queue.lock = D.23048;
kernel/audit.c:518: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
<-- snip -->
--
Summary: error: statement makes a memory store, but has no
V_MAY_DEFS nor V_MUST_DEFS
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23402
[Bug c/23402] error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
--- Additional Comments From bunk at stusta dot de 2005-08-15 15:28 --- Created an attachment (id=9498) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9498&action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23402
[Bug c/23402] error: statement makes a memory store, but has no V_MAY_DEFS nor V_MUST_DEFS
-- What|Removed |Added Known to work||4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23402
[Bug testsuite/23400] "make check" fixinclude failure
-- What|Removed |Added Version|unknown |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23400
[Bug c/23445] New: [4.1 Regression] ICE with -O1 -ftree-vrp -fdelete-null-pointer-checks
I'm getting the ICE below when trying to compile the file fs/asfs/extents.c
Linux kernel 2.6.13-rc5-mm1 with a current CVS HEAD gcc.
As soon as I remove _one_ of the three options "-O1 -ftree-vrp
-fdelete-null-pointer-checks" the problem disappears.
<-- snip -->
...
$ /TMP/test/gcc/install/bin/gcc -m32 -Wp,-MD,fs/asfs/.extents.o.d -nostdinc
-isystem /TMP/test/gcc/install/lib/gcc/i686-pc-linux-gnu/4.1.0/include
-D__KERNEL__ -Iinclude -Iinclude/asm-i386/mach-default
-DKBUILD_BASENAME=extents -DKBUILD_MODNAME=asfs -c -o fs/asfs/extents.o
fs/asfs/extents.c -O1 -ftree-vrp -fdelete-null-pointer-checks
fs/asfs/extents.c: In function 'asfs_deletebnode':
fs/asfs/extents.c:325: internal compiler error: in compare_name_with_value, at
tree-vrp.c:2963
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
$
<-- snip -->
--
Summary: [4.1 Regression] ICE with -O1 -ftree-vrp -fdelete-null-
pointer-checks
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23445
[Bug c/23445] [4.1 Regression] ICE with -O1 -ftree-vrp -fdelete-null-pointer-checks
--- Additional Comments From bunk at stusta dot de 2005-08-17 16:33 --- Created an attachment (id=9520) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9520&action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23445
[Bug c/23445] [4.1 Regression] ICE with -O1 -ftree-vrp -fdelete-null-pointer-checks
-- What|Removed |Added Keywords||ice-on-valid-code Known to work||4.0.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23445
[Bug c/34027] New: [4.3 regression] -Os code size nearly doubled
PR32044 makes it for months impossible to compile the Linux kernel with gcc
4.3, but I'll leave the discussions who's technically at fault (and whether gcc
4.3 will ever be able to compile the Linux kernel) to the people who know more
about such things.
But the fact that the code emitted with -Os used is nearly twice as big that's
a regression in gcc.
Test case:
$ cat test.c
unsigned long long foobar(unsigned long long ns)
{
while(ns >= 10L)
ns -= 10L;
return ns;
}
$ gcc --version
gcc (GCC) 4.2.3 20071014 (prerelease) (Debian 4.2.2-3)
...
$ gcc -Os test.c -c -o old-gcc.o
$ /usr/local/DIR/gcc-svn20071108/bin/gcc -Os test.c -c -o new-gcc.o
$ objdump -D old-gcc.o
old-gcc.o: file format elf32-i386
Disassembly of section .text:
:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 8b 45 08mov0x8(%ebp),%eax
6: 8b 55 0cmov0xc(%ebp),%edx
9: eb 08 jmp13
b: 05 00 36 65 c4 add$0xc4653600,%eax
10: 83 d2 ffadc$0x,%edx
13: 83 fa 00cmp$0x0,%edx
16: 77 f3 ja b
18: 3d ff c9 9a 3b cmp$0x3b9ac9ff,%eax
1d: 77 ec ja b
1f: 5d pop%ebp
20: c3 ret
Disassembly of section .comment:
...
$ objdump -D new-gcc.o
new-gcc.o: file format elf32-i386
Disassembly of section .text:
:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 57 push %edi
4: 56 push %esi
5: 53 push %ebx
6: bb 00 36 65 c4 mov$0xc4653600,%ebx
b: 83 ec 0csub$0xc,%esp
e: 8b 7d 0cmov0xc(%ebp),%edi
11: 8b 75 08mov0x8(%ebp),%esi
14: 6a 00 push $0x0
16: 68 00 ca 9a 3b push $0x3b9aca00
1b: 57 push %edi
1c: 56 push %esi
1d: e8 fc ff ff ff call 1e
22: 83 c4 10add$0x10,%esp
25: 69 ca 00 36 65 c4 imul $0xc4653600,%edx,%ecx
2b: 29 c1 sub%eax,%ecx
2d: f7 e3 mul%ebx
2f: 01 f0 add%esi,%eax
31: 8d 14 11lea(%ecx,%edx,1),%edx
34: 11 fa adc%edi,%edx
36: 8d 65 f4lea-0xc(%ebp),%esp
39: 5b pop%ebx
3a: 5e pop%esi
3b: 5f pop%edi
3c: 5d pop%ebp
3d: c3 ret
Disassembly of section .comment:
...
$
--
Summary: [4.3 regression] -Os code size nearly doubled
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34027
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #21 from bunk at stusta dot de 2007-11-09 16:26 --- Let's leave the right/wrong discussion and look at it more pragmatically: Could gcc get some kind of --expensive-libgcc flag that tells gcc that libgcc calls are a bit more expensive than usually and should be avoided? -- bunk at stusta dot de changed: What|Removed |Added CC||bunk at stusta dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #23 from bunk at stusta dot de 2007-11-09 17:09 --- We need a way to globally prevent it in the kernel or it will be a repeating source of problems there. Is -fno-tree-scev-cprop a reasonable (and not too expensive) workaround for the Linux kernel? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #25 from bunk at stusta dot de 2007-11-10 07:41 --- Adding workarounds in all affected places in the kernel would be horribly fragile, but I've confirmed your -fno-tree-scev-cprop suggestion works around it and I'll submit a patch to the Linux kernel to use it with gcc 4.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug tree-optimization/34027] [4.3 regression] -Os code size nearly doubled
--- Comment #6 from bunk at stusta dot de 2007-11-10 07:58 --- I remove the dependency on PR32044: This bug is really just something I observed by chance when looking at the kernel compilation problem, but unless I completely misunderstood your comments here whatever is required to fix this issue does not depend on PR32044 being fixed. Also the other way round __umoddi3 wouldn't be better than __udivdi3 for the kernel although it mightbe what gets emitted after this bug gets fixed. -- bunk at stusta dot de changed: What|Removed |Added BugsThisDependsOn|32044 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34027
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #31 from bunk at stusta dot de 2007-11-27 19:16 --- (In reply to comment #29) > This is IMHO at most a QOI issue - at Novell we mark timespec_add_ns's u64 > parameter as volatile to work around this issue. I expect upstream to adopt > a workaround as well. Note that some targets in the kernel have parts of > libgcc implemented, but i?86 misses at least __udivdi3. The problem is that this is very fragile - imagine what might happen when a frequently used struct member gets changed from int to u64. After all, when looking at current practice, the kernel will support being built with gcc 4.3 until 2013 or 2014. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug middle-end/32044] [4.3 regression] udivdi3 counterproductive, unwarranted use
--- Comment #32 from bunk at stusta dot de 2007-11-27 19:31 --- (In reply to comment #30) >... > I am not a kernel developer, but my feeling as a GCC developer is that > you must provide the entry points in libgcc whenever you are linking > code compiled with GCC. In other words, that GCC should be free to use > functions from libgcc as it pleases. >... Status quo up to gcc 4.2 was that gcc did not use them in the kernel on i386. The root of the problem is that your feeling and what the kernel currently implements do not match, and some flamewars^Wdiscussions might be required for getting this sorted out in either gcc or the kernel... Even if this specific issue in the kernel would turn out as a misoptimization, the general problem would still remain waiting to pop up at some later time at a different place. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32044
[Bug other/36018] New: [4.3/4.4 Regression] powerpc64: internal compiler error: in copy_to_mode_reg, at explow.c:621
$ powerpc64-linux-gcc -m64 -Wp,-MD,drivers/md/.raid6altivec1.o.d -nostdinc -isystem /usr/local/DIR/gcc-powerpc64-4.3-20080417/lib/gcc/powerpc64-linux/4.3.1/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/bunk/linux/kernel-2.6/git/linux-2.6/include -include include/linux/autoconf.h -Iarch/powerpc -I/home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/md -Idrivers/md -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O2 -fno-stack-protector -msoft-float -pipe -I/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/powerpc -Iarch/powerpc -mminimal-toc -mtraceback=none -mcall-aixdesc -mcpu=power4 -mno-altivec -mno-spe -funit-at-a-time -mno-string -Wa,-maltivec -fomit-frame-pointer -Wdeclaration-after-statement -Wno-pointer-sign -maltivec -mabi=altivec -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(raid6altivec1)" -D"KBUILD_MODNAME=KBUILD_STR(raid456)" -c -o drivers/md/raid6altivec1.o drivers/md/raid6altivec1.c drivers/md/raid6altivec1.c: In function 'raid6_altivec1_gen_syndrome_real': drivers/md/raid6altivec1.c:88: internal compiler error: in copy_to_mode_reg, at explow.c:621 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. $ -- Summary: [4.3/4.4 Regression] powerpc64: internal compiler error: in copy_to_mode_reg, at explow.c:621 Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bunk at stusta dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36018
[Bug other/36018] [4.3/4.4 Regression] powerpc64: ICE in copy_to_mode_reg, at explow.c:621
--- Comment #1 from bunk at stusta dot de 2008-04-22 20:25 --- Created an attachment (id=15512) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15512&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36018
[Bug other/36018] [4.3/4.4 Regression] powerpc64: ICE in copy_to_mode_reg, at explow.c:621
--- Comment #2 from bunk at stusta dot de 2008-04-22 20:27 --- No ICE when trying to compile this kernel with gcc 4.3.0, gcc 4.4 wasn't tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36018
[Bug target/36018] [4.3/4.4 Regression] powerpc64: ICE in copy_to_mode_reg, at explow.c:621
--- Comment #4 from bunk at stusta dot de 2008-04-25 17:38 --- Works with 4.3-20080424, so whatever it was it seems to be already fixed. -- bunk at stusta dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36018
[Bug middle-end/34226] [4.3/4.4 Regression][frv] ICE in default_secondary_reload, at targhooks.c:612
--- Comment #13 from bunk at stusta dot de 2008-04-25 20:46 --- Rask, what is the status of your patch? It would be nice if this bug was fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
[Bug other/36210] New: [4.3/4.4 Regression] as doesn't like the assembler code
$ arm-linux-gcc -Wp,-MD,arch/arm/mm/.mmu.o.d -nostdinc -isystem
/usr/local/DIR/gcc-arm-4.3-20080508/lib/gcc/arm-linux/4.3.1/include
-D__KERNEL__ -Iinclude -Iinclude2
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/include -include
include/linux/autoconf.h -mlittle-endian
-I/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/arm/mm -Iarch/arm/mm -Wall
-Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Os -fno-stack-protector -marm
-fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux
-mno-thumb-interwork -D__LINUX_ARM_ARCH__=5 -march=armv5te -mtune=xscale
-Wa,-mcpu=xscale -msoft-float -Uarm -fno-omit-frame-pointer
-fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(mmu)"
-D"KBUILD_MODNAME=KBUILD_STR(mmu)" -c -o arch/arm/mm/mmu.o
/home/bunk/linux/kernel-2.6/git/linux-2.6/arch/arm/mm/mmu.c -save-temps
mmu.s: Assembler messages:
mmu.s:382: Error: can't resolve `_end' {*UND* section} - `_stext' {*UND*
section}
$
Working:
- 4.3-20080501
Broken:
- 4.3-20080508
Not tested:
- 4.4
Preprocessed source is the same, diff of the assembler code:
--- mmu.s-working 2008-05-11 16:03:42.0 +0300
+++ mmu.s-broken2008-05-11 16:05:10.0 +0300
@@ -365,10 +365,9 @@
sub fp, ip, #4
sub sp, sp, #4
ldr r1, .L51
- ldr r2, .L51+4
mov r4, r0
+ ldr r2, .L51+4
mov r3, #0
- rsb r2, r1, r2
bl reserve_bootmem_node
mov r0, r4
ldr r1, .L51+8
@@ -380,7 +379,7 @@
.align 2
.L51:
.word _stext-536870912
- .word _end-536870912
+ .word _end-_stext
.word swapper_pg_dir-536870912
.size reserve_node_zero, .-reserve_node_zero
.section.rodata.str1.1
--
Summary: [4.3/4.4 Regression] as doesn't like the assembler code
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bunk at stusta dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36210
[Bug other/36210] [4.3/4.4 Regression] as doesn't like the assembler code
--- Comment #1 from bunk at stusta dot de 2008-05-11 14:01 --- Created an attachment (id=15626) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15626&action=view) preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36210
[Bug other/36210] [4.3/4.4 Regression] as doesn't like the assembler code
--- Comment #2 from bunk at stusta dot de 2008-05-11 14:02 --- Created an attachment (id=15627) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15627&action=view) assembler generated by 4.3-20080501 (working) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36210
[Bug other/36210] [4.3/4.4 Regression] as doesn't like the assembler code
--- Comment #3 from bunk at stusta dot de 2008-05-11 14:03 --- Created an attachment (id=15628) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15628&action=view) assembler generated by 4.3-20080508 (broken) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36210
[Bug other/36210] [4.3/4.4 Regression] as doesn't like the assembler code
--- Comment #5 from bunk at stusta dot de 2008-05-14 18:30 --- I can confirm that it's fixed. -- bunk at stusta dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36210
[Bug c/36359] [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2
--- Comment #10 from bunk at stusta dot de 2008-06-10 10:11 --- Created an attachment (id=15745) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15745&action=view) Mirco's usbcore.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug c/36359] [Regression] compile error in linux-kernel 2.6.26-rc4 with -O2
--- Comment #11 from bunk at stusta dot de 2008-06-10 10:28 --- (In reply to comment #7) > Looking at http://www.readcode.org/code/linux-2.6.20/include/linux/log2.h it > seems that either the argument to ilog _is_ zero or the compiler thinks so. If you disassemble Mirco's usbcore.o you'll see why I said "I'd have said your gcc has a bug regarding __builtin_constant_p()": The compiler does not think the argument to ilog() was zero - it expanded _all_ the code for the case when __builtin_constant_p(n) returns true. -- bunk at stusta dot de changed: What|Removed |Added CC| |bunk at stusta dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36359
[Bug target/35419] [4.3/4.4 Regression] bfin libgcc build error
--- Comment #3 from bunk at stusta dot de 2008-06-24 20:19 --- Yes, bfin-uclinux works for me. It might be nice to get bfin-linux as an alias for bfin-uclinux, but this bug of mine is definitely INVALID. -- bunk at stusta dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35419
[Bug target/32424] [4.3/4.4 Regression] gcc.c-torture/compile/20050303-1.c FAILs
--- Comment #8 from bunk at stusta dot de 2008-07-06 18:45 --- See the duplicate #35454: This is a problem often seen when compiling Linux kernels. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32424
[Bug c/36929] New: [4.3/4.4 Regression] internal compiler error: Segmentation fault
$ m68k-linux-gcc -O2 -m5200 route.i /home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv4/route.c: In function 'ipv4_sysctl_rtcache_flush': /home/bunk/linux/kernel-2.6/git/linux-2.6/net/ipv4/route.c:2896: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. $ -- Summary: [4.3/4.4 Regression] internal compiler error: Segmentation fault Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bunk at stusta dot de GCC target triplet: m68k-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36929
[Bug c/36929] [4.3/4.4 Regression] internal compiler error: Segmentation fault
--- Comment #1 from bunk at stusta dot de 2008-07-25 09:58 --- Created an attachment (id=15959) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15959&action=view) route.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36929
[Bug lto/97787] New: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 Bug ID: 97787 Summary: [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: bunk at stusta dot de CC: marxin at gcc dot gnu.org Target Milestone: --- https://buildd.debian.org/status/fetch.php?pkg=dolfin&arch=mips64el&ver=2019.2.0~git20200629.946dbd3-4&stamp=1604936169&raw=0 /usr/bin/c++ -fPIC -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -isystem /<>/debian/tmp/usr/include -DVERSION_INFO=\"2019.2.0.dev0\" -O3 -DNDEBUG -flto -Wl,-z,relro -shared -Wl,-soname,cpp.cpython-38-mips64el-linux-gnuabi64.so -o ../lib.linux-mips64-3.8/dolfin/cpp.cpython-38-mips64el-linux-gnuabi64.so CMakeFiles/cpp.dir/src/dolfin.cpp.o CMakeFiles/cpp.dir/src/parameter.cpp.o CMakeFiles/cpp.dir/src/adaptivity.cpp.o CMakeFiles/cpp.dir/src/ale.cpp.o CMakeFiles/cpp.dir/src/common.cpp.o CMakeFiles/cpp.dir/src/fem.cpp.o CMakeFiles/cpp.dir/src/function.cpp.o CMakeFiles/cpp.dir/src/generation.cpp.o CMakeFiles/cpp.dir/src/geometry.cpp.o CMakeFiles/cpp.dir/src/graph.cpp.o CMakeFiles/cpp.dir/src/log.cpp.o CMakeFiles/cpp.dir/src/math.cpp.o CMakeFiles/cpp.dir/src/mesh.cpp.o CMakeFiles/cpp.dir/src/multistage.cpp.o CMakeFiles/cpp.dir/src/ts.cpp.o CMakeFiles/cpp.dir/src/io.cpp.o CMakeFiles/cpp.dir/src/la.cpp.o CMakeFiles/cpp.dir/src/nls.cpp.o CMakeFiles/cpp.dir/src/refinement.cpp.o CMakeFiles/cpp.dir/src/MPICommWrapper.cpp.o -Wl,-rpath,"/<>/debian/tmp/usr/lib/mips64el-linux-gnuabi64:/usr/lib/mips64el-linux-gnuabi64/hdf5/openmpi:/usr/lib/slepcdir/slepc3.14/mips64el-linux-gnuabi64-real/lib:/usr/lib/petscdir/petsc3.14/mips64el-linux-gnuabi64-real/lib:/usr/lib/mips64el-linux-gnuabi64/openmpi/lib" "/<>/debian/tmp/usr/lib/mips64el-linux-gnuabi64/libdolfin.so.2019.2.0.dev0" /usr/lib/mips64el-linux-gnuabi64/libboost_timer.so /usr/lib/mips64el-linux-gnuabi64/libboost_chrono.so /usr/lib/mips64el-linux-gnuabi64/hdf5/openmpi/libhdf5.so /usr/lib/mips64el-linux-gnuabi64/libsz.so /usr/lib/mips64el-linux-gnuabi64/libz.so /usr/lib/mips64el-linux-gnuabi64/libdl.so /usr/lib/mips64el-linux-gnuabi64/libm.so /usr/lib/slepcdir/slepc3.14/mips64el-linux-gnuabi64-real/lib/libslepc_real.so /usr/lib/petscdir/petsc3.14/mips64el-linux-gnuabi64-real/lib/libpetsc_real.so /usr/lib/mips64el-linux-gnuabi64/openmpi/lib/libmpi_cxx.so /usr/lib/mips64el-linux-gnuabi64/openmpi/lib/libmpi.so /usr/bin/ld: /tmp/cpp.cpython-39-mips64el-linux-gnuabi64.so.1TtsmU.ltrans32.ltrans.o: .symtab local symbol at index 214 (>= sh_info of 34) /usr/bin/ld: /tmp/cpp.cpython-39-mips64el-linux-gnuabi64.so.1TtsmU.ltrans32.ltrans.o: error adding symbols: bad value https://buildd.debian.org/status/fetch.php?pkg=bibletime&arch=mips64el&ver=3.0-2&stamp=1601887167&raw=0 /usr/bin/c++ -g -O2 -fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -flto -fno-fat-lto-objects -Wl,-z,relro -Wl,-z,now CMakeFiles/bibletime.dir/bibletime_autogen/mocs_compilation.cpp.o CMakeFiles/bibletime.dir/src/frontend/BookmarkItem.cpp.o CMakeFiles/bibletime.dir/src/frontend/BtMimeData.cpp.o CMakeFiles/bibletime.dir/src/frontend/bibletime.cpp.o CMakeFiles/bibletime.dir/src/frontend/bibletime_init.cpp.o CMakeFiles/bibletime.dir/src/frontend/bibletime_slots.cpp.o CMakeFiles/bibletime.dir/src/frontend/bibletimeapp.cpp.o CMakeFiles/bibletime.dir/src/frontend/bookmarks/bteditbookmarkdialog.cpp.o CMakeFiles/bibletime.dir/src/frontend/bookmarks/cbookmarkindex.cpp.o CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelfinstallfinalpage.cpp.o CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelflanguagespage.cpp.o CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelfremovefinalpage.cpp.o CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelfsourcespage.cpp.o CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelfsourcesprogresspage.cpp.o CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelftaskpage.cpp.o CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelfwizard.cpp.o CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelfwizardpage.cpp.o CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btbookshelfworkspage.cpp.o CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/btinstallpagemodel.cpp.o CMakeFiles/bibletime.dir/src/frontend/bookshelfwizard/cswordsetupinstallsourcesdialog.cpp.o CMakeFiles/bibletime.dir/src/frontend/btaboutdialog.cpp.o CMakeFiles/bibletime.dir/src/frontend/btaboutmoduledialog.cpp.o CMakeFiles/bibletime.dir/src/frontend/btbookshelfdockwidget.cpp.o CMakeFi
[Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 Adrian Bunk changed: What|Removed |Added CC||bunk at stusta dot de --- Comment #3 from Adrian Bunk --- (In reply to Richard Biener from comment #1) > I guess it succeeds when you do not enable -g? Still fails with -g0 (In reply to Richard Biener from comment #1) > Can you check if reverting > 63a2bdbfb42628800a6999e98804928855592ce7 or > 136256c32db63600168516e562441f73c26a187a helps? That said, is 10.1.0 OK? (In reply to Martin Liška from comment #2) > I bet 136256c32db63600168516e562441f73c26a187a should fix that. Sorry for omitting more exact version information in the bug report. Known-broken are all Debian gcc-10 packages since gcc 10 became default in Debian unstable, upstream this is the gcc-10 branch from 20200808 to 20201029. This implies that the two mentioned commits did not break or fix it. Is there any debug information I could gather that might be useful for you?
[Bug lto/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #5 from Adrian Bunk --- (In reply to Richard Biener from comment #4) > You can also try to 'reduce' the testcase. Since you are linking a shared > object you can try to strip as many linker inputs as possible and then > reduce the source files. Bisecting does not work when both halves are working, but I now found some clues: $ g++ -flto -shared CMakeFiles/cpp.dir/src/dolfin.cpp.o CMakeFiles/cpp.dir/src/parameter.cpp.o CMakeFiles/cpp.dir/src/adaptivity.cpp.o CMakeFiles/cpp.dir/src/ale.cpp.o CMakeFiles/cpp.dir/src/common.cpp.o CMakeFiles/cpp.dir/src/fem.cpp.o CMakeFiles/cpp.dir/src/function.cpp.o CMakeFiles/cpp.dir/src/generation.cpp.o CMakeFiles/cpp.dir/src/geometry.cpp.o CMakeFiles/cpp.dir/src/graph.cpp.o CMakeFiles/cpp.dir/src/log.cpp.o CMakeFiles/cpp.dir/src/math.cpp.o CMakeFiles/cpp.dir/src/mesh.cpp.o CMakeFiles/cpp.dir/src/multistage.cpp.o CMakeFiles/cpp.dir/src/ts.cpp.o CMakeFiles/cpp.dir/src/io.cpp.o CMakeFiles/cpp.dir/src/la.cpp.o CMakeFiles/cpp.dir/src/nls.cpp.o CMakeFiles/cpp.dir/src/refinement.cpp.o CMakeFiles/cpp.dir/src/MPICommWrapper.cpp.o /usr/bin/ld: /tmp/ccofV1SZ.ltrans32.ltrans.o: .symtab local symbol at index 214 (>= sh_info of 34) /usr/bin/ld: /tmp/ccofV1SZ.ltrans32.ltrans.o: error adding symbols: bad value collect2: error: ld returned 1 exit status $ g++ -flto -shared dolfin.ii parameter.ii adaptivity.ii ale.ii common.ii fem.ii function.ii generation.ii geometry.ii graph.ii log.ii math.ii mesh.ii multistage.ii ts.ii io.ii la.ii nls.ii refinement.ii MPICommWrapper.ii /tmp/ccraiNyo.ltrans9.ltrans.o: in function `std::__exception_ptr::exception_ptr::operator=(std::__exception_ptr::exception_ptr&&)': :(.text+0x290): relocation truncated to fit: R_MIPS_CALL16 against `std::__exception_ptr::exception_ptr::~exception_ptr()@@CXXABI_1.3.3' /tmp/ccraiNyo.ltrans9.ltrans.o: in function `std::__cxx11::to_string(int)': :(.text+0x414): relocation truncated to fit: R_MIPS_CALL16 against `std::__cxx11::basic_string, std::allocator >::basic_string(unsigned long, char, std::allocator const&)@@GLIBCXX_3.4.21' :(.text+0x42c): relocation truncated to fit: R_MIPS_CALL16 against `std::allocator::~allocator()@@GLIBCXX_3.4' :(.text+0x498): relocation truncated to fit: R_MIPS_CALL16 against `std::allocator::~allocator()@@GLIBCXX_3.4' :(.text+0x4b0): relocation truncated to fit: R_MIPS_CALL16 against `_Unwind_Resume@@GCC_3.0' :(.text+0x4e0): relocation truncated to fit: R_MIPS_CALL16 against `_Unwind_Resume@@GCC_3.0' /tmp/ccraiNyo.ltrans9.ltrans.o: in function `std::__cxx11::to_string(unsigned long)': :(.text+0x584): relocation truncated to fit: R_MIPS_CALL16 against `std::__cxx11::basic_string, std::allocator >::basic_string(unsigned long, char, std::allocator const&)@@GLIBCXX_3.4.21' :(.text+0x598): relocation truncated to fit: R_MIPS_CALL16 against `std::allocator::~allocator()@@GLIBCXX_3.4' :(.text+0x5c8): relocation truncated to fit: R_MIPS_CALL16 against `std::__cxx11::basic_string, std::allocator >::size() const@@GLIBCXX_3.4.21' :(.text+0x610): relocation truncated to fit: R_MIPS_CALL16 against `std::allocator::~allocator()@@GLIBCXX_3.4' :(.text+0x628): additional relocation overflows omitted from the output collect2: error: ld returned 1 exit status $ g++ -flto -shared dolfin.ii parameter.ii adaptivity.ii ale.ii common.ii fem.ii function.ii generation.ii geometry.ii graph.ii log.ii math.ii mesh.ii multistage.ii ts.ii io.ii la.ii nls.ii refinement.ii MPICommWrapper.ii -mxgot $ g++ -flto -shared CMakeFiles/cpp.dir/src/dolfin.cpp.o CMakeFiles/cpp.dir/src/parameter.cpp.o CMakeFiles/cpp.dir/src/adaptivity.cpp.o CMakeFiles/cpp.dir/src/ale.cpp.o CMakeFiles/cpp.dir/src/common.cpp.o CMakeFiles/cpp.dir/src/fem.cpp.o CMakeFiles/cpp.dir/src/function.cpp.o CMakeFiles/cpp.dir/src/generation.cpp.o CMakeFiles/cpp.dir/src/geometry.cpp.o CMakeFiles/cpp.dir/src/graph.cpp.o CMakeFiles/cpp.dir/src/log.cpp.o CMakeFiles/cpp.dir/src/math.cpp.o CMakeFiles/cpp.dir/src/mesh.cpp.o CMakeFiles/cpp.dir/src/multistage.cpp.o CMakeFiles/cpp.dir/src/ts.cpp.o CMakeFiles/cpp.dir/src/io.cpp.o CMakeFiles/cpp.dir/src/la.cpp.o CMakeFiles/cpp.dir/src/nls.cpp.o CMakeFiles/cpp.dir/src/refinement.cpp.o CMakeFiles/cpp.dir/src/MPICommWrapper.cpp.o -flto-partition=none $ Adding -mxgot to compiler and linker flags of a normal LTO build does not work, but -flto-partition=none during linking is a workaround.
[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97787 --- Comment #7 from Adrian Bunk --- (In reply to Richard Biener from comment #6) > I see. Still GCC or GAS produces a bogus object file (the original linker > error). It might be the new problem is an entirely different one? It looks > more and more like a target problem to me. My guess would be that the situations where -mxgot is required on 64bit MIPS are not (no longer?) handled properly with LTO. Note that when compiling from precompiled sources the linker also exits with an error, the main difference in that case is that the correct "relocation truncated to fit" error message is not output in the LTO case. More worrisome is that adding -mxgot to compiler and linker flags did not fix it in the LTO case.
[Bug target/104713] New: gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713 Bug ID: 104713 Summary: gcc does not reject -march=i686 -fcf-protection Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bunk at stusta dot de Target Milestone: --- To support the Geode in OLPC, the toolchain definition of i686 does include CMOV but it does not include multi-byte NOPs. https://bugs.debian.org/1004894 is due to autodetection for -fcf-protection that incorrectly succeeds with -march=i686. The bug is likely in https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-options.cc;h=805539364108eee07f5bda527acd6f39f3f7bf95;hb=HEAD#l2929 A similar problem in a different place was bug 84148. Testcase: $ touch test.c $ gcc -m32 -march=i586 -fcf-protection -c test.c cc1: error: ‘-fcf-protection’ is not compatible with this target $ gcc -m32 -march=i686 -fcf-protection -c test.c $
[Bug target/104713] gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713 --- Comment #2 from Adrian Bunk --- (In reply to Andrew Pinski from comment #1) > Is OLPC really still around? I thought it died when Google came out with > their chrome books. Sorry for being unclear, this is the historical reason why the binutils/gcc definition of i686 does not include multi-byte NOPs. While all 32bit x86 hardware is pretty dated in the year 2022, there is still a surprisingly large number of users of 32bit x86 including like in the case of this Debian bug on a (likely non-OLPC) Geode. The Debian i386 port has the toolchain configured for i686, and it is therefore a problem that due to this gcc bug an autoconf test for -fcf-protection succeeds.
[Bug target/104713] gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713 --- Comment #4 from Adrian Bunk --- (In reply to Jakub Jelinek from comment #3) > Just build for those as -march=i586. There is no "for those" in Debian. There is one build of all packages for one i386 Debian release architecture. Building the Debian i386 architecture with -march=i586 would also remove CMOV support. > i686 is what is used as the supported lowest > common denominator of 32-bit code. This is not true. The lowest common denominator of 32-bit x86 code on Linux is -march=i486, since the 486 is the lowest supported CPU in the kernel. Distributions usually use various baselines higher than 486 for their 32-bit x86 ports. E.g. for distributions dropping support for actual 32-bit hardware (keeping only multiarch/multilib support), using -march=x86-64 (or whatever higher they are using for their 64bit x86) might make more sense since it also brings MMX/SSE/SSE2 which are not in -march=i686 (this also allows using SSE instead of the x87 FPU with its excess precision oddity). > preventing -fcf-protection with > -march=i686 would be a really bad idea, that would basically prevent all of > CET protection for 32-bit code, The toolchain emitting instructions not supported by the selected target is also a really bad idea. gcc rejecting -fcf-protection for < 686 indicates that this option was not intended to enable emitting instructions not already supported by the -march setting. The proper solution might be a -mmultibyte-nops option?
[Bug target/102602] New: [10/11/12 Regression] 32bit mips: Error: branch out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102602 Bug ID: 102602 Summary: [10/11/12 Regression] 32bit mips: Error: branch out of range Product: gcc Version: 10.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bunk at stusta dot de Target Milestone: --- Created attachment 51552 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51552&action=edit Preprocessed sources With a command like /usr/lib/gcc/mipsel-linux-gnu/10/cc1plus -fpreprocessed Options.ii -mel -quiet -dumpbase Options.ii -march=mips32r2 -auxbase Options -O2 -version -o /tmp/cccmq2Yu.s the attached file from a failed build of https://tracker.debian.org/pkg/kstars generates code the assembler rejects. $ g++-10 -c -O2 Options.ii /tmp/ccecXwRM.s: Assembler messages: /tmp/ccecXwRM.s:4908: Error: branch out of range /tmp/ccecXwRM.s:54845: Error: branch out of range /tmp/ccecXwRM.s:54868: Error: branch out of range $ For working and known broken gcc versions, Debian revisions and date they were taken from the upstream branch are: Working: 10.2.1-6 (git 20210110 from the gcc-10 branch) Broken: 10.3.0-11 (git 20210918 from the gcc-10 branch) 11.2.0-8 (git 20210924 from the gcc-11 branch) 20210909-1 (git 20210918 from master)
[Bug target/102602] [10/11/12 Regression] 32bit mips: Error: branch out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102602 --- Comment #1 from Adrian Bunk --- Created attachment 51553 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51553&action=edit Generated assembler
[Bug target/104713] gcc does not reject -march=i686 -fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713 --- Comment #6 from Adrian Bunk --- (In reply to James Addison from comment #5) > Could the findings indicate that there are two bugs here? > > - The Geode LX target capable of supporting fcf-protection but GCC-11 > currently rejects that architecture and flag combination The problem is the opposite.
[Bug driver/81358] libatomic not automatically linked with C11 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 --- Comment #15 from Adrian Bunk --- (In reply to Tobias Burnus from comment #11) > RFC draft patch – also to solve an offload problem with atomic and nvptx > libgomp: > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/556297.html > See reply for what still needs to be done (esp. related to building > libraries + testsuite). Was there any reason why this was stalled? More and more packages in Debian need manual addition of libatomic on some 32bit vintage architectures (armv5/m68k/mips/powerpc/sh4) due to this, which is a pain. Is the only issue that noone has addressed the comments in the reply on the mailing list, or have there also been other problems?
[Bug target/116122] [14 Regression]: __FLT16_MAX__ is defined even with -mno-sse2 on 32-bit x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116122 Adrian Bunk changed: What|Removed |Added CC||bunk at stusta dot de --- Comment #3 from Adrian Bunk --- This change was apparently intentional in Bug#109504 and I can understand the rationale there, but it can break existing compile time detection of _Float16 support (as Qt does). The relevant part in the Qt sources is: #if defined(__STDCPP_FLOAT16_T__) # define QFLOAT16_IS_NATIVE1 using NativeFloat16Type = std::float16_t; #elif defined(Q_CC_CLANG) && defined(__FLT16_MAX__) && 0 // disabled due to https://github.com/llvm/llvm-project/issues/56963 # define QFLOAT16_IS_NATIVE1 using NativeFloat16Type = decltype(__FLT16_MAX__); #elif defined(Q_CC_GNU_ONLY) && defined(__FLT16_MAX__) # define QFLOAT16_IS_NATIVE1 # ifdef __ARM_FP16_FORMAT_IEEE using NativeFloat16Type = __fp16; # else using NativeFloat16Type = _Float16; # endif #else # define QFLOAT16_IS_NATIVE0 using NativeFloat16Type = void; #endif With gcc 14 this needs -#elif defined(Q_CC_GNU_ONLY) && defined(__FLT16_MAX__) +#elif defined(Q_CC_GNU_ONLY) && defined(__FLT16_MAX__) && (!defined(__i386__) || defined(__SSE2__)) or some other similar change to check for SSE2. If this gcc change will not be reverted, it should be documented as a change in the gcc 14 "Changes" and "Porting to" documentation.
[Bug middle-end/119015] [14/15 Regression] g++ -O2 uses huge amounts of time and memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119015 --- Comment #3 from Adrian Bunk --- (In reply to Richard Biener from comment #1) > given -Os isn't affected this is likely triggered by inlining (-fno-inline > brings down compile-time again). I can confirm that this is the case on armhf (~ 20% time increase -Os -> -O2 -fno-inline).
[Bug c++/119015] New: [14 Regression] g++ -O2 uses huge amounts of time and memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119015 Bug ID: 119015 Summary: [14 Regression] g++ -O2 uses huge amounts of time and memory Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bunk at stusta dot de Target Milestone: --- Created attachment 60585 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60585&action=edit preprocessed amd64 source KDE Marble failed to build in Debian on armhf with "virtual memory exhausted: Cannot allocate memory", and of all files the only one where gcc runs out of address space is the source of the "About" dialog. While running out of address space is specific to architecture and compile flags, the issue itself does not seem to be. This also indicates that this is not an infinite loop, it's just using a huge amount of time and memory. On armhf the build time difference is more like a factor of 50, but the issue is also visible on amd64: $ time g++-14 MarbleAboutDialog.cpp.ii -c -Os real0m2.694s user0m2.665s sys 0m0.024s $ time g++-14 MarbleAboutDialog.cpp.ii -c -O2 real0m18.784s user0m18.683s sys 0m0.072s $ With gcc 13 both -Os and -O2 are fast (~ 50% time increase -Os -> -O2 on amd64).
[Bug ada/118939] [14 Regression] ada: executable segfaults on arm-linux-gnueabi when assigning an access to controlled type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939 Adrian Bunk changed: What|Removed |Added CC||bunk at stusta dot de --- Comment #6 from Adrian Bunk --- (In reply to Matthias Klose from comment #5) > yes, there's the Debian patchset, but I'm usually not applying any > code-modifying patches on my own. Applying patch 0004-Ada-merge-all-timeval-and-timespec-definitions-and-c.diff patching file src/gcc/ada/Makefile.rtl Hunk #3 succeeded at 2850 (offset 7 lines). patching file src/gcc/ada/cal.c patching file src/gcc/ada/gcc-interface/Makefile.in patching file src/gcc/ada/libgnarl/a-exetim__posix.adb patching file src/gcc/ada/libgnarl/s-linux.ads patching file src/gcc/ada/libgnarl/s-linux__alpha.ads patching file src/gcc/ada/libgnarl/s-linux__android.ads patching file src/gcc/ada/libgnarl/s-linux__hppa.ads patching file src/gcc/ada/libgnarl/s-linux__loongarch.ads patching file src/gcc/ada/libgnarl/s-linux__mips.ads patching file src/gcc/ada/libgnarl/s-linux__riscv.ads patching file src/gcc/ada/libgnarl/s-linux__sparc.ads patching file src/gcc/ada/libgnarl/s-linux__x32.ads patching file src/gcc/ada/libgnarl/s-osinte__aix.adb patching file src/gcc/ada/libgnarl/s-osinte__aix.ads patching file src/gcc/ada/libgnarl/s-osinte__android.adb patching file src/gcc/ada/libgnarl/s-osinte__android.ads patching file src/gcc/ada/libgnarl/s-osinte__darwin.adb patching file src/gcc/ada/libgnarl/s-osinte__darwin.ads patching file src/gcc/ada/libgnarl/s-osinte__dragonfly.adb patching file src/gcc/ada/libgnarl/s-osinte__dragonfly.ads patching file src/gcc/ada/libgnarl/s-osinte__freebsd.adb patching file src/gcc/ada/libgnarl/s-osinte__freebsd.ads patching file src/gcc/ada/libgnarl/s-osinte__gnu.adb patching file src/gcc/ada/libgnarl/s-osinte__gnu.ads patching file src/gcc/ada/libgnarl/s-osinte__hpux-dce.adb patching file src/gcc/ada/libgnarl/s-osinte__hpux-dce.ads patching file src/gcc/ada/libgnarl/s-osinte__hpux.ads patching file src/gcc/ada/libgnarl/s-osinte__kfreebsd-gnu.ads patching file src/gcc/ada/libgnarl/s-osinte__linux.ads patching file src/gcc/ada/libgnarl/s-osinte__lynxos178.adb patching file src/gcc/ada/libgnarl/s-osinte__lynxos178e.ads patching file src/gcc/ada/libgnarl/s-osinte__posix.adb patching file src/gcc/ada/libgnarl/s-osinte__qnx.adb patching file src/gcc/ada/libgnarl/s-osinte__qnx.ads patching file src/gcc/ada/libgnarl/s-osinte__rtems.adb patching file src/gcc/ada/libgnarl/s-osinte__rtems.ads patching file src/gcc/ada/libgnarl/s-osinte__solaris.adb patching file src/gcc/ada/libgnarl/s-osinte__solaris.ads patching file src/gcc/ada/libgnarl/s-osinte__vxworks.adb patching file src/gcc/ada/libgnarl/s-osinte__vxworks.ads patching file src/gcc/ada/libgnarl/s-osinte__x32.adb patching file src/gcc/ada/libgnarl/s-qnx.ads patching file src/gcc/ada/libgnarl/s-taprop__hpux-dce.adb patching file src/gcc/ada/libgnarl/s-taprop__solaris.adb patching file src/gcc/ada/libgnarl/s-taprop__vxworks.adb patching file src/gcc/ada/libgnarl/s-tpopmo.adb patching file src/gcc/ada/libgnat/a-calcon.adb patching file src/gcc/ada/libgnat/a-calcon.ads patching file src/gcc/ada/libgnat/a-calend.adb patching file src/gcc/ada/libgnat/a-calend.ads patching file src/gcc/ada/libgnat/g-calend.adb patching file src/gcc/ada/libgnat/g-calend.ads patching file src/gcc/ada/libgnat/g-socket.adb patching file src/gcc/ada/libgnat/g-socthi.adb patching file src/gcc/ada/libgnat/g-socthi__vxworks.adb patching file src/gcc/ada/libgnat/g-sothco.ads patching file src/gcc/ada/libgnat/g-spogwa.adb patching file src/gcc/ada/libgnat/s-c_time.adb patching file src/gcc/ada/libgnat/s-c_time.ads patching file src/gcc/ada/libgnat/s-optide.adb patching file src/gcc/ada/libgnat/s-osprim__darwin.adb patching file src/gcc/ada/libgnat/s-osprim__posix.adb patching file src/gcc/ada/libgnat/s-osprim__posix2008.adb patching file src/gcc/ada/libgnat/s-osprim__rtems.adb patching file src/gcc/ada/libgnat/s-osprim__solaris.adb patching file src/gcc/ada/libgnat/s-osprim__unix.adb patching file src/gcc/ada/libgnat/s-osprim__x32.adb patching file src/gcc/ada/libgnat/s-parame.ads patching file src/gcc/ada/libgnat/s-parame__hpux.ads patching file src/gcc/ada/libgnat/s-parame__posix2008.ads patching file src/gcc/ada/libgnat/s-parame__vxworks.ads patching file src/gcc/ada/s-oscons-tmplt.c Applying patch 0009-Ada-select-64-bits-time-functions-from-GNU-libc-when.diff patching file src/gcc/ada/libgnarl/a-exetim__posix.adb patching file src/gcc/ada/libgnarl/s-osinte__gnu.ads patching file src/gcc/ada/libgnarl/s-osinte__kfreebsd-gnu.ads patching file src/gcc/ada/libgnarl/s-osinte__linux.ads patching file src/gcc/ada/libgnat/g-spogwa.adb patching file src/gcc/ada/libgnat/s-osprim__posix.adb patching file src/gcc/ada/libgnat/s-osprim__posix2008.adb patching file src/gcc/ada/s-oscons-tmplt.c Applying patch pr7
[Bug ada/118939] [14 Regression] ada: executable segfaults on arm-linux-gnueabi when assigning an access to controlled type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118939 --- Comment #9 from Adrian Bunk --- (In reply to Adrian Bunk from comment #6) >"ada: GNAT Calendar Support for > 64-bit Unix Time" reverted (which is on the gcc 14 branch). Sorry, I was looking at the wrong branch. This is not in gcc 14.
