[Bug sanitizer/61604] missing line numbers in a sanitizer backtrace from an OMP region
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61604 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.9.2, 5.0 Resolution|--- |FIXED --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- This seems now fixed. gfortran -O1 -g3 -fno-omit-frame-pointer -fsanitize=leak -fopenmp PR61604.f90 ; export OMP_NUM_THREADS=2 ; ./a.out = ==30967==ERROR: LeakSanitizer: detected memory leaks Direct leak of 400 byte(s) in 1 object(s) allocated from: #0 0x7fbcd1bfac06 in __interceptor_malloc ../../../../gcc/libsanitizer/lsan/lsan_interceptors.cc:51 #1 0x400865 in s1_._omp_fn.0 /data/vjoost/gnu/bugs/PR61604.f90:4 #2 0x7fbcd1a9b4ed in gomp_thread_start ../../../gcc/libgomp/team.c:117 Direct leak of 400 byte(s) in 1 object(s) allocated from: #0 0x7fbcd1bfac06 in __interceptor_malloc ../../../../gcc/libsanitizer/lsan/lsan_interceptors.cc:51 #1 0x400865 in s1_._omp_fn.0 /data/vjoost/gnu/bugs/PR61604.f90:4 #2 0x7fbcd1a9756e in GOMP_parallel ../../../gcc/libgomp/parallel.c:167 SUMMARY: LeakSanitizer: 800 byte(s) leaked in 2 allocation(s).
[Bug fortran/48244] iso-c-binding support missing on NetBSD (with patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48244 --- Comment #6 from Kai-Uwe Eckhardt kuehro at gmx dot de --- --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Any progress? Gerald Pfeifer offered to help, but somehow it slipped through. The patch still works for the latest 5.0 snapshot 20141130: Hi Kai-Uwe, On Thu, 4 Jul 2013, Kai-Uwe Eckhardt wrote: in order to fix gcc bug 48244, a copy of gcc/config/freebsd-stdint.h to gcc/config/netbsd-stdint.h is necessary. I am not sure about the legal aspects, but I would like to ask if you have any objections against doing a copy and keeping your name as the contributor. I guess you have commit rights ? If this is the case, it would be very kind if you could do the commit. first of all sorry for the delay in getting back to this. It simply slipped through. Sorry! I'm have no objections whatsoever for you to reuse freebsd-stdint.h as gcc/config/netbsd-stdint.h and will be happy to commit a patch. I assume you'll also need to update config.gcc, similar to what I have done in 2009-06-01 Gerald Pfeifer * config/freebsd-stdint.h: New file. * config.gcc (*-*-freebsd): Set use_gcc_stdint=wrap. Add freebsd-stdint.h to tm_file. How about if you submit a patch for config.gcc and testresults (to gcc-testresu...@gcc.gnu.org) before and after the desired changes to gcc-patc...@gcc.gnu.org and copy me? Gerald I didn't send testresults to the list because without a dozen patches gcc won't compile at all. Testresults and necessary patches can be found at http://pkgsrc-wip.cvs.sourceforge.net/viewvc/pkgsrc-wip/wip/gcc50snapshot and gfortran works quite well on NetBSD. Would it help to send test_summary.log to the testresult mailing list ? Kai-Uwe
[Bug fortran/59345] _gfortran_internal_pack on compiler generated temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59345 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2013-12-22 00:00:00 |2014-12-6 CC||Joost.VandeVondele at mat dot ethz ||.ch Known to fail||4.9.2, 5.0 --- Comment #2 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- still happens with trunk. In the microbenchmark below, seems like a 3-fold overhead due to packing. This is similar to using an assumed shape dummy arg as a temp, while in the latter case, this can be fixed with the contiguous attribute. Could the solution be as simple as somehow providing the 'contiguous' attribute to compiler generated temporaries ? gfortran -Ofast -fno-inline t.f90 ./a.out with packing: 1.81572298 sec. without packing: 0.490925997 sec. assumed shape, no contiguous : 1.90471006 sec. assumed shape, contiguous : 0.466928948 sec. total calls to foo: 4 expected 2 cat t.f90 MODULE M INTEGER, SAVE :: count=0 CONTAINS SUBROUTINE S1(A,foo) REAL :: A(3) CALL foo(-A) END SUBROUTINE SUBROUTINE S2(A,foo) REAL :: A(3) REAL :: B(3) B=-A CALL foo(B) END SUBROUTINE SUBROUTINE S3(A,B,foo) REAL :: A(3) REAL :: B(:) B=-A CALL foo(B) END SUBROUTINE SUBROUTINE S4(A,B,foo) REAL :: A(3) REAL, CONTIGUOUS :: B(:) B=-A CALL foo(B) END SUBROUTINE SUBROUTINE foo(A) REAL :: A(3) count=count+1 END SUBROUTINE END MODULE PROGRAM TEST USE M IMPLICIT NONE REAL :: A(3),B(3) INTEGER :: i REAL*8 :: t1,t2,t3,t4,t5,t6,t7,t8 INTEGER :: N A=0 N=1 CALL CPU_TIME(t1) DO i=1,N CALL S1(A,foo) ENDDO CALL CPU_TIME(t2) CALL CPU_TIME(t3) DO i=1,N CALL S2(A,foo) ENDDO CALL CPU_TIME(t4) CALL CPU_TIME(t5) DO i=1,N CALL S3(A,B,foo) ENDDO CALL CPU_TIME(t6) CALL CPU_TIME(t7) DO i=1,N CALL S4(A,B,foo) ENDDO CALL CPU_TIME(t8) WRITE(6,*) with packing:, t2-t1, sec. WRITE(6,*) without packing:, t4-t3, sec. WRITE(6,*) assumed shape, no contiguous :, t6-t5, sec. WRITE(6,*) assumed shape, contiguous :, t8-t7, sec. WRITE(6,*) total calls to foo:, count, expected, 2*N END
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Last reconfirmed|2013-11-17 00:00:00 |2014-12-6 CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #5 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- confirmed for trunk, backtrace now: f951: internal compiler error: Segmentation fault 0xb364df crash_signal ../../gcc/gcc/toplev.c:358 0x658af9 gfc_sym_get_dummy_args(gfc_symbol*) ../../gcc/gcc/fortran/symbol.c:4659 0x632130 resolve_fl_procedure ../../gcc/gcc/fortran/resolve.c:11189 0x632130 resolve_symbol ../../gcc/gcc/fortran/resolve.c:13568 0x6511e3 do_traverse_symtree ../../gcc/gcc/fortran/symbol.c:3641 0x63c61f resolve_types ../../gcc/gcc/fortran/resolve.c:14781 0x6304a3 gfc_resolve ../../gcc/gcc/fortran/resolve.c:14882 0x6304a3 gfc_resolve(gfc_namespace*) ../../gcc/gcc/fortran/resolve.c:14870 0x62580a gfc_parse_file() ../../gcc/gcc/fortran/parse.c:5080 0x6652e5 gfc_be_parse_file ../../gcc/gcc/fortran/f95-lang.c:222 Please submit a full bug report,
[Bug fortran/64207] vectorization report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64207 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||Joost.VandeVondele at mat dot ethz ||.ch Resolution|--- |FIXED --- Comment #1 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- -fopt-info is the replacement for -ftree-vectorizer-verbose, the latter is deprecated for example try -fopt-info-vec-missed or -fopt-info-all best is to keep the part to analyze rather simple, since it generates a lot of info that isn't always easy to understand: cat t.f90 subroutine s(a,b,c) real, dimension(1024, 1024) :: a,b,c do i=1,1024 do j=1,1024 c(i,j) = a(j,i)*b(j,i) end do end do end subroutine gfortran -c -O3 -march=native -ffast-math -fopt-info-vec-missed t.f90 t.f90:3:0: note: not vectorized: complicated access pattern. t.f90:3:0: note: bad data access. t.f90:4:0: note: not consecutive access *c_19(D)[_10] = _18; t.f90:4:0: note: not vectorized: complicated access pattern. t.f90:4:0: note: bad data access. [...] cat t.f90 subroutine s(a,b,c) real, dimension(1024, 1024) :: a,b,c do i=1,1024 do j=1,1024 c(j,i) = a(j,i)*b(j,i) end do end do end subroutine gfortran -c -O3 -march=native -ffast-math -fopt-info-vec t.f90 t.f90:4:0: note: loop vectorized t.f90:4:0: note: loop peeled for vectorization to enhance alignment
[Bug preprocessor/63831] [5 Regression] r217292 causes segfaults with -MM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63831 --- Comment #19 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #17) Created attachment 34199 [details] gcc5-pr63831.patch Untested fix. Thanks Jakub - Works for me - on x86_64-darwin12 all langs (incl. Ada, Java and Obj-C++) bootstrap [with fix for libcc1 @ https://gcc.gnu.org/ml/gcc-patches/2014-12/msg00568.html] testing now.
[Bug fortran/48244] iso-c-binding support missing on NetBSD (with patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48244 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- I didn't send testresults to the list because without a dozen patches gcc won't compile at all. Did someone opened PRs for these failures? Patches should be submitted to gcc-patc...@gcc.gnu.org (and to fort...@gcc.gnu.org for Fortran or libstd...@gcc.gnu.org for libstdc++-v3). Testresults and necessary patches can be found at http://pkgsrc-wip.cvs.sourceforge.net/viewvc/pkgsrc-wip/wip/gcc50snapshot and gfortran works quite well on NetBSD. Would it help to send test_summary.log to the testresult mailing list ? I am reluctant to post test results with a lot of patches. I think it is better to post the results with the minimal set of patches to bootstrap, then results with one or two specific patches you can refer to on the gcc lists.
[Bug libstdc++/64140] match_results.prefix() returns an incorrect result if regex_iterator holds a zero-length match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64140 --- Comment #2 from Tim Shen timshen at gcc dot gnu.org --- Author: timshen Date: Sat Dec 6 11:32:21 2014 New Revision: 218445 URL: https://gcc.gnu.org/viewcvs?rev=218445root=gccview=rev Log: PR libstdc++/64140 Backport form mainline 2014-12-04 Tim Shen tims...@google.com * include/bits/regex.tcc (regex_iterator::operator++): Update prefix.matched after modifying prefix.first. * testsuite/28_regex/iterators/regex_iterator/char/64140.cc: New testcase. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/28_regex/iterators/regex_iterator/char/64140.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/bits/regex.tcc
[Bug target/64200] ICE: in decide_alg, at config/i386/i386.c:24510 with -mmemcpy-strategy=libcall:-1:align -minline-stringops-dynamically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64200 --- Comment #2 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Sat Dec 6 11:32:46 2014 New Revision: 218446 URL: https://gcc.gnu.org/viewcvs?rev=218446root=gccview=rev Log: Don't assert alg != libcall for -minline-stringops-dynamically gcc/ PR target/64200 * config/i386/i386.c (decide_alg): Don't assert alg != libcall for TARGET_INLINE_STRINGOPS_DYNAMICALLY. gcc/testsuite/ PR target/64200 * gcc.target/i386/memcpy-strategy-4.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/memcpy-strategy-4.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/64183] [5.0 Regression] Complete unroll doesn't happen for a while-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64183 --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Sat Dec 6 13:10:31 2014 New Revision: 218447 URL: https://gcc.gnu.org/viewcvs?rev=218447root=gccview=rev Log: PR tree-optimization/64183 * c-gimplify.c (c_gimplify_expr): Don't convert the RHS of a shift-expression if it is integer_type_node. Use types_compatible_p. * gcc.dg/tree-ssa/pr64183.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr64183.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/64183] [5.0 Regression] Complete unroll doesn't happen for a while-loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64183 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug fortran/60238] Allow colon-separated triplet in array initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60238 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Anybody against closing this PR as WONTFIX? No answer since almost nine months. Closing as WONTFIX.
[Bug fortran/62087] A Piece of code compiling with ifort but giving error by gfortran 4.8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62087 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- There insufficient and clear code to reproduce the issue. Please attach a complete self-contained example. I was considering the same question. The question was asked more than three months ago without feedback. Closing as INVALID.
[Bug libfortran/62296] EXECUTE_COMMAND_LINE not F2008 conforming
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62296 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- (In reply to Harald Anlauf from comment #4) (In reply to Harald Anlauf from comment #3) One might be able to do better on any reasonable Unix/Linux system. Replying to myself: Intel has changed/fixed their implementation of EXECUTE_COMMAND_LINE in version 15.1, and it appears to work reasonably now. What does it mean for gfortran?
[Bug fortran/61928] a fortran90 program compiles on hopper at NERSC but not under gfortran 4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61928 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr --- From comment 7 (posted more than four months ago) closing as INVALID.
[Bug fortran/61768] Fortran compiler goes into infinite loop while compiling SPEC2000 applu.f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61768 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- No reproducer, no feedback for more than four months. Closing as INVALID.
[Bug fortran/64138] gfortran interface issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64138 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #10 from Dominique d'Humieres dominiq at lps dot ens.fr --- The argument in comment 9 not being challenged, closing as INVALID.
[Bug fortran/61179] Can not compile type is(double complex)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61179 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- No feedback for more than six months, closing as WONTFIX.
[Bug rtl-optimization/64208] New: [4.9 Regression][iwmmxt] ICE: internal compiler error: Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64208
Bug ID: 64208
Summary: [4.9 Regression][iwmmxt] ICE: internal compiler error:
Max. number of generated reload insns per insn is
achieved (90)
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: siarhei.siamashka at gmail dot com
GCC 4.9.2
$ arm-none-linux-gnueabi-gcc -c -O1 -march=iwmmxt test.c
test.c: In function 'x2':
test.c:16:1: internal compiler error: Max. number of generated reload insns per
insn is achieved (90)
The test program itself (generated by creduce):
//
long long x6(void);
void x7(long long, long long);
void x8(long long);
int x0;
long long *x1;
void x2(void) {
long long *x3 = x1;
while (x1) {
long long x4 = x0, x5 = x6();
x7(x4, x5);
x8(x5);
*x3 = 0;
}
}
//
[Bug fortran/59345] _gfortran_internal_pack on compiler generated temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59345 --- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- I'm pasting here another testcase, since I think it is related. This works as it should (i.e. no pack/unpack), an allocatable as function result: cat tt.f90 SUBROUTINE S1(A) INTERFACE FUNCTION CONTIGUOUS_F1() RESULT(res) INTEGER, ALLOCATABLE :: res(:) END FUNCTION END INTERFACE CALL S2(CONTIGUOUS_F1()) END SUBROUTINE This generates a pack/unpack as well, i.e. an array that is a function result: cat tt.f90 SUBROUTINE S1(A) INTERFACE FUNCTION CONTIGUOUS_F1() RESULT(res) INTEGER :: res(5) END FUNCTION END INTERFACE CALL S2(CONTIGUOUS_F1()) END SUBROUTINE This also leads to a pack, a function that returns an allocatable, but called via a procedure pointer. cat tt.f90 SUBROUTINE S1(A) INTERFACE FUNCTION CONTIGUOUS_F1() RESULT(res) INTEGER, ALLOCATABLE :: res(:) END FUNCTION END INTERFACE PROCEDURE(CONTIGUOUS_F1), POINTER :: A CALL S2(A()) END SUBROUTINE In these cases, the issue seems that gfc_is_simply_contiguous returns false, while maybe it should return true ? I think this is also the reason things go wrong with the testcase in comment #1, this is an EXPR_OP, and somehow might be simply_contiguous nevertheless.
[Bug fortran/64209] New: [OOP] copy class(*) component from type with a subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64209 Bug ID: 64209 Summary: [OOP] copy class(*) component from type with a subroutine Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: polajnar.miha at gmail dot com Created attachment 34209 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34209action=edit Source code describing the bug The attached source code produces segmentation fault : Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7FA69CC6F4D0 #1 0x7FA69CC6E6B0 #2 0x7FA69C17E54F #3 0x4011FC in __copy_INTEGER_4_.3528 at gfort_bug.f90:? #4 0x4010B0 in __m_MOD_copy #5 0x401411 in MAIN__ at gfort_bug.f90:? Segmentation fault with gcc version 5.0.0 20141202 (experimental) [trunk revision 218267] (SUSE Linux). The code works fine with ifort.
[Bug fortran/59398] Wrong bounds for allocatable result and for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59398 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- Any progress or should this PR be closed as INVALID?
[Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-06 Ever confirmed|0 |1 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Aaron Graham from comment #3) I've solved this problem in my own setup by building the toolchain and application binaries with the same -mcpu. Yes, that's basically what you need to do if -mcpu can affect the availability of atomics. This has been known for some time (the same problem exists for i386 vs i486+) but it seems to be causing problems on ARM more and more often. I think PR 42734 is the same issue.
[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- Not sure what correct etiquette is for checking on bug status, but this has been sitting for close to two months now, so I thought I would poke my head in again. Nasty answer: what did you do to fix it? I RTFM and saw at https://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html#Cray-pointers The pointer is an integer that is intended to hold a memory address. The pointee may be an array or scalar. A pointee can be an assumed size array—that is, the last dimension may be left unspecified by using a * in place of a value—but a pointee cannot be an assumed shape array. No space is allocated for the pointee. So the test in comment 0 seems valid according the above. So either the POINTER statement is not recorded in the module, or it is recorded, but not used when the module is read. Note that using f77 extensions with f90+ standard features is a *VERY BAD* idea: if one wants to modernize a legacy f77 code, I think the first step should be to replace all the non-standard extensions with the suitable standard f90+ constructs, then refactor the code to use modules, ... . For this PR, I see three possibilities: (1) Document that cray pointers should not be used in modules for assumed size arrays. That's the easiest. (2) Reject cray pointers used in modules for assumed size arrays. This requires that you find the location to do it, but should not be too difficult. (3) Accept cray pointers used in modules for assumed size arrays, i.e., check that cray pointers are recorded in the module and that the information is properly used when reading the module. This is probably a lot of work, especially if you know very little about the generation and use of *.mod files (it is also quite tricky to change this part of the code). So pick your choice and do the work. Good luck!
[Bug libstdc++/64203] shared_mutex compile errors on bare-metal targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64203 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-12-06 Ever confirmed|0 |1
[Bug libstdc++/64203] shared_mutex compile errors on bare-metal targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64203 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Attachment #34208|0 |1 is obsolete|| --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org --- Created attachment 34210 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34210action=edit fix config macros for shared_lock (In reply to Sandra Loosemore from comment #2) FAOD it looks like on this target _GLIBCXX_USE_C99_STDINT_TR1 is defined but _GLIBCXX_HAS_GTHREADS is not. Right, which means that defer_lock_t etc should be defined, but my patch was incomplete and shared_mutex didn't include mutex to get those definitions. How's this one?
[Bug fortran/64207] vectorization report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64207 --- Comment #2 from Mike Page mike at mikepage dot us --- Thanks, Joost. I need to go find some current documentation. Thanks for fixing the typo in my bad example.
[Bug fortran/64207] vectorization report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64207 --- Comment #3 from Mike Page mike at mikepage dot us --- BTW, I was using https://gcc.gnu.org/projects/tree-ssa/vectorization.html#using for my info on optimization options.
[Bug target/64210] New: FAIL: gcc.target/i386/avx512vl-(vmovdqa64|vpbroadcastd)-1.c ... with -fpic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64210
Bug ID: 64210
Summary: FAIL:
gcc.target/i386/avx512vl-(vmovdqa64|vpbroadcastd)-1.c
... with -fpic
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
CC: hjl at gcc dot gnu.org, iains at gcc dot gnu.org,
tocarip at gcc dot gnu.org
Target: x86_64-*-*
Compiling the following tests with -fpic fail some scan-assembler-times tests
FAIL: gcc.target/i386/avx512vl-vmovdqa64-1.c scan-assembler-times vmovdqa64[
t]+[^{\\n]*%ymm[0-9]+[^\\n^x^y]*(.{5}(?:\\n|[ t]+#) 1
FAIL: gcc.target/i386/avx512vl-vmovdqa64-1.c scan-assembler-times vmovdqa64[
t]+([^\\n]*%xmm[0-9]+(?:\\n|[ t]+#) 1
FAIL: gcc.target/i386/avx512vl-vmovdqa64-1.c scan-assembler-times vmovdqa64[
t]+([^\\n]*%ymm[0-9]+(?:\\n|[ t]+#) 1
FAIL: gcc.target/i386/avx512vl-vpbroadcastd-1.c scan-assembler-times
vpbroadcastd[ t]+%e[^\\n]*%ymm[0-9]+{%k[1-7]}(?:\\n|[ t]+#) 1
see, e.g., https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg00687.html, with
both -m32 and -m64, except gcc.target/i386/avx512vl-vpbroadcastd-1.c which
fails with -m64 only.
In the later case the failure is likely due to
vpbroadcastd%r8d, %ymm0{%k5}
For gcc.target/i386/avx512vl-vmovdqa64-1.c, grepping vmovdqa64 gives
vmovdqa64(%eax), %ymm1
vmovdqa64(%ecx), %ymm0
vmovdqa64%ymm1, %ymm0{%k1}
vmovdqa64%ymm0, (%ecx)
vmovdqa64(%edi), %xmm1
vmovdqa64(%esi), %xmm0
vmovdqa64%xmm1, %xmm0{%k2}
vmovdqa64(%esi), %ymm0
vmovdqa64%ymm0, %ymm0{%k3}{z}
vmovdqa64%ymm0, (%ecx)
vmovdqa64(%edi), %xmm0
vmovdqa64%xmm0, %xmm0{%k4}{z}
vmovdqa64(%esi), %ymm0
vmovdqa64%ymm0, (%ecx)
vmovdqa64(%esi), %xmm0
vmovdqa64(%ecx), %ymm0
vmovdqa64(%ebx), %ymm0{%k5}
vmovdqa64%ymm0, (%ecx)
vmovdqa64(%edx), %xmm0
vmovdqa64(%ebx), %xmm0{%k6}
vmovdqa64(%ebx), %ymm0{%k7}{z}
vmovdqa64%ymm0, (%ecx)
vmovdqa64(%ebx), %xmm0{%k1}{z}
vmovdqa64(%ecx), %ymm0
vmovdqa64%ymm0, (%ebx)
vmovdqa64(%edx), %xmm0
vmovdqa64(%ecx), %ymm0
vmovdqa64%ymm0, (%ecx){%k2}
vmovdqa64(%edx), %xmm0
vmovdqa64%xmm0, (%eax){%k3}
but I failed to see where are the problems.
[Bug fortran/64207] vectorization report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64207 --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Mike Page from comment #3) BTW, I was using https://gcc.gnu.org/projects/tree-ssa/vectorization.html#using for my info on optimization options. yes, I agree that there is lots of outdated info, also I had to search a while to find the proper option name. Almost all hits online refer to the old option. The web never forgets ;-)
[Bug fortran/63529] Bad error and ICE with Cray Pointers in Modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529 --- Comment #10 from Steve Kargl sgk at troutmask dot apl.washington.edu --- On Sat, Dec 06, 2014 at 04:38:53PM +, dominiq at lps dot ens.fr wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63529 --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- Not sure what correct etiquette is for checking on bug status, but this has been sitting for close to two months now, so I thought I would poke my head in again. Nasty answer: what did you do to fix it? I RTFM and saw at https://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html#Cray-pointers That's a tad bit harsh. I don't recall Russell reporting previous bugs/issues. Don't want to scare off a potential contributor. :) Russell, there is no correct etiquette when inferring about the status of a bug. Unfortunately, the reality of the situation is that there are too few gfortran developers and too many issues. That is, there is a man power problem. A gfortran developer typically fixes bugs that effect his own ability to use gfortran or, well, bugs that he knows how to fix. The individual who implemented the Cray pointer feature (and the person with the most intimate knowledge of how it works) hasn't contributed to gfortran in a long time, which is understandable in that the priorities of volunteers do change. Dominique's advise of not mixing vendor extensions with newer Fortran features (i.e., cray pointers and modules) is well intended. I know this above isn't what you want to read, but unfortunately, it is the reality of the situation.
[Bug tree-optimization/54742] Switch elimination in FSM loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 --- Comment #39 from Sebastian Pop spop at gcc dot gnu.org --- Author: spop Date: Sat Dec 6 19:19:37 2014 New Revision: 218451 URL: https://gcc.gnu.org/viewcvs?rev=218451root=gccview=rev Log: extend jump thread for finite state automata PR tree-optimization/54742 * params.def (max-fsm-thread-path-insns, max-fsm-thread-length, max-fsm-thread-paths): New. * doc/invoke.texi (max-fsm-thread-path-insns, max-fsm-thread-length, max-fsm-thread-paths): Documented. * tree-cfg.c (split_edge_bb_loc): Export. * tree-cfg.h (split_edge_bb_loc): Declared extern. * tree-ssa-threadedge.c (simplify_control_stmt_condition): Restore the original value of cond when simplification fails. (fsm_find_thread_path): New. (fsm_find_control_statement_thread_paths): New. (thread_through_normal_block): Call find_control_statement_thread_paths. * tree-ssa-threadupdate.c (dump_jump_thread_path): Pretty print EDGE_FSM_THREAD. (verify_seme): New. (duplicate_seme_region): New. (thread_through_all_blocks): Generate code for EDGE_FSM_THREAD edges calling duplicate_seme_region. * tree-ssa-threadupdate.h (jump_thread_edge_type): Add EDGE_FSM_THREAD. * testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c: New test. * testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-6.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi trunk/gcc/params.def trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c trunk/gcc/tree-cfg.h trunk/gcc/tree-ssa-threadedge.c trunk/gcc/tree-ssa-threadupdate.c trunk/gcc/tree-ssa-threadupdate.h
[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794 Bug 19794 depends on bug 54742, which changed state. Bug 54742 Summary: Switch elimination in FSM loop https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/54742] Switch elimination in FSM loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54742 Sebastian Pop spop at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #40 from Sebastian Pop spop at gcc dot gnu.org --- Fixed in r218451.
[Bug libstdc++/63829] _Lock_policy used in thread.cc can cause incompatibilities with binaries using different -mcpu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63829 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Aaron Graham from comment #3) I've solved this problem in my own setup by building the toolchain and application binaries with the same -mcpu. A more general solution might be to move more code out of places like thread.cc and into the headers. I think the right solution is to determine the lock policy when GCC is configured and set it once and not have it change at compile-time based on flags such as -mcpu.
[Bug libstdc++/64203] shared_mutex compile errors on bare-metal targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64203 --- Comment #4 from Sandra Loosemore sandra at codesourcery dot com --- (In reply to Jonathan Wakely from comment #3) How's this one? Looks better; this version fixes the compile-time errors.
[Bug tree-optimization/26731] Jump threading gets in the way of loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26731
Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
||.ch
--- Comment #3 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch
---
(In reply to Andrew Pinski from comment #0)
Jump threading causes bad interactions with loops:
int f(int t, int a, int x)
{
int n, g;
if (t)
n = a;
else
n = 4;
for (g=0; gn; g++)
x++;
return x;
}
This should be optimized to:
int f(int t, int a, int x)
{
int n, g;
if (t)
n = a;
else
n = 4;
x+=n;
return x;
}
But is not because of jump threading getting in the way to dect that the
loop is finite.
actually, it should not, for a0 and t=1.
[Bug libstdc++/61947] [4.8/4.9 Regression] Ambiguous calls when constructing std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Sat Dec 6 20:38:01 2014 New Revision: 218453 URL: https://gcc.gnu.org/viewcvs?rev=218453root=gccview=rev Log: PR libstdc++/61947 * include/std/tuple (_Head_base): Use allocator_arg_t parameters to disambiguate unary constructors. (_Tuple_impl): Pass allocator_arg_t arguments. * testsuite/20_util/tuple/61947.cc: New. * testsuite/20_util/uses_allocator/cons_neg.cc: Adjust dg-error line. Added: branches/gcc-4_8-branch/libstdc++-v3/testsuite/20_util/tuple/61947.cc - copied, changed from r218452, branches/gcc-4_8-branch/libstdc++-v3/testsuite/20_util/uses_allocator/cons_neg.cc Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/std/tuple branches/gcc-4_8-branch/libstdc++-v3/testsuite/20_util/uses_allocator/cons_neg.cc
[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Sat Dec 6 20:38:07 2014 New Revision: 218454 URL: https://gcc.gnu.org/viewcvs?rev=218454root=gccview=rev Log: PR libstdc++/59603 * include/bits/stl_algo.h (random_shuffle): Prevent self-swapping. * testsuite/25_algorithms/random_shuffle/59603.cc: New. Added: branches/gcc-4_8-branch/libstdc++-v3/testsuite/25_algorithms/random_shuffle/59603.cc Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/bits/stl_algo.h
[Bug libstdc++/63840] std::function copy constructor deletes an uninitialized pointer if new fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63840 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Sat Dec 6 20:37:54 2014 New Revision: 218452 URL: https://gcc.gnu.org/viewcvs?rev=218452root=gccview=rev Log: PR libstdc++/63840 * include/std/functional (function::function(const function)): Set _M_manager after operations that might throw. * include/tr1/functional (function::function(const function), function::function(_Functor, _Useless)): Likewise. * testsuite/20_util/function/63840.cc: New. * testsuite/tr1/3_function_objects/function/63840.cc: New. Added: branches/gcc-4_8-branch/libstdc++-v3/testsuite/20_util/function/63840.cc branches/gcc-4_8-branch/libstdc++-v3/testsuite/tr1/3_function_objects/function/63840.cc Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/std/functional branches/gcc-4_8-branch/libstdc++-v3/include/tr1/functional
[Bug libstdc++/59603] std::random_shuffle tries to swap element with itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59603 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.4 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed in all active branches.
[Bug libfortran/62094] Program crash when executing DEALLOCATE with addresses that have 0 in bits 26 and higher (little-endian)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62094 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- No feedback for almost four months. Closing as INVALID.
[Bug fortran/62007] default(none) conflicts with iteration variable in openmp parallel loop simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62007 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |NEW CC||jakub at gcc dot gnu.org --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- % cat pr62007_db.f program hello integer :: i, x C$omp parallel do simd private(x) default(none) do i=1,10 x=x+1 end do end program hello triggers the same error.
[Bug fortran/60751] Extra comma in WRITE statement not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751 --- Comment #12 from Dominique d'Humieres dominiq at lps dot ens.fr --- Is there an agreement to downgrade the error from GFC_STD_GNU in gcc/fortran/io.c: !gfc_notify_std (GFC_STD_GNU, Comma before i/o item list at %L, to GFC_STD_LEGACY? If yes, I'll submit a patch. If not, this PR should be closed as WONTFIX.
[Bug libstdc++/63840] std::function copy constructor deletes an uninitialized pointer if new fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63840 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Sat Dec 6 22:24:11 2014 New Revision: 218456 URL: https://gcc.gnu.org/viewcvs?rev=218456root=gccview=rev Log: PR libstdc++/63840 * include/std/functional (function::function(const function)): Set _M_manager after operations that might throw. * include/tr1/functional (function::function(const function), function::functionFunctor, _Useless)): Likewise. * testsuite/20_util/function/63840.cc: New. * testsuite/tr1/3_function_objects/function/63840.cc: New. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/function/63840.cc branches/gcc-4_9-branch/libstdc++-v3/testsuite/tr1/3_function_objects/function/63840.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/std/functional branches/gcc-4_9-branch/libstdc++-v3/include/tr1/functional
[Bug libstdc++/61947] [4.8/4.9 Regression] Ambiguous calls when constructing std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947 --- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org --- Author: redi Date: Sat Dec 6 22:24:16 2014 New Revision: 218457 URL: https://gcc.gnu.org/viewcvs?rev=218457root=gccview=rev Log: PR libstdc++/61947 * include/std/tuple (_Head_base): Use allocator_arg_t parameters to disambiguate unary constructors. (_Tuple_impl): Pass allocator_arg_t arguments. * testsuite/20_util/tuple/61947.cc: New. * testsuite/20_util/uses_allocator/cons_neg.cc: Adjust dg-error line. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/tuple/61947.cc - copied, changed from r218456, branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/uses_allocator/cons_neg.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/std/tuple branches/gcc-4_9-branch/libstdc++-v3/testsuite/20_util/uses_allocator/cons_neg.cc
[Bug libstdc++/63840] std::function copy constructor deletes an uninitialized pointer if new fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63840 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for 4.8.4, 4.9.3 and 5.1
[Bug libstdc++/61947] [4.8/4.9 Regression] Ambiguous calls when constructing std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.10.0 |5.0 Resolution|--- |FIXED --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org --- Fixed for 4.8.4 and 4.9.3 too
[Bug fortran/56660] Fails to read NAMELIST with certain form array syntax
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56660 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr --- I guess it is PR55117. I think this PR should be closed if there is no plans to back port the fix. No feedback for almost a year. The PR is fixed on 4.9.2 and on trunk (5.0). Closing as FIXED.
[Bug fortran/56744] [meta-bug] Namelist bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56744 Bug 56744 depends on bug 56660, which changed state. Bug 56660 Summary: Fails to read NAMELIST with certain form array syntax https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56660 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/56203] gfortran.dg/minlocval_3.f90 times out on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56203 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Without feedback I'll close this PR as WONTFIX.
[Bug fortran/56203] gfortran.dg/minlocval_3.f90 times out on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56203 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- dominiq at lps dot ens.fr gcc-bugzi...@gcc.gnu.org writes: --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Without feedback I'll close this PR as WONTFIX. This has become more pronounced with increased gfortran testing parallelism. I'll provide more feedback next week. Rainer
