[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59573 Yvan Roux yvan.roux at linaro dot org changed: What|Removed |Added CC||yvan.roux at linaro dot org --- Comment #5 from Yvan Roux yvan.roux at linaro dot org --- Yes, I've tried with foundation_v8, and not only it extremely slow, but also it fails here. compiling gcc in qemu takes 5hours, but takes one week (someone told me) in foudation model. for another simulator, do you have any suggestion? is the foundation model failing for the same reason here (i.e. not recognizing the cmeq instruction) ?
[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569 --- Comment #8 from Bingfeng Mei bmei at broadcom dot com --- Sorry for the regression. The assertion happens if storing a constant value with negative step. Doing permutation of constant is not the best optimization here. So the easy way to fix is to skip vectorizing this statement in the same way as before the patch. Or maybe better way is to form a constant vector to store.
[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569
--- Comment #9 from Bingfeng Mei bmei at broadcom dot com ---
Seems simple patch is to just bypass permutation for constant operand as
vec_oprnd is a constant vector with identical elements.
Index: tree-vect-stmts.c
===
--- tree-vect-stmts.c (revision 206176)
+++ tree-vect-stmts.c (working copy)
@@ -5353,7 +5353,8 @@ vectorizable_store (gimple stmt, gimple_
set_ptr_info_alignment (get_ptr_info (dataref_ptr), align,
misalign);
- if (negative)
+ if (negative
+ !CONSTANT_CLASS_P (gimple_assign_rhs1 (stmt)))
{
tree perm_mask = perm_mask_for_reverse (vectype);
tree perm_dest
[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Bingfeng Mei from comment #9)
Seems simple patch is to just bypass permutation for constant operand as
vec_oprnd is a constant vector with identical elements.
Index: tree-vect-stmts.c
===
--- tree-vect-stmts.c (revision 206176)
+++ tree-vect-stmts.c (working copy)
@@ -5353,7 +5353,8 @@ vectorizable_store (gimple stmt, gimple_
set_ptr_info_alignment (get_ptr_info (dataref_ptr), align,
misalign);
- if (negative)
+ if (negative
+ !CONSTANT_CLASS_P (gimple_assign_rhs1 (stmt)))
{
tree perm_mask = perm_mask_for_reverse (vectype);
tree perm_dest
I think checking dt == vect_constant_def || dt == vect_external_def would be
more appropriate. But, IMNSHO you don't need to check at the analysis phase
!perm_mask_for_reverse (vectype)
either.
[Bug bootstrap/59583] New: --enable-targets=all --with-cpu=broadwell isn't allowed to configure i686-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59583 Bug ID: 59583 Summary: --enable-targets=all --with-cpu=broadwell isn't allowed to configure i686-linux Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com I got # /export/gnu/import/git/gcc/configure --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared i686-linux --prefix=/usr/gcc-4.9.0 --with-local-prefix=/usr/local --enable-targets=all --with-cpu=broadwell --with-fpmath=sse ... # make bootstrap ... Unsupported CPU used in --with-cpu=broadwell, supported values: generic intel atom slm core2 corei7 corei7-avx nocona x86-64 bdver4 bdver3 bdver2 bdver1 btver2 btver1 amdfam10 barcelona k8 opteron athlon64 athlon-fx athlon64-sse3 k8-sse3 opteron-sse3 make[3]: *** [configure-stage1-gcc] Error 1 make[3]: Leaving directory `/export/build/gnu/gcc-test-32bit/build-i686-linux' make[2]: *** [stage1-bubble] Error 2 make[2]: Leaving directory `/export/build/gnu/gcc-test-32bit/build-i686-linux' make[1]: *** [bootstrap] Error 2
[Bug c++/59111] [4.9 Regression] [c++11] ICE on invalid usage of auto in return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59111 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Mon Dec 23 12:14:56 2013 New Revision: 206177 URL: http://gcc.gnu.org/viewcvs?rev=206177root=gccview=rev Log: PR c++/59111 cp/ * search.c (lookup_conversions): Return NULL_TREE if !CLASS_TYPE_P. testsuite/ * g++.dg/cpp0x/pr59111.C: New test. * g++.dg/cpp1y/pr59110.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr59111.C trunk/gcc/testsuite/g++.dg/cpp1y/pr59110.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/search.c trunk/gcc/testsuite/ChangeLog
[Bug lto/59582] LTO discards symbol that defined as weak elsewhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59582 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-23 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Please try binutils 2.24.
[Bug rtl-optimization/57422] [4.9 Regression] ICE: SIGSEGV in dominated_by_p with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57422 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #7 from H.J. Lu hjl.tools at gmail dot com --- Please add the testcase.
[Bug rtl-optimization/57422] [4.9 Regression] ICE: SIGSEGV in dominated_by_p with custom flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57422 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Andrey Belevantsev abel at gcc dot gnu.org --- See the thread in gcc-patches: the test does not make sense as it is very sensitive on the scheduler decisions -- even now I had to use the exact reported revision to get the failure. I have added extra asserts in the separate commit instead.
[Bug c++/59111] [4.9 Regression] [c++11] ICE on invalid usage of auto in return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59111 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug middle-end/59584] New: [4.9 Regression]: gcc.dg/pr50251.c ICE exposed by Don't reject TER unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59584
Bug ID: 59584
Summary: [4.9 Regression]: gcc.dg/pr50251.c ICE exposed by
Don't reject TER unnecessarily
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: hp at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Host: x86_64-unknown-linux-gnu
Target: cris-axis-elf
This test previously passed, now it fails.
A patch in the revision range (last_known_working:first_known_failing)
206008:206011 exposed or caused this regression. Since then it fails as
follows:
Running /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/dg.exp ...
...
FAIL: gcc.dg/pr50251.c (internal compiler error)
FAIL: gcc.dg/pr50251.c (test for excess errors)
In gcc.log:
Executing on host: /tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/gcc/
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/pr50251.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O2 -S -isystem
/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/./newlib/targ-include -isystem
/tmp/hpautotest-gcc1/gcc/newlib/libc/include -o pr50251.s(timeout = 300)
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/pr50251.c: In function 'main':
/tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/pr50251.c:18:1: internal compiler
error: in fixup_args_size_notes, at expr.c:3978
0x698221 fixup_args_size_notes(rtx_def*, rtx_def*, int)
/tmp/hpautotest-gcc1/gcc/gcc/expr.c:3978
0x67aef9 try_split(rtx_def*, rtx_def*, int)
/tmp/hpautotest-gcc1/gcc/gcc/emit-rtl.c:3602
0x886e61 split_insn
/tmp/hpautotest-gcc1/gcc/gcc/recog.c:2850
0x887104 split_all_insns()
/tmp/hpautotest-gcc1/gcc/gcc/recog.c:2940
0x8871d2 rest_of_handle_split_after_reload
/tmp/hpautotest-gcc1/gcc/gcc/recog.c:3889
0x8871d2 execute
/tmp/hpautotest-gcc1/gcc/gcc/recog.c:3918
Please submit a full bug report,
with preprocessed source if appropriate.
(as the test-case is without preprocessing directives no such action necessary)
A few more hints from gdb shows that gcc ties itself in a knot when splitting:
(set (reg/f:SI 14 sp) (mem/f/c:SI (symbol_ref:SI (p)))
into:
(gdb) call debug_rtx_range (seq, 0)
(insn 33 0 34 (set (reg/f:SI 14 sp)
(symbol_ref:SI (p) var_decl 0x77eb2000 p)) -1
(nil))
(insn 34 33 0 (set (reg/f:SI 14 sp)
(mem/f/c:SI (reg/f:SI 14 sp) [2 p+0 S4 A8])) -1
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil)))
(nil)
While this define_split has a bug (by matching sp, allowing to set the stack
temporarily in an inconsistent state by using sp as a temporary for the
symbol), I doubt that's the actual bug causing internal inconsistency within
gcc. Anyway:
(gdb) r -fpreprocessed pr50251.i -melf -quiet -dumpbase pr50251.c
-auxbase-strip pr50251.s -O2 -version -fno-diagnostics-show-caret
-fdiagnostics-color=never -o pr50251.s
GNU C (GCC) version 4.9.0 20131223 (experimental) [trunk revision 206176]
(cris-elf)
compiled by GNU C version 4.4.4 20100630 (Red Hat 4.4.4-10), GMP
version 4.3.0, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.9.0 20131223 (experimental) [trunk revision 206176]
(cris-elf)
compiled by GNU C version 4.4.4 20100630 (Red Hat 4.4.4-10), GMP
version 4.3.0, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: cc4b37aa04284e09676146c2c3d35a20
Breakpoint 1, fancy_abort (file=0xd4f878 /tmp/hpautotest-gcc1/gcc/gcc/expr.c,
line=3978,
function=0xd50d50 fixup_args_size_notes) at
/tmp/hpautotest-gcc1/gcc/gcc/diagnostic.c:1182
1182{
Missing separate debuginfos, use: debuginfo-install glibc-2.11.1-1.x86_64
libgcc-4.4.4-10.fc12.x86_64 libstdc++-4.4.4-10.fc12.x86_64
(gdb) up
#1 0x00698222 in fixup_args_size_notes (prev=0x0, last=value
optimized out,
end_args_size=value optimized out) at
/tmp/hpautotest-gcc1/gcc/gcc/expr.c:3978
3978 gcc_assert (!saw_unknown);
(gdb) p prev
(gdb) p prev
$1 = (rtx_def *) 0x0
(gdb) p last
$2 = value optimized out
(gdb) up
#2 0x0067aefa in try_split (pat=value optimized out,
trial=0x77ea47e0, last=1)
at /tmp/hpautotest-gcc1/gcc/gcc/emit-rtl.c:3602
3602 fixup_args_size_notes (NULL_RTX, insn_last, INTVAL (XEXP
(note, 0)));
(gdb) p insn_last
$3 = (rtx_def *) 0x77ea4c60
(gdb) p note
$4 = (rtx_def *) 0x77ea2df8
(gdb) pr
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil))
(gdb) call debug_rtx_range ($3, 0)
(insn 34 33 0 (set (reg/f:SI 14 sp)
(mem/f/c:SI (reg/f:SI 14 sp) [2 p+0 S4 A8])) -1
(expr_list:REG_ARGS_SIZE (const_int 0 [0])
(nil)))
(nil)
(gdb) bt
#0 fancy_abort
[Bug middle-end/59584] [4.9 Regression]: gcc.dg/pr50251.c ICE exposed by Don't reject TER unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59584 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Are you sure it didn't fail before r205026 as well, because what my patch did was essentially restore the old behavior unless strictly necessary (then it would keep the r205026+ behavior).
[Bug middle-end/59584] [4.9 Regression]: gcc.dg/pr50251.c ICE exposed by Don't reject TER unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59584 --- Comment #2 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #1) Are you sure it didn't fail before r205026 as well, because what my patch did was essentially restore the old behavior unless strictly necessary (then it would keep the r205026+ behavior). Sounds like you have a good grip on the circumstances. :) There was no reason to check for earlier failure ranges, but it certainly failed before and with r205023, started passing with r205046 up until as noted. So, I guess this will be a low-priority PR, particularly as it uses an odd builtin-construct very unlikely to be seen in user code - not to mention it will also be hidden behind a target-specific fix.
[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59573
--- Comment #6 from Dennis Lan (dlan) dennis.yxun at gmail dot com ---
(In reply to Yvan Roux from comment #5)
is the foundation model failing for the same reason here (i.e. not
recognizing the cmeq instruction) ?
Not exactly, the foundation_v8 got abort while compiling gcc..
and yes, it does recognize the cmeq instruction.
to clarify, the former gcc build log[1] I provided was generated in qemu which
have *no* cmeq support.
I do have a patch[2] for qemu which implement cmeq support (which I tested
passed), yes, could if anyone can review those patches[3]
for the qemu which implement cmeq, it does pass the glibc compilation and
install successfully, but with the new glibc, gcc fail to build executable
image[4]
[1] http://gcc.gnu.org/bugzilla/attachment.cgi?id=31498
[2]
https://github.com/dlanx/qemu/commit/1a9b3a40917c416125f10accba9e531ed91677d4
[3] git://github.com/dlanx/qemu (branch aarch64-1.6, top four patches)
[4] following output from qemu with cmeq implemented
(202940) insn # gcc -v
Using built-in specs.
COLLECT_GCC=/usr/aarch64-unknown-linux-gnu/gcc-bin/4.9.0-pre/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-unknown-linux-gnu/4.9.0-pre/lto
-wrapper
Target: aarch64-unknown-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.9.0_pre/work/gcc-4.9.0-999
9/configure --prefix=/usr
--bindir=/usr/aarch64-unknown-linux-gnu/gcc-bin/4.9.0-
pre
--includedir=/usr/lib/gcc/aarch64-unknown-linux-gnu/4.9.0-pre/includ
e --datadir=/usr/share/gcc-data/aarch64-unknown-linux-gnu/4.9.0-pre
--mandir
=/usr/share/gcc-data/aarch64-unknown-linux-gnu/4.9.0-pre/man
--infodir=/usr/
share/gcc-data/aarch64-unknown-linux-gnu/4.9.0-pre/info
--with-gxx-include-d
ir=/usr/lib/gcc/aarch64-unknown-linux-gnu/4.9.0-pre/include/g++-v4
--host=aa
rch64-unknown-linux-gnu --build=aarch64-unknown-linux-gnu --disable-altivec
--di
sable-fixed-point --without-cloog --disable-lto --enable-nls
--without-included-
gettext --with-system-zlib --enable-obsolete --disable-werror
--enable-secureplt
--disable-multilib --disable-libmudflap --disable-libssp --enable-libgomp
--wit
h-python-dir=/share/gcc-data/aarch64-unknown-linux-gnu/4.9.0-pre/python
--en
able-checking=release --disable-libgcj --enable-libstdcxx-time
--enable-language
s=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit
--$
nable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gento
o 4.9.0_pre'
Thread model: posix
gcc version 4.9.0-pre 20130926 (experimental) commit
07ca5686e64d32f7df4ccf4
205d0b914f120da5e (Gentoo 4.9.0_pre)
(202940) insn # cat cmeq_test.c
#include stdio.h
#include stdlib.h
long long fn(long long val)
{
asm volatile(
fmov d0, x0\n\t
cmeq d0, d0, #0\n\t
fmov x0, d0\n\t
);
}
int main(int argc, char *argv[])
{
long long v = strtoul(argv[1], NULL, 0);
printf(result: 0x%lx, 0x%lx\n, v, fn(v));
return 0;
}
(202940) insn # ./cmeq_test 1
result: 0x1, 0x0
(202940) insn # ./cmeq_test 0
result: 0x0, 0x
(202940) insn # ./cmeq_test 0x00
result: 0x00, 0x0
(202940) insn # gcc -o mytest_v4 mytest_v4.c
/usr/lib/gcc/aarch64-unknown-linux-gnu/4.9.0-pre/../../../../aarch64-unknown-linux-gnu/bin/ld:
error: Cannot change output format whilst linking AArch64 binaries.
collect2: error: ld returned 1 exit status
(the above cmeq_test was built with sane gcc - with 07ca5686e64 reverted)
[Bug sanitizer/59585] Tests failing due to trailing newline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59585 --- Comment #1 from Yury Gribov y.gribov at samsung dot com --- Created attachment 31503 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31503action=edit Draft patch
[Bug sanitizer/59585] New: Tests failing due to trailing newline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59585 Bug ID: 59585 Summary: Tests failing due to trailing newline Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: y.gribov at samsung dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, mpolacek at gcc dot gnu.org, tetra2005 at gmail dot com, v.garbuzov at samsung dot com Host: x86_64-unknown-linux-gnu Target: arm-v7a15-linux-gnueabi Created attachment 31502 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31502action=edit Log file Hi folks, I've tested ubsan in cross-gcc on ARM platform and got a series of similiar errors: FAIL: c-c++-common/ubsan/div-by-zero-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none \ output pattern test, is /home/ygribov/gcc/gcc-master/gcc/testsuite/c-c++-common/ubsan/div-by-zero-1.c:11:5: runtime error: division by zero /home/ygribov/gcc/gcc-master/gcc/testsuite/c-c++-common/ubsan/div-by-zero-1.c:12:5: runtime error: division by zero /home/ygribov/gcc/gcc-master/gcc/testsuite/c-c++-common/ubsan/div-by-zero-1.c:13:5: runtime error: division by zero /home/ygribov/gcc/gcc-master/gcc/testsuite/c-c++-common/ubsan/div-by-zero-1.c:14:5: runtime error: division by zero /home/ygribov/gcc/gcc-master/gcc/testsuite/c-c++-common/ubsan/div-by-zero-1.c:15:5: runtime error: division by zero, should match division by zero( |^M |^M)[^ ^M]*division by zero( |^M |^M)[^ ^M]*division by zero( |^M |^M)[^ ^M]*division by zero( |^M |^M)[^ ^M]*division by zero( |^M |^M) Extract from log file attached.
[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569 --- Comment #11 from meibf at gcc dot gnu.org --- Author: meibf Date: Mon Dec 23 15:07:58 2013 New Revision: 206179 URL: http://gcc.gnu.org/viewcvs?rev=206179root=gccview=rev Log: 2013-12-23 Bingfeng Mei b...@broadcom.com PR middle-end/59569 * tree-vect-stmts.c (vectorizable_store): Skip permutation for consant operand, and add a few missing \n. * gcc.c-torture/compile/pr59569-1.c: New test. * gcc.c-torture/compile/pr59569-2.c: Ditto. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr59569-1.c trunk/gcc/testsuite/gcc.c-torture/compile/pr59569-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug fortran/59577] OpenMP: ICE with type(c_ptr) in private()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59577 --- Comment #1 from Thomas Needham 06needhamt at gmail dot com --- Also occurs in version 4.8.2
[Bug fortran/59577] OpenMP: ICE with type(c_ptr) in private()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59577 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-23 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Also occurs in version 4.8.2 And all versions I have tested down to 4.3.1.
[Bug c++/41090] [4.7/4.8/4.9 Regression] Using static label reference in c++ class constructor produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090 --- Comment #19 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Mon Dec 23 17:49:47 2013 New Revision: 206182 URL: http://gcc.gnu.org/viewcvs?rev=206182root=gccview=rev Log: PR c++/41090 Add -fdeclone-ctor-dtor. gcc/cp/ * optimize.c (can_alias_cdtor, populate_clone_array): Split out from maybe_clone_body. (maybe_thunk_body): New function. (maybe_clone_body): Call it. * mangle.c (write_mangled_name): Remove code to suppress writing of mangled name for cloned constructor or destructor. (write_special_name_constructor): Handle decloned constructor. (write_special_name_destructor): Handle decloned destructor. * method.c (trivial_fn_p): Handle decloning. * semantics.c (expand_or_defer_fn_1): Clone after setting linkage. gcc/c-family/ * c.opt: Add -fdeclone-ctor-dtor. * c-opts.c (c_common_post_options): Default to on iff -Os. gcc/ * cgraph.h (struct cgraph_node): Add calls_comdat_local. (symtab_comdat_local_p, symtab_in_same_comdat_p): New. * cif-code.def: Add USES_COMDAT_LOCAL. * symtab.c (verify_symtab_base): Make sure we don't refer to a comdat-local symbol from outside its comdat. * cgraph.c (verify_cgraph_node): Likewise. * cgraphunit.c (mark_functions_to_output): Don't mark comdat-locals. * ipa.c (symtab_remove_unreachable_nodes): Likewise. (function_and_variable_visibility): Handle comdat-local fns. * ipa-cp.c (determine_versionability): Don't clone comdat-locals. * ipa-inline-analysis.c (compute_inline_parameters): Update calls_comdat_local. * ipa-inline-transform.c (inline_call): Likewise. (save_inline_function_body): Don't clear DECL_COMDAT_GROUP. * ipa-inline.c (can_inline_edge_p): Check calls_comdat_local. * lto-cgraph.c (input_overwrite_node): Read calls_comdat_local. (lto_output_node): Write it. * symtab.c (symtab_dissolve_same_comdat_group_list): Clear DECL_COMDAT_GROUP for comdat-locals. include/ * demangle.h (enum gnu_v3_ctor_kinds): Added literal gnu_v3_unified_ctor. (enum gnu_v3_ctor_kinds): Added literal gnu_v3_unified_dtor. libiberty/ * cp-demangle.c (cplus_demangle_fill_ctor,cplus_demangle_fill_dtor): Handle unified ctor/dtor. (d_ctor_dtor_name): Handle unified ctor/dtor. Added: trunk/gcc/testsuite/g++.dg/ext/label13a.C trunk/gcc/testsuite/g++.dg/opt/declone1.C Modified: trunk/gcc/ChangeLog trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-opts.c trunk/gcc/c-family/c.opt trunk/gcc/cgraph.c trunk/gcc/cgraph.h trunk/gcc/cgraphunit.c trunk/gcc/cif-code.def trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/mangle.c trunk/gcc/cp/method.c trunk/gcc/cp/optimize.c trunk/gcc/cp/semantics.c trunk/gcc/doc/invoke.texi trunk/gcc/ipa-cp.c trunk/gcc/ipa-inline-analysis.c trunk/gcc/ipa-inline-transform.c trunk/gcc/ipa-inline.c trunk/gcc/ipa.c trunk/gcc/lto-cgraph.c trunk/gcc/symtab.c trunk/include/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c
[Bug c++/41090] [4.7/4.8/4.9 Regression] Using static label reference in c++ class constructor produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|4.8.3 |4.9.0 --- Comment #20 from Jason Merrill jason at gcc dot gnu.org --- Fixed for 4.9.
[Bug middle-end/59584] [4.9 Regression]: gcc.dg/pr50251.c ICE exposed by Don't reject TER unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59584 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- So is this actually a regression then (I mean, has it worked in 4.8 or 4.7 etc.)?
[Bug c++/59349] [4.9 Regression] ICE on invalid: Segmentation fault toplev.c:336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59349 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/59586] New: Segmentation fault with -Ofast -floop-parallelize-all -ftree-parallelize-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586 Bug ID: 59586 Summary: Segmentation fault with -Ofast -floop-parallelize-all -ftree-parallelize-loops Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: chaosgate at gmail dot com Created attachment 31504 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31504action=edit Test case This code results in the following segfault when compiled with gfortran -o /dev/null -c -Ofast -floop-parallelize-all -ftree-parallelize-loops=1 -fopenmp t3.f t3.f: In function ‘subsm’: t3.f:1:0: internal compiler error: Segmentation fault subroutine subsm ( n, x, xp, xx) ^ Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gcc -v: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/paludis/build/sys-devel-gcc-4.8.2/work/gcc-4.8.2/configure --prefix=/usr --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --disable-silent-rules --enable-fast-install --libdir=/usr/lib64 --cache-file=config.cache --libdir=/usr/lib64 --with-pkgversion='exherbo gcc-4.8.2' --program-suffix=-4.8 --disable-bootstrap --enable-clocale=gnu --enable-languages=c,c++,fortran,java --enable-lto --disable-multilib --enable-nls --enable-serial-configure --enable-libquadmath --enable-libquadmath-support --with-cloog --enable-libgomp --disable-libobjc --disable-libssp --with-as=x86_64-pc-linux-gnu-as --with-ld=x86_64-pc-linux-gnu-ld --with-system-zlib Thread model: posix gcc version 4.8.2 (exherbo gcc-4.8.2)
[Bug tree-optimization/59586] Segmentation fault with -Ofast -floop-parallelize-all -ftree-parallelize-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-23 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed for 4.8.2 and trunk with -O3 -ffast-math -floop-parallelize-all, but no ICE for 4.5.4, 4.6.4, and 4.7.3. Likely a 4.8/4.9 regression. I'll try to bisect when I find some time.
[Bug target/59587] New: cpu_names in i386.c is accessed with wrong index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59587
Bug ID: 59587
Summary: cpu_names in i386.c is accessed with wrong index
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
i386.c has
static const char *const cpu_names[TARGET_CPU_DEFAULT_max] =
{
generic,
...
btver2
};
...
if (!opts-x_ix86_tune_string)
{
opts-x_ix86_tune_string = cpu_names[TARGET_CPU_DEFAULT];
ix86_tune_defaulted = 1;
}
...
fprintf (file, %*sarch = %d (%s)\n,
indent, ,
ptr-arch,
((ptr-arch TARGET_CPU_DEFAULT_max)
? cpu_names[ptr-arch]
: unknown));
fprintf (file, %*stune = %d (%s)\n,
indent, ,
ptr-tune,
((ptr-tune TARGET_CPU_DEFAULT_max)
? cpu_names[ptr-tune]
: unknown));
But ptr-arch and ptr-tune are set by
ptr-arch = ix86_arch;
ptr-schedule = ix86_schedule;
ptr-tune = ix86_tune;
ix86_arch is set by
/* Which instruction set architecture to use. */
enum processor_type ix86_arch;
ix86_arch = processor_alias_table[i].processor;
and ix86_tune is set by
/* Which cpu are we optimizing for. */
enum processor_type ix86_tune;
ix86_tune = processor_alias_table[i].processor;
We are using enum processor_type as index to access array of
enum target_cpu_default
enum target_cpu_default
{
TARGET_CPU_DEFAULT_generic = 0,
...
TARGET_CPU_DEFAULT_max
};
x86 backend only uses TARGET_CPU_DEFAULT_generic to set up the
default tuning:
#ifndef TARGET_CPU_DEFAULT
#define TARGET_CPU_DEFAULT TARGET_CPU_DEFAULT_generic
#endif
...
if (!opts-x_ix86_tune_string)
{
opts-x_ix86_tune_string = cpu_names[TARGET_CPU_DEFAULT];
ix86_tune_defaulted = 1;
}
We never define a different TARGET_CPU_DEFAULT. When GCC is
configured with --with-arch=/--with-cpu=, we have
[hjl@gnu-6 build-x86_64-linux]$ cat gcc/configargs.h
/* Generated automatically. */
static const char configuration_arguments[] =
/export/gnu/import/git/gcc/configure --enable-languages=c,c++,fortran
--disable-bootstrap --prefix=/usr/gcc-4.9.0 --with-local-prefix=/usr/local
--enable-gnu-indirect-function --with-fpmath=sse;
static const char thread_model[] = posix;
static const struct {
const char *name, *value;
} configure_default_options[] = { { cpu, generic }, { arch, x86-64 } };
[hjl@gnu-6 build-x86_64-linux]$
which passes -march=/-mtune= to toplev.c.
[Bug middle-end/59584] [4.9 Regression]: gcc.dg/pr50251.c ICE exposed by Don't reject TER unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59584 --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) So is this actually a regression then (I mean, has it worked in 4.8 or 4.7 etc.)? That's not the definition. At one point it work on trunk (4.9) thus it's a regression.
[Bug middle-end/59584] [4.9 Regression]: gcc.dg/pr50251.c ICE exposed by Don't reject TER unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59584 --- Comment #5 from Hans-Peter Nilsson hp at gcc dot gnu.org --- The actual bug causing the ICE is that the combination of expr.c:find_args_size_adjust and expr.c:fixup_args_size_notes\ can't handle a define_split matching for the stack-adjustment assignment instruction emitted by __builtin_stack_restor\ e. I'm going to mark my commit for the CRIS port with this PR number (since it fixes the regression per se), but it will j\ ust remove the define_split part happening for the CRIS port; the bug is still there so the PR should not be closed. Though, I'll change the title.
[Bug target/59587] cpu_names in i386.c is accessed with wrong index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59587 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 31505 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31505action=edit A patch I am testing this patch.
[Bug middle-end/59584] [4.9 Regression]: gcc.dg/pr50251.c ICE exposed by Don't reject TER unnecessarily
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59584 --- Comment #6 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Author: hp Date: Mon Dec 23 22:33:52 2013 New Revision: 206187 URL: http://gcc.gnu.org/viewcvs?rev=206187root=gccview=rev Log: PR middle-end/59584 * config/cris/predicates.md (cris_nonsp_register_operand): New define_predicate. * config/cris/cris.md: Replace register_operand with cris_nonsp_register_operand for destinations in all define_splits where a register is set more than once. Modified: trunk/gcc/ChangeLog trunk/gcc/config/cris/cris.md trunk/gcc/config/cris/predicates.md
[Bug middle-end/59584] [4.9 Regression]: cannot handle define_split for insn emitted for __builtin_stack_restore
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59584 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Summary|[4.9 Regression]: |[4.9 Regression]: cannot |gcc.dg/pr50251.c ICE|handle define_split for |exposed by Don't reject|insn emitted for |TER unnecessarily |__builtin_stack_restore
[Bug target/59588] New: Odd codes in ix86_option_override_internal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59588
Bug ID: 59588
Summary: Odd codes in ix86_option_override_internal
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
ix86_option_override_internal has
if (opts-x_ix86_arch_string)
opts-x_ix86_tune_string = opts-x_ix86_arch_string;
if (!opts-x_ix86_tune_string)
{
opts-x_ix86_tune_string = cpu_names[TARGET_CPU_DEFAULT];
ix86_tune_defaulted = 1;
}
/* opts-x_ix86_tune_string is set to opts-x_ix86_arch_string
or defaulted. We need to use a sensible tune option. */
if (!strcmp (opts-x_ix86_tune_string, generic)
|| !strcmp (opts-x_ix86_tune_string, x86-64)
|| !strcmp (opts-x_ix86_tune_string, i686))
{
opts-x_ix86_tune_string = generic;
}
Why is opts-x_ix86_tune_string changed to generic. If
opts-x_ix86_tune_string is generic. there is no need to
change it to generic. If an option is valid for -march=,
it should also be valid for -mtune.
[Bug target/59203] config/cris/cris.c:2491: possible typo ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59203 --- Comment #3 from Hans-Peter Nilsson hp at gcc dot gnu.org --- Author: hp Date: Mon Dec 23 23:12:09 2013 New Revision: 206188 URL: http://gcc.gnu.org/viewcvs?rev=206188root=gccview=rev Log: PR target/59203 * config/cris/cris.c (cris_pic_symbol_type_of): Fix typo, checking t1 twice instead of t1 and t2 respectively. Modified: trunk/gcc/ChangeLog trunk/gcc/config/cris/cris.c
[Bug tree-optimization/59586] [4.8/4.9 Regression] [graphite] Segmentation fault with -Ofast -floop-parallelize-all -ftree-parallelize-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||spop at gcc dot gnu.org Summary|Segmentation fault with |[4.8/4.9 Regression] |-Ofast |[graphite] Segmentation |-floop-parallelize-all |fault with -Ofast |-ftree-parallelize-loops|-floop-parallelize-all ||-ftree-parallelize-loops --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Revision r188914 (2012-06-24) is OK, r189336 (2012-07-06) gives the ICE. (gdb) bt #0 0x00010053910b in compute_deps (scop=0x1418bcc00, pbbs=..., must_raw=0xde650, may_raw=0xfc080, must_raw_no_source=0x141907f50, may_raw_no_source=0x141920330, must_war=error reading variable: Could not find the frame base for compute_deps(scop*, vecpoly_bb*, va_heap, vl_ptr, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**)., may_war=error reading variable: Could not find the frame base for compute_deps(scop*, vecpoly_bb*, va_heap, vl_ptr, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**)., must_war_no_source=error reading variable: Could not find the frame base for compute_deps(scop*, vecpoly_bb*, va_heap, vl_ptr, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**)., may_war_no_source=error reading variable: Could not find the frame base for compute_deps(scop*, vecpoly_bb*, va_heap, vl_ptr, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**)., must_waw=error reading variable: Could not find the frame base for compute_deps(scop*, vecpoly_bb*, va_heap, vl_ptr, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**)., may_waw=error reading variable: Could not find the frame base for compute_deps(scop*, vecpoly_bb*, va_heap, vl_ptr, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**)., must_waw_no_source=error reading variable: Could not find the frame base for compute_deps(scop*, vecpoly_bb*, va_heap, vl_ptr, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**)., may_waw_no_source=error reading variable: Could not find the frame base for compute_deps(scop*, vecpoly_bb*, va_heap, vl_ptr, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**, isl_union_map**).) at ../../_clean/gcc/graphite-dependences.c:430 #1 0x00010053965e in loop_is_parallel_p (loop=optimized out, bb_pbb_mapping=..., depth=optimized out) at ../../_clean/gcc/graphite-dependences.c:566 #2 0x000100537597 in translate_clast (context_loop=0x1418bcc00, stmt=0x1419084c0, next_e=0xde650, bb_pbb_mapping=..., level=1099988816, ip=0x141920330) at ../../_clean/gcc/graphite-clast-to-gimple.c:1200 #3 0x00010053793c in gloog (scop=optimized out, bb_pbb_mapping=...) at ../../_clean/gcc/graphite-clast-to-gimple.c:1705 #4 0x00010053200f in graphite_transform_loops () at ../../_clean/gcc/graphite.c:304 #5 0x00010053251a in pass_graphite_transforms::execute (this=optimized out) at ../../_clean/gcc/graphite.c:332 #6 0x00010067c4b9 in execute_one_pass (pass=optimized out) at ../../_clean/gcc/passes.c:2213 #7 0x00010067c74e in execute_pass_list (pass=optimized out) at ../../_clean/gcc/passes.c:2266 #8 0x00010067c760 in execute_pass_list (pass=optimized out) at ../../_clean/gcc/passes.c:2267 #9 0x00010067c760 in execute_pass_list (pass=optimized out) at ../../_clean/gcc/passes.c:2267 #10 0x00010067c760 in execute_pass_list (pass=optimized out) at ../../_clean/gcc/passes.c:2267 #11 0x0001003c66cf in expand_function (node=optimized out) at ../../_clean/gcc/cgraphunit.c:1763
[Bug target/59203] config/cris/cris.c:2491: possible typo ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59203 Hans-Peter Nilsson hp at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Hans-Peter Nilsson hp at gcc dot gnu.org --- done
[Bug target/59587] cpu_names in i386.c is accessed with wrong index
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59587 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Attachment #31505|0 |1 is obsolete|| --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- Created attachment 31506 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31506action=edit An updated patch Test this updated patch.
[Bug fortran/59589] New: Memory leak when deallocating polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589 Bug ID: 59589 Summary: Memory leak when deallocating polymorphic Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Created attachment 31507 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31507action=edit Test code demonstrating leak The attached code leaks memory, as indicated by the 'ps' call.
[Bug fortran/58007] [4.7/4.9 Regression] [OOP] ICE in free_pi_tree(): Unresolved fixup - resolve_fixups does not fixup component of __class_bsr_Bsr_matrix
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58007 --- Comment #11 from Rich Townsend townsend at astro dot wisc.edu --- #6 fails with 4.9.0 (svn rev. 206179), on both OS X and Linux.
[Bug fortran/59589] Memory leak when deallocating polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589 --- Comment #1 from Rich Townsend townsend at astro dot wisc.edu --- Oops, missed out details. This is with rev. 206179, on both OS X and Linux.
[Bug fortran/59589] Memory leak when deallocating polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-24 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Works for me on OS X for 4.8.2 or trunk. What command are you using?
[Bug c/59590] New: gcc produces an infinite loop on O2 optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59590
Bug ID: 59590
Summary: gcc produces an infinite loop on O2 optimization
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: cottrell at wfu dot edu
Created attachment 31508
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31508action=edit
minimal test case
I'm getting an infinite loop with -O2, though the code is compiled
correctly with just -O.
I'm attaching a minimal test case -- but please see also the real
function that exposes the problem: the following is the real
counterpart to fake_gradient() in the minimal case:
static int richardson_gradient (double *b, double *g, int n,
BFGS_CRIT_FUNC func, void *data)
{
double df[RSTEPS];
double eps = 1.0e-4;
double d = 0.0001;
double v = 2.0;
double h, p4m;
double bi0, f1, f2;
int r = RSTEPS;
int i, k, m;
int err = 0;
for (i=0; in; i++) {
bi0 = b[i];
h = d * b[i] + eps * (b[i] == 0.0);
for (k=0; kr; k++) {
b[i] = bi0 - h;
f1 = func(b, data);
b[i] = bi0 + h;
f2 = func(b, data);
if (na(f1) || na(f2)) {
b[i] = bi0;
return 1;
}
df[k] = (f2 - f1) / (2.0 * h);
h /= v;
}
b[i] = bi0;
p4m = 4.0;
for (m=0; mr-1; m++) {
for (k=0; kr-m; k++) {
df[k] = (df[k+1] * p4m - df[k]) / (p4m - 1.0);
// if (k == r-m-1) break;
}
p4m *= 4.0;
}
g[i] = df[0];
}
return err;
}
[Bug fortran/59589] Memory leak when deallocating polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589 --- Comment #3 from Rich Townsend townsend at astro dot wisc.edu --- (In reply to Dominique d'Humieres from comment #2) Works for me on OS X for 4.8.2 or trunk. What command are you using? townsend@talos ~ $ gfortran -v Using built-in specs. COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.9.0/lto-wrapper Target: x86_64-apple-darwin11.4.2 Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0' --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk --with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk --with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran --disable-multilib --disable-nls --disable-libsanitizer Thread model: posix gcc version 4.9.0 20131223 (experimental) (GCC) townsend@talos ~ $ gfortran -o test_leak test_leak.f90 townsend@talos ~ $ ./test_leak ./test_leak 39688 ./test_leak 78764 ./test_leak 117828 ./test_leak 156908 ./test_leak 195972 ./test_leak 235036 ./test_leak 274100 ./test_leak 313164 ./test_leak 352228 ./test_leak 391292 ...so, the memory usage grows on each iteration of the loop; this suggests a leak.
[Bug c/59590] gcc produces an infinite loop on O2 optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59590 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- df[k+1] reads past the bounds of df as k is 0...RSTEPS-1 so k+1 is 1...RSTEPS and the bounds of df is 0...RSTEPS-1.
[Bug target/59573] aarch64: commit 07ca5686e64 broken glibc-2.17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59573 --- Comment #7 from Dennis Lan (dlan) dennis.yxun at gmail dot com --- Ok, it's qemu problem, not gcc. I've built rootfs in qemu (with cmeq insn implemented), then deploy the rootfs into foudation_v8 emulator. test to compiles code with gcc, and it works fine, without the linker error.
[Bug c/59590] gcc produces an infinite loop on O2 optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59590 --- Comment #2 from Allin Cottrell cottrell at wfu dot edu --- OK, you're right, there's an off-by-one bug in the second k-loop. But it's not very nice that gcc takes that as a license to produce an infinite loop. However, I guess that makes this report a duplicate of some others that have made the same observation.
[Bug c++/59349] [4.9 Regression] ICE on invalid: Segmentation fault toplev.c:336
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59349 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Dec 24 04:22:15 2013 New Revision: 206192 URL: http://gcc.gnu.org/viewcvs?rev=206192root=gccview=rev Log: PR c++/59349 * parser.c (cp_parser_lambda_introducer): Handle empty init. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-init7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/59271] [4.9 Regression] a.C:16:21: internal compiler error: in strip_typedefs, at cp/tree.c:1315
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59271 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Dec 24 04:22:23 2013 New Revision: 206193 URL: http://gcc.gnu.org/viewcvs?rev=206193root=gccview=rev Log: PR c++/59271 * lambda.c (build_capture_proxy): Use build_cplus_array_type. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-vla1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/lambda.c
[Bug lto/59582] LTO discards symbol that defined as weak elsewhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59582 --- Comment #2 from Joey Ye joey.ye at arm dot com --- Lastest binutils trunk still has this issue. I'm assuming 2.24 the same.
