[Bug bootstrap/63787] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63787 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- I think the issue is older, see PR61773 comment 5.
[Bug sanitizer/63788] New: ICE: SIGSEGV in contains_struct_check with -O -fsanitize=undefined on almost any fortran code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63788 Bug ID: 63788 Summary: ICE: SIGSEGV in contains_struct_check with -O -fsanitize=undefined on almost any fortran code Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz 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 Created attachment 33925 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33925action=edit reduced testcase Compiler output: $ gcc -O -fsanitize=undefined testcase.f ==32638== Invalid read of size 2 ==32638==at 0xEA80B8: contains_struct_check (tree.h:2864) ==32638==by 0xEA80B8: build_call_expr_loc_array(unsigned int, tree_node*, int, tree_node**) (tree.c:10556) ==32638==by 0xEA8240: build_call_expr_loc(unsigned int, tree_node*, int, ...) (tree.c:10589) ==32638==by 0xC62757: instrument_object_size(gimple_stmt_iterator*, bool) (ubsan.c:1522) ==32638==by 0xC664F0: (anonymous namespace)::pass_ubsan::execute(function*) (ubsan.c:1670) ==32638==by 0xB4E9D8: execute_one_pass(opt_pass*) (passes.c:2269) ==32638==by 0xB4EF85: execute_pass_list_1(opt_pass*) (passes.c:2321) ==32638==by 0xB4EFD8: execute_pass_list(function*, opt_pass*) (passes.c:2332) ==32638==by 0xB4D734: do_per_function_toporder(void (*)(function*, void*), void*) (passes.c:1638) ==32638==by 0xB4F5C6: execute_ipa_pass_list(opt_pass*) (passes.c:2670) ==32638==by 0x85A7B4: ipa_passes (cgraphunit.c:2049) ==32638==by 0x85A7B4: symbol_table::compile() (cgraphunit.c:2172) ==32638==by 0x85C357: symbol_table::finalize_compilation_unit() (cgraphunit.c:2325) ==32638==by 0xAAF1C7: write_global_declarations() (langhooks.c:339) ==32638== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==32638== testcase.f:3:0: end ^ internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Almost any fortran code causes this ICE. Tested revisions: r217250 - ICE
[Bug c++/63789] New: g++ -m32 on solaris has trouble finding abs with int64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63789
Bug ID: 63789
Summary: g++ -m32 on solaris has trouble finding abs with
int64_t
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard at netbsd dot org
with the following simplified test program (tabs.cc):
==8===
#include stdint.h
#include stdlib.h
int64_t tabs(int64_t foo)
{
returnabs(foo);
}
=8
building with g++ -m32 -c tabs.cc gives the following error:
tabs.cc: In function ‘int64_t tabs(int64_t)’:
tabs.cc:6:16: error: call of overloaded ‘abs(int64_t)’ is ambiguous
return abs(foo);
^
tabs.cc:6:16: note: candidates are:
In file included from /usr/include/stdlib.h:37:0,
from tabs.cc:2:
/usr/include/iso/stdlib_iso.h:165:16: note: long int std::abs(long int)
inline long abs(long _l) { return labs(_l); }
^
/usr/include/iso/stdlib_iso.h:119:12: note: int std::abs(int)
extern int abs(int);
^
there is no error specifying -m64.
Also, copying tabs.cc to tabs.c and building with gcc gives no error either
('gcc -m32 -c tabs.c' or to be pedantic with -std=c99 added).
I should mention that this seems to work okay with gcc4.4.4, but reproducible
with the compilers accessible, namely gcc47..gcc49.
The test program seems to work fine on NetBSD and FreeBSD.
This platform is SunOS 5.11 (illumos).
[Bug c++/63789] g++ -m32 on solaris has trouble finding abs with int64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63789 --- Comment #1 from Richard PALO richard at netbsd dot org --- I should mention that rendering the test program pure c++ by replacing the first two lines with: #include cstdlib #include cmath allows the snippet build with both -m32 and -m64. It should be able to build as is, though.
[Bug middle-end/63790] New: [5 Regression] Tests XFAILed because of the match-and-simplify merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63790 Bug ID: 63790 Summary: [5 Regression] Tests XFAILed because of the match-and-simplify merge Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org g++.dg/cpp0x/constexpr-reinterpret1.C gcc.dg/tree-ssa/pr21031.c
[Bug middle-end/63790] [5 Regression] Tests XFAILed because of the match-and-simplify merge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63790 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||xfail Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-11-09 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Mine.
[Bug bootstrap/63787] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63787 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Depends on||61773 Target Milestone|--- |5.0
[Bug tree-optimization/63785] [5.0 regression] FAIL: gfortran.dg/transfer_simplify_2.f90 -O0 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63785 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-11-09 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I believe that this is fixed by r217260.
[Bug c++/63657] [4.9/5 regression] -Wunused-variable: warning supressed by virtual dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63657 petschy at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE |--- --- Comment #5 from petschy at gmail dot com --- To further prove my case, here is the disassembly of foo() and bar(). As expected, they are identical, no ctors/dtors are ever called, so there can be no side effects. Dump of assembler code for function foo(): 0x00400766 +0: push %rbp 0x00400767 +1: mov%rsp,%rbp 0x0040076a +4: sub$0x10,%rsp 0x0040076e +8: callq 0x400797 getfoo() 0x00400773 +13:mov%rax,-0x8(%rbp) 0x00400777 +17:leaveq 0x00400778 +18:retq End of assembler dump. Dump of assembler code for function bar(): 0x00400779 +0: push %rbp 0x0040077a +1: mov%rsp,%rbp 0x0040077d +4: sub$0x10,%rsp 0x00400781 +8: callq 0x4007a2 getbar() 0x00400786 +13:mov%rax,-0x8(%rbp) 0x0040078a +17:leaveq 0x0040078b +18:retq End of assembler dump.
[Bug tree-optimization/63778] [5 Regression] Segfault with r217178 building 416.gamess from cpu2006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63778 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-11-09 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |5.0 Summary|Segfault with r217178 |[5 Regression] Segfault |building 416.gamess from|with r217178 building |cpu2006 |416.gamess from cpu2006 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I believe this was fixed with r217214 and thus is a dup of PR63770.
[Bug c++/63789] g++ -m32 on solaris has trouble finding abs with int64_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63789 --- Comment #2 from Marc Glisse glisse at gcc dot gnu.org --- long long (or int64_t) is not part of C++03, so solaris headers don't provide the overload. We complete the set of overloads in c* headers, but there is a well known bug that we don't provide wrappers for the *.h headers. It would be interesting to see how Oracle is updating the solaris headers for C++11.
[Bug c/63791] New: use 32-byte version of vpbroadcastb on AVX2 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63791 Bug ID: 63791 Summary: use 32-byte version of vpbroadcastb on AVX2 platform Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: marcus.kool at urlfilterdb dot com Created attachment 33926 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33926action=edit code with _mm256_set1_epi8, _mm256_loadu_si256, _mm256_cmpeq_epi8, _mm256_movemask_epi8 With gcc 4.9.2 and compile options -std=c99 -mavx2 -mbmi -mbmi2 -O3 -fno-tree-vectorize on an Intel Haswell CPU the intrinsic function _mm256_set1_epi8() generates 3 instructions while it could do better with only 2 instructions. Generated code is either vmovd reg, xmmreg vpbroadcastb xmmreg, xmmreg vinserti128 $1, xmmreg, ymmreg, ymmreg or vmovd reg, xmmreg vpbroadcastb xmmreg, xmmreg vperm2i128$0, ymmreg, ymmreg, ymmreg But it could generate faster code instead: vmovd reg, xmmreg vpbroadcastb xmmreg, ymmreg Example C source is in the attachment.
[Bug bootstrap/63740] [4.9 Regression] GCC 4.9.2 bootstrap fails on ARM, haifa-sched.c:6507:1: internal compiler error: in lra_create
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63740 --- Comment #7 from Aaro Koskinen aaro.koskinen at iki dot fi --- Result from bisection (4.9 git branch): 611da9dd72a4c9d9ece2a8d24612e4aee435414a is the first bad commit commit 611da9dd72a4c9d9ece2a8d24612e4aee435414a Author: jakub jakub@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Wed Oct 1 14:42:46 2014 + Backported from mainline 2014-09-18 Vladimir Makarov vmaka...@redhat.com PR debug/63285 * haifa-sched.c (schedule_block): Advance cycle at the end of BB if advance != 0.
[Bug sanitizer/63788] ICE: SIGSEGV in contains_struct_check with -O -fsanitize=undefined on almost any fortran code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63788 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-09 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- I see the ICE at r216153 (2014-10-13), r216016 (2014-10-08) is OK.
[Bug other/63792] New: libcc1 doesn't built i386 multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63792
Bug ID: 63792
Summary: libcc1 doesn't built i386 multilib
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: howarth at bromo dot med.uc.edu
On x86_64-apple-darwin, using the bootstrap fixes from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773 at r217238, the libcc1 code
isn't built as a -m32 i386 multilib. Shouldn't there be an entry like...
target_modules = { module= libcc1; lib_path=.libs; };
in Makefile.def to achieve this or is something else required?
[Bug middle-end/63793] New: -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793 Bug ID: 63793 Summary: -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT) Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: howarth at bromo dot med.uc.edu The src_flexwrf_v3.1 package from http://flexpart.eu/downloads/src_flexwrf_v3.1.tar.gz fails to link on x86_64 darwin when compiled with the required -mcmodel=medium option due to a code generation bug that the darwin linker fails on. The offending file is compiled with... gfortran -c -I/sw/include -fno-common -mcmodel=medium -fconvert=little-endian -finit-local-zero -fno-range-check convmix_kfeta.f90 and the linkage later fails as... gfortran *.o -o flexwrf31_gnu_serial -L/sw/lib -fno-common -mcmodel=medium -fconvert=little-endian -finit-local-zero -fno-range-check -L/sw/lib -lnetcdff final section layout: __TEXT/__text addr=0x117F5, size=0x00126A11, fileOffset=0x17F5, type=1 __TEXT/__stubs addr=0x100128206, size=0x023A, fileOffset=0x00128206, type=28 __TEXT/__stub_helper addr=0x100128440, size=0x03C6, fileOffset=0x00128440, type=32 __TEXT/__cstring addr=0x100128808, size=0x0B97, fileOffset=0x00128808, type=13 __TEXT/__const addr=0x1001293A0, size=0xA6BC, fileOffset=0x001293A0, type=0 __TEXT/__eh_frame addr=0x100133A60, size=0x4598, fileOffset=0x00133A60, type=19 __DATA/__got addr=0x100138000, size=0x02B8, fileOffset=0x00138000, type=29 __DATA/__nl_symbol_ptr addr=0x1001382B8, size=0x0010, fileOffset=0x001382B8, type=29 __DATA/__la_symbol_ptr addr=0x1001382C8, size=0x02F8, fileOffset=0x001382C8, type=27 __DATA/__data addr=0x1001385C0, size=0x08F0, fileOffset=0x001385C0, type=0 __DATA/__common addr=0x100138EC0, size=0x00EC, fileOffset=0x, type=25 __DATA/__bss5 addr=0x100138FC0, size=0x0070, fileOffset=0x, type=25 __DATA/__pu_bss5 addr=0x100139040, size=0x17F0, fileOffset=0x, type=25 __DATA/__bss6 addr=0x10013A840, size=0x00855AF4, fileOffset=0x, type=25 __DATA/__pu_bss2 addr=0x100990334, size=0x047C, fileOffset=0x, type=25 __DATA/__pu_bss6 addr=0x1009907C0, size=0x01EBCAA8, fileOffset=0x, type=25 __DATA/__pu_bss3 addr=0x10284D268, size=0x0010, fileOffset=0x, type=25 __DATA/__pu_bss4 addr=0x10284D280, size=0x001C, fileOffset=0x, type=25 __DATA/__bss2 addr=0x10284D29C, size=0x0020, fileOffset=0x, type=25 __DATA/__huge addr=0x10284D2C0, size=0x129E8DD40, fileOffset=0x, type=25 ld: 32-bit RIP relative reference out of range (4246534707 max is +/-4GB): from _convmix_kfeta_ (0x100058E3C) to _sumpartgrid.2471 (0x1FD229580) in '_convmix_kfeta_' from convmix_kfeta.o for architecture x86_64 collect2: error: ld returned 1 exit status The darwin linker developer has provided the following analysis of this bug... --- This is a little known aspect of x86_64 mach-o that allows the use of the small code model everywhere (that is not need a large code model). When the compiler references “large” ( = 1MB) zero-fill data, it should do it through the GOT (instead of direct RIP relative reference). When the linker lays out the output, if it is bigger than 2GB, it moves all large zero-fill symbols to a new __DATA,__huge section which the linker puts last. As long as all the uses of moved large data is through the GOT, this just works and you can have very large mach-o binaries. In this case the file from convmix_kfeta.o defines _sumpartgrid.2471 (which is a 4MB zero-fill symbol) but that same file has a reference to _sumpartgrid.2471 from the function _convmix_kfeta_ that is RIP relative (instead of using the GOT).
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793 --- Comment #1 from howarth at bromo dot med.uc.edu --- Created attachment 33927 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33927action=edit assembly file for convex_kfeta.s on x86_64 darwin14 Generated with gfortran -c -I/sw/include -fno-common -mcmodel=medium -fconvert=little-endian -finit-local-zero -fno-range-check convmix_kfeta.f90 --save-temps
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793 --- Comment #2 from howarth at bromo dot med.uc.edu --- Unfortunately, due to the number of modules required by convex_kfeta.f90, it is impossible to create a small test case. However this problem can be reproduced by downloading the src_flexwrf_v3.1.tar.bz2 source code and executing... make -f makefile.mom serial
[Bug other/39363] [meta-bug] pending patches from ARC International (UK) Ltd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39363 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added Depends on|31634 | --- Comment #1 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- 31634 used to be relevant for ARC, but that port has since ceased to support changing the name if TEXT_SECTION_ASM_OP etc. by command line option, and uses now a string literal, precisely in order to work around this bug.
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793 --- Comment #3 from howarth at bromo dot med.uc.edu --- Note that the default makefile.mom in the source tarball can be linked against the libnetcdff installed from the fink (http://finkproject.org) netcdf-fortran7/netcdf-fortran7-shlibs packages.
[Bug pch/31634] *_SECTION_ASM_OP storage has undocumented constraints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31634 --- Comment #4 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- 31634 used to be relevant for ARC, but that port has since ceased to support changing the name if TEXT_SECTION_ASM_OP etc. by command line option, and uses now a string literal, precisely in order to work around this bug. Hence, this no longer blocks other/39363 .
[Bug middle-end/63794] New: -mcmodel=large in gfortran on x86_64 emits references junk `@GOTOFF' after expression on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63794 Bug ID: 63794 Summary: -mcmodel=large in gfortran on x86_64 emits references junk `@GOTOFF' after expression on darwin Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: howarth at bromo dot med.uc.edu The src_flexwrf_v3.1 package from http://flexpart.eu/downloads/src_flexwrf_v3.1.tar.gz fails to compile on x86_64 darwin with the -mcmodel=large option at the error... gfortran -c -I/sw/include -mcmodel=large -fconvert=little-endian -finit-local-zero -fno-range-check cmapf_mod.f90 /var/tmp//ccy9jxUR.s:32:junk `@GOTOFF' after expression /var/tmp//ccy9jxUR.s:35:junk `@GOTOFF' after expression /var/tmp//ccy9jxUR.s:40:junk `@GOTOFF' after expression ... in the Xcode 6.1 as assembler.
[Bug middle-end/63794] -mcmodel=large in gfortran on x86_64 emits references junk `@GOTOFF' after expression on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63794 --- Comment #1 from howarth at bromo dot med.uc.edu --- Created attachment 33928 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33928action=edit assembly for cmapf_mod.f90 compiled with -mcmodel=large on x86_64 darwin Produced with gfortran -c -I/sw/include -mcmodel=large -fconvert=little-endian -finit-local-zero -fno-range-check cmapf_mod.f90 --save-temps
[Bug middle-end/63794] -mcmodel=large in gfortran on x86_64 emits references junk `@GOTOFF' after expression on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63794 --- Comment #3 from howarth at bromo dot med.uc.edu --- Note that the default makefile.mom in the source tarball can be linked against the libnetcdff installed from the fink (http://finkproject.org) netcdf-fortran7/netcdf-fortran7-shlibs packages.
[Bug middle-end/63794] -mcmodel=large in gfortran on x86_64 emits references junk `@GOTOFF' after expression on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63794 --- Comment #2 from howarth at bromo dot med.uc.edu --- Unfortunately, due to the number of modules required cmapf_mod.f90, it is impossible to create a small test case. However this problem can be reproduced by downloading the src_flexwrf_v3.1.tar.bz2 source code and executing... make -f makefile.mom serial
[Bug target/39346] no mxp target port
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39346 --- Comment #2 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- target/39346, other/39347 and other/39348 are no longer relevant to other/39363, because the Successor of ARC International (UK) Ltd, Synopsys, does not offer an mxp option in its DesignWare ARC Processor Cores lineup.
[Bug middle-end/63794] -mcmodel=large in gfortran on x86_64 emits references junk `@GOTOFF' after expression on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63794 --- Comment #4 from howarth at bromo dot med.uc.edu --- I am unclear if this is a code-generation bug or if the assembly generated in gfortran 4.9.2 for the cmapf_mod.f90 sources using -mcmodel=large is tickling a bug in the legacy gas (as) in Xcode 6.1. # as -version Apple Inc version cctools-862, GNU assembler version 1.38
[Bug other/39363] [meta-bug] pending patches from ARC International (UK) Ltd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39363 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added Depends on|39347, 39348| --- Comment #2 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- target/39346, other/39347 and other/39348 are no longer relevant to other/39363, because the Successor of ARC International (UK) Ltd, Synopsys, does not offer an mxp option in its DesignWare ARC Processor Cores lineup.
[Bug middle-end/63794] -mcmodel=large in gfortran on x86_64 emits references junk `@GOTOFF' after expression on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63794 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Probably related to pr50077.
[Bug libstdc++/63780] std::remquo returns wrong quotient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63780 --- Comment #3 from Charles Karney charles at karney dot com --- Thanks Jonathan. I've submitted a glibc bug report using your version. See https://sourceware.org/bugzilla/show_bug.cgi?id=17569
[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793 --- Comment #4 from howarth at bromo dot med.uc.edu --- The offending instructions can be seen with... % grep _sumpartgrid.2471 convmix_kfeta.s leaq_sumpartgrid.2471(%rip), %rax leaq_sumpartgrid.2471(%rip), %rax leaq_sumpartgrid.2471(%rip), %rdx leaq_sumpartgrid.2471(%rip), %rdx leaq_sumpartgrid.2471(%rip), %rdx .zerofill __DATA,__bss6,_sumpartgrid.2471,400,6
[Bug c/63795] New: Noreturn failure (test case builtin-noret-1.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63795
Bug ID: 63795
Summary: Noreturn failure (test case builtin-noret-1.c)
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: fxcoudert at gcc dot gnu.org
On x86_64-apple-darwin14, the following noreturn-related testcases fail with
internal compiler errors, at optimization levels -Os, -O2 and above:
gcc.dg/torture/builtin-noret-1.c
gcc.dg/torture/builtin-noret-2.c
A reduced testcase is:
---
#pragma weak _exit
#pragma weak _Exit
void _exit (int i)
{
__builtin_abort ();
}
void _Exit (int i)
{
__builtin_abort ();
}
---
The issue is related to to ipa-icf, as demonstrated by the backtrace:
* thread #1: tid = 0x68e3f7, 0x0001007a790a
cc1`ipa_merge_profiles(dst=0x, src=0x000142c12498) + 10 at
ipa-utils.c:413, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x2)
frame #0: 0x0001007a790a cc1`ipa_merge_profiles(dst=0x,
src=0x000142c12498) + 10 at ipa-utils.c:413
410 bool match = true;
411
412 if (!src-definition
- 413 || !dst-definition)
414 return;
415 if (src-frequency dst-frequency)
416 src-frequency = dst-frequency;
(lldb) bt
* thread #1: tid = 0x68e3f7, 0x0001007a790a
cc1`ipa_merge_profiles(dst=0x, src=0x000142c12498) + 10 at
ipa-utils.c:413, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=1, address=0x2)
* frame #0: 0x0001007a790a cc1`ipa_merge_profiles(dst=0x,
src=0x000142c12498) + 10 at ipa-utils.c:413
frame #1: 0x00010079300b
cc1`ipa_icf::sem_function::merge(this=unavailable, alias_item=unavailable)
+ 667 at ipa-icf.c:683
frame #2: 0x00010079895f
cc1`ipa_icf::sem_item_optimizer::merge_classes(this=unavailable,
prev_class_count=unavailable) + 879 at ipa-icf.c:2288
frame #3: 0x00010079d052
cc1`ipa_icf::sem_item_optimizer::execute(this=0x000141e1cfd0) + 338 at
ipa-icf.c:1648
frame #4: 0x00010079de52
cc1`ipa_icf::pass_ipa_icf::execute(this=unavailable, (null)=unavailable) +
18 at ipa-icf.c:2366
frame #5: 0x00010088dd7b cc1`execute_one_pass(pass=0x000141e0ec50)
+ 395 at passes.c:2269
frame #6: 0x00010088ea5a
cc1`execute_ipa_pass_list(pass=0x000141e0ec50) + 154 at passes.c:2663
frame #7: 0x0001004d8ec9 cc1`symbol_table::compile() + 197 at
cgraphunit.c:2088
frame #8: 0x0001004d8e04
cc1`symbol_table::compile(this=0x000142c05000) + 1188
frame #9: 0x0001004dad3e
cc1`symbol_table::finalize_compilation_unit(this=0x000142c05000) + 110 at
cgraphunit.c:2325
frame #10: 0x000100021109 cc1`c_write_global_declarations() + 601 at
c-decl.c:10779
frame #11: 0x000100968d4f cc1`compile_file + 143 at toplev.c:583
frame #12: 0x000100e80c74 cc1`toplev::main(this=unavailable, argc=4,
argv=0x7fff5fbff9b8) + 3764 at toplev.c:2013
frame #13: 0x000100e8129c cc1`main(argc=4, argv=0x7fff5fbff9b8) +
44 at main.c:38
frame #14: 0x7fff8e0895c9 libdyld.dylib`start + 1
frame #15: 0x7fff8e0895c9 libdyld.dylib`start + 1
[Bug c/63795] ipa-icf ICE with noreturn functions (test case builtin-noret-1.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63795 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-apple-darwin14 Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-09 CC||iains at gcc dot gnu.org, ||marxin at gcc dot gnu.org Host||x86_64-apple-darwin14 Summary|Noreturn failure (test case |ipa-icf ICE with noreturn |builtin-noret-1.c) |functions (test case ||builtin-noret-1.c) Ever confirmed|0 |1 Build||x86_64-apple-darwin14
[Bug c/63795] ipa-icf ICE with noreturn functions (test case builtin-noret-1.c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63795 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- One of the many fall out of the IPA_ICF commit: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c7. The ICE disappears if you compile with -fno-ipa-icf.
[Bug tree-optimization/63778] [5 Regression] Segfault with r217178 building 416.gamess from cpu2006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63778 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Target|powerpc64-unknown-linux-gnu | Status|WAITING |NEW Host|powerpc64-unknown-linux-gnu | Build|powerpc64-unknown-linux-gnu | --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- I can reproduce it on Linux/x86-64 with r217256.
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573 --- Comment #12 from Andreas Schwab sch...@linux-m68k.org --- This also breaks g++.dg/ipa/pr63587-2.C on powerpc -m32, but the patches in #c6 and #c8 don't fix that. $ gcc/xg++ -Bgcc/ ../gcc/testsuite/g++.dg/ipa/pr63587-2.C -nostdinc++ -Ipowerpc64-linux/32/libstdc++-v3/include/powerpc64-linux -Ipowerpc64-linux/32/libstdc++-v3/include -I../libstdc++-v3/libsupc++ -I../libstdc++-v3/include/backward -I../libstdc++-v3/testsuite/util -std=gnu++11 -O2 -S -m32 -o pr63587-2.s ../gcc/testsuite/g++.dg/ipa/pr63587-2.C: In static member function ‘static int boost::function_obj_invoker0FunctionObj::invoke(boost::function_buffer) [with FunctionObj = boost::test_case_template_invokerdefault_formatting_invoker]’: ../gcc/testsuite/g++.dg/ipa/pr63587-2.C:21:3: internal compiler error: in expand_expr_addr_expr_1, at expr.c:7725
[Bug sanitizer/63788] ICE: SIGSEGV in contains_struct_check with -O -fsanitize=undefined on almost any fortran code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63788 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Mine.
[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018
--- Comment #8 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org ---
(In reply to Francois-Xavier Coudert from comment #7)
Richard, I am willing to debug this, but don't know where to go after the
above analysis.
I think it's a libgcc miscompilation somehow. Directly calling __addvsi3 as
follows:
int __addvsi3 (int, int);
int main (void)
{ volatile int x = __addvsi3 (__INT_MAX__, 1); }
does not abort, even though (in my understanding) it should.
[Bug sanitizer/63788] ICE: SIGSEGV in contains_struct_check with -O -fsanitize=undefined on almost any fortran code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63788 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Supposed BUILT_IN_OBJECT_SIZE builtin decl isn't wired. So, either you need to avoid instrumenting -fsanitize=object-size, if it is NULL, or e.g. initialize_sanitizer_builtins needs to create the __builtin_object_size builtin if it is not created by the FE. As that built-in isn't a sanitizer built-in, thus not in sanitizer.def, supposedly you could just copy the: DEF_GCC_BUILTIN(BUILT_IN_OBJECT_SIZE, object_size, BT_FN_SIZE_CONST_PTR_INT, ATTR_PURE_NOTHROW_LEAF_LIST) line below #include sanitizer.def in asan.c.
[Bug c/63791] use 32-byte version of vpbroadcastb on AVX2 platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63791 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-09 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- This got fixed on the trunk with r216541. As it isn't a regression, I think no plans to backport that, there have been lots of permutation/broadcast changes and improvements on the trunk, most of them related to AVX512, but some of them AVX2 specific too.
[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620 --- Comment #27 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Sun Nov 9 16:45:15 2014 New Revision: 217265 URL: https://gcc.gnu.org/viewcvs?rev=217265root=gccview=rev Log: 2014-11-09 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/63620 * lra-constraints.c (substitute_pseudo): Add prefix lra_ to the name. Move to lra.c. Make it external. (substitute_pseudo_within_insn): Ditto. (inherit_reload_reg, split_reg, remove_inheritance_pseudos): Use the new names. (undo_optional_reloads): Ditto. * lra-int.h (lra_dump_bitmap_with_title, lra_substitute_pseudo): New prototypes. (lra_substitute_pseudo_within_insn): Ditto. * lra-lives.c (bb_killed_pseudos, bb_gen_pseudos): New. (mark_regno_live): Add parameter. Update bb_gen_pseudos. (mark_regno_dead): Add parameter. Update bb_gen_pseudos and bb_killed_pseudos. (struct bb_data, bb_data_t, bb_data): New. (get_bb_data, get_bb_data_by_index): Ditto. (all_hard_regs_bitmap): New. (live_trans_fun, live_con_fun_0, live_con_fun_n, all_blocks): New. (initiate_live_solver, finish_live_solver): New. (process_bb_lives): Change return type. Add code updating local live data and removing dead insns. Pass new argument to mark_regno_live and mark_regno_dead. Check changing bb pseudo life info. Return the result. (lra_create_live_ranges): Add code to do global pseudo live analysis. (lra_live_ranges_init): Call initiate_live_solver. (lra_live_ranges_finish): Call finish_live_solver. * lra.c (lra_dump_bitmap_with_title): New. (lra_substitute_pseudo, lra_substitute_pseudo_within_insn): Move from lra-constraints.c. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-constraints.c trunk/gcc/lra-int.h trunk/gcc/lra-lives.c trunk/gcc/lra.c
[Bug bootstrap/63784] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63784 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com --- A patch is posted at https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00737.html
[Bug tree-optimization/63796] New: [5.0 regression] FAIL: g++.dg/ipa/devirt-42.C -std=gnu++11 scan-tree-dump-times optimized return 2 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63796 Bug ID: 63796 Summary: [5.0 regression] FAIL: g++.dg/ipa/devirt-42.C -std=gnu++11 scan-tree-dump-times optimized return 2 2 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: hubicka at ucw dot cz Target: powerpc64-*-* $ gcc/xg++ -Bgcc/ ../gcc/gcc/testsuite/g++.dg/ipa/devirt-42.C -nostdinc++ -Ipowerpc64-linux/libstdc++-v3/include/powerpc64-linux -Ipowerpc64-linux/libstdc++-v3/include -I../gcc/libstdc++-v3/libsupc++ -I../gcc/libstdc++-v3/include/backward -I../gcc/libstdc++-v3/testsuite/util -std=gnu++11 -O3 -fno-ipa-cp -fdump-ipa-inline-details -fno-early-inlining -fdump-tree-optimized -S -m64 -o devirt-42.s grep -c return 2 devirt-42.C.*.optimized 3
[Bug c++/63657] [4.9/5 regression] -Wunused-variable: warning supressed by virtual dtor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63657 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||paolo.carlini at oracle dot com --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- It occurs to me that a pretty robust (and in principle easy to implement) way to decide whether we want to suppress the warning or not would be storing in a flag of the VAR_DECL whether set_up_extended_ref_temp has been called on it. However, I don't think we have any unused flag... Jason, what do you think?
[Bug fortran/63797] New: Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 Bug ID: 63797 Summary: Bogus ambiguous reference to 'sqrt' Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Reported by David Smith on COMP-FORTRAN-90, https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=comp-fortran-90;75486336.1411 The following code is rejected with: y = sqrt(x) 1 Error: Name 'sqrt' at (1) is an ambiguous reference to 'sqrt' from module '(intrinsic)' Malcolm Cohen writes: cut I don't see anything wrong with this. Neither does the NAG compiler. module mod1 !double precision :: max_allowed = 1.0d+75 double precision :: max_allowed = sqrt(sqrt(huge(max_allowed))) This will result in the intrinsic SQRT being exported from MOD1. This is not a problem in the standard, which indeed allows this, but I guess this is the source of the problem... interface sqrt module procedure sqrt_pair Here is the second SQRT, this is a user-defined generic name. y = sqrt(x) Here is the line that gfortran complains about. At this point there are indeed two SQRT's visible. But the Fortran standard explicitly allows this: (I'm quoting the draft F2015 here, but similar text exists in every standard since Fortran 90.) Two or more accessible entities, other than generic interfaces or defined operators, may have the same local identifier only if the identifier is not used. Generic interfaces and defined operators are handled as described in 12.4.3.4. Both the intrinsic SQRT and the user-defined SQRT are generic, so the first sentence does not apply, and the second sentence does. In other words, you are allowed to import the same generic name from different modules, as long as that generic follows the rules in 12.4.3.4 (which lay out requirements on non-ambiguity, both being subroutines or both being functions, etc.). 12.4.3.4 goes on for pages in excruciating detail which I will not reproduce here! So this looks like a simple gfortran bug to me. Doubtless you could work around it by putting a PRIVATE SQRT statement in mod1 (since you probably did not intend to export the intrinsic SQRT from there anyway). /cut And here's the code: cut module mod1 !double precision :: max_allowed = 1.0d+75 double precision :: max_allowed = sqrt(sqrt(huge(max_allowed))) integer :: kw = 6 end module mod1 module mod2 type pair double precision :: a_pair(2) = (/ 0, 0 /) end type interface sqrt module procedure sqrt_pair end interface contains function sqrt_pair(a) use mod1 implicit none type (pair) :: a, sqrt_pair intent (in) :: a sqrt_pair%a_pair(1) = min( sqrt(a%a_pair(1)), max_allowed ) sqrt_pair%a_pair(2) = min( sqrt(a%a_pair(2)), max_allowed ) end function sqrt_pair end module mod2 program test use mod1 use mod2 type (pair) x, y x%a_pair(1) = 1.23d+100 x%a_pair(2) = 1.23d+200 y = sqrt(x) write (kw,*) ' y = ', y%a_pair(1), y%a_pair(2) end program test
[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63797 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-09 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.4.5, 4.8.3, 5.0
[Bug target/55023] hppa: wrong code generated with tail call optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55023 --- Comment #7 from dave.anglin at bell dot net --- On 7-Nov-14, at 5:24 PM, law at redhat dot com wrote: Is the setup for the memory store different? ie, in the sibcall case are we making it hard for DSE to see that we have argument stores? different base register perhaps? Your suspicion appears correct. When we optimize sibling calls, the argument stores use the frame pointer (%r3). When sibcalls are not optimized, the stores use the stack pointer (%r30). Dave -- John David Anglindave.ang...@bell.net
[Bug testsuite/63305] ASan reported heap-buffer-overflow in gcc.target/i386/avx256-unaligned-load{store}-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63305
--- Comment #4 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org ---
Author: hjl
Date: Sun Nov 9 18:01:12 2014
New Revision: 217269
URL: https://gcc.gnu.org/viewcvs?rev=217269root=gccview=rev
Log:
Fix buffer overflow in avx256-unaligned-{load|store}-7.c
Backported from mainline
PR testsuite/63305
* gcc.target/i386/avx256-unaligned-load-7.c (avx_test): Fix
buffer overflow.
* gcc.target/i386/avx256-unaligned-store-7.c (avx_test): Likewise.
Modified:
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-load-7.c
branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/avx256-unaligned-store-7.c
[Bug testsuite/63305] ASan reported heap-buffer-overflow in gcc.target/i386/avx256-unaligned-load{store}-7.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63305 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.3 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com --- Fixed on trunk and 4.9 branch.
[Bug c/63782] avoid implicit declaration warning for incompatible builtin implicit declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63782 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-09 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334 Tim O'Neil tim at matterfab dot com changed: What|Removed |Added CC||tim at matterfab dot com --- Comment #49 from Tim O'Neil tim at matterfab dot com --- In the hope this will help, I try to stay pretty current: --- $ clang++ --version Ubuntu clang version 3.5-1ubuntu1 (trunk) (based on LLVM 3.5) Target: x86_64-pc-linux-gnu Thread model: posix $ clang++ -Wall -std=c++11 bugtest.c -o bugtest clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated $ ./bugtest terminate called after throwing an instance of 'std::length_error' what(): basic_string::_S_create Aborted [Exit 134 SIGABRT] $ clang++ -Wall -std=c++11 -stdlib=libc++ bugtest.c -o bugtest clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated $ ./bugtest $ g++ --version g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 Copyright (C) 2013 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. $ g++ -Wall -std=c++11 bugtest.c -o bugtest $ ./bugtest terminate called after throwing an instance of 'std::length_error' what(): basic_string::_S_create Aborted [Exit 134 SIGABRT] $
[Bug libstdc++/21334] Lack of Posix compliant thread safety in std::basic_string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21334 --- Comment #50 from Tim O'Neil tim at matterfab dot com --- (In reply to Tim O'Neil from comment #49) In the hope this will help, I try to stay pretty current: Oh, this is using the code James posted on 2005-05-02 above.
[Bug bootstrap/63573] [5 Regression] libgo: ICE building libgo on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63573 --- Comment #13 from Andreas Schwab sch...@linux-m68k.org --- Also breaks gcc.dg/tree-ssa/ldist-19.c (both -m32 and -m64). $ gcc/xgcc -Bgcc/ ../gcc/gcc/testsuite/gcc.dg/tree-ssa/ldist-19.c -O3 -fdump-tree-ldist-details -S -m32 -o ldist-19.s grep -c generated memset ldist-19.c.* 4
[Bug c/43797] __attribute__((deprecated(message))) produces unexpected messages in some cases.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43797 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Target|ia32-pc-linux, | |i686-apple-darwin9 | Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-09 CC||fxcoudert at gcc dot gnu.org Version|4.6.0 |5.0 Ever confirmed|0 |1 --- Comment #4 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Still exists on trunk, target-independent.
[Bug bootstrap/32537] Boostrap failure: ICE when compiling gengtype-lex.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32537 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Test results have been posted for ppc-darwin in the last 2.5 years, so this has apparently been fixed.
[Bug java/32010] bootstrap fails; chooses wrong zlib for building jc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32010 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||fxcoudert at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- I don't know the current status of this bug. Let's close it, but of course feel free to reopen if it still is an issue. In that case, a documentation patch would be appreciated.
[Bug bootstrap/61763] [4.9 Regression] bootstrap with -O3 gives comparison failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61763 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-09 CC||fxcoudert at gcc dot gnu.org Summary|[4.9 Regression] gcc-4.9.0 |[4.9 Regression] bootstrap |4.9.1 Bootstrap comparison |with -O3 gives comparison |failure! when |failure |bootstrapping with -O3 | Ever confirmed|0 |1 --- Comment #7 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- I'm not sure what we want to do here… on one hand, bootstrapping with -O3 is asking for trouble, but on the other hand I'm not sure it's explicitly unsupported.
[Bug rtl-optimization/63620] RELOAD lost SET_GOT dependency on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620 --- Comment #28 from Uroš Bizjak ubizjak at gmail dot com --- (In reply to Vladimir Makarov from comment #27) Author: vmakarov Date: Sun Nov 9 16:45:15 2014 New Revision: 217265 Unfortunately, the patch does not fix the Reproducer for linux testcase when the patch from comment 19 is reverted.
[Bug tree-optimization/63798] New: [5.0 regression] FAIL: gcc.target/powerpc/ppc-fmadd-1.c scan-assembler-not f(add|sub|mul|neg)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63798 Bug ID: 63798 Summary: [5.0 regression] FAIL: gcc.target/powerpc/ppc-fmadd-1.c scan-assembler-not f(add|sub|mul|neg) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: rguenther at suse dot de Target: powerpc*-*-* $ gcc/xgcc -Bgcc/ ../gcc/gcc/testsuite/gcc.target/powerpc/ppc-fmadd-1.c -ffast-math -O2 -ffat-lto-objects -S -m32 -o ppc-fmadd-1.s grep -Ec f(add|sub|mul|neg) ppc-fmadd-1.s 4 f619ecaed41d1487091098a0f4fdf4d6ed1fa379 is the first bad commit commit f619ecaed41d1487091098a0f4fdf4d6ed1fa379 Author: rguenth rguenth@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Mon Oct 27 11:30:23 2014 + 2014-10-27 Richard Biener rguent...@suse.de * tree-ssa-forwprop.c: Include tree-cfgcleanup.h and tree-into-ssa.h. (lattice): New global. (fwprop_ssa_val): New function. (fold_all_stmts): Likewise. (pass_forwprop::execute): Finally fold all stmts.
[Bug rtl-optimization/63799] New: [5 Regression] r217265 caused libjava failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63799 Bug ID: 63799 Summary: [5 Regression] r217265 caused libjava failures Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: vmakarov at redhat dot com On Linux/ia32, r217265 caused: FAIL: Array_3 execution - source compiled test FAIL: Array_3 -findirect-dispatch execution - source compiled test FAIL: Array_3 -O3 -findirect-dispatch execution - source compiled test FAIL: Divide_2 execution - source compiled test FAIL: Divide_2 -findirect-dispatch execution - source compiled test
[Bug bootstrap/63699] Bootstrap fails in libcc1 on darwin14
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63699 --- Comment #5 from howarth at bromo dot med.uc.edu --- Posted patch at https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00662.html. Note that the alternate approach of modifying gcc/system.h to include string conditionally on __cplusplus before safe-ctype.h causes bootstrap breakage elsewhere on darwin.
[Bug bootstrap/63750] use of undeclared identifier 'do_not_use_isalnum_with_safe_ctype'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63750 --- Comment #4 from howarth at bromo dot med.uc.edu --- Patch posted at https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00661.html. Note that the alternate approach of modifying gcc/system.h to include string conditionally on __cplusplus before safe-ctype.h causes bootstrap breakage elsewhere on darwin.
[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target|x86_64-apple-darwin13 |x86_64-apple-darwin1[34] Last reconfirmed|2014-08-05 00:00:00 |2014-11-9 Component|middle-end |target Host|x86_64-apple-darwin13 |x86_64-apple-darwin1[34] Build|x86_64-apple-darwin13 |x86_64-apple-darwin1[34] --- Comment #9 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Some more debugging, and finally a victory: I understand what happens. But I don't know how to fix it. 0. With my testcase from comment #8, compiling with -static-libgcc makes the executable have the desired behavior (abort), but compiling without it (or with -shared-libgcc) makes it not abort. 1. Yet forcing to compile with the shared object file (_addvsi3_s.o) leads to correct result (abort). So, it's not a miscomputation. 2. Running the -shared-libgcc executable with DYLD_PRINT_LIBRARIES=y shows that it's loading the correct libgcc_s: dyld: loaded: /Users/fx/devel/gcc/irun2/./a.out dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /usr/local/gfortran/lib/libgcc_s.1.dylib 3. But running it with DYLD_PRINT_BINDINGS=y shows that our ___addvsi3 does not get pulled from libgcc_s.1.dylib, as we'd like, but from the system's libcompiler_rt.dylib (which has, apparently, a faulty version of this symbol for backward compatibility reasons): dyld: lazy bind: a.out:0x10D212010 = libcompiler_rt.dylib:___addvsi3, *0x10D212010 = 0x7FFF9158BF67 4. And confirmation: forcing it to resolve symbols from libgcc_s.1.dylib, by saying DYLD_FORCE_FLAT_NAMESPACE=y DYLD_INSERT_LIBRARIES=/usr/local/gfortran/lib/libgcc_s.1.dylib, makes the executable have the expected behavior (aborts). --- Conclusion: it's really a darwin bug. We need to have symbols taken from our own libgcc override those from the system's libcompiler_rt (which is itself pulled from libSystem, if I understand correctly). Any idea how we achieve that?
[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 --- Comment #10 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Francois-Xavier Coudert from comment #9) Some more debugging, and finally a victory: I understand what happens. But I don't know how to fix it. 0. With my testcase from comment #8, compiling with -static-libgcc makes the executable have the desired behavior (abort), but compiling without it (or with -shared-libgcc) makes it not abort. 1. Yet forcing to compile with the shared object file (_addvsi3_s.o) leads to correct result (abort). So, it's not a miscomputation. Great! 2. Running the -shared-libgcc executable with DYLD_PRINT_LIBRARIES=y shows that it's loading the correct libgcc_s: dyld: loaded: /Users/fx/devel/gcc/irun2/./a.out dyld: loaded: /usr/lib/libSystem.B.dylib dyld: loaded: /usr/local/gfortran/lib/libgcc_s.1.dylib 3. But running it with DYLD_PRINT_BINDINGS=y shows that our ___addvsi3 does not get pulled from libgcc_s.1.dylib, as we'd like, but from the system's libcompiler_rt.dylib (which has, apparently, a faulty version of this symbol for backward compatibility reasons): dyld: lazy bind: a.out:0x10D212010 = libcompiler_rt.dylib:___addvsi3, *0x10D212010 = 0x7FFF9158BF67 4. And confirmation: forcing it to resolve symbols from libgcc_s.1.dylib, by saying DYLD_FORCE_FLAT_NAMESPACE=y DYLD_INSERT_LIBRARIES=/usr/local/gfortran/lib/libgcc_s.1.dylib, makes the executable have the expected behavior (aborts). --- Conclusion: it's really a darwin bug. We need to have symbols taken from our own libgcc override those from the system's libcompiler_rt (which is itself pulled from libSystem, if I understand correctly). Any idea how we achieve that? ld64 should pull the symbol from the first place that mentions it on the link line. It should place the two-level namespace information in the exe so that the symbol is resolved from the correct place at runtime. Can you confirm this? if that's the case potential solutions: (a) more fiddling with library ordering in the specs (b) we could punt on the hope of ever getting the extension shared library to play nicely with the already installed stuff and revert to putting these items in a crt. This would be a static lib and mentioned on the link-line would take precedence over the system ones. *sigh* also on my TODO is tidying up the maze of twisty passages that constitutes the crt/libgcc_s/libcc_ext support across the darwin patch. This is where we have a huge challenge c.f. other systems since it's not acceptable for end Users to just install some new libs into some part of /usr/ as root. Thus we have to make whatever we do interact well with what's already there.
[Bug target/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62018 --- Comment #11 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #10) ld64 should pull the symbol from the first place that mentions it on the link line. It should place the two-level namespace information in the exe so that the symbol is resolved from the correct place at runtime. Can you confirm this? Linking simply with gcc a.c -ftrapv calls collect2 with (removed the -L options for clarity): collect2 -dynamic -arch x86_64 -macosx_version_min 10.10.0 -weak_reference_mismatches non-weak -o a.out a.o -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v and in turn ld with: ld -dynamic -arch x86_64 -macosx_version_min 10.10.0 -weak_reference_mismatches non-weak -o a.out a.o -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v If I manually call collect2 with -lgcc_ext.10.5 -lgcc -lSystem instead of -lSystem -lgcc_ext.10.5 -lgcc -lSystem (removing the first -lSystem), then the executable aborts it should. So: (a) more fiddling with library ordering in the specs It so happens that gcc/config/darwin10.h says: Fix PR47558 by linking against libSystem ahead of libgcc_ext. So it looks like this is going to be fun!
[Bug tree-optimization/63800] New: ICE on valid code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63800
Bug ID: 63800
Summary: ICE on valid code at -O3 on x86_64-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux-gnu in both 32-bit and 64-bit modes.
It is a regression from 4.9.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/5.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 5.0.0 20141108 (experimental) [trunk revision 217256] (GCC)
$ gcc-trunk -O2 -c small.c
$ gcc-4.9 -O3 -c small.c
$
$ gcc-trunk -O3 -c small.c
small.c: In function ‘fn1’:
small.c:4:1: internal compiler error: Segmentation fault
fn1 ()
^
0xa32bff crash_signal
../../gcc-trunk/gcc/toplev.c:358
0xbf5d90 update_dep_bb
../../gcc-trunk/gcc/tree-ssa-tail-merge.c:427
0xbf8a68 stmt_update_dep_bb
../../gcc-trunk/gcc/tree-ssa-tail-merge.c:457
0xbf8a68 same_succ_hash
../../gcc-trunk/gcc/tree-ssa-tail-merge.c:481
0xbf8a68 find_same_succ_bb
../../gcc-trunk/gcc/tree-ssa-tail-merge.c:742
0xbf91ac find_same_succ
../../gcc-trunk/gcc/tree-ssa-tail-merge.c:773
0xbf91ac init_worklist
../../gcc-trunk/gcc/tree-ssa-tail-merge.c:792
0xbf91ac tail_merge_optimize(unsigned int)
../../gcc-trunk/gcc/tree-ssa-tail-merge.c:1682
0xbb197f execute
../../gcc-trunk/gcc/tree-ssa-pre.c:4831
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.
$
int a, b, c, d[2];
int
fn1 ()
{
int f = 0;
d[1] = b = 1;
for (; b; b--)
{
for (c = 0; c 2; c++)
{
d[b] 1 b;
if (d[0])
f = d[b] * a;
if (f)
return 0;
}
d[b] (d[0] = 0);
}
return 0;
}
[Bug target/55023] hppa: wrong code generated with tail call optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55023 --- Comment #8 from dave.anglin at bell dot net --- find_call_stack_args() is not called for sibcalls. It seemed at first that it needed to be called from mark_insn to mark the arguments of sibcalls but it can't handle arguments stored using the argument pointer and a similar use in the call pattern. It starting to look like I should just disable sibcalls on PA. Dave -- John David Anglindave.ang...@bell.net
[Bug fortran/47007] Values from namelist file should not depend on locale settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 --- Comment #24 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Mon Nov 10 00:17:16 2014 New Revision: 217273 URL: https://gcc.gnu.org/viewcvs?rev=217273root=gccview=rev Log: PR 47007 and 61847 Locale failures in libgfortran. 2014-11-10 Janne Blomqvist j...@gcc.gnu.org PR libfortran/47007 PR libfortran/61847 * config.h.in: Regenerated. * configure: Regenerated. * configure.ac (AC_CHECK_HEADERS_ONCE): Check for xlocale.h. (AC_CHECK_FUNCS_ONCE): Check for newlocale, freelocale, uselocale, strerror_l. * io/io.h (locale.h): Include. (xlocale.h): Include if present. (c_locale): New variable. (old_locale): New variable. (old_locale_ctr): New variable. (old_locale_lock): New variable. (st_parameter_dt): Add old_locale member. * io/transfer.c (data_transfer_init): Set locale to C if doing formatted transfer. (finalize_transfer): Reset locale to previous. * io/unit.c (c_locale): New variable. (old_locale): New variable. (old_locale_ctr): New variable. (old_locale_lock): New variable. (init_units): Init c_locale, init old_locale_lock. (close_units): Free c_locale. * runtime/error.c (locale.h): Include. (xlocale.h): Include if present. (gf_strerror): Use strerror_l if available. Reset locale to LC_GLOBAL_LOCALE for strerror_r branch. 2014-11-10 Janne Blomqvist j...@gcc.gnu.org PR libfortran/47007 PR libfortran/61847 * gfortran.texi: Add note about locale issues to thread-safety section. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unit.c trunk/libgfortran/runtime/error.c
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #24 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Mon Nov 10 00:17:16 2014 New Revision: 217273 URL: https://gcc.gnu.org/viewcvs?rev=217273root=gccview=rev Log: PR 47007 and 61847 Locale failures in libgfortran. 2014-11-10 Janne Blomqvist j...@gcc.gnu.org PR libfortran/47007 PR libfortran/61847 * config.h.in: Regenerated. * configure: Regenerated. * configure.ac (AC_CHECK_HEADERS_ONCE): Check for xlocale.h. (AC_CHECK_FUNCS_ONCE): Check for newlocale, freelocale, uselocale, strerror_l. * io/io.h (locale.h): Include. (xlocale.h): Include if present. (c_locale): New variable. (old_locale): New variable. (old_locale_ctr): New variable. (old_locale_lock): New variable. (st_parameter_dt): Add old_locale member. * io/transfer.c (data_transfer_init): Set locale to C if doing formatted transfer. (finalize_transfer): Reset locale to previous. * io/unit.c (c_locale): New variable. (old_locale): New variable. (old_locale_ctr): New variable. (old_locale_lock): New variable. (init_units): Init c_locale, init old_locale_lock. (close_units): Free c_locale. * runtime/error.c (locale.h): Include. (xlocale.h): Include if present. (gf_strerror): Use strerror_l if available. Reset locale to LC_GLOBAL_LOCALE for strerror_r branch. 2014-11-10 Janne Blomqvist j...@gcc.gnu.org PR libfortran/47007 PR libfortran/61847 * gfortran.texi: Add note about locale issues to thread-safety section. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/libgfortran/ChangeLog trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c trunk/libgfortran/io/unit.c trunk/libgfortran/runtime/error.c
[Bug fortran/61847] bug in gfortran runtime: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #25 from Janne Blomqvist jb at gcc dot gnu.org --- Fixed on trunk, closing.
[Bug fortran/47007] Values from namelist file should not depend on locale settings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jb at gcc dot gnu.org --- Comment #25 from Janne Blomqvist jb at gcc dot gnu.org --- Fixed on trunk, closing.
[Bug fortran/56744] [meta-bug] Namelist bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56744 Bug 56744 depends on bug 47007, which changed state. Bug 47007 Summary: Values from namelist file should not depend on locale settings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug bootstrap/63771] internal compiler error: in lra_create_copy, at lra.c:1532
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63771 --- Comment #2 from AythanGCC at hotmail dot com --- @ Richard Earnshaw You really should update your assembler. 2008 is pretty ancient. 1. --with-as=/home/slug/optware/cs08q1armel/toolchain/arm-2008q1/bin/arm-none-linux-gnueabi-as is not the assembler I am using. It is the assebler used when the old compiler I am using now was build. This is an older compiler, but the latst pre-compiled ipkg distripution: gcc 4.2.3-1 The GNU Compiler Collection. 2. At first, I was using the as and ld of gnu (binutils), again from the latest pre-compiled ipkg: binutils 2.19.1-1 -- the GNU assembler and linker and related tools. This vesrion dates to 31-Aug-2011 09:50 (http://ftp.gnu.org/gnu/binutils). So it is not that old. 3. Nevertheless, I downloaded, built and installed the latest binutils version: binutils-2.24 02-Dec-2013 05:10(http://ftp.gnu.org/gnu/binutils). 4. This helped with the '.inst' pseudo instruction problem. In the release note, for example at: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob_plain;f=gas/NEWS;hb=refs/tags/binutils-2_24 is says: Changes in 2.20: . . . * ARM assembler now supports .inst[.nw] pseudo-ops to insert opcodes specified in binary rather than text. Hoora ... my pre-compiled 2.19.1 was the lates non-compatible version. 4. OK. So now, aimed with the new 2.14 assembler which I build and installed, I returned the arm.md back to the original, and tried to build again, from scratch. 5. After two days of once again chewing up bits and spitting the out, the make process, once more, stopped, and with, how surprising, same error message a before: /share/homes/admin/Gnu/gcc/gcc-4.9.2-build/./prev-gcc/xg++ -B/share/homes/admin/Gnu/gcc/gcc-4.9.2-build/./prev-gcc/ -B/share/homes/admin/Gnu/gcc/gcc-4.9.2-install/armv5tel-unknown-linux-gnueabi/bin/ -nostdinc++ -B/share/homes/admin/Gnu/gcc/gcc-4.9.2-build/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/src/.libs -B/share/homes/admin/Gnu/gcc/gcc-4.9.2-build/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++/.libs -I/share/homes/admin/Gnu/gcc/gcc-4.9.2-build/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/include/armv5tel-unknown-linux-gnueabi -I/share/homes/admin/Gnu/gcc/gcc-4.9.2-build/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/include -I/share/homes/admin/Gnu/gcc/gcc-4.9.2/libstdc++-v3/libsupc++ -L/share/homes/admin/Gnu/gcc/gcc-4.9.2-build/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/src/.libs -L/share/homes/admin/Gnu/gcc/gcc-4.9.2-build/prev-armv5tel-unknown-linux-gnueabi/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/share/homes/admin/Gnu/gcc/gcc-4.9.2/gcc -I/share/homes/admin/Gnu/gcc/gcc-4.9.2/gcc/. -I/share/homes/admin/Gnu/gcc/gcc-4.9.2/gcc/../include -I/share/homes/admin/Gnu/gcc/gcc-4.9.2/gcc/../libcpp/include -I/share/homes/admin/Gnu/gcc/gcc-4.9.2-build/./gmp -I/share/homes/admin/Gnu/gcc/gcc-4.9.2/gmp -I/share/homes/admin/Gnu/gcc/gcc-4.9.2-build/./mpfr -I/share/homes/admin/Gnu/gcc/gcc-4.9.2/mpfr -I/share/homes/admin/Gnu/gcc/gcc-4.9.2/mpc/src -I/share/homes/admin/Gnu/gcc/gcc-4.9.2/gcc/../libdecnumber -I/share/homes/admin/Gnu/gcc/gcc-4.9.2/gcc/../libdecnumber/dpd -I../libdecnumber -I/share/homes/admin/Gnu/gcc/gcc-4.9.2/gcc/../libbacktrace -DCLOOG_INT_GMP -I/share/homes/admin/Gnu/gcc/gcc-4.9.2-build/./cloog/include -I/share/homes/admin/Gnu/gcc/gcc-4.9.2/cloog/include -I/share/homes/admin/Gnu/gcc/gcc-4.9.2/cloog/include -I/share/homes/admin/Gnu/gcc/gcc-4.9.2-build/./isl/include -I/share/homes/admin/Gnu/gcc/gcc-4.9.2/isl/include -o haifa-sched.o -MT haifa-sched.o -MMD -MP -MF ./.deps/haifa-sched.TPo /share/homes/admin/Gnu/gcc/gcc-4.9.2/gcc/haifa-sched.c /share/homes/admin/Gnu/gcc/gcc-4.9.2/gcc/haifa-sched.c: In function 'bool schedule_block(basic_block_def**, state_t)': /share/homes/admin/Gnu/gcc/gcc-4.9.2/gcc/haifa-sched.c:6507:1: internal compiler error: in lra_create_copy, at lra.c:1532 } ^ no stack trace because unwind library not available Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[3]: *** [haifa-sched.o] Error 1 make[3]: Leaving directory `/share/MD0_DATA/homes/admin/Gnu/gcc/gcc-4.9.2-build/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/share/MD0_DATA/homes/admin/Gnu/gcc/gcc-4.9.2-build' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/share/MD0_DATA/homes/admin/Gnu/gcc/gcc-4.9.2-build' make: *** [all] Error 2 [/share/homes/admin/Gnu/gcc/gcc-4.9.2-build] # 6. So What's next?
[Bug rtl-optimization/63718] [5 Regression] ARM Thumb1 bootstrap fail after fuse-caller-save info in cprop-hardreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63718 --- Comment #9 from Joey Ye joey.ye at arm dot com --- Indeed, the patch is conservative, but that's not such a bad idea for a correctness fix. We can always folllow up with a more optimal patch. Tom, are you going to submit this patch for review, or are you working on a more optimal one? Better to have this conservative patch to recover the bootstrap first. - Joey
[Bug target/55023] hppa: wrong code generated with tail call optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55023
--- Comment #9 from dave.anglin at bell dot net ---
After some more digging, I think the problem is in dse, not dce. It
deletes this instruction
which stores part of the sibcall arguments:
(insn 31 27 50 2 (set (mem:SI (reg/f:SI 115) [0 S4 A64])
(reg:SI 125)) pr55023.c:17 40 {*pa.md:2204}
(expr_list:REG_DEAD (reg:SI 125)
(expr_list:REG_DEAD (reg/f:SI 115)
(nil
**scanning insn=31
mem: (reg/f:SI 115)
after canon_rtx address: (plus:SI (reg/f:SI 3 %r3)
(const_int -56 [0xffc8]))
gid=0 offset=-56
processing const base store gid=0[-56..-52)
trying store in insn=26 gid=0[-52..-48)
mems_found = 1, cannot_delete = false
[...]
Locally deleting insn 31
deferring deletion of insn with uid = 31.
Locally deleting insn 26
deferring deletion of insn with uid = 26.
The argument setup for this argument is:
(insn 25 22 26 2 (set (reg/f:SI 124)
(plus:SI (reg/f:SI 3 %r3)
(const_int -52 [0xffcc]))) pr55023.c:17 112
{addsi3}
(nil))
(insn 26 25 27 2 (set (mem:SI (reg/f:SI 124) [0 S4 A32])
(reg:SI 119 [ D.1503 ])) pr55023.c:17 40 {*pa.md:2204}
(expr_list:REG_DEAD (reg/f:SI 124)
(nil)))
(insn 27 26 31 2 (set (reg:SI 125)
(ashiftrt:SI (reg:SI 119 [ D.1503 ])
(const_int 31 [0x1f]))) pr55023.c:17 174 {*pa.md:6548}
(expr_list:REG_DEAD (reg:SI 119 [ D.1503 ])
(nil)))
(insn 31 27 50 2 (set (mem:SI (reg/f:SI 115) [0 S4 A64])
(reg:SI 125)) pr55023.c:17 40 {*pa.md:2204}
(expr_list:REG_DEAD (reg:SI 125)
(expr_list:REG_DEAD (reg/f:SI 115)
(nil
Pseudo SI 115 was loaded earlier:
(insn 16 12 20 2 (set (reg/f:SI 115)
(plus:SI (reg/f:SI 3 %r3)
(const_int -56 [0xffc8]))) pr55023.c:16 112
{addsi3}
(nil))
Dave
--
John David Anglindave.ang...@bell.net
[Bug target/55023] hppa: wrong code generated with tail call optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55023 --- Comment #10 from Jeffrey A. Law law at redhat dot com --- IIRC, the PA was a bit unique in how we had to set up the virtual registers due to the combination of stack growth and arg growth directions. It may be the case that after virtual register instantiation we're left with something different than is seen on any other architecture. Thus the potential oversight in DSE's handling of argument setup, particularly with sibcalls which use the parent's stack. But that's just speculation based on knowledge from 2 decades ago... Take it with a grain of salt...
[Bug libgcc/63801] New: error: templates must have C++ linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63801
Bug ID: 63801
Summary: error: templates must have C++ linkage
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at ryandesign dot com
Hello, I'm a developer with the MacPorts project. I'm not the maintainer of our
gcc ports, but I am the one who created our gcc5 port and kept it updated until
version 5-20140824. No later snapshot of gcc5 has successfully built for me on
OS X, failing instead with the following message:
ccache /usr/bin/clang++ -arch x86_64 -c -g -DIN_GCC-fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common -DHAVE_CONFIG_H -I. -I.
-I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc
-I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/.
-I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/../include
-I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/../libcpp/include
-I/opt/local/include -I/opt/local/include -I/opt/local/include
-I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/../libdecnumber
-I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/../libdecnumber/dpd
-I../libdecnumber
-I/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/../libbacktrace
-DCLOOG_INT_GMP -I/opt/local/include -DCLOOG_INT_GMP -I/opt/local/include -o
graphite-clast-to-gimple.o -MT graphite-clast-to-gimple.o -MMD -MP -MF
./.deps/graphite-clast-to-gimple.TPo
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/graphite-clast-to-gimple.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
clang: warning: treating 'cpp-output' input as 'c++-cpp-output' when in C++
mode, this behavior is deprecated
In file included from
/opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/graphite-clast-to-gimple.c:36:
In file included from /opt/local/include/isl/val_gmp.h:4:
In file included from /opt/local/include/gmp.h:34:
In file included from
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/iosfwd:89:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__config:494:1:
error: templates must have C++ linkage
template bool struct __static_assert_test;
^~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__config:495:20:
error: explicit specialization of non-template struct '__static_assert_test'
template struct __static_assert_testtrue {};
^ ~~
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__config:496:1:
error: templates must have C++ linkage
template unsigned struct __static_assert_check {};
^~~
We are using gmp version 6.0.0 and isl version 0.14.
This was with the following OS X, Xcode and clang versions, but similar failure
occurs on earlier versions:
$ sw_vers
ProductName:Mac OS X
ProductVersion:10.10.1
BuildVersion:14B17
$ xcodebuild -version
Xcode 6.1
Build version 6A1052d
$ clang -v
Apple LLVM version 6.0 (clang-600.0.54) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
$
[Bug tree-optimization/63800] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63800 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-11-10 CC||mpolacek at gcc dot gnu.org Known to work||4.9.2 Target Milestone|--- |5.0 Summary|ICE on valid code at -O3 on |[5 Regression] ICE on valid |x86_64-linux-gnu|code at -O3 on ||x86_64-linux-gnu Ever confirmed|0 |1 Known to fail||5.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug middle-end/63801] error: templates must have C++ linkage when building with isl and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63801 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|libgcc |middle-end Summary|error: templates must have |error: templates must have |C++ linkage |C++ linkage when building ||with isl and clang --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This might be a bug in isl/gmp where it does an extern C around some include files.
[Bug middle-end/63801] error: templates must have C++ linkage when building with isl and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63801
--- Comment #2 from Ryan Schmidt gcc at ryandesign dot com ---
Isn't the extern C coming from lines 32-38 of gcc/graphite-clast-to-gimple.c
which in version 5-20141109 say:
#if defined(__cplusplus)
extern C {
#endif
#include isl/val_gmp.h
#if defined(__cplusplus)
}
#endif
The first 4 lines of /opt/local/include/isl/val_gmp.h are simply:
#ifndef ISL_VAL_GMP_H
#define ISL_VAL_GMP_H
#include gmp.h
Lines 31-36 of /opt/local/include/gmp.h (the first non-comment lines) are:
#ifndef __GMP_H__
#if defined (__cplusplus)
#include iosfwd /* for std::istream, std::ostream, std::string */
#include cstdio
#endif
[Bug middle-end/63801] error: templates must have C++ linkage when building with isl and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63801 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||build --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2014-02/msg00558.html Looks like it was needed at one point because a bug in isl headers. But this might have been fixed already
[Bug middle-end/63801] error: templates must have C++ linkage when building with isl and clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63801 --- Comment #4 from Ryan Schmidt gcc at ryandesign dot com --- Thanks. If I remove the extern C then it fails with: /opt/local/var/macports/build/_Users_rschmidt_macports_dports_lang_gcc5/libgcc-devel/work/gcc-5-20141109/gcc/graphite-optimize-isl.c:357:12: error: use of undeclared identifier 'isl_band_member_is_zero_distance' if (isl_band_member_is_zero_distance (Band, i)) ^ The isl changelog, under the heading Changes since isl-0.12, says The function isl_band_member_is_zero_distance has been removed. Essentially the same functionality is available through isl_band_member_is_coincident, except that is requires setting up coincidence constraints. The option schedule_outer_zero_distance has accordingly been replaced by the option schedule_outer_coincidence.
[Bug tree-optimization/63800] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63800 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/63800] [5 Regression] ICE on valid code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63800 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r211725.
[Bug rtl-optimization/63718] [5 Regression] ARM Thumb1 bootstrap fail after fuse-caller-save info in cprop-hardreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63718 --- Comment #10 from vries at gcc dot gnu.org --- Tom, are you going to submit this patch for review I was planning to put this patch through build regtest and submit, but next week. Unfortunately I don't have time until then, I'm trying to submit something else before stage1 closes.
