[Bug target/66747] [6 Regression] The commit r225260 broke the builds of the mips-{mti,img}-linux-gnu tool chains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66747 Bernd Edlinger changed: What|Removed |Added Component|middle-end |target Assignee|unassigned at gcc dot gnu.org |edlinger at gcc dot gnu.org --- Comment #6 from Bernd Edlinger --- patch was posted here: https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00238.html
[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714
--- Comment #12 from vries at gcc dot gnu.org ---
Created attachment 35908
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35908&action=edit
patch to be more aggressive in gt_cleare_cache
Using this patch, we can trigger the problem with minimal testcase, and also
for openmp:
...
$ cat libgomp/testsuite/libgomp.c/pr66714.c
* { dg-do "compile" } */
/* { dg-additional-options "--param ggc-min-expand=0" } */
/* { dg-additional-options "--param ggc-min-heapsize=0" } */
/* { dg-additional-options "-g" } */
/* Minimized from on target-2.c. */
void
fn3 (int x)
{
double b[3 * x];
int i;
#pragma omp target
#pragma omp parallel for
for (i = 0; i < x; i++)
b[i] += 1;
}
...
[Bug debug/66714] ICE in loc_list_from_tree with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66714 vries at gcc dot gnu.org changed: What|Removed |Added Version|unknown |6.0 Summary|gomp4: |ICE in loc_list_from_tree |libgomp.oacc-c-c++-common/a |with -g |tomic_capture-1.c -g ICE| --- Comment #13 from vries at gcc dot gnu.org --- (In reply to vries from comment #12) > Created attachment 35908 [details] > patch to be more aggressive in gt_cleare_cache > > Using this patch, we can trigger the problem with minimal testcase, and also > for openmp: This is a trunk patch, not a gomp-4-0-branch patch.
[Bug tree-optimization/26854] Inordinate compile times on large routines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26854 --- Comment #130 from Paolo Bonzini --- A late update... all.i: with GCC 4.8.3 on a Xeon E5 v3 time is taken mostly by alias stmt walking alias stmt walking : 272.52 (65%) (-O2) alias stmt walking : 116.06 (67%) (-O1) Requred memory is 700 MB. With GCC 5.1, but on a Core i7 Ivy Bridge laptop so times are not comparable, time is also taken mostly by alias stmt walking: alias stmt walking : 604.43 (54%) usr (-O1) and memory usage is also around 700 MB. Brad was using -fschedule-insns too, and it's pretty expensive: scheduling : 430.61 (38%)(-O1 -fschedule-insns, 5.1) scheduling : 122.68 (41%)(-O1 -fschedule-insns, 4.8.3) It also brings the top memory usage to 1 GB. - compile.i: with GCC 4.8.3 time is taken mostly by scheduling and some tree passes (-O1): alias stmt walking : 206.77 (36%) tree CFG cleanup: 42.66 ( 7%) usr 0.02 ( 0%) sys 42.65 ( 7%) wall 1108 kB ( 0%) ggc dominator optimization : 39.98 ( 7%) usr 0.04 ( 1%) sys 39.97 ( 7%) wall 23123 kB ( 3%) ggc Required memory is around 1 GB. I haven't tested 5.1 but the alias stmt walking seems to be a common feature of the Gambit testcases. In both cases, memory usage is at least under control. However, total compile time has regressed since the previous report in comment 115. As expected walk_aliased_vdefs has a high % of time spent, but the time is spent in bitmap operations rather than the callbacks! This is because the callback is the trivial mark_modified function. The guilty walk_aliased_vdefs invocation is parm_ref_data_preserved_p, invoked from ipa_load_from_parm_agg and in turn from unmodified_parm_or_parm_agg_item. Memoization via parms_ainfo seems like a plan, I'm opening a separate bug.
[Bug ipa/66760] New: [4.9/5/6 Regression] compile time regression in IPA inline analysis on PR26854 testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66760 Bug ID: 66760 Summary: [4.9/5/6 Regression] compile time regression in IPA inline analysis on PR26854 testcase Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: bonzini at gnu dot org Target Milestone: --- PR26854 is spending a lot of time in alias stmt walking alias stmt walking : 272.52 (65%) (-O2) alias stmt walking : 116.06 (67%) (-O1) walk_aliased_vdefs has a high % of time spent, but the time is spent in bitmap operations rather than the callbacks! This is because the callback is the trivial mark_modified function. The guilty walk_aliased_vdefs invocation is parm_ref_data_preserved_p, invoked from ipa_load_from_parm_agg and in turn from unmodified_parm_or_parm_agg_item. Memoization via parms_ainfo seems like a plan.
[Bug ipa/66760] [4.9/5/6 Regression] compile time regression in IPA inline analysis on PR26854 testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66760 Paolo Bonzini changed: What|Removed |Added Keywords||compile-time-hog CC||hubicka at gcc dot gnu.org --- Comment #1 from Paolo Bonzini --- Testcase: http://www.math.purdue.edu/~lucier/gcc/test-files/bugzilla/1/all.i.gz
[Bug libgomp/66761] New: libgomp: ThreadSanitizer: data race in libgomp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66761 Bug ID: 66761 Summary: libgomp: ThreadSanitizer: data race in libgomp Product: gcc Version: 5.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch CC: jakub at gcc dot gnu.org Target Milestone: --- After compiling libgomp with -fsanitize=thread, the following testcase triggers a warning, which might indicate a problem in libgomp/config/linux/wait.h:52 : > cat test.f90 SUBROUTINE copy(a,b,n) INTEGER :: a(*),b(*),n !$OMP PARALLEL DO SHARED(a,b,n) PRIVATE(i) DO i=1,n a(i)=b(i) ENDDO END SUBROUTINE SUBROUTINE test() INTEGER, PARAMETER :: N=1024 INTEGER :: a(N),b(N),i !$OMP PARALLEL SHARED(a,b) PRIVATE(i) !$OMP DO DO i=1,N b(i)=i ENDDO !$OMP BARRIER !$OMP MASTER CALL copy(a,b,n) !$OMP END MASTER !$OMP END PARALLEL END SUBROUTINE PROGRAM tester CALL test() END > gfortran -fopenmp -fsanitize=thread -g test.f90 > ./a.out == WARNING: ThreadSanitizer: data race (pid=66889) Atomic write of size 8 at 0x7f30d27667c0 by main thread: #0 __tsan_atomic64_fetch_add /data/vjoost/toolchain-sanitize/build/gcc-5.1.0/libsanitizer/tsan/tsan_interface_atomic.cc:616 (libtsan.so.0+0x00058880) #1 gomp_team_end /data/vjoost/toolchain-sanitize/build/gcc-5.1.0/libgomp/team.c:875 (libgomp.so.1+0x00019752) #2 GOMP_parallel_end /data/vjoost/toolchain-sanitize/build/gcc-5.1.0/libgomp/parallel.c:159 (libgomp.so.1+0x00010b7b) #3 GOMP_parallel /data/vjoost/toolchain-sanitize/build/gcc-5.1.0/libgomp/parallel.c:169 (libgomp.so.1+0x00010c71) #4 copy_ /data/vjoost/gnu/bugs/test.f90:5 (a.out+0x00400c4e) #5 test_._omp_fn.0 /data/vjoost/gnu/bugs/test.f90:22 (a.out+0x00400dd0) #6 GOMP_parallel /data/vjoost/toolchain-sanitize/build/gcc-5.1.0/libgomp/parallel.c:168 (libgomp.so.1+0x00010c6c) #7 test_ /data/vjoost/gnu/bugs/test.f90:13 (a.out+0x00400bb9) #8 tester /data/vjoost/gnu/bugs/test.f90:30 (a.out+0x00400c80) #9 main /data/vjoost/gnu/bugs/test.f90:31 (a.out+0x00400cc9) Previous read of size 8 at 0x7f30d27667c0 by thread T29: #0 do_spin /data/vjoost/toolchain-sanitize/build/gcc-5.1.0/libgomp/config/linux/wait.h:52 (libgomp.so.1+0x0001bcee) #1 do_wait /data/vjoost/toolchain-sanitize/build/gcc-5.1.0/libgomp/config/linux/wait.h:64 (libgomp.so.1+0x0001bcee) #2 gomp_team_barrier_wait_end /data/vjoost/toolchain-sanitize/build/gcc-5.1.0/libgomp/config/linux/bar.c:112 (libgomp.so.1+0x0001bcee) #3 gomp_team_barrier_wait_final /data/vjoost/toolchain-sanitize/build/gcc-5.1.0/libgomp/config/linux/bar.c:136 (libgomp.so.1+0x0001c039) #4 gomp_thread_start /data/vjoost/toolchain-sanitize/build/gcc-5.1.0/libgomp/team.c:119 (libgomp.so.1+0x000177b4) Location is global 'gomp_managed_threads' of size 8 at 0x7f30d27667c0 (libgomp.so.1+0x002317c0) Thread T29 (tid=66919, running) created by main thread at: #0 pthread_create /data/vjoost/toolchain-sanitize/build/gcc-5.1.0/libsanitizer/tsan/tsan_interceptors.cc:895 (libtsan.so.0+0x00026c94) #1 gomp_team_start /data/vjoost/toolchain-sanitize/build/gcc-5.1.0/libgomp/team.c:796 (libgomp.so.1+0x00017fee) #2 GOMP_parallel /data/vjoost/toolchain-sanitize/build/gcc-5.1.0/libgomp/parallel.c:167 (libgomp.so.1+0x00010c67) #3 test_ /data/vjoost/gnu/bugs/test.f90:13 (a.out+0x00400bb9) #4 tester /data/vjoost/gnu/bugs/test.f90:30 (a.out+0x00400c80) #5 main /data/vjoost/gnu/bugs/test.f90:31 (a.out+0x00400cc9) SUMMARY: ThreadSanitizer: data race /data/vjoost/toolchain-sanitize/build/gcc-5.1.0/libgomp/team.c:875 gomp_team_end == ThreadSanitizer: reported 1 warnings
[Bug target/66509] the new clang-based assembler in Xcode 7 on 10.11 fails on the libjava/java/lang/reflect/natArray.cc file from FSF gcc 5.1 at -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66509 --- Comment #26 from Jack Howarth --- FYI, test results for back port onto gcc-4_9-branch is posted at... https://gcc.gnu.org/ml/gcc-testresults/2015-07/msg00400.html
[Bug fortran/66762] New: ICE when compiling gfortran.dg/submodule_[16].f90 with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66762 Bug ID: 66762 Summary: ICE when compiling gfortran.dg/submodule_[16].f90 with -flto Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: hubicka at gcc dot gnu.org, pault at gcc dot gnu.org Blocks: 52846 Target Milestone: --- When compiling gfortran.dg/submodule_[16].f90 with -flto I get the following ICE: lto1: error: two or more sections for .gnu.lto___foo_interface_MOD___vtab_foo_interface_Foo.b6ec16be3917c0c lto1: internal compiler error: cannot read LTO decls from /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cc71MURs.o lto1: internal compiler error: Abort trap: 6 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846 [Bug 52846] [F2008] Support submodules
[Bug tree-optimization/66729] Segfault starting with r224967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66729 --- Comment #9 from rsandifo at gcc dot gnu.org --- Turns out to be a linker bug that is still present in binutils mainline. I'm testing a patch.
[Bug testsuite/64221] contrib/compare_tests confused by c-c++-common/ubsan/shift-5.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64221 --- Comment #1 from Marc Glisse --- Currently it is c-c++-common/ubsan/float-cast-overflow-8.c that always appears in compare_tests output.
[Bug target/66114] some indirect_jump patterns use operands[] in their condition when they shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66114 --- Comment #1 from John David Anglin --- Author: danglin Date: Sat Jul 4 13:42:55 2015 New Revision: 225412 URL: https://gcc.gnu.org/viewcvs?rev=225412&root=gcc&view=rev Log: PR target/66114 * config/pa/pa.md (indirect_jump): Use pmode_register_operand instead of register_operand. Remove constraint. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.md
[Bug target/66114] some indirect_jump patterns use operands[] in their condition when they shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66114 --- Comment #2 from John David Anglin --- Author: danglin Date: Sat Jul 4 13:44:39 2015 New Revision: 225413 URL: https://gcc.gnu.org/viewcvs?rev=225413&root=gcc&view=rev Log: PR target/66114 * config/pa/pa.md (indirect_jump): Use pmode_register_operand instead of register_operand. Remove constraint. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/pa/pa.md
[Bug target/66114] some indirect_jump patterns use operands[] in their condition when they shouldn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66114 --- Comment #3 from John David Anglin --- Author: danglin Date: Sat Jul 4 13:46:11 2015 New Revision: 225414 URL: https://gcc.gnu.org/viewcvs?rev=225414&root=gcc&view=rev Log: PR target/66114 * config/pa/pa.md (indirect_jump): Use pmode_register_operand instead of register_operand. Remove constraint. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/pa/pa.md
[Bug middle-end/66334] cleanup block fails to initialize EBX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66334 --- Comment #10 from H.J. Lu --- (In reply to Vladimir Makarov from comment #9) > > I will work on the patch and commit it on next week. > > Thanks. I tried this patch: https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=ab377c74f283f3db51b4e250b9c7acecc32e8ff8 It seems to work.
[Bug target/66703] [4.9/5/6] gcc.target/i386/readeflags-1.c aborts on -march=i586 or on -miamcu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66703
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #1 from H.J. Lu ---
We have
unsigned int
readeflags_test (unsigned int a, unsigned int b)
{
unsigned x = (a == b);
return __builtin_ia32_readeflags_u32 ();
}
For
unsigned x = (a == b);
-march=i586 generates:
;; _3 = a_1(D) == b_2(D);
(insn 5 4 6 (set (reg:SI 90)
(mem/c:SI (reg/f:SI 81 virtual-incoming-args) [0 a+0 S4 A32])) y.i:4 -1
(nil))
(insn 6 5 7 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 90)
(mem/c:SI (plus:SI (reg/f:SI 81 virtual-incoming-args)
(const_int 4 [0x4])) [0 b+0 S4 A32]))) y.i:4 -1
(nil))
(insn 7 6 0 (set (reg:QI 87 [ D.1413 ])
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) y.i:4 -1
(nil))
;; x_4 = (unsigned int) _3;
(insn 8 7 9 (parallel [
(set (reg:SI 91)
(zero_extend:SI (reg:QI 87 [ D.1413 ])))
(clobber (reg:CC 17 flags))
]) y.i:4 -1
(nil))
(insn 9 8 0 (set (mem/c:SI (plus:SI (reg/f:SI 82 virtual-stack-vars)
(const_int -4 [0xfffc])) [0 x+0 S4 A32])
(reg:SI 91)) y.i:4 -1
(nil))
EFLAGS register is clobbered and __builtin_ia32_readeflags_u32
returns clobbered value. So the testcase is expected to fail
if zero-extend bool to unsigned int clobbers EFLAGS register. Since
we have
/* X86_TUNE_ZERO_EXTEND_WITH_AND: Use AND instruction instead
of mozbl/movwl. */
DEF_TUNE (X86_TUNE_ZERO_EXTEND_WITH_AND, "zero_extend_with_and",
m_486 | m_PENT)
This test should fail with -march=i486, -march=i586 or -miamcu.
[Bug fortran/66762] ICE when compiling gfortran.dg/submodule_[16].f90 with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66762 --- Comment #1 from Paul Thomas --- Hi Dominique, What are the precise circumstances that you see this, please? I cannot reproduce the problem. Cheers Paul
[Bug libstdc++/66763] New: 25_algorithms/remove/requirements/explicit_instantiation/2.cc fails on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66763 Bug ID: 66763 Summary: 25_algorithms/remove/requirements/explicit_instantiati on/2.cc fails on AIX Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- 25_algorithms/remove/requirements/explicit_instantiation/2.cc:34:22: error: 'std::value_type* std::remove(std::iterator_type, std::iterator_type, const value_type&)' is not declared in 'std' const value_type&);
[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286 --- Comment #21 from Magnus Granberg --- Do this happen on gcc 6.0 with --enable-default-pie and trunk glibc?
[Bug libstdc++/66763] 25_algorithms/remove/requirements/explicit_instantiation/2.cc fails on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66763 --- Comment #1 from David Edelsohn --- Created attachment 35909 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35909&action=edit gzipped 2.ii pre-processed testcase
[Bug fortran/66725] Issue with silent conversion int to char, ICE if int too large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66725 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Jul 4 15:37:04 2015 New Revision: 225415 URL: https://gcc.gnu.org/viewcvs?rev=225415&root=gcc&view=rev Log: 2015-07-04 Steven G. Kargl PR fortran/66725 * io.c (is_char_type): New function to test for BT_CHARACTER (gfc_match_open, gfc_match_close, match_dt_element): Use it. 2015-07-03 Steven G. Kargl PR fortran/66725 * gfortran.dg/pr66725.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr66725.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/66725] Issue with silent conversion int to char, ICE if int too large
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66725 --- Comment #5 from kargl at gcc dot gnu.org --- Patch posted here. https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00235.html
[Bug c/45286] kact.sa_restorer = &restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286 --- Comment #22 from H.J. Lu --- (In reply to Magnus Granberg from comment #21) > Do this happen on gcc 6.0 with --enable-default-pie and trunk glibc I built glibc master using gcc 6.0 with --enable-default-pie and there are no problems on x86-64.
[Bug ipa/66764] New: ICE in analyze_function() on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66764
Bug ID: 66764
Summary: ICE in analyze_function() on AIX
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
Analyzing compilation unit
Breakpoint 1, fancy_abort(char const*, int, char const*) ()
at /nasfarm/edelsohn/src/src/gcc/diagnostic.c:1340
1340 internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) up
#1 0x10f2fa10 in symtab_node::get_alias_target (this=)
(gdb) up
#2 0x10872574 in analyze_functions(bool) ()
at /nasfarm/edelsohn/src/src/gcc/cgraphunit.c:969
969 node->fixup_same_cpp_alias_visibility (node->get_alias_target
());
(gdb) print (ipa_ref) ref
$2 = {referring = 0x0, referred = 0xd, stmt = 0x2ff22670,
lto_stmt_uid = 17316952, referred_index = 2, use = IPA_REF_STORE,
speculative = 1}
[Bug libstdc++/66763] 25_algorithms/remove/requirements/explicit_instantiation/2.cc fails on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66763 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-07-04 Ever confirmed|0 |1 --- Comment #2 from Jonathan Wakely --- Ville mentioned this to me too, happening on gcc112 (ppc64le-linux), I haven't seen it though
[Bug ipa/66764] ICE in analyze_function() on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66764 --- Comment #1 from David Edelsohn --- Created attachment 35910 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35910&action=edit gzipped pre-processed tuple.ii from libstdc++ testsuite
[Bug fortran/66765] New: gfortran invoking cc1 on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66765 Bug ID: 66765 Summary: gfortran invoking cc1 on AIX Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- Target: powerpc-ibm-aix* /tmp/20150703/gcc/testsuite/gfortran5/../../gfortran -B/tmp/20150703/gcc/testsuite/gfortran5/../../ -B/tmp/20150703/powerpc-ibm-aix7.1.0.0/./libgfortran/ /nasfarm/edelsohn/src/src/gcc/testsuite/gfortran.dg/implicit_class_1.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never-O0 -fdump-fortran-original -B/tmp/20150703/powerpc-ibm-aix7.1.0.0/./libgfortran/.libs -L/tmp/20150703/powerpc-ibm-aix7.1.0.0/./libgfortran/.libs -lm-o ./implicit_class_1.exe cc1: error: unrecognized command line option '-fdump-fortran-original' collect2: fatal error: gcc returned 1 exit status compilation terminated. compiler exited with status 1 On AIX collect2-ld is a wrapper around the linker. It finds static initializers and finalizers, writes them to a file, and compiles them with gcc. It passes the command line arguments to gcc. Compiling and linking a GNU Fortran program with a single command line causes Fortran options to be passed to cc1 through collect2, causing cc1 to report a fatal error of an unrecognized command line option.
[Bug fortran/66762] ICE when compiling gfortran.dg/submodule_[16].f90 with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66762 --- Comment #2 from Dominique d'Humieres --- > What are the precise circumstances that you see this, please? [Book15] f90/bug% gfc /opt/gcc/_clean/gcc/testsuite/gfortran.dg/submodule_1.f90 -flto lto1: error: two or more sections for .gnu.lto___foo_interface_MOD___vtab_foo_interface_Foo.b6ec16be3917c0c ... [Book15] f90/bug% gfc -v Using built-in specs. COLLECT_GCC=gfc COLLECT_LTO_WRAPPER=/opt/gcc/gcc6w/libexec/gcc/x86_64-apple-darwin14.4.0/6.0.0/lto-wrapper Target: x86_64-apple-darwin14.4.0 Configured with: ../work/configure --prefix=/opt/gcc/gcc6w --enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp-new --with-system-zlib --with-isl=/opt/mp-new --enable-lto --enable-plugin --with-arch=corei7 --with-cpu=corei7 Thread model: posix gcc version 6.0.0 20150703 (experimental) [trunk revision 225405] (GCC) clean revision r225405.
[Bug target/66747] [6 Regression] The commit r225260 broke the builds of the mips-{mti,img}-linux-gnu tool chains.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66747 --- Comment #7 from Bernd Edlinger --- Author: edlinger Date: Sat Jul 4 19:02:18 2015 New Revision: 225416 URL: https://gcc.gnu.org/viewcvs?rev=225416&root=gcc&view=rev Log: 2015-07-04 Bernd Edlinger PR target/66747 * config/mips/mips.c (mips_find_gp_ref): Handle instruction sequences. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c
[Bug c++/66766] New: Reference to an “auto” function as a template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66766
Bug ID: 66766
Summary: Reference to an “auto” function as a template
parameter
Product: gcc
Version: 5.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: quentin.c.diaz at gmail dot com
Target Milestone: ---
The following code :
template
struct Foo {
static auto value() {}
};
void bar() {}
template struct Foo::value>;
Causes the following error :
error: could not convert template argument ‘Foo::value’ to ‘void (&)()’
template struct Foo::value>;
^
Any of the following makes it compile successfully :
- Declaring value() as returning void instead of deducing it
- "Dereferencing" value : template struct Foo<*Foo::value>;
- Parenthesizing value : template struct Foo<(Foo::value)>;
- Making a a pointer : template struct Foo ...
[Bug fortran/52251] Nonadvancing I/O and the t edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52251 --- Comment #6 from Jerry DeLisle --- Created attachment 35911 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35911&action=edit A patch to fix this. This patch issues the tab spacing based on spaces previously skipped pending transfer of data. In the test case, there is no data transferred so we were skipping handling the skips.
[Bug tree-optimization/66759] [6 Regression] ICE in generic-match.c on 456.hmmer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66759 kugan at gcc dot gnu.org changed: What|Removed |Added CC||kugan at gcc dot gnu.org --- Comment #1 from kugan at gcc dot gnu.org --- Most likely started with r225375
[Bug bootstrap/66521] xgcc: cc1plus segfaults when compiling libstdc++-v3/src/c++11/ostream-inst.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66521 Eric Gallager changed: What|Removed |Added CC||cmtice at google dot com --- Comment #2 from Eric Gallager --- Just a follow-up, removing --enable-vtable-verify from my configure options (and also selecting a set of less-expensive stage1-checking options) allowed the build to continue successfully and get past this part, so it looks like it's definitely a problem with the vtable verification feature; I'm adding the libvtv maintainer listed in MAINTAINERS on CC... (CC-ing someone on a bug doesn't count as contacting them directly, right? Just making sure I'm not violating that line from MAINTAINERS...)
