[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 wangzheyu tony.wang at arm dot com changed: What|Removed |Added CC||tony.wang at arm dot com --- Comment #64 from wangzheyu tony.wang at arm dot com --- Fix: Index: gcc/tree-ssa-loop-ivopts.c === --- gcc/tree-ssa-loop-ivopts.c (revision 213050) +++ gcc/tree-ssa-loop-ivopts.c (working copy) @@ -1704,6 +1704,8 @@ may_be_unaligned_p (tree ref, tree step) return false; unsigned int align = TYPE_ALIGN (TREE_TYPE (ref)); + if (GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))) align) +align = GET_MODE_ALIGNMENT (TYPE_MODE (TREE_TYPE (ref))); unsigned HOST_WIDE_INT bitpos; unsigned int ref_align; can you test and apply that patch? Also run into a similar regression on arm target, which will generate unaligned memory access on target which don't support unaligned data access. This patch does fix this regression. Thx
[Bug rtl-optimization/62030] wrong code due to ifcvt merging two stores which have different aliasing sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #2 from vries at gcc dot gnu.org --- I think the test-case is reading an undefined value from n-next, but that's easy enough to fix with an intializer for node. Taking the tentative patch from PR62004, ( https://gcc.gnu.org/bugzilla/attachment.cgi?id=33242action=diff ), with this patch added prevents the if-conversion in this case: ... @@ -2504,7 +2534,9 @@ noce_process_if_block (struct noce_if_info *if_info) if (! insn_b || insn_b != last_active_insn (else_bb, FALSE) || (set_b = single_set (insn_b)) == NULL_RTX - || ! rtx_equal_p (x, SET_DEST (set_b))) + || ! (rtx_equal_p (x, SET_DEST (set_b)) +(GET_CODE (x) != MEM + || mem_interchangeable_p (x, SET_DEST (set_b return FALSE; } else ...
[Bug rtl-optimization/62030] wrong code due to ifcvt merging two stores which have different aliasing sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to vries from comment #2) I think the test-case is reading an undefined value from n-next, but that's easy enough to fix with an intializer for node. Since node is a global variable, it is zero initialized so there is no reading from an uninitialized area.
[Bug rtl-optimization/62004] dead type-unsafe load replaces type-safe load
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62004 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Richard Biener from comment #1) Heh, interesting set of events ;) I have a store version that fires on mips64 with a modified testcase too, see bug 62030.
[Bug c/62031] New: Different results between O2 and O3 for gcc-4.7.2-5 (Debian 4.7.2-5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031
Bug ID: 62031
Summary: Different results between O2 and O3 for gcc-4.7.2-5
(Debian 4.7.2-5)
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tomasz.ostaszewski at interia dot pl
Created attachment 33255
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33255action=edit
problematic code, preprocessed
Hello,
My little program produces different results when compiled with O2 and O3
options. Turning on/off '-fstrict-aliasing' does not make any difference.
#include stdlib.h
#include stdio.h
#define NUM_OF_STATES 4
typedef unsigned int entry_t[2];
typedef struct entries_item { entry_t metricEntries_[0]; } entries_item_t;
void test_00(size_t numOfStates, entries_item_t* p_bm, const unsigned int*
polyArray,
size_t polyArraySize) {
size_t idx;
unsigned int hlp0, hlp1;
for (idx = 0; idx numOfStates; ++idx) {
size_t idy;
hlp0 = (idx 1) | 0x00;
hlp1 = (idx 1) | 0x01;
p_bm-metricEntries_[idx][0] = 0;
p_bm-metricEntries_[idx][1] = 0;
for (idy = 0; idy polyArraySize; ++idy) {
p_bm-metricEntries_[idx][0] |= __builtin_parity(hlp0
polyArray[idy]) idy;
p_bm-metricEntries_[idx][1] |= __builtin_parity(hlp1
polyArray[idy]) idy;
#if 0
fprintf(stderr, %4.4u : %8.8x %8.8x\n, __LINE__,
p_bm-metricEntries_[idx][0], p_bm-metricEntries_[idx][1]);
#endif
}
}
fprintf(stderr, %4.4u :, __LINE__);
for (idx = 0; idx numOfStates; ++idx) {
fprintf(stderr, %2u:%2u , p_bm-metricEntries_[idx][0],
p_bm-metricEntries_[idx][1]);
}
fprintf(stderr, \n);
}
int main(__attribute__((unused)) int argc, __attribute__((unused)) char** argv)
{
unsigned int polyArray[] = { 0x07, 0x05 };
entries_item_t* pBranchMetrics;
pBranchMetrics = malloc(sizeof(entry_t) * NUM_OF_STATES);
test_00(NUM_OF_STATES, pBranchMetrics, polyArray, sizeof(polyArray) /
sizeof(polyArray[0]));
free(pBranchMetrics);
return 0;
}
When compiled with O2 produces a correct result:
0029 : 0: 3 1: 2 3: 0 2: 1
When compiled with O3 produces an incorrect result:
0029 : 0: 2 0: 2 2: 0 2: 0
Suprisingly, changing #if 0 to #if 1 forces program to produce correct results.
Also adding the 'static' keyword before 'void test_00' also changes program to
produce a correct result. Also, changing zero sized array to fixed array (size
1) also makes the problem go away.
Valgrind does not report any violations in either case (O2/O3). Both gcc-4.6.3
and clang 3.5.0 produce correct results with O3.
problematic gcc version:
$ gcc --verbose
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.7/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-5'
--with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object
--enable-plugin --enable-objc-gc --enable-targets=all --with-arch-32=i586
--with-tune=generic --enable-checking=release --build=i486-linux-gnu
--host=i486-linux-gnu --target=i486-linux-gnu
Thread model: posix
gcc version 4.7.2 (Debian 4.7.2-5)
Assembler:
$as --version
GNU assembler (GNU Binutils for Debian) 2.22
Copyright 2011 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `i486-linux-gnu'.
System:
Linux debian-vm-x86 3.2.0-4-686-pae #1 SMP Debian 3.2.60-1+deb7u3 i686
GNU/Linux
LibC:
/lib/i386-linux-gnu/libc-2.13.so
GNU C Library (Debian EGLIBC 2.13-38+deb7u3) stable release version 2.13, by
Roland McGrath et al.
Copyright (C) 2011 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.
Compiled by GNU CC version 4.4.7.
Compiled on a Linux 3.2.57 system on 2014-07-09.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
http://www.debian.org/Bugs/.
[Bug rtl-optimization/62030] wrong code due to ifcvt merging two stores which have different aliasing sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030 --- Comment #4 from vries at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #3) (In reply to vries from comment #2) I think the test-case is reading an undefined value from n-next, but that's easy enough to fix with an intializer for node. Since node is a global variable, it is zero initialized so there is no reading from an uninitialized area. Ah, right, I thought that only applied to static. Thanks for setting that straight.
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 --- Comment #15 from ktkachov at gcc dot gnu.org --- I can't reproduce this with current trunk and 4.9.1. What exact compiler version and options did you use? I used -O2 -mgeneral-regs-only on an aarch64-none-elf compiler gcc version 4.10.0 20140805
[Bug tree-optimization/62032] New: FAIL: vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032 Bug ID: 62032 Summary: FAIL: vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amker.cheng at gmail dot com Created attachment 33256 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33256action=edit tarball of dump files Hi, I monitored below failures on both aarch64-none-elf and arm-none-eabi. FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none FAIL: gcc.c-torture/execute/builtins/vsnprintf-chk.c execution, -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects It's first introduced by r213585, but I am not sure if it's revealed by the change. The corresponding (goodbogus) dump files are attached. arm-none-eabi is configured like: ../gcc/configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=arm-none-eabi --prefix=.../trunk-orig/target/ --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-sysroot=.../trunk-orig/target/arm-none-eabi --with-host-libstdcxx=... --with-mode=thumb --with-arch=armv7-m --disable-multilib --enable-lto --enable-languages=c,c++,lto Thanks.
[Bug c/62031] Different results between O2 and O3 for gcc-4.7.2-5 (Debian 4.7.2-5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031
Mikael Pettersson mikpelinux at gmail dot com changed:
What|Removed |Added
CC||mikpelinux at gmail dot com
--- Comment #1 from Mikael Pettersson mikpelinux at gmail dot com ---
I can reproduce with 4.8.3 and 4.9.1. -fsanitize={address,undefined} finds
nothing to complain about.
[Bug tree-optimization/62032] FAIL: vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032 --- Comment #1 from bin.cheng amker.cheng at gmail dot com --- Only fail with lto options.
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 --- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Aug 6 08:40:19 2014 New Revision: 213652 URL: https://gcc.gnu.org/viewcvs?rev=213652root=gccview=rev Log: PR rtl-optimization/61801 * gcc.target/i386/pr61801.c: Rewritten. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr61801.c
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Aug 6 08:44:05 2014 New Revision: 213653 URL: https://gcc.gnu.org/viewcvs?rev=213653root=gccview=rev Log: PR rtl-optimization/61801 * gcc.target/i386/pr61801.c: Rewritten. Modified: branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr61801.c
[Bug rtl-optimization/61801] sched2 miscompiles syscall sequence with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801 --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Aug 6 08:50:12 2014 New Revision: 213654 URL: https://gcc.gnu.org/viewcvs?rev=213654root=gccview=rev Log: PR rtl-optimization/61801 * gcc.target/i386/pr61801.c: Rewritten. Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/gcc.target/i386/pr61801.c
[Bug tree-optimization/62032] FAIL: vsnprintf-chk.c execution, -O2 -flto -fno-use-linker-plugin -flto-partition=none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62032 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.9.1 Keywords||lto Last reconfirmed||2014-08-06 CC||ktkachov at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |4.10.0 Known to fail||4.10.0 --- Comment #2 from ktkachov at gcc dot gnu.org --- confirmed, I've noticed this as well. This seems to appear with LTO
[Bug tree-optimization/62031] [4.8/4.9/4.10 Regression] Different results between O2 and O2 -fpredictive-commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.3.4 Keywords||wrong-code Last reconfirmed||2014-08-06 Component|c |tree-optimization CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Summary|Different results between |[4.8/4.9/4.10 Regression] |O2 and O3 for gcc-4.7.2-5 |Different results between |(Debian 4.7.2-5)|O2 and O2 ||-fpredictive-commoning Target Milestone|--- |4.8.4 Known to fail||4.7.4, 4.9.1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- -O2 -fpredictive-commoning fails as well (thus culprit found).
[Bug lto/62026] [4.9/4.10 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.9.2
[Bug tree-optimization/62033] New: okteta 4.13.97 error at -O3 -D_FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62033 Bug ID: 62033 Summary: okteta 4.13.97 error at -O3 -D_FORTIFY_SOURCE=2 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amodra at gmail dot com Created attachment 33257 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33257action=edit delta+hand reduced testcase Found on powerpc64le with 4.9, and then with x86_64 4.10.0 20140727 Due to __warn_memset_zero_len reference in object, we get .../bytearraymodel_p.o: In function `memset': .../bits/string3.h:81: warning: memset used with constant zero length parameter; this could be due to transposed parameters collect2: error: ld returned 1 exit status Compile testcase with -O3 -fvisibility=hidden -Werror=return-type -fvisibility-inlines-hidden
[Bug tree-optimization/62033] okteta 4.13.97 error at -O3 -D_FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62033 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- I don't see a bug here as there is one case where addSize can return 0 and with jump threading and basic block copying, we get a zero size passed to memset.
[Bug rtl-optimization/62030] wrong code due to ifcvt merging two stores which have different aliasing sets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62030 --- Comment #5 from vries at gcc dot gnu.org --- Created attachment 33258 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33258action=edit Updated tentative patch for if-conversion, including fix for pr62030 Updated tentative patch for if-conversion, including fix for pr62030
[Bug tree-optimization/62033] okteta 4.13.97 error at -O3 -D_FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62033 --- Comment #2 from Alan Modra amodra at gmail dot com --- I can see where you're coming from Andrew, but what is disconcerting about this is that the _FORTIFY_SOURCE warning is plainly incorrect here. How is one supposed to write a string.h memset macro using __builtin_constant_p() to provide a useful _FORTIFY_SOURCE warning, in the face of this sort of optimisation? Users are going to see this as __builtin_constant_p() is broken.
[Bug lto/49571] -flto -Wl,--as-needed drops needed libraries with GNU ld and linker plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49571 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||amodra at gmail dot com Resolution|--- |WORKSFORME --- Comment #3 from Alan Modra amodra at gmail dot com --- Works with BFD ld too.
[Bug lto/52401] lto can't handle ld script
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52401 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||amodra at gmail dot com Resolution|--- |WORKSFORME --- Comment #4 from Alan Modra amodra at gmail dot com --- Works with mainline ld. Has been fixed for quite a while.
[Bug tree-optimization/62031] [4.8/4.9/4.10 Regression] Different results between O2 and O2 -fpredictive-commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r175704.
[Bug lto/62034] New: ICE for big statically initialized arrays compiled with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034
Bug ID: 62034
Summary: ICE for big statically initialized arrays compiled
with LTO
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: enkovich.gnu at gmail dot com
Created attachment 33259
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33259action=edit
Reproducer
I get ICE when try to compile tests with big amount of statically initialized
data.
gcc --version
gcc (GCC) 4.10.0 20140806 (experimental)
Copyright (C) 2014 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.
gcc -flto test.c
gcc: internal compiler error: Segmentation fault (program lto1)
0x405c80 execute
../../gcc-ref/gcc/gcc.c:2900
0x409fe9 do_spec_1
../../gcc-ref/gcc/gcc.c:4704
0x40d475 process_brace_body
../../gcc-ref/gcc/gcc.c:5987
0x40d2b1 handle_braces
../../gcc-ref/gcc/gcc.c:5901
0x40bf9d do_spec_1
../../gcc-ref/gcc/gcc.c:5358
0x40d475 process_brace_body
../../gcc-ref/gcc/gcc.c:5987
0x40d2b1 handle_braces
../../gcc-ref/gcc/gcc.c:5901
0x40bf9d do_spec_1
../../gcc-ref/gcc/gcc.c:5358
0x40c38c do_spec_1
../../gcc-ref/gcc/gcc.c:5473
0x40d475 process_brace_body
../../gcc-ref/gcc/gcc.c:5987
0x40d2b1 handle_braces
../../gcc-ref/gcc/gcc.c:5901
0x40bf9d do_spec_1
../../gcc-ref/gcc/gcc.c:5358
0x409664 do_spec_2
../../gcc-ref/gcc/gcc.c:4405
0x409582 do_spec(char const*)
../../gcc-ref/gcc/gcc.c:4372
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
lto-wrapper: fatal error: gcc-ref-build/bin/gcc returned 4 exit status
compilation terminated.
/usr/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
Debugger shows that problem appears when lto_input_tree tries to dig through a
bunch of SCC entries in input stream. Each SCC entry cause two new functions
(lto_input_tree and lto_input_tree_1) in the call stack. With many consequent
SCC entries stack may grow too much (in my case compiler segfaulted with ~600
000 entries in the call stack).
Attached test has a statically initialized array with a million elements.
Bigger data set may be required to break the compiler if you use increased
stack size.
Problem appeared after this commit:
https://gcc.gnu.org/ml/gcc-cvs/2014-07/msg00291.html
Following patch removing recursion helps me to compile my tests:
diff --git a/gcc/lto-streamer-in.c b/gcc/lto-streamer-in.c
index 698f926..25657da 100644
--- a/gcc/lto-streamer-in.c
+++ b/gcc/lto-streamer-in.c
@@ -1345,7 +1345,16 @@ lto_input_tree_1 (struct lto_input_block *ib, struct
data_in *data_in,
tree
lto_input_tree (struct lto_input_block *ib, struct data_in *data_in)
{
- return lto_input_tree_1 (ib, data_in, streamer_read_record_start (ib), 0);
+ enum LTO_tags tag;
+
+ /* Skip SCC entries. */
+ while ((tag = streamer_read_record_start (ib)) == LTO_tree_scc)
+{
+ unsigned len, entry_len;
+ lto_input_scc (ib, data_in, len, entry_len);
+}
+
+ return lto_input_tree_1 (ib, data_in, tag, 0);
}
Did not fully test this patch yet.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #65 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #61 from Eric Botcazou ebotcazou at gcc dot gnu.org --- [...] can you test and apply that patch? I think that it needs to be applied on both mainline and 4.9 branch then. Testing on the 4.9 branch also completed successfully, so from my POV the patch is good to go in both mainline and branch. Thanks. Rainer
[Bug tree-optimization/62031] [4.8/4.9/4.10 Regression] Different results between O2 and O2 -fpredictive-commoning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62031 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Mine then.
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #66 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Aug 6 11:41:13 2014 New Revision: 213661 URL: https://gcc.gnu.org/viewcvs?rev=213661root=gccview=rev Log: 2014-08-06 Richard Biener rguent...@suse.de PR tree-optimization/61320 * tree-ssa-loop-ivopts.c (may_be_unaligned_p): Properly handle misaligned loads. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-ivopts.c
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 --- Comment #67 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Aug 6 11:42:22 2014 New Revision: 213662 URL: https://gcc.gnu.org/viewcvs?rev=213662root=gccview=rev Log: 2014-08-06 Richard Biener rguent...@suse.de PR tree-optimization/61320 * tree-ssa-loop-ivopts.c (may_be_unaligned_p): Properly handle misaligned loads. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-loop-ivopts.c
[Bug bootstrap/61320] [4.10 regression] ICE in jcf-parse.c:1622 (parse_class_file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61320 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||4.10.0, 4.8.3, 4.9.2 Resolution|--- |FIXED Target Milestone|4.10.0 |4.9.2 Known to fail|4.8.3 |4.9.1 --- Comment #68 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/62021] ICE in verify_gimple_assign_single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62021 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- The problem is that get_vectype_for_scalar_type_and_size for pointers just returns vectors of pointer sized integers instead of vectors of pointers. So, either we need to VCE it, or change the simd_clones to instead use vectors of pointer sized integers instead of vectors of pointers for the arguments.
[Bug target/61535] [4.10 Regression] SIGBUS in gen_group_rtx compiling 64-bit gcc.dg/vect/vect-singleton_1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61535 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- I'm seeing the same on the 4.7, 4.8, and 4.9 branches. Also reproducible in i386-pc-solaris2.11 x sparc-solaris2.11 and x86_64-unknown-linux-gnu crosses. Rainer
[Bug lto/62034] ICE for big statically initialized arrays compiled with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-08-06 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Ah, the issue is that the tail-recursion doesn't work. Mine.
[Bug lto/62034] ICE for big statically initialized arrays compiled with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org ---
Better patch:
Index: gcc/lto-streamer-in.c
===
--- gcc/lto-streamer-in.c (revision 213660)
+++ gcc/lto-streamer-in.c (working copy)
@@ -1325,13 +1325,17 @@ lto_input_tree_1 (struct lto_input_block
}
else if (tag == LTO_tree_scc)
{
- unsigned len, entry_len;
-
- /* Input and skip the SCC. */
- lto_input_scc (ib, data_in, len, entry_len);
+ /* Input and skip SCCs. */
+ do
+ {
+ unsigned len, entry_len;
+ lto_input_scc (ib, data_in, len, entry_len);
+ tag = streamer_read_record_start (ib);
+ }
+ while (tag == LTO_tree_scc);
/* Recurse. */
- return lto_input_tree (ib, data_in);
+ return lto_input_tree_1 (ib, data_in, tag, 0);
}
else
{
[Bug tree-optimization/62021] ICE in verify_gimple_assign_single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62021 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) The problem is that get_vectype_for_scalar_type_and_size for pointers just returns vectors of pointer sized integers instead of vectors of pointers. So, either we need to VCE it, or change the simd_clones to instead use vectors of pointer sized integers instead of vectors of pointers for the arguments. The latter. There are no vectors of pointers. Richard.
[Bug lto/62034] ICE for big statically initialized arrays compiled with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org ---
Or actually
Index: gcc/lto-streamer-in.c
===
--- gcc/lto-streamer-in.c (revision 213660)
+++ gcc/lto-streamer-in.c (working copy)
@@ -1324,15 +1324,7 @@ lto_input_tree_1 (struct lto_input_block
streamer_tree_cache_append (data_in-reader_cache, result, hash);
}
else if (tag == LTO_tree_scc)
-{
- unsigned len, entry_len;
-
- /* Input and skip the SCC. */
- lto_input_scc (ib, data_in, len, entry_len);
-
- /* Recurse. */
- return lto_input_tree (ib, data_in);
-}
+gcc_unreachable ();
else
{
/* Otherwise, materialize a new node from IB. */
@@ -1345,7 +1337,15 @@ lto_input_tree_1 (struct lto_input_block
tree
lto_input_tree (struct lto_input_block *ib, struct data_in *data_in)
{
- return lto_input_tree_1 (ib, data_in, streamer_read_record_start (ib), 0);
+ enum LTO_tags tag;
+
+ /* Input and skip SCCs. */
+ while ((tag = streamer_read_record_start (ib)) == LTO_tree_scc)
+{
+ unsigned len, entry_len;
+ lto_input_scc (ib, data_in, len, entry_len);
+}
+ return lto_input_tree_1 (ib, data_in, tag, 0);
}
[Bug tree-optimization/62035] New: [4.9 Regresion] wrong code building libapache-mod-perl with -O1, works with -O1 -fno-tree-dse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62035 Bug ID: 62035 Summary: [4.9 Regresion] wrong code building libapache-mod-perl with -O1, works with -O1 -fno-tree-dse Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Created attachment 33260 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33260action=edit test case [forwarded from http://bugs.debian.org/754901] libapache2-mod-perl2 build segfaults in the test suite when built with gcc 4.9 (r213317) with -O1 or higher, building with -O1 -fno-tree-dse works around it. seen at least on x86_64-linux-gnu. attributing one function with __attribute__((optimize(-fno-tree-dse))) modperl_enc.c (modperl_env_table_populate) is enough to avoid the segfaults in the test suite. The diff in the assembler is: --- ok/modperl_env.s2014-08-06 12:42:36.714269110 + +++ bad/modperl_env.s 2014-08-06 12:40:44.441445210 + @@ -118,7 +118,6 @@ .LVL15: movq%rax, %r14 .LVL16: - movq%rax, 40(%rsp) subq$8, %rsp .cfi_def_cfa_offset 120 pushq $0
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874
--- Comment #8 from Uroš Bizjak ubizjak at gmail dot com ---
After lots of debugging...
The problem is with the label that is passed as an argument to
__go_set_defer_retaddr. In function main.$thunk0, in _.179r.cse1 dump, we have:
...
(insn 7 3 8 2 (set (reg:DI 84)
(high:DI (label_ref:DI 47))) rr.go:57 236 {*movdi}
(insn_list:REG_LABEL_OPERAND 47 (nil)))
(insn 8 7 9 2 (set (reg:DI 83)
(lo_sum:DI (reg:DI 84)
(label_ref:DI 47))) rr.go:57 230 {*movdi_er_low_l}
(insn_list:REG_LABEL_OPERAND 47 (expr_list:REG_EQUAL (label_ref:DI 47)
(nil
(insn 9 8 10 2 (set (reg:DI 16 $16)
(reg:DI 83)) rr.go:57 236 {*movdi}
(nil))
(call_insn 10 9 11 2 (parallel [
(set (reg:DI 0 $0)
(call (mem:DI (symbol_ref:DI (__go_set_defer_retaddr) [flags
0x41] function_decl 0x266a900 __go_set_defer_retaddr) [0
__go_set_defer_retaddr S8 A64])
(const_int 0 [0])))
(use (reg:DI 29 $29))
(clobber (reg:DI 26 $26))
]) rr.go:57 357 {*call_value_osf_1_er}
(expr_list:REG_CALL_DECL (symbol_ref:DI (__go_set_defer_retaddr) [flags
0x41] function_decl 0x266a900 __go_set_defer_retaddr)
(nil))
(expr_list:DI (use (reg:DI 16 $16))
(nil)))
...
(call_insn 46 45 47 5 (parallel [
(call (mem:DI (reg/f:DI 80 [ D.1014 ]) [0 *_42 S8 A64])
(const_int 4048 [0xfd0]))
(use (reg:DI 29 $29))
(clobber (reg:DI 26 $26))
]) rr.go:57 210 {*call_osf_1_er}
(expr_list:REG_DEAD (reg/f:DI 80 [ D.1014 ])
(expr_list:REG_DEAD (reg:DI 21 $21)
(expr_list:REG_DEAD (reg:DI 20 $20)
(expr_list:REG_DEAD (reg:DI 19 $19)
(expr_list:REG_DEAD (reg:DI 18 $18)
(expr_list:REG_DEAD (reg:DI 17 $17)
(expr_list:REG_DEAD (reg:DI 16 $16)
(expr_list:REG_CALL_DECL (nil)
(nil)
(expr_list (use (reg:DI 21 $21))
(expr_list (use (reg:DI 20 $20))
(expr_list (use (reg:DI 19 $19))
(expr_list (use (reg:DI 18 $18))
(expr_list (use (reg:DI 17 $17))
(expr_list (use (reg:DI 16 $16))
(expr_list:BLK (use (mem:BLK (reg/f:DI 30 $30) [0
S4048 A64]))
(nil)
;; succ: 6 [100.0%] (FALLTHRU)
;; lr out 15 [$15] 26 [$26] 29 [$29] 30 [$30] 31 [AP] 63 [FP]
;; live out 15 [$15] 29 [$29] 30 [$30] 31 [AP] 63 [FP]
;; basic block 6, loop depth 0, count 0, freq 1, maybe hot
;; prev block 5, next block 7, flags: (REACHABLE, RTL, MODIFIED)
;; pred: 2 [39.0%]
;; 5 [100.0%] (FALLTHRU)
;; bb 6 artificial_defs: { }
;; bb 6 artificial_uses: { u-1(15){ }u-1(29){ }u-1(30){ }u-1(31){ }u-1(63){ }}
;; lr in15 [$15] 26 [$26] 29 [$29] 30 [$30] 31 [AP] 63 [FP]
;; lr use 15 [$15] 29 [$29] 30 [$30] 31 [AP] 63 [FP]
;; lr def 81
;; live in 15 [$15] 29 [$29] 30 [$30] 31 [AP] 63 [FP]
;; live gen 81
;; live kill
(code_label/s 47 46 48 6 2 (retaddr) [5 uses])
(note 48 47 49 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn 49 48 52 6 (set (reg:DI 81 [ retval ])
(const_int 0 [0])) rr.go:57 236 {*movdi}
(nil))
succ: 8 [100.0%] (FALLTHRU)
Unfortunatelly, this is not a robust approach, since in a follow-up
_.180r.fwprop1 pass (insn 49) propagates to function return value, leaving:
(code_label/s 47 46 48 6 2 (retaddr) [5 uses])
(note 48 47 52 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
;; succ: 8 [100.0%] (FALLTHRU)
The following 181r.cprop pass removes the label (also updates passed argument
to __go_set_defer_retaddr in (insn 7) and (insn 8)) and merges bb after a thunk
call:
(insn 7 3 8 2 (set (reg/f:DI 84)
(high:DI (label_ref:DI [47 deleted]))) rr.go:57 236 {*movdi}
(insn_list:REG_LABEL_OPERAND 47 (nil)))
(insn 8 7 9 2 (set (reg/f:DI 83)
(lo_sum:DI (reg/f:DI 84)
(label_ref:DI [47 deleted]))) rr.go:57 230 {*movdi_er_low_l}
(expr_list:REG_DEAD (reg/f:DI 84)
(insn_list:REG_LABEL_OPERAND 47 (expr_list:REG_EQUAL (label_ref:DI [47
deleted])
(nil)
...
(call_insn 46 45 47 5 (parallel [
(call (mem:DI (reg/f:DI 80 [ D.1014 ]) [0 *_42 S8 A64])
(const_int 4048 [0xfd0]))
(use (reg:DI 29 $29))
(clobber (reg:DI 26 $26))
]) rr.go:57 210 {*call_osf_1_er}
(expr_list:REG_DEAD (reg/f:DI 80 [ D.1014 ])
(expr_list:REG_DEAD (reg:DI 21 $21)
(expr_list:REG_DEAD (reg:DI 20 $20)
(expr_list:REG_DEAD (reg:DI 19 $19)
(expr_list:REG_DEAD (reg:DI 18 $18)
(expr_list:REG_DEAD (reg:DI 17 $17)
(expr_list:REG_DEAD (reg:DI 16 $16)
[Bug tree-optimization/62035] [4.9 Regresion] wrong code building libapache-mod-perl with -O1, works with -O1 -fno-tree-dse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62035 --- Comment #1 from Matthias Klose doko at gcc dot gnu.org --- seen with r213518 on the trunk as well
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874
--- Comment #9 from Uroš Bizjak ubizjak at gmail dot com ---
To illustrate unreliable approach, please compile following test:
--cut here--
extern void foo (void *);
int test(void)
{
__label__ bla;
foo (bla);
bla:
return 0;
}
--cut here--
gcc -O2:
test:
.L2:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
movl$.L2, (%esp)
callfoo
xorl%eax, %eax
leave
ret
The passed argument doesn't represent return address.
[Bug target/61749] arm_neon.h _lane and _n intrinsics can cause ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61749 --- Comment #3 from ktkachov at gcc dot gnu.org --- vqdmlal_lane_s16 expects an immediate/literal lane number as the fourth argument and the builtin expansion code in aarch64-builtins.c is actually equipped to error out when given a variable (in the SIMD_ARG_CONSTANT case of aarch64_simd_expand_args). However the type qualifiers for vqdmlal_lane_s16 are the QUADOP qualifiers which don't enforce qualifier_immediate on the builtin, thus falling into the SIMD_ARG_COPY_TO_REG and later on failing the CONST_INT_P assert when processing the lane numbers. If I give qualifier_immediate to the 4th argument I get a more helpful: error: incompatible type for argument 4, expected 'const int' message but the compiler still tries to proceed and ends up ICEing anyway.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 --- Comment #10 from Andreas Schwab sch...@linux-m68k.org --- If you never use goto *exp in the same function the value of label is undefined.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 --- Comment #11 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Andreas Schwab from comment #10) If you never use goto *exp in the same function the value of label is undefined. I did try adding goto bla: just before label, but never managed to get something around return address. Care to post and example, please?
[Bug tree-optimization/62035] [4.9/4.10 Regresion] wrong code building libapache-mod-perl with -O1, works with -O1 -fno-tree-dse
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62035 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.2
[Bug lto/62034] ICE for big statically initialized arrays compiled with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Aug 6 13:53:09 2014 New Revision: 213664 URL: https://gcc.gnu.org/viewcvs?rev=213664root=gccview=rev Log: 2014-08-06 Richard Biener rguent...@suse.de PR lto/62034 * lto-streamer-in.c (lto_input_tree_1): Assert we do not read SCCs here. (lto_input_tree): Pop SCCs here. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-in.c
[Bug lto/62034] ICE for big statically initialized arrays compiled with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62034 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 --- Comment #12 from Ian Lance Taylor ian at airs dot com --- Thanks for the analysis. See also PR 60406. Dominik sent me a patch for 60406 but 1) he has no copyright assignment; 2) I think that his patch does not work for SJLJ exceptions.
[Bug ipa/61393] [trans-mem] O3 optimization level constant propagation problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393 --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Wed Aug 6 13:59:18 2014 New Revision: 213666 URL: https://gcc.gnu.org/viewcvs?rev=213666root=gccview=rev Log: 2014-08-06 Martin Jambor mjam...@suse.cz PR ipa/61393 * cgraphclones.c (cgraph_node::create_clone): Also copy tm_clone. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphclones.c
[Bug ipa/61393] [trans-mem] O3 optimization level constant propagation problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Jambor jamborm at gcc dot gnu.org --- Hopefully fixed even on trunk.
[Bug c++/62036] New: Braced-init-list issuing -Wsequence-point warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62036
Bug ID: 62036
Summary: Braced-init-list issuing -Wsequence-point warning
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dacamara.cameron at gmail dot com
#include algorithm
#include iostream
#include iterator
#include thread
int main() {
int arr[10];
std::iota(std::begin(arr), std::end(arr), 1);
using itr_t = decltype(std::begin(arr));
// the function that will display each element
auto f = [] (itr_t first, itr_t last) {while (first != last)
std::cout*(first++)' ';};
// we have 3 threads so we need to figure out the ranges for each thread to
show
int increment = std::distance(std::begin(arr), std::end(arr)) / 3;
auto first= std::begin(arr);
auto to = first + increment;
auto last = std::end(arr);
std::thread threads[3] = {
std::thread{f, first, to},
std::thread{f, (first = to), (to += increment)},
std::thread{f, (first = to), last} // go to last here to account for
odd array sizes
};
for (auto t : threads) t.join();
}
I'm getting the sequence point warning with this piece of code and when I
execute it the thread at threads[1] prints nothing whatsoever. This should be
well defined according to the standard (I'm using sec. 8.5.4.4 as reference).
The fact that gcc even issues the -Wsequence-point warning is indicative that
the standard isn't being followed.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #13 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Ian Lance Taylor from comment #12) Thanks for the analysis. See also PR 60406. Dominik sent me a patch for 60406 but 1) he has no copyright assignment; 2) I think that his patch does not work for SJLJ exceptions. Actually, this remaining problem is the same as PR60406. The original problem is fixed.
[Bug go/60406] reflect.go:test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-06 CC||ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #1 from Uroš Bizjak ubizjak at gmail dot com --- This problem also happens on alpha, please see analysis at [1]. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874#c8
[Bug c/62037] New: cannot pass 'int **' as a 'int const* const*' parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62037 Bug ID: 62037 Summary: cannot pass 'int **' as a 'int const* const*' parameter Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mrolnik at gmail dot com Created attachment 33261 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33261action=edit .i file when I pass 'int **' object as a function parameter declares as 'int const* const*' I get a warning (see below) Using built-in specs. COLLECT_GCC=c:\MinGW\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/lto-wrapper.exe Target: mingw32 Configured with: ../gcc-4.8.1/configure --prefix=/mingw --host=mingw32 --build=mingw32 --without-pic --enable-shared --enable-static --with-gnu-ld --enable-lto --enable-libssp --disable-multilib --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-sjlj-exceptions --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --with-gmp=/usr/src/pkg/gmp-5.1.2-1-mingw32-src/bld --with-mpc=/usr/src/pkg/mpc-1.0.1-1-mingw32-src/bld --with-mpfr= --with-system-zlib --with-gnu-as --enable-decimal-float=yes --enable-libgomp --enable-threads --with-libiconv-prefix=/mingw32 --with-libintl-prefix=/mingw --disable-bootstrap LDFLAGS=-s CFLAGS=-D_USE_32BIT_TIME_T Thread model: win32 gcc version 4.8.1 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=pentiumpro' c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/cc1.exe -E -quiet -v -iprefix c:\mingw\bin\../lib/gcc/mingw32/4.8.1/ test.c -mtune=generic -march=pentiumpro -fpch-preprocess -o test.i ignoring duplicate directory c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include ignoring duplicate directory c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/../../../../include ignoring duplicate directory /mingw/include ignoring duplicate directory c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/include-fixed ignoring duplicate directory c:/mingw/lib/gcc/../../lib/gcc/mingw32/4.8.1/../../../../mingw32/include ignoring duplicate directory /mingw/include #include ... search starts here: #include ... search starts here: c:\mingw\bin\../lib/gcc/mingw32/4.8.1/include c:\mingw\bin\../lib/gcc/mingw32/4.8.1/../../../../include c:\mingw\bin\../lib/gcc/mingw32/4.8.1/include-fixed c:\mingw\bin\../lib/gcc/mingw32/4.8.1/../../../../mingw32/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=pentiumpro' c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/cc1.exe -fpreprocessed test.i -quiet -dumpbase test.c -mtune=generic -march=pentiumpro -auxbase test -version -o test.s GNU C (GCC) version 4.8.1 (mingw32) compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C (GCC) version 4.8.1 (mingw32) compiled by GNU C version 4.8.1, GMP version 5.1.2, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 767202a405449496e68a54c4eee91a28 test.c: In function 'main': test.c:13:2: warning: passing argument 1 of 'foo' from incompatible pointer type [enabled by default] foo(pA); ^ test.c:3:6: note: expected 'const int * const*' but argument is of type 'int **' void foo(const int * const* a) ^ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=pentiumpro' c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/as.exe -v -o test.o test.s GNU assembler version 2.23.2 (mingw32) using BFD version (GNU Binutils) 2.23.2 COMPILER_PATH=c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/;c:/mingw/bin/../libexec/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ LIBRARY_PATH=c:/mingw/bin/../lib/gcc/mingw32/4.8.1/;c:/mingw/bin/../lib/gcc/;c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/;c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-mtune=generic' '-march=pentiumpro' c:/mingw/bin/../libexec/gcc/mingw32/4.8.1/collect2.exe -Bdynamic c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib/crt2.o c:/mingw/bin/../lib/gcc/mingw32/4.8.1/crtbegin.o -Lc:/mingw/bin/../lib/gcc/mingw32/4.8.1 -Lc:/mingw/bin/../lib/gcc -Lc:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/lib -Lc:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../.. test.o -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt -ladvapi32 -lshell32 -luser32 -lkernel32 -lmingw32 -lgcc -lgcc_eh -lmoldname -lmingwex -lmsvcrt c:/mingw/bin/../lib/gcc/mingw32/4.8.1/crtend.o
[Bug c/62037] cannot pass 'int **' as a 'int const* const*' parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62037 --- Comment #1 from Michael Rolnik mrolnik at gmail dot com --- Created attachment 33262 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33262action=edit compiler output
[Bug rtl-optimization/61608] [4.10 regression] FAIL: gcc.target/arm/epilog-1.c scan-assembler tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61608 jgreenhalgh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from jgreenhalgh at gcc dot gnu.org --- This looks resolved to me.
[Bug c/62037] cannot pass 'int **' as a 'int const* const*' parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62037 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- Firstly, a warning doesn't mean you cannot do it, you just get a warning. Secondly, that's the correct behaviour, see http://c-faq.com/ansi/constmismatch.html
[Bug other/62002] -fcilkplus switch breaks format attribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62002
Igor Zamyatin izamyatin at gmail dot com changed:
What|Removed |Added
CC||izamyatin at gmail dot com
--- Comment #2 from Igor Zamyatin izamyatin at gmail dot com ---
Am I correct that adding -fcilkplus just fixes the bug somehow?
I see that regular trunk g++ gives error for
struct foo
{
void bar(void *my_object, char const *, ...)
__attribute__((__format__(__printf__, 2, 3)));
};
which is supposed to be correct according to the
docs(https://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html#Function-Attributes)
[Bug c++/62036] Braced-init-list issuing -Wsequence-point warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62036 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- As pointed out at http://stackoverflow.com/questions/25115189/optimization-bug-regarding-gcc-stdthread#comment39095137_25115189 (where you apparently copied this code from) there's a known bug which is fixed in GCC 4.9, see PR51253
[Bug c/62037] cannot pass 'int **' as a 'int const* const*' parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62037 Michael Rolnik mrolnik at gmail dot com changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #4 from Michael Rolnik mrolnik at gmail dot com --- it seems my assumption about const pointers to const data was wrong.
[Bug c++/62036] Braced-init-list issuing -Wsequence-point warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62036 --- Comment #2 from Cameron dacamara.cameron at gmail dot com --- Welp looks like my friend got to it before I did. My bad. Carry on and good work!
[Bug c/62037] cannot pass 'int **' as a 'int const* const*' parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62037 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Yeah, I don't think there's anything to do. With latest GCC, you can suppress this particular warning using -Wno-incompatible-pointer-types.
[Bug regression/61510] [4.10 Regression]: 20_util/scoped_allocator/requirements/explicit_instantiation.cc and tr1/6_containers/tuple/requirements/explicit_instantiation.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61510 jgreenhalgh at gcc dot gnu.org changed: What|Removed |Added Target|cris-axis-elf, |cris-axis-elf, |arm-none-eabi, | |aarch64-none-elf| Status|NEW |WAITING --- Comment #7 from jgreenhalgh at gcc dot gnu.org --- This is now fixed on aarch64 and arm. Hans, do you still see it on cris?
[Bug libstdc++/62023] [4.10 regression] 30_threads/condition_variable_any/50862.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62023 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #2 from Rainer Orth ro at gcc dot gnu.org --- A reghunt revealed that this was caused by this patch: 2014-07-30 Jason Merrill ja...@redhat.com PR lto/53808 PR c++/61659 * pt.c (push_template_decl_real): Set DECL_COMDAT on templates. (check_explicit_specialization): Clear it on specializations. * decl.c (duplicate_decls, start_decl): Likewise. (grokmethod, grokfndecl): Set DECL_COMDAT on inlines. * method.c (implicitly_declare_fn): Set DECL_COMDAT. Determine linkage after setting the appropriate flags. * tree.c (decl_linkage): Don't check DECL_COMDAT. * decl2.c (mark_needed): Mark clones. (import_export_decl): Not here. I've not yet checked what exactly is going wrong here. Rainer
[Bug libstdc++/62022] [4.10 regression] 27_io/basic_ofstream/pthread2.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62022 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org Depends on||62023 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org --- This was caused by the same patch as PR libstdc++/62023. Rainer
[Bug middle-end/61294] [4.9 Regression] erroneous memset used with constant zero length parameter warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61294 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- *** Bug 62033 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/62033] okteta 4.13.97 error at -O3 -D_FORTIFY_SOURCE=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62033 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Alan Modra from comment #2) I can see where you're coming from Andrew, but what is disconcerting about this is that the _FORTIFY_SOURCE warning is plainly incorrect here. How is one supposed to write a string.h memset macro using __builtin_constant_p() to provide a useful _FORTIFY_SOURCE warning, in the face of this sort of optimisation? This is why Jakub moved it to the front-end away from glibc (See PR 61294). Users are going to see this as __builtin_constant_p() is broken. It is not. It is working correctly as on that path, it is constant. This is an exact duplicate of bug 61294 really. *** This bug has been marked as a duplicate of bug 61294 ***
[Bug other/62002] -fcilkplus switch breaks format attribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62002 --- Comment #3 from Viacheslav Chernyshev astellar at ro dot ru --- No, fcilkplus switch triggers compilation error when code is perfectly valid. Your example is wrong, as in C++ this pointer is an implicit first argument of member function.
[Bug debug/61923] [4.8/4.9/4.10 Regression] -fcompare-debug errors while building Linux kernel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923 --- Comment #6 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Wed Aug 6 15:35:49 2014 New Revision: 213674 URL: https://gcc.gnu.org/viewcvs?rev=213674root=gccview=rev Log: 2014-08-06 Vladimir Makarov vmaka...@redhat.com PR debug/61923 * haifa-sched.c (advance_one_cycle): Fix dump. (schedule_block): Don't advance cycle if we are already at the beginning of the cycle. 2014-08-06 Vladimir Makarov vmaka...@redhat.com PR debug/61923 * gcc.target/i386/pr61923.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr61923.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/haifa-sched.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug debug/61923] [4.8/4.9/4.10 Regression] -fcompare-debug errors while building Linux kernel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923 --- Comment #7 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Wed Aug 6 15:40:26 2014 New Revision: 213675 URL: https://gcc.gnu.org/viewcvs?rev=213675root=gccview=rev Log: 2014-08-06 Vladimir Makarov vmaka...@redhat.com PR debug/61923 * haifa-sched.c (advance_one_cycle): Fix dump. (schedule_block): Don't advance cycle if we are already at the beginning of the cycle. 2014-08-06 Vladimir Makarov vmaka...@redhat.com PR debug/61923 * gcc.target/i386/pr61923.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr61923.c Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c trunk/gcc/testsuite/ChangeLog
[Bug other/62002] -fcilkplus switch breaks format attribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62002 --- Comment #4 from Igor Zamyatin izamyatin at gmail dot com --- Right, it is mentioned explicitly in the docs. Will take a look
[Bug debug/61923] [4.8/4.9/4.10 Regression] -fcompare-debug errors while building Linux kernel.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61923 --- Comment #8 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Thanks Vladimir. I can now build my kernel with GCC_COMPARE_DEBUG=1 without any issues.
[Bug target/61749] arm_neon.h _lane and _n intrinsics can cause ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61749 ktkachov at gcc dot gnu.org changed: What|Removed |Added Assignee|jgreenhalgh at gcc dot gnu.org |ktkachov at gcc dot gnu.org Target Milestone|--- |4.10.0 --- Comment #4 from ktkachov at gcc dot gnu.org --- I think I have a trunk patch to address this
[Bug ipa/61393] [trans-mem] O3 optimization level constant propagation problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61393 --- Comment #9 from torvald at gcc dot gnu.org --- Alex, can you confirm that this is fixed?
[Bug debug/55641] debug info for the type of a reference declared with a typedef has spurious 'const'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 --- Comment #9 from Tom Tromey tromey at gcc dot gnu.org --- I think this happens due to this code in gen_variable_die: tree type = TREE_TYPE (decl_or_origin); if (decl_by_reference_p (decl_or_origin)) add_type_attribute (var_die, TREE_TYPE (type), 0, 0, context_die); else add_type_attribute (var_die, type, TREE_READONLY (decl_or_origin), TREE_THIS_VOLATILE (decl_or_origin), context_die); For the reduced test case we enter the second call to add_type_attribute. g is marked as TREE_READONLY, so this forces the const to be emitted. Is there ever a case where this is correct? That is, where the DWARF needs to emit const or volatile but the only note is on the object and not the object's type? I didn't know.
[Bug ada/61954] Ada fails to properly pass pointer arguments on x32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61954 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-06 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Maybe Ada fails to tell the backend that a parameter is a pointer: Yes, there are known issues in this area for ABIs that treat pointers and integers of the same size differently, e.g. the Linux ABI for m68K.
[Bug go/60406] recover.go: test13reflect2 test failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60406 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Summary|reflect.go:test13reflect2 |recover.go: test13reflect2 |test failure|test failure --- Comment #2 from Uroš Bizjak ubizjak at gmail dot com --- Corrected Summary.
[Bug libstdc++/62023] [4.10 regression] 30_threads/condition_variable_any/50862.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62023 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Jonathan Wakely from comment #1) Which means the __gthread_active_p() function in libgcc/gthr-posix.h is returning false Looks like there's a Solaris-specific version of __gthread_active_p, but I can't think why marking it as DECL_COMDAT would break things. Let me know what you find.
[Bug go/60874] FAIL: go.test/test/recover.go execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60874 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Target Milestone|4.10.0 |4.9.2
[Bug target/62038] New: Out of range branch target in thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62038
Bug ID: 62038
Summary: Out of range branch target in thunk
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: danglin at gcc dot gnu.org
Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
Build: hppa-unknown-linux-gnu
Created attachment 33263
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33263action=edit
Preprocessed source
The compilation of texmaker.cpp fails as follows:
g++ -c -pipe -g -O2 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -w
-D_REENTRANT -fPIE -DTEXMAKERVERSION=\4.3\ -DHAVE_SPLASH -DPOPPLER24
-DPREFIX=\/usr\ -DDEBIAN_SPELLDIR -DQT_NO_DEBUG -DQT_WEBKITWIDGETS_LIB
-DQT_QUICK_LIB -DQT_OPENGL_LIB -DQT_PRINTSUPPORT_LIB -DQT_WEBKIT_LIB
-DQT_QML_LIB -DQT_WIDGETS_LIB -DQT_SCRIPT_LIB -DQT_CONCURRENT_LIB
-DQT_NETWORK_LIB -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB
-I/usr/lib/hppa-linux-gnu/qt5/mkspecs/linux-g++ -I. -isystem
/usr/include/poppler/qt5 -isystem /usr/include/poppler -isystem
/usr/include/synctex -isystem /usr/include/hppa-linux-gnu/qt5 -isystem
/usr/include/hppa-linux-gnu/qt5/QtWebKitWidgets -isystem
/usr/include/hppa-linux-gnu/qt5/QtQuick -isystem
/usr/include/hppa-linux-gnu/qt5/QtOpenGL -isystem
/usr/include/hppa-linux-gnu/qt5/QtPrintSupport -isystem
/usr/include/hppa-linux-gnu/qt5/QtWebKit -isystem
/usr/include/hppa-linux-gnu/qt5/QtQml -isystem
/usr/include/hppa-linux-gnu/qt5/QtWidgets -isystem
/usr/include/hppa-linux-gnu/qt5/QtScript -isystem
/usr/include/hppa-linux-gnu/qt5/QtConcurrent -isystem
/usr/include/hppa-linux-gnu/qt5/QtNetwork -isystem
/usr/include/hppa-linux-gnu/qt5/QtXml -isystem
/usr/include/hppa-linux-gnu/qt5/QtGui -isystem
/usr/include/hppa-linux-gnu/qt5/QtCore -I.moc -I.ui -o .obj/texmaker.o
texmaker.cpp
{standard input}: Assembler messages:
{standard input}:246604: Error: Field out of range [-262144..262143] (-417748).
{standard input}:246674: Error: Field out of range [-262144..262143] (-417856).
make[1]: *** [.obj/texmaker.o] Error 1
Problem is branches in following thunks:
.cfi_startproc
_ZThn8_N8TexmakerD1Ev:
.PROC
.CALLINFO FRAME=128,CALLS,SAVE_RP,ENTRY_GR=7
.ENTRY
b _ZN8TexmakerD2Ev
ldo -8(%r26),%r26
.EXIT
.PROCEND
.cfi_endproc
.cfi_startproc
_ZThn8_N8TexmakerD0Ev:
.PROC
.CALLINFO FRAME=64,CALLS,SAVE_RP,ENTRY_GR=4
.ENTRY
b _ZN8TexmakerD0Ev
ldo -8(%r26),%r26
.EXIT.PROCEND
.cfi_endproc
We need to force targets into register %r1 and use bv branch to ensure
we can reach target.
[Bug libstdc++/62039] New: concept checking for std::prev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62039 Bug ID: 62039 Summary: concept checking for std::prev Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: glisse at gcc dot gnu.org Hello, std::prev forwards to advance without any concept checking, and advance then doesn't mind if the iterator is a forward iterator. I have seen several posts on stackoverflow where people complained that the compiler didn't tell them how silly their code was, and it would have been nice to be able to say: look, it does if you ask nicely with -D_GLIBCXX_CONCEPT_CHECKS. Yes, I know those are deprecated, feel free to close immediatly.
[Bug c++/62036] Braced-init-list issuing -Wsequence-point warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62036 Cameron dacamara.cameron at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Cameron dacamara.cameron at gmail dot com --- duplicate of bug 51253 *** This bug has been marked as a duplicate of bug 51253 ***
[Bug c++/51253] [C++11][DR 1030] Evaluation order (sequenced-before relation) among initializer-clauses in braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51253 Cameron dacamara.cameron at gmail dot com changed: What|Removed |Added CC||dacamara.cameron at gmail dot com --- Comment #22 from Cameron dacamara.cameron at gmail dot com --- *** Bug 62036 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/62040] New: internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62040 Bug ID: 62040 Summary: internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1555 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: xinliangli at gmail dot com Compile the attached source file with option -Os -g using aarch64 compiler, the compiler ICEs: et2.c: In function 'foo': et2.c:189:1: internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1555 }
[Bug rtl-optimization/62040] internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62040 --- Comment #1 from davidxl xinliangli at gmail dot com --- Created attachment 33264 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33264action=edit test case
[Bug rtl-optimization/62040] internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62040
--- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org ---
(insn 144 82 145 2 (set (reg:V2DI 33 v1 [orig:96 D.2914 ] [96])
(vec_concat:V2DI (reg:DI 32 v0 [orig:95 D.2915 ] [95])
(vec_duplicate:DI (const_int 0 [0] t456.c:76 1030
{move_lo_quad_internal_v2di}
(expr_list:REG_DEAD (reg:DI 32 v0 [orig:95 D.2915 ] [95])
(nil)))
Is bogus.
[Bug target/62040] internal compiler error: in simplify_const_unary_operation, at simplify-rtx.c:1555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62040 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Target||aarch64*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-06 Component|rtl-optimization|target Ever confirmed|0 |1 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- Here is what I wrote on an internal bug about this same issue: This is just bogus RTL as vec_dup of a scalar mode does not make sense. We should have a different pattern for the 2 element case. Confirmed.
[Bug target/62041] New: vector fneg codegen uses a subtract instead of an xor (x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62041
Bug ID: 62041
Summary: vector fneg codegen uses a subtract instead of an xor
(x86-64)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: spatel at rotateright dot com
$ cat fneg.c
#include xmmintrin.h
__m128 fneg4(__m128 x) {
return _mm_sub_ps(_mm_set1_ps(-0.0), x);
}
$ ~gcc49/local/bin/gcc -march=core-avx2 -O2 -S fneg.c -o -
...
_fneg4:
LFB513:
vmovapsLC0(%rip), %xmm1
vsubps%xmm0, %xmm1, %xmm0
ret
...
LC0:
.long2147483648
.long2147483648
.long2147483648
.long2147483648
Instead of generating 'vsubps' here, it would be better to generate 'vxorps'
because we know we're just flipping the sign bit of each element. This is what
gcc does for the scalar version of this code.
Note that there is no difference if I use -ffast-math with this testcase. With
-ffast-math enabled, we should generate the same 'xorps' code even if the
-0.0 is +0.0. Again, that's what the scalar codegen does, so I think this
is just a deficiency when generating vector code.
I can file the -ffast-math case as a separate bug if that would be better.
[Bug c++/43906] missing warnings the comparison between an address with a null pointer constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43906 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Aug 6 19:09:08 2014 New Revision: 213682 URL: https://gcc.gnu.org/viewcvs?rev=213682root=gccview=rev Log: /cp 2014-08-06 Paolo Carlini paolo.carl...@oracle.com PR c++/43906 * typeck.c (cp_build_binary_op): Extend to more cases the -Waddress warning. /testsuite 2014-08-06 Paolo Carlini paolo.carl...@oracle.com PR c++/43906 * g++.dg/warn/Waddress-1.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/Waddress-1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c++/43906] missing warnings the comparison between an address with a null pointer constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43906 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed.
[Bug c++/51312] [C++0x] Wrong interpretation of converted constant expressions (for enumerator initializers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312
--- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com ---
I'm having a look at the issue and it seems rather different than I (we)
thought. Suffices to say that it does not affect constexpr non-operator member
functions, and that sort-of explains this (ugly) workaround:
enum : int { e = X().operator int() };
Also, isn't just about C++11 enums, eg, this should be also accepted:
enum { e = X() };
[Bug ada/62042] New: Missing optimization of copying non-limited objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62042 Bug ID: 62042 Summary: Missing optimization of copying non-limited objects Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: porton at narod dot ru The below program, compiled with GNAT 4.9, calls Adjust two times when copying a T1 object. But it does the same operations with a T2 object without calling Adjust. So calling Adjust on a T1 object is here redundant and can be optimized away for greater performance. Ada Reference Manual allows this kind of optimization. So GNAT is not as good as I expected, isn't it? with Ada.Finalization; with Ada.Text_IO; procedure Main is type T1 is new Ada.Finalization.Controlled with null record; type T2 is new Ada.Finalization.Limited_Controlled with null record; overriding procedure Adjust(Object: in out T1) is begin Ada.Text_IO.Put_Line(Adjust); end; function F return T1 is begin return (Ada.Finalization.Controlled with null record); end; function F return T2 is begin return (Ada.Finalization.Limited_Controlled with null record); end; X: T1 := F; Y: T2 := F; begin null; end;
[Bug regression/61510] [4.10 Regression]: 20_util/scoped_allocator/requirements/explicit_instantiation.cc and tr1/6_containers/tuple/requirements/explicit_instantiation.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61510 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to jgreenhalgh from comment #7) This is now fixed on aarch64 and arm. Hans, do you still see it on cris? Fixed for CRIS too, thanks. BTW, it's ok to close once for all targets unless some target difference has been noted earlier.
[Bug libstdc++/62039] concept checking for std::prev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62039 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-06 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- makes sense to me
[Bug target/62014] [AArch64] Using -mgeneral-regs-only may lead to ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62014 Evandro Menezes e.menezes at samsung dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #16 from Evandro Menezes e.menezes at samsung dot com --- If it's working, it's good for me.
[Bug c++/51312] [C++0x] Wrong interpretation of converted constant expressions (for enumerator initializers)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51312 --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com --- build_expr_type_conversion is the answer
[Bug lto/51744] Erroneous warning: memset used with constant zero length parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51744 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||amodra at gmail dot com Resolution|--- |FIXED --- Comment #11 from Alan Modra amodra at gmail dot com --- This has now been fixed on mainline binutils
[Bug c++/61994] constexpr vector array ICE [4.9.1 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61994 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-08-07 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/61994] constexpr vector array ICE [4.9.1 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61994 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 7 01:44:06 2014 New Revision: 213688 URL: https://gcc.gnu.org/viewcvs?rev=213688root=gccview=rev Log: PR c++/61994 * init.c (build_vec_init): Leave atype an ARRAY_TYPE if we're just returning an INIT_EXPR. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c
[Bug c++/60417] [DR 1518] Bogus error on C++03 aggregate initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60417 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Aug 7 01:44:11 2014 New Revision: 213689 URL: https://gcc.gnu.org/viewcvs?rev=213689root=gccview=rev Log: PR c++/60417 * init.c (build_vec_init): Reorganize earlier change a bit. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/init.c
[Bug c++/62043] New: [4.9/4.10 Regression] GCC hangs / aborts / double free or corruption (!prev) on invalid input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62043 Bug ID: 62043 Summary: [4.9/4.10 Regression] GCC hangs / aborts / double free or corruption (!prev) on invalid input Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: d.g.gorbachev at gmail dot com Created attachment 33265 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33265action=edit Testcase 2.i:1:0: sorry, unimplemented: inter-module optimizations not implemented for C++ typedef __builtin_va_list __gnuc_va_list; ^ In file included from 2.i:1:0: 4.i:1:0: sorry, unimplemented: inter-module optimizations not implemented for C++ ^ *** Error in `/usr/local/libexec/gcc/i686-pc-linux-gnu/4.10.0/cc1plus': double free or corruption (!prev): 0x094e04e8 *** === Backtrace: = /usr/lib/libc.so.6(+0x6c449)[0xb7e1c449] /usr/lib/libc.so.6(+0x72557)[0xb7e22557] /usr/lib/libc.so.6(+0x72d3d)[0xb7e22d3d] /usr/lib/libc.so.6(fclose+0x14a)[0xb7e129da] /usr/local/libexec/gcc/i686-pc-linux-gnu/4.10.0/cc1plus(_ZN6fcacheD1Ev+0x17)[0x8f07a8b] /usr/local/libexec/gcc/i686-pc-linux-gnu/4.10.0/cc1plus(_Z26diagnostic_file_cache_finiv+0x32)[0x8f07b04] /usr/local/libexec/gcc/i686-pc-linux-gnu/4.10.0/cc1plus(_Z17diagnostic_finishP18diagnostic_context+0x5b)[0x8f0385f] /usr/local/libexec/gcc/i686-pc-linux-gnu/4.10.0/cc1plus(_Z11toplev_mainiPPc+0xf95)[0x8882674] /usr/local/libexec/gcc/i686-pc-linux-gnu/4.10.0/cc1plus(main+0x1b)[0x8ef17b9] /usr/lib/libc.so.6(__libc_start_main+0xde)[0xb7dc7e2e] /usr/local/libexec/gcc/i686-pc-linux-gnu/4.10.0/cc1plus[0x8134f3b] === Memory map: 08048000-093de000 r-xp 00:0b 9771298 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.10.0/cc1plus 093de000-093e4000 rw-p 01395000 00:0b 9771298 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.10.0/cc1plus 093e4000-0950 rw-p 00:00 0 [heap] b7afc000-b7b18000 r-xp 00:0b 9816159/usr/lib/libgcc_s.so.1 b7b18000-b7b19000 rw-p 0001b000 00:0b 9816159/usr/lib/libgcc_s.so.1 b7b2f000-b7db rw-p 00:00 0 b7db-b7f6b000 r-xp 00:0b 8269221/usr/lib/libc-2.19.so b7f6b000-b7f6e000 r--p 001ba000 00:0b 8269221/usr/lib/libc-2.19.so b7f6e000-b7f7 rw-p 001bd000 00:0b 8269221/usr/lib/libc-2.19.so b7f7-b7f72000 rw-p 00:00 0 b7f72000-b7fbc000 r-xp 00:0b 8269178/usr/lib/libm-2.19.so b7fbc000-b7fbd000 r--p 00049000 00:0b 8269178/usr/lib/libm-2.19.so b7fbd000-b7fbe000 rw-p 0004a000 00:0b 8269178/usr/lib/libm-2.19.so b7fbe000-b7fc1000 r-xp 00:0b 8269187/usr/lib/libdl-2.19.so b7fc1000-b7fc2000 r--p 2000 00:0b 8269187/usr/lib/libdl-2.19.so b7fc2000-b7fc3000 rw-p 3000 00:0b 8269187/usr/lib/libdl-2.19.so b7fd-b7fd9000 rw-p 00:00 0 b7fd9000-b7fdb000 r--p 00:00 0 b7fdb000-b7fdc000 r-xp 00:00 0 [vdso] b7fdc000-b7ffd000 r-xp 00:0b 8269205/usr/lib/ld-2.19.so b7ffd000-b7ffe000 rw-p 00:00 0 b7ffe000-b7fff000 r--p 00021000 00:0b 8269205/usr/lib/ld-2.19.so b7fff000-b800 rw-p 00022000 00:0b 8269205/usr/lib/ld-2.19.so bffdf000-c000 rw-p 00:00 0 [stack] 2.i:1:0: internal compiler error: Aborted typedef __builtin_va_list __gnuc_va_list; ^ 0x8880092 crash_signal ../../gcc-4.10/gcc/toplev.c:337 0x8f07a8a fcache::~fcache() ../../gcc-4.10/gcc/input.c:348 0x8f07b03 diagnostic_file_cache_fini() ../../gcc-4.10/gcc/input.c:193 0x8f0385e diagnostic_finish(diagnostic_context*) ../../gcc-4.10/gcc/diagnostic.c:180 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. GCC 4.7/4.8 just say sorry, unimplemented.
[Bug c++/62043] [4.9/4.10 Regression] GCC hangs / aborts / double free or corruption (!prev) on invalid input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62043 --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- Created attachment 33266 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33266action=edit Backtrace
