[Bug libfortran/67535] write.c sanitizer detects null pointer passed to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67535 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- It is still undefined behavior, so e.g. gcc will happily remove NULL pointer checks after it sees a pointer used in memcpy, etc.
[Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67513 --- Comment #2 from Jakub Jelinek --- Note, the asan pass emits the checks in the order of first testing for non-zero and then doing the sub-quadword comparison (if any), but uses bitwise and in between the two conditions and the choice to expand it this way is the expander and backend choice. To force the behavior you want we'd need to create explicit conditional jump around the second test in the IL.
[Bug c/67502] ICE with collapsed for simd loop inside of parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67502 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Thu Sep 10 07:28:27 2015 New Revision: 227605 URL: https://gcc.gnu.org/viewcvs?rev=227605&root=gcc&view=rev Log: PR c/67502 * c-parser.c (c_parser_omp_for_loop): Emit DECL_EXPR stmts into OMP_FOR_PRE_BODY rather than before the loop. * c-c++-common/gomp/pr67502.c: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr67502.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/67514] ICE in omp_add_variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67514 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Thu Sep 10 07:31:14 2015 New Revision: 227607 URL: https://gcc.gnu.org/viewcvs?rev=227607&root=gcc&view=rev Log: PR c++/67514 * gimplify.c (gimplify_omp_for): For loop SIMD construct, if iterator is not explicitly determined, but is defined inside of the combined workshare region, handle it like if it has DECL_EXPR in OMP_FOR_PRE_BODY. * g++.dg/gomp/pr67514.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr67514.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug c++/67511] ICE with invalid OpenMP random access iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67511 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Thu Sep 10 07:30:29 2015 New Revision: 227606 URL: https://gcc.gnu.org/viewcvs?rev=227606&root=gcc&view=rev Log: PR c++/67511 * semantics.c (handle_omp_for_class_iterator): Don't wrap error_mark_node into a NOP_EXPR to void_type_node. * g++.dg/gomp/pr67511.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr67511.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/67517] ICE in gimplify_scan_omp_clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67517 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Thu Sep 10 07:32:13 2015 New Revision: 227608 URL: https://gcc.gnu.org/viewcvs?rev=227608&root=gcc&view=rev Log: PR middle-end/67517 * gimplify.c (gimplify_scan_omp_clauses): Instead of asserting that decl is not specified in octx->variables, break out of the loop if it is. * c-c++-common/gomp/pr67517.c: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr67517.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/67521] ICE when OpenMP loop expressions mention the IV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67521 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Thu Sep 10 07:32:54 2015 New Revision: 227609 URL: https://gcc.gnu.org/viewcvs?rev=227609&root=gcc&view=rev Log: PR middle-end/67521 * gimplify.c (gimplify_omp_for): Don't call omp_add_variable if decl is already in outer->variables. * c-c++-common/gomp/pr67521.c: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr67521.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug c++/67522] OpenMP ICE in type_dependent_expression_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67522 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Thu Sep 10 07:34:42 2015 New Revision: 227610 URL: https://gcc.gnu.org/viewcvs?rev=227610&root=gcc&view=rev Log: PR c++/67522 * semantics.c (handle_omp_array_sections_1): Only run type_dependent_expression_p on VAR_DECL/PARM_DECLs. (finish_omp_clauses) : Likewise. Don't adjust OMP_CLAUSE_LINEAR_STEP if OMP_CLAUSE_DECL is not a VAR_DECL/PARM_DECL. * g++.dg/gomp/pr67522.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr67522.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug target/67169] -fstack-check=no doesn't disable stack checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67169 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |INVALID --- Comment #3 from Eric Botcazou --- > If I use '-fstack-check=specific' *that* does seem to do what I want. But > I'm not sure I should be suggesting that as an upstream fix for the MinGW > build, because it seems wrong. No, -fstack-check=specific only changes the stack checking method. In any case, stack checking is required by the ABI on Windows so cannot be disabled.
[Bug c++/67523] ICE with invalid combined simd inside of a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67523 --- Comment #1 from Jakub Jelinek --- Author: jakub Date: Thu Sep 10 07:35:56 2015 New Revision: 227611 URL: https://gcc.gnu.org/viewcvs?rev=227611&root=gcc&view=rev Log: PR c++/67523 * gimplify.c (gimplify_omp_for): If inner stmt is not found for combined loop, assert seen_error () and return GS_ERROR. * g++.dg/gomp/pr67523.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr67523.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog
[Bug c/67502] ICE with collapsed for simd loop inside of parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67502 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Thu Sep 10 07:37:00 2015 New Revision: 227612 URL: https://gcc.gnu.org/viewcvs?rev=227612&root=gcc&view=rev Log: PR c/67502 * c-parser.c (c_parser_omp_for_loop): Emit DECL_EXPR stmts into OMP_FOR_PRE_BODY rather than before the loop. * c-c++-common/gomp/pr67502.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/c-c++-common/gomp/pr67502.c Modified: branches/gcc-5-branch/gcc/c/ChangeLog branches/gcc-5-branch/gcc/c/c-parser.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c++/67511] ICE with invalid OpenMP random access iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67511 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Thu Sep 10 07:37:48 2015 New Revision: 227613 URL: https://gcc.gnu.org/viewcvs?rev=227613&root=gcc&view=rev Log: PR c++/67511 * semantics.c (handle_omp_for_class_iterator): Don't wrap error_mark_node into a NOP_EXPR to void_type_node. * g++.dg/gomp/pr67511.C: New test. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/gomp/pr67511.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/semantics.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c++/67514] ICE in omp_add_variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67514 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Thu Sep 10 07:38:30 2015 New Revision: 227614 URL: https://gcc.gnu.org/viewcvs?rev=227614&root=gcc&view=rev Log: PR c++/67514 * gimplify.c (gimplify_omp_for): For loop SIMD construct, if iterator is not explicitly determined, but is defined inside of the combined workshare region, handle it like if it has DECL_EXPR in OMP_FOR_PRE_BODY. * g++.dg/gomp/pr67514.C: New test. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/gomp/pr67514.C Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/gimplify.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug middle-end/67521] ICE when OpenMP loop expressions mention the IV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67521 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Thu Sep 10 07:39:53 2015 New Revision: 227616 URL: https://gcc.gnu.org/viewcvs?rev=227616&root=gcc&view=rev Log: PR middle-end/67521 * gimplify.c (gimplify_omp_for): Don't call omp_add_variable if decl is already in outer->variables. * c-c++-common/gomp/pr67521.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/c-c++-common/gomp/pr67521.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/gimplify.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug middle-end/67517] ICE in gimplify_scan_omp_clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67517 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Thu Sep 10 07:39:20 2015 New Revision: 227615 URL: https://gcc.gnu.org/viewcvs?rev=227615&root=gcc&view=rev Log: PR middle-end/67517 * gimplify.c (gimplify_scan_omp_clauses): Instead of asserting that decl is not specified in octx->variables, break out of the loop if it is. * c-c++-common/gomp/pr67517.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/c-c++-common/gomp/pr67517.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/gimplify.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c++/67522] OpenMP ICE in type_dependent_expression_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67522 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Thu Sep 10 07:40:59 2015 New Revision: 227617 URL: https://gcc.gnu.org/viewcvs?rev=227617&root=gcc&view=rev Log: PR c++/67522 * semantics.c (handle_omp_array_sections_1): Only run type_dependent_expression_p on VAR_DECL/PARM_DECLs. (finish_omp_clauses) : Likewise. Don't adjust OMP_CLAUSE_LINEAR_STEP if OMP_CLAUSE_DECL is not a VAR_DECL/PARM_DECL. * g++.dg/gomp/pr67522.C: New test. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/gomp/pr67522.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/semantics.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c++/67523] ICE with invalid combined simd inside of a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67523 --- Comment #2 from Jakub Jelinek --- Author: jakub Date: Thu Sep 10 07:41:34 2015 New Revision: 227618 URL: https://gcc.gnu.org/viewcvs?rev=227618&root=gcc&view=rev Log: PR c++/67523 * gimplify.c (gimplify_omp_for): If inner stmt is not found for combined loop, assert seen_error () and return GS_ERROR. * g++.dg/gomp/pr67523.C: New test. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/gomp/pr67523.C Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/gimplify.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug ada/67205] violation of No_Implicit_Dynamic_Code restriction not reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67205 Eric Botcazou changed: What|Removed |Added Summary|Unnecessary trampolines for |violation of |nested packages |No_Implicit_Dynamic_Code ||restriction not reported --- Comment #2 from Eric Botcazou --- > The attached example requires generation of trampolines. This may be due to > bug 57999, but I think a front-end fix would be more reliable. Please clarify "front-end fix". The language requires pointers to nested functions in this case and you cannot reasonably change that, nested functions being first-class citizens in Ada. More generally, trampolines can indeed be eliminated, but you need changes in the entire compiler to do it. > As an additional surprise, pragma Restrictions (No_Implicit_Dynamic_Code) > does not cause compilation to fail. The error is only detected at binding > time, and -Wtrampolines is needed to find the culprit. Yes, the violation is detected but the error is not issued, probably because it's the instantiation of a run-time unit.
[Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67513 --- Comment #3 from Andrey Ryabinin --- (In reply to Yury Gribov from comment #1) > (In reply to Andrey Ryabinin from comment #0) > > (shadow value is usually zero). > > What makes you think so? AFAIU for less-than-8-byte scalars it's always > non-zero. If 'a' is a pointer to an individual stack/global variable then yes, shadow will be non-zero. But if it's part of some array or a struct field, more likely shadow will be zero. So I'm not saying that we should blindly switch to non-zero test first, but it definitely worth trying. > I vaguely remember than Kostya did something like this in Clang > case and it resulted in negligeable improvement. clang (version 3.7.0 (tags/RELEASE_370/final)) tests for non-zero first: foo:# @foo .cfi_startproc # BB#0: pushq %rax .Ltmp0: .cfi_def_cfa_offset 16 testl %esi, %esi je .LBB0_4 # BB#1: # %.lr.ph movq%rdi, %rax shrq$3, %rax movb2147450880(%rax), %al testb %al, %al jne .LBB0_2 .LBB0_3: movl$0, (%rdi) .LBB0_4: popq%rax retq .LBB0_2: movl%edi, %ecx andl$7, %ecx addl$3, %ecx movsbl %al, %eax cmpl%eax, %ecx jl .LBB0_3 # BB#5: callq __asan_report_store4 #APP #NO_APP .Lfunc_end0: .size foo, .Lfunc_end0-foo .cfi_endproc
[Bug fortran/66993] Spurious ambiguous symbol error with submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66993 Paul Thomas changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-10 CC||paul.richard.thomas at gmail dot c ||om, pault at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Paul Thomas --- Dear Mikael, By golly, you are correct! I'll take it. Thanks for pointing this out. Cheers Paul
[Bug target/67169] -fstack-check=no doesn't disable stack checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67169 --- Comment #4 from David Woodhouse --- It's required by Windows but not by UEFI, which otherwise has the same ABI. We had previously been able to build UEFI firmware with MinGW.
[Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67513 --- Comment #4 from Andrey Ryabinin --- (In reply to Andrey Ryabinin from comment #3) > (In reply to Yury Gribov from comment #1) > > (In reply to Andrey Ryabinin from comment #0) > > > (shadow value is usually zero). > > > > What makes you think so? AFAIU for less-than-8-byte scalars it's always > > non-zero. > > If 'a' is a pointer to an individual stack/global variable then yes, shadow > will be non-zero. > But if it's part of some array or a struct field, more likely shadow will be > zero. > So I'm not saying that we should blindly switch to non-zero test first, but > it definitely worth trying. > > > I vaguely remember than Kostya did something like this in Clang > > case and it resulted in negligeable improvement. > > clang (version 3.7.0 (tags/RELEASE_370/final)) > tests for non-zero first: > this was a dump from slightly different test-case, here is correct one: foo:# @foo .cfi_startproc # BB#0: pushq %rax .Ltmp0: .cfi_def_cfa_offset 16 movq%rdi, %rax shrq$3, %rax movb2147450880(%rax), %al testb %al, %al jne .LBB0_1 .LBB0_3: movb$0, (%rdi) popq%rax retq .LBB0_1: movl%edi, %ecx andl$7, %ecx movsbl %al, %eax cmpl%eax, %ecx jl .LBB0_3 # BB#2: callq __asan_report_store1 #APP #NO_APP .Lfunc_end0: .size foo, .Lfunc_end0-foo .cfi_endproc
[Bug fortran/63570] [F2015] Implement 13.7.137 RANDOM INIT (REPEATABLE, IMAGE DISTINCT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63570 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-10 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Marked as NEW.
[Bug target/67169] add an option to disable stack checking on x86 for UEFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67169 Eric Botcazou changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2015-09-10 Resolution|INVALID |--- Summary|-fstack-check=no doesn't|add an option to disable |disable stack checking |stack checking on x86 for ||UEFI Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #5 from Eric Botcazou --- > It's required by Windows but not by UEFI, which otherwise has the same ABI. OK. Let's reopen it as a target-specific enhancement request then. > We had previously been able to build UEFI firmware with MinGW. Presumably because you had only small frames?
[Bug libfortran/67535] write.c sanitizer detects null pointer passed to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67535 --- Comment #3 from Vittorio Zecca --- (In reply to kargl from comment #1) > What happens to performance? Simply making changes to > make sanitizer happy seems rather questionable. It's clear > from context that if base_name == NULL, then base_name_len > == 0, and the memcpy should be a NOP. How costly is that NOP compared to if(base_name_len)? How costly is to let go an undefined behaviour?
[Bug fortran/66707] Endless compilation on wrong usage of common
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66707 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-10 CC||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed with 4.9.3 and 5.2. This seems to have been fixed on trunk between revision r226476 (2015-08-02, endless compilation) and r227016 (2015-08-19, tests compiled in a fraction of second).
[Bug fortran/67524] ICE on using implicit character instead of implicit none etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67524 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-09-10 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0).
[Bug c++/67523] ICE with invalid combined simd inside of a template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67523 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed for 5.3+.
[Bug tree-optimization/67476] Add --param parloops-schedule=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67476 --- Comment #3 from vries at gcc dot gnu.org --- Created attachment 36318 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36318&action=edit Tentative patch
[Bug bootstrap/66038] [5 regression] (stage 2) build/genmatch issue (gcc/hash-table.h|c) with --disable-checking [ introduced by r218976 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038 --- Comment #29 from Douglas Mencken --- Vanilla GCC 5.2 bootstraps perfectly (without --disable-checking) on my side
[Bug fortran/60110] ICE in gfc_get_symbol_decl, at fortran/trans-decl.c:1266
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60110 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Dominique d'Humieres --- >From comment 5 > > It could be a duplicate of pr52332 (ICE at the same place). > > It might be. ... and comment 8 > The tests in this PR compile when the patch at > https://gcc.gnu.org/ml/fortran/2015-09/msg00042.html is applied. Marked as duplicate. *** This bug has been marked as a duplicate of bug 52332 ***
[Bug fortran/52332] Internal compiler error in in gfc_get_symbol_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52332 Dominique d'Humieres changed: What|Removed |Added CC||walt.brainerd at gmail dot com --- Comment #4 from Dominique d'Humieres --- *** Bug 60110 has been marked as a duplicate of this bug. ***
[Bug fortran/62246] internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62246 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Dominique d'Humieres --- The tests in this PR compile when the patch at https://gcc.gnu.org/ml/fortran/2015-09/msg00042.html is applied. Marked as duplicate of pr52332. *** This bug has been marked as a duplicate of bug 52332 ***
[Bug fortran/52332] Internal compiler error in in gfc_get_symbol_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52332 Dominique d'Humieres changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #5 from Dominique d'Humieres --- *** Bug 62246 has been marked as a duplicate of this bug. ***
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 Sebastian Huber changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #11 from Sebastian Huber --- Yes, the mingw build is still broken. Git has compatibility functions for setenv() and unsetenv(): https://github.com/git/git/blob/master/compat/setenv.c https://github.com/git/git/blob/master/compat/unsetenv.c Maybe something like this can be used in GCC as well.
[Bug fortran/65766] gFortran Compiler SEGFAULTING on compiling simple program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65766 --- Comment #5 from Dominique d'Humieres --- Fixed by the patch at https://gcc.gnu.org/ml/fortran/2015-07/msg00166.html.
[Bug fortran/61676] Allocatable string as type component causes compile time segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61676 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Dominique d'Humieres --- Fixed by the patch at https://gcc.gnu.org/ml/fortran/2015-07/msg00166.html. Marked as duplicate of pr65766. *** This bug has been marked as a duplicate of bug 65766 ***
[Bug fortran/65766] gFortran Compiler SEGFAULTING on compiling simple program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65766 Dominique d'Humieres changed: What|Removed |Added CC||ian.thompson at liv dot ac.uk --- Comment #6 from Dominique d'Humieres --- *** Bug 61676 has been marked as a duplicate of this bug. ***
[Bug fortran/63494] ICE with deferred-character-length component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63494 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Dominique d'Humieres --- Fixed by the patch at https://gcc.gnu.org/ml/fortran/2015-07/msg00166.html. Marked as duplicate of pr65766. *** This bug has been marked as a duplicate of bug 65766 ***
[Bug fortran/65766] gFortran Compiler SEGFAULTING on compiling simple program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65766 Dominique d'Humieres changed: What|Removed |Added CC||jwmwalrus at gmail dot com --- Comment #7 from Dominique d'Humieres --- *** Bug 63494 has been marked as a duplicate of this bug. ***
[Bug middle-end/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118 Arthur LAMBERT changed: What|Removed |Added CC||lambertarthur22 at gmail dot com --- Comment #3 from Arthur LAMBERT --- Same problem for me after updating my gcc version from 4.8.4 to 4.9.3. I have a piece of code using pthread_clean_push/pop which lead to the same warning : error: variable ‘x’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered] error: variable ‘y’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered] error: variable ‘__cancel_routine’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Werror=clobbered] Just need to comment the pthread_clean_X call to remove the warning. Any update on this ?
[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506 --- Comment #5 from Kazumoto Kojima --- (In reply to Oleg Endo from comment #4) > Could you please test it? It fixes all test cases for the cross trunk sh4-unknown-linux-gnu compiler. There is no new failures with the top level "make -k check".
[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506 --- Comment #6 from Oleg Endo --- (In reply to Kazumoto Kojima from comment #5) > (In reply to Oleg Endo from comment #4) > > Could you please test it? > > It fixes all test cases for the cross trunk sh4-unknown-linux-gnu compiler. > There is no new failures with the top level "make -k check". Thanks. I will commit it and add attachment 36309 as a c-torture test.
[Bug target/67480] AVX512 bitwise logic operations pattern is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67480 --- Comment #3 from Alexander Fomin --- There is another problem with the same pattern. Suppose an V16SF insn mode and AVX512F target (e.g. KNL). We'll emit something like vandps %zmm1, %zmm2, %zmm3; however, vps family requires AVX512VL and/or AVX512DQ CPUID.
[Bug middle-end/67421] gcc.dg/wide-shift-64.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67421 --- Comment #5 from Jiong Wang --- Author: jiwang Date: Thu Sep 10 10:37:17 2015 New Revision: 227629 URL: https://gcc.gnu.org/viewcvs?rev=227629&root=gcc&view=rev Log: [Patch/expand] Cost instruction sequences when doing left wide shift Patch background details: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg01147.html gcc/ PR rtl-optimization/67421 * expr.c (expand_expr_real_2): Cost instrcution sequences when doing left wide shift tranformation. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c
[Bug target/67439] [4.9/5/6 Regression]ICE: unrecognizable insn compiling arm-fp16 testcases with -march=armv7-a and -mrestrict-it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67439 --- Comment #6 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Thu Sep 10 10:43:43 2015 New Revision: 227630 URL: https://gcc.gnu.org/viewcvs?rev=227630&root=gcc&view=rev Log: [ARM] PR 67439: Allow matching of *arm32_movhf when -mrestrict-it is on PR target/67439 * config/arm/arm.md (*arm32_movhf): Remove !arm_restrict_it from predicate. Set predicable_short_it attr to "no". * gcc.target/arm/pr67439_1.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr67439_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.md trunk/gcc/testsuite/ChangeLog
[Bug middle-end/67421] gcc.dg/wide-shift-64.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67421 Jiong Wang changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jiong Wang --- fixed
[Bug target/67439] [4.9/5/6 Regression]ICE: unrecognizable insn compiling arm-fp16 testcases with -march=armv7-a and -mrestrict-it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67439 --- Comment #7 from ktkachov at gcc dot gnu.org --- Fixed for trunk. Will backport to 5 and 4.9 in a few days
[Bug ada/67205] violation of No_Implicit_Dynamic_Code restriction not reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67205 --- Comment #3 from Florian Weimer --- (In reply to Eric Botcazou from comment #2) > > The attached example requires generation of trampolines. This may be due to > > bug 57999, but I think a front-end fix would be more reliable. > > Please clarify "front-end fix". The language requires pointers to nested > functions in this case and you cannot reasonably change that, nested > functions being first-class citizens in Ada. > > More generally, trampolines can indeed be eliminated, but you need changes > in the entire compiler to do it. Couldn't you put the static chain for the dispatching subprograms into the vtable of the tagged type? In some examples (including this one, and those I recently submitted as a GNAT tools patch), it seems rather straightforward to float the generic instantiation out of the nested subprogram. Some care is necessary to make sure the transformation is in fact valid, but I had hoped this would be a more localized change in the compiler.
[Bug ada/67205] violation of No_Implicit_Dynamic_Code restriction not reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67205 --- Comment #4 from Eric Botcazou --- > Couldn't you put the static chain for the dispatching subprograms into the > vtable of the tagged type? Presumably not, the vtable layout is constrained by the C++ compatibility and this extends to local tagged types since Ada 2005. In any case, see below. > In some examples (including this one, and those I recently submitted as a > GNAT tools patch), it seems rather straightforward to float the generic > instantiation out of the nested subprogram. Some care is necessary to make > sure the transformation is in fact valid, but I had hoped this would be a > more localized change in the compiler. The truth is, the versions of GNAT released by AdaCore use a general scheme to eliminate (almost) all trampolines, at least on native platforms, so there is no incentive for small tricks like this. We could submit the scheme if there is some interest from the community.
[Bug ada/67205] violation of No_Implicit_Dynamic_Code restriction not reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67205 --- Comment #5 from Florian Weimer --- (In reply to Eric Botcazou from comment #4) > The truth is, the versions of GNAT released by AdaCore use a general scheme > to eliminate (almost) all trampolines, at least on native platforms, so > there is no incentive for small tricks like this. We could submit the > scheme if there is some interest from the community. Fedora has policies against executable stack, and fewer off them are always welcome. Are your changes restricted to gcc/ada, or would you need reviewers frm other parts of GCC?
[Bug libstdc++/67537] New: [6 Regression] r225189 breaks building boost hana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67537 Bug ID: 67537 Summary: [6 Regression] r225189 breaks building boost hana Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org CC: ville.voutilainen at gmail dot com Target Milestone: --- Created attachment 36319 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36319&action=edit failing testcase for clang Starting with r225189 I get many errors like: (gcc-5 libstdc++ is fine) trippels@gcc2-power8 test % clang++ -gcc-toolchain ~/gcc_5/usr/local/ -DBOOST_HANA_CONFIG_ENABLE_STRING_UDL -DBOOST_HANA_TEST_PART=7 -O2 -I/home/trippels/hana/include -I/home/trippels/hana/test/include -I/home/trippels/hana/test -Wno-gnu-string-literal-operator-template -ftemplate-backtrace-limit=0 -pedantic -std=c++1y -W -Wall -Wextra -Wno-unused-local-typedefs -Wwrite-strings -o CMakeFiles/test.ext.std.tuple.part7.dir/ext/std/tuple.cpp.o -c /home/trippels/hana/test/ext/std/tuple.cpp trippels@gcc2-power8 test % clang++ -gcc-toolchain ~/gcc_6/usr/local/ -ferror-limit=1 -DBOOST_HANA_CONFIG_ENABLE_STRING_UDL -DBOOST_HANA_TEST_PART=7 -O2 -I/home/trippels/hana/include -I/home/trippels/hana/test/include -I/home/trippels/hana/test -Wno-gnu-string-literal-operator-template -ftemplate-backtrace-limit=0 -pedantic -std=c++1y -W -Wall -Wextra -Wno-unused-local-typedefs -Wwrite-strings -o CMakeFiles/test.ext.std.tuple.part7.dir/ext/std/tuple.cpp.o -c /home/trippels/hana/test/ext/std/tuple.cpp In file included from /home/trippels/hana/test/ext/std/tuple.cpp:7: In file included from /home/trippels/hana/include/boost/hana/ext/std/tuple.hpp:27: /home/trippels/gcc_6/usr/local/lib/gcc/powerpc64le-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0/tuple:481:62: error: pack expansion contains parameter packs '_Elements' and '_UElements' that have different lengths (1 vs. 0) return __and_...>::value; ~ ~~ ^ /home/trippels/gcc_6/usr/local/lib/gcc/powerpc64le-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0/tuple:580:21: note: in instantiation of function template specialization 'std::_TC >::_MoveConstructibleTuple<>' requested here _MoveConstructibleTuple<_UElements...>() ^ /home/trippels/gcc_6/usr/local/lib/gcc/powerpc64le-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0/tuple:585:19: note: while substituting prior template arguments into non-type template parameter [with _UElements = <>] constexpr tuple(_UElements&&... __elements) ^ /home/trippels/gcc_6/usr/local/lib/gcc/powerpc64le-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0/tuple:521:11: note: while substituting deduced template arguments into function template 'tuple' [with _UElements = <>, $1 = (no value)] class tuple : public _Tuple_impl<0, _Elements...> ^ /home/trippels/hana/include/boost/hana/basic_tuple.hpp:86:15: note: in instantiation of template class 'boost::hana::detail::elt<1, std::tuple >, false>' requested here : detail::elt... ^ /home/trippels/hana/include/boost/hana/basic_tuple.hpp:103:11: note: in instantiation of template class 'boost::hana::detail::basic_tuple_impl, std::tuple<>, std::tuple >, std::tuple, boost::hana::test::integer<1, 17, void> >, std::tuple, boost::hana::test::integer<1, 17, void>, boost::hana::test::integer<2, 17, void> >, std::tuple, boost::hana::test::integer<1, 17, void>, boost::hana::test::integer<2, 17, void>, boost::hana::test::integer<3, 17, void>, boost::hana::test::integer<4, 17, void> > >' requested here : detail::basic_tuple_impl, Xn...> ^ /home/trippels/hana/include/boost/hana/tuple.hpp:63:28: note: in instantiation of template class 'boost::hana::basic_tuple, std::tuple >, std::tuple, boost::hana::test::integer<1, 17, void> >, std::tuple, boost::hana::test::integer<1, 17, void>, boost::hana::test::integer<2, 17, void> >, std::tuple, boost::hana::test::integer<1, 17, void>, boost::hana::test::integer<2, 17, void>, boost::hana::test::integer<3, 17, void>, boost::hana::test::integer<4, 17, void> > >' requested here basic_tuple storage_; ^ /home/trippels/hana/include/boost/hana/tuple.hpp:270:49: note: in instantiation of template class 'boost::hana::tuple, std::tuple >, std::tuple, boost::hana::test::integer<1, 17, void> >, std::tuple, boost::hana::test::integer<1, 17, void>, boost::hana::test::integer<2, 17, void> >, std::tuple, boost::hana::test::integer<1, 17, void>, boost::hana::test::integer<2, 17, void>, boost::hana::test::integer<3, 17, void>, boost::hana::test::integer<4, 17, void> > >' requested here tuple::type...> app
[Bug ada/67205] violation of No_Implicit_Dynamic_Code restriction not reported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67205 --- Comment #6 from Eric Botcazou --- > Fedora has policies against executable stack, and fewer off them are always > welcome. Are your changes restricted to gcc/ada, or would you need > reviewers frm other parts of GCC? The latter, although the changes are localized (nested functions decomposition pass, RTL expander and bits in a few back-ends). Mostly straightforward, but only helps Ada and we already have a slew of such patches pending review, so we have started to prioritize. I'll give it a try though.
[Bug fortran/67538] New: ICE with invalid source allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67538 Bug ID: 67538 Summary: ICE with invalid source allocation Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Target Milestone: --- The following code is invalid since the array dimension is missing, but since it is an ICE I am reporting it. $ gfortran --version GNU Fortran (GCC) 6.0.0 20150910 (experimental) $ gfortran -c ice.f90 ice.f90:10:0: allocate( x , source=y ) 1 internal compiler error: in gfc_conv_expr_descriptor, bei fortran/trans-array.c:6656 0x68059b gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) trans-array.c:6656 0x6d003a gfc_trans_allocate(gfc_code*) trans-stmt.c:5175 0x66e2a7 trans_code trans.c:1798 0x6911b3 gfc_generate_function_code(gfc_namespace*) trans-decl.c:5900 0x671611 gfc_generate_module_code(gfc_namespace*) trans.c:2014 0x62ac1d translate_all_program_units parse.c:5513 0x62ac1d gfc_parse_file() parse.c:5731 0x66b662 gfc_be_parse_file f95-lang.c:209 module m implicit none contains subroutine s() real, allocatable :: x(:) real :: y y = 5.0 allocate( x , source=y ) end subroutine s end module m
[Bug ada/67416] raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:428
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67416 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #1 from Eric Botcazou --- This works with GCC 5 and above.
[Bug libstdc++/67537] [6 Regression] r225189 breaks building boost hana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67537 --- Comment #1 from Jonathan Wakely --- My first impression is that this is a clang bug. This: template using _TMC = _TC<(sizeof...(_Elements) == sizeof...(_UElements)), _Elements...>; should make it impossible to get: /home/trippels/gcc_6/usr/local/lib/gcc/powerpc64le-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0/tuple:481:62: error: pack expansion contains parameter packs '_Elements' and '_UElements' that have different lengths (1 vs. 0) return __and_...>::value; ~ ~~ ^ /home/trippels/gcc_6/usr/local/lib/gcc/powerpc64le-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0/tuple:580:21: note: in instantiation of function template specialization 'std::_TC >::_MoveConstructibleTuple<>' requested here _MoveConstructibleTuple<_UElements...>() ^ because it should not be possible for _Elements and _UElements to have different lengths inside _TC, it should have gone to _TC instead.
[Bug ada/67473] init.c undefined behaviour referencing misaligned pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67473 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ebotcazou at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #1 from Eric Botcazou --- This code is specific to x86-64.
[Bug fortran/67539] New: Segmentation fault with elemental defined assignment and scalar function at the RHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67539 Bug ID: 67539 Summary: Segmentation fault with elemental defined assignment and scalar function at the RHS Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Target Milestone: --- The attached code produces a segmentation fault: $ gfortran --version GNU Fortran (GCC) 6.0.0 20150910 (experimental) $ ./test Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7FD288EF6757 #1 0x7FD288EF6D5E #2 0x7FD28842EE8F #3 0x400B69 in __m_MOD_copy_t_a at test.f90:17 (discriminator 3) #4 0x400D15 in p at test.f90:40 (discriminator 2) Notice that both workarounds a) using a scalar temporary tmp and b) assigning to each element separately work. module m implicit none type :: t_a real, allocatable :: x end type t_a interface assignment(=) module procedure copy_t_a end interface contains elemental subroutine copy_t_a(y,x) type(t_a), intent(in) :: x type(t_a), intent(out) :: y allocate( y%x , source=x%x ) end subroutine copy_t_a elemental function new_t_a(x) result(res) real, intent(in) :: x type(t_a) :: res allocate( res%x ) res%x = x end function new_t_a end module m program p use m implicit none integer :: i type(t_a) :: tmp type(t_a), allocatable :: v(:) allocate( v(2) ) v = new_t_a(1.5) ! -> segmentation fault !tmp = new_t_a(1.5) ! -> OK !v = tmp !do i=1,size(v) ! -> also OK ! v(i) = new_t_a(1.5) !enddo do i=1,size(v) write(*,*) " i = ",i write(*,*) allocated(v(i)%x) write(*,*) v(i)%x enddo end program p
[Bug libfortran/67540] New: string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67540 Bug ID: 67540 Summary: string_intrinsics_inc.c sanitizer detects null pointer passed to memcpy Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: zeccav at gmail dot com Target Milestone: --- During make check-fortran in gcc build the sanitizer complains that a null pointer is passed to memcpy in string_intrinsics_inc.c:89 res = MEMCMP (s1, s2, ((len1 < len2) ? len1 : len2)); string_intrinsics_inc.c:90:7: runtime error: null pointer passed as argument 1, which is declared to never be null because s1 == NULL My fix is int lvz=len1 < len2 ? len1 : len2; if(lvz) res = MEMCMP (s1, s2, lvz); else res=0;
[Bug libstdc++/67537] [6 Regression] r225189 breaks building boost hana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67537
--- Comment #2 from Jonathan Wakely ---
Reduced:
template
struct pair { };
template
void sink(_Elements&&...);
template
struct _TC
{
template
static constexpr bool _MoveConstructibleTuple()
{
sink( pair<_Elements, _UElements>{} ... );
return true;
}
};
template
struct _TC
{
template
static constexpr bool _MoveConstructibleTuple()
{
return false;
}
};
template
struct enable_if { using type = bool; };
template<>
struct enable_if { };
template
struct tuple
{
template using _TMC =
_TC<(sizeof...(_Elements) == sizeof...(_UElements)), _Elements...>;
template::template
_MoveConstructibleTuple<_UElements...>()>::type=true>
constexpr tuple(_UElements&&...) { }
constexpr tuple() { }
};
struct X { };
constexpr tuple t{};
This compiles with GCC but Clang gives:
c.cc:13:41: error: pack expansion contains parameter packs '_Elements' and
'_UElements' that have different lengths (1 vs. 0)
sink( pair<_Elements, _UElements>{} ... );
~ ~~^
c.cc:41:52: note: in instantiation of function template specialization
'_TC::_MoveConstructibleTuple<>' requested here
enable_if<_TMC<_UElements...>::template
_MoveConstructibleTuple<_UElements...>()>::type=true>
^
c.cc:42:17: note: while substituting prior template arguments into non-type
template parameter [with _UElements = <>]
constexpr tuple(_UElements&&...) { }
^
c.cc:35:8: note: while substituting deduced template arguments into function
template 'tuple' [with _UElements = <>, $1 = (no value)]
struct tuple
^
1 error generated.
Here we get an error inside _TC even though the true specialization
should be unreachable.
[Bug libfortran/67535] write.c sanitizer detects null pointer passed to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67535 --- Comment #4 from Steve Kargl --- On Thu, Sep 10, 2015 at 09:00:06AM +, zeccav at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67535 > > --- Comment #3 from Vittorio Zecca --- > (In reply to kargl from comment #1) > > > What happens to performance? Simply making changes to > > make sanitizer happy seems rather questionable. It's clear > > from context that if base_name == NULL, then base_name_len > > == 0, and the memcpy should be a NOP. > > How costly is that NOP compared to if(base_name_len)? I don't know. Of course, I'm not the one purposing a change. > > How costly is to let go an undefined behaviour? > It's undefined behavior to pass a NULL pointer into a function?
[Bug libstdc++/67537] [6 Regression] r225189 breaks building boost hana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67537 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Markus Trippelsdorf --- OK, thank you. Closing.
[Bug libstdc++/67537] [6 Regression] r225189 breaks building boost hana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67537 --- Comment #4 from Ville Voutilainen --- I'll see if I can do a reasonable library fix, even if the problem is caused by a buggy front-end.
[Bug libfortran/67535] write.c sanitizer detects null pointer passed to memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67535 --- Comment #5 from Jakub Jelinek --- (In reply to Steve Kargl from comment #4) > It's undefined behavior to pass a NULL pointer into a function? To a function that does not allow it? Yes. Citing the C standard: 7.21.2.1/2: "The memcpy function copies n characters from the object pointed to by s2 into the object pointed to by s1." (NULL pointer does not point to any object). 7.1.4/1: "If a function argument is described as being an array, the pointer actually passed to the function shall have a value such that all address computations and accesses to objects (that would be valid if the pointer did point to the first element of such an array) are in fact valid." 7.21.1: "Where an argument declared as size_t n specifies the length of the array for a function, n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values, as described in 7.1.4."
[Bug libstdc++/67537] [6 Regression] r225189 breaks building boost hana
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67537 --- Comment #5 from Jonathan Wakely --- Reported as https://llvm.org/bugs/show_bug.cgi?id=24770
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #10 from Eric Botcazou --- Just to mention that we have really thought hard about this bug at AdaCore and the current patch seems (unfortunately) to be the only plausible way out, if we don't want to pessimize the common case. But suggestions are of course welcome. We have also discussed papering over it in the Ada front-end by initializing the Out parameter to zero. The problem is that you can write an equivalent Ada testcase with an explicitly uninitialized variable and trigger the bug (Pierre-Marie, could you attach it to the PR? Concatenate the files though and mention that it needs to be gnatchop'ed) so we cannot paper over it in all cases. But the fundamental thing to keep in mind here is that this is a valid Ada program and that it could be translated into a valid C program: there is indeed an uninitialized variable but the run-time behavior of the program doesn't depend on its value. The bug in REE effectively propagates the uninitializedness of this variable to another, perfectly initialized variable, because the latter initialization is done with a zero-extension that is eliminated.
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #11 from Pierre-Marie de Rodat --- Created attachment 36320 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36320&action=edit Reproducer with an uninitialized variable (no OUT parameter)
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #12 from Eric Botcazou --- Thanks. I misremembered, the testcase has a single variable with two fields, one uninitialized and one initialized, instead of two variables, but it's exactly the same reasoning (and it would be trivial to add the two variables anyway).
[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66790 --- Comment #13 from Pierre-Marie de Rodat --- (In reply to Eric Botcazou from comment #12) > Thanks. I misremembered, the testcase has a single variable with two > fields, one uninitialized and one initialized, instead of two variables, but > it's exactly the same reasoning (and it would be trivial to add the two > variables anyway). Thank you for your involvement into this! :-)
[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506 --- Comment #7 from Oleg Endo --- Author: olegendo Date: Thu Sep 10 14:53:48 2015 New Revision: 227646 URL: https://gcc.gnu.org/viewcvs?rev=227646&root=gcc&view=rev Log: gcc/ PR target/67506 * config/sh/sh.c (sh_extending_set_of_reg::use_as_extended_reg): Add missing simplify_gen_subreg. gcc/testsuite/ PR target/67506 * gcc.c-torture/compile/pr67506.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr67506.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/sh/sh.c trunk/gcc/testsuite/ChangeLog
[Bug c++/67522] OpenMP ICE in type_dependent_expression_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67522 Jakub Jelinek changed: What|Removed |Added Keywords||ice-on-invalid-code, openmp Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Target Milestone|--- |5.3 --- Comment #3 from Jakub Jelinek --- Fixed for 5.3+.
[Bug middle-end/67517] ICE in gimplify_scan_omp_clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67517 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed for 5.3+.
[Bug c++/67511] ICE with invalid OpenMP random access iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67511 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed for 5.3+.
[Bug c/67502] ICE with collapsed for simd loop inside of parallel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67502 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed for 5.3+.
[Bug middle-end/67521] ICE when OpenMP loop expressions mention the IV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67521 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed for 5.3+.
[Bug c++/67514] ICE in omp_add_variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67514 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed for 5.3+.
[Bug target/67506] [5/6 Regression][SH]: error: unrecognizable insn when compiling texlive-binaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67506 --- Comment #8 from Oleg Endo --- Author: olegendo Date: Thu Sep 10 15:07:02 2015 New Revision: 227647 URL: https://gcc.gnu.org/viewcvs?rev=227647&root=gcc&view=rev Log: gcc/ Backport from mainline 2015-09-10 Oleg Endo PR target/67506 * config/sh/sh.c (sh_extending_set_of_reg::use_as_extended_reg): Add missing simplify_gen_subreg. gcc/testsuite/ Backport from mainline PR target/67506 * gcc.c-torture/compile/pr67506.c: New test. Added: branches/gcc-5-branch/gcc/testsuite/gcc.c-torture/compile/pr67506.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/sh/sh.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug c++/67504] ICE with type dependent collapse argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67504 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed for 5.3+.
[Bug c/67501] Bad error recovery for invalid OpenMP clauses in C FE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67501 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed for 5.3+.
[Bug c/67500] OpenMP ICE with invalid safelen/simdlen/alignment expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67500 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed for 5.3+.
[Bug c/67495] #pragma omp atomic ICEs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67495 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed for 5.3+.
[Bug fortran/66993] Spurious ambiguous symbol error with submodules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66993 --- Comment #2 from Paul Thomas --- Author: pault Date: Thu Sep 10 15:22:20 2015 New Revision: 227648 URL: https://gcc.gnu.org/viewcvs?rev=227648&root=gcc&view=rev Log: 2015-09-10 Paul Thomas PR fortran/66993 * module.c (read_module): If a symtree exists and the symbol has been associated in a submodule from a parent (sub)module, attach the symbol to a 'unique symtree' and the new symbol to the existing symtree. 2015-09-10 Paul Thomas PR fortran/66993 * gfortran.dg/submodule_11.f08: New test. Added: trunk/gcc/testsuite/gfortran.dg/submodule_11.f08 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c trunk/gcc/testsuite/ChangeLog
[Bug c++/67318] [6 regression] Parsing error when using abbreviated integral type names in template parameter pack declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67318 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Sep 10 15:36:54 2015 New Revision: 227650 URL: https://gcc.gnu.org/viewcvs?rev=227650&root=gcc&view=rev Log: /cp 2015-09-10 Paolo Carlini PR c++/67318 * parser.c (cp_parser_parameter_declaration): Consume the ellipsis and set template_parameter_pack_p also when the type is null. /testsuite 2015-09-10 Paolo Carlini PR c++/67318 * g++.dg/cpp0x/variadic166.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic166.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/67318] [6 regression] Parsing error when using abbreviated integral type names in template parameter pack declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67318 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #5 from Paolo Carlini --- Fixed.
[Bug tree-optimization/67055] [5 Regression] Segmentation fault in fold_builtin_alloca_with_align in tree-ssa-ccp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67055 --- Comment #14 from Markus Trippelsdorf --- Still happens on gcc-5 branch. (This breaks building the Linux kernel with -O3 with my config) -fno-ipa-icf "fixes" the issue.
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 --- Comment #12 from John David Anglin --- Created attachment 36321 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36321&action=edit Patch I sent this change this morning to gcc-patches but it seems to have disappeared.
[Bug middle-end/66332] goacc/acc_on_device-2.c scan-rtl-dump-times expand testsuite failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66332 Steve Ellcey changed: What|Removed |Added CC||sje at gcc dot gnu.org --- Comment #7 from Steve Ellcey --- I think the patch checked in on August 10 broke my MIPS build. The install dies with: /usr/bin/install: cannot create regular file `/scratch/sellcey/repos/nightly/install-mips-mti-linux-gnu/lib/gcc/mips-mti-linux-gnu/6.0.0/finclude/omp_lib_kinds.mod': File exists Note that I am building a multilib cross compiler with parallel make. See https://gcc.gnu.org/ml/gcc/2015-09/msg00161.html
[Bug fortran/67541] New: -Wconversion-extra no warning on double = double + single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67541
Bug ID: 67541
Summary: -Wconversion-extra no warning on double = double +
single
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jamiebayne at hotmail dot com
Target Milestone: ---
It is my belief (or at least desire) that every assignment in the following
program should emit a warning with the -Wconversion{,-extra} flags (GCC
5.2.1):
PROGRAM conversion_test
INTEGER, PARAMETER :: sp = KIND(1.0)
INTEGER, PARAMETER :: dp = KIND(1.d0)
REAL(sp) :: single
REAL(dp) :: double
double = 4.0_sp! -Wconversion-extra: Warning: Conversion from
! REAL(4) to REAL(8) at (1)
double = single! -Wconversion-extra: Warning: Conversion from
! REAL(4) to REAL(8) at (1)
single = double! -Wconversion: Warning: Possible change of
! value in conversion from REAL(8) to
! REAL(4) at (1)
! -Wconversion-extra: Warning: Conversion from
! REAL(8) to REAL(4)
single = double + single ! -Wconversion: Warning: Possible change
! of value in conversion from REAL(8)
! to REAL(4) at (1)
! -Wconversion-extra: Conversion from
! REAL(8) to REAL(4) at (1)
! no warnings
single = 7.0_dp
double = double + single
END PROGRAM conversion_test
Is this intended behaviour, or am I right in thinking that particularly the
double = double + single line should give a warning?
(For my purposes, I'm specifically interested in any expression which results
in a cvtss2sd on x86-64.)
[Bug fortran/67541] -Wconversion-extra no warning on double = double + single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67541 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-09-10 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- With 5.2 I get pr67541.f90:6:17: double = 4.0_sp! -Wconversion-extra: Warning: Conversion from 1 Warning: Conversion from 'REAL(4)' to 'REAL(8)' at (1) [-Wconversion-extra] pr67541.f90:8:17: double = single! -Wconversion-extra: Warning: Conversion from 1 Warning: Conversion from REAL(4) to REAL(8) at (1) [-Wconversion-extra] pr67541.f90:10:17: single = double! -Wconversion: Warning: Possible change of 1 Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1) [-Wconversion] pr67541.f90:15:17: single = double + single ! -Wconversion: Warning: Possible change 1 Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1) [-Wconversion] With trunk (6.0) I get pr67541.f90:15:32: single = double + single ! -Wconversion: Warning: Possible change 1 Warning: Conversion from REAL(4) to REAL(8) at (1) [-Wconversion-extra] pr67541.f90:23:32: double = double + single 1 Warning: Conversion from REAL(4) to REAL(8) at (1) [-Wconversion-extra] pr67541.f90:6:17: double = 4.0_sp! -Wconversion-extra: Warning: Conversion from 1 Warning: Conversion from 'REAL(4)' to 'REAL(8)' at (1) [-Wconversion-extra] pr67541.f90:8:17: double = single! -Wconversion-extra: Warning: Conversion from 1 Warning: Conversion from REAL(4) to REAL(8) at (1) [-Wconversion-extra] pr67541.f90:10:17: single = double! -Wconversion: Warning: Possible change of 1 Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1) [-Wconversion] pr67541.f90:15:17: single = double + single ! -Wconversion: Warning: Possible change 1 Warning: Possible change of value in conversion from REAL(8) to REAL(4) at (1) [-Wconversion] pr67541.f90:22:17: single = 7.0_dp 1 Warning: Conversion from 'REAL(8)' to 'REAL(4)' at (1) [-Wconversion-extra] IMO warnings for double = single double = 4.0_sp and double = double + single does not make sense.
[Bug fortran/67542] New: ICE on initializing type variable with a longer array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67542 Bug ID: 67542 Summary: ICE on initializing type variable with a longer array Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This test case with a longer array in initializer of y : $ cat z1.f90 program p type t integer :: n character(8) :: c(1) end type type(t) :: x = t(1, ['a']) type(t) :: y = t(1, ['a', 'b']) end Yields with gfortran 5.2.1 and 4.9.0 : internal compiler error: in native_encode_initializer, at dwarf2out.c:16210 Compiles with no error using gfortran 4.8.3
[Bug fortran/67542] ICE on initializing type variable with a longer array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67542 --- Comment #1 from Gerhard Steinmetz --- The ICE disappears if some prints are added : $ cat z2.f90 program p type t integer :: n character(8) :: c(1) end type type(t) :: x = t(1, ['a']) type(t) :: y = t(1, ['a', 'b']) print *, x print *, y end $ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z2.f90 $ a.out 1 a 1 a
[Bug fortran/67541] -Wconversion-extra no warning on double = double + single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67541 --- Comment #2 from Jamie Bayne --- Ah, so it's fixed in trunk. Thanks for the info. RE the warnings making sense: floating-point promotions may not lose data, but they do have an associated runtime cost (about equivalent to an add on recent Intel architectures), which can be important for code optimisation.
[Bug fortran/67543] New: ICE on associate with improper association
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67543 Bug ID: 67543 Summary: ICE on associate with improper association Product: gcc Version: 5.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gerhard.steinmetz.fort...@t-online.de Target Milestone: --- This construct with an improper association with null ... subroutine s associate (x => null()) end associate end subroutine or this variation ... subroutine s associate (x => [null()]) end associate end subroutine yields : f951: internal compiler error: in resolve_assoc_var, at fortran/resolve.c:7987
[Bug fortran/67541] -Wconversion-extra no warning on double = double + single
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67541 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dominique d'Humieres --- So FIXED (such enhancements are not back ported).
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 --- Comment #13 from İsmail Dönmez --- (In reply to John David Anglin from comment #12) > Created attachment 36321 [details] > Patch > > I sent this change this morning to gcc-patches but it seems to have > disappeared. The patch declares the functions but those functions do not exist on mingw-w64, seems to be this will just fail with an undefined symbol error.
[Bug fortran/67526] ICE on missing end parenthesis in substring construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67526 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Sep 10 17:13:11 2015 New Revision: 227651 URL: https://gcc.gnu.org/viewcvs?rev=227651&root=gcc&view=rev Log: 2015-09-09 Steven G. Kargl PR fortran/67526 * gfortran.dg/pr67526.f90: New test. 2015-09-09 Steven G. Kargl PR fortran/67526 * expr.c (gfc_check_init_expr): Do not dereference a NULL pointer. Added: trunk/gcc/testsuite/gfortran.dg/pr67526.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67513
--- Comment #5 from Kostya Serebryany ---
(In reply to Yury Gribov from comment #1)
> (In reply to Andrey Ryabinin from comment #0)
> > (shadow value is usually zero).
>
> What makes you think so? AFAIU for less-than-8-byte scalars it's always
> non-zero. I vaguely remember than Kostya did something like this in Clang
> case and it resulted in negligeable improvement.
The code in llvm uses branch weights to indicate that the slow path
is rarely taken.
if (ClAlwaysSlowPath || (TypeSize < 8 * Granularity)) {
// We use branch weights for the slow path check, to indicate that the slow
// path is rarely taken. This seems to be the case for SPEC benchmarks.
TerminatorInst *CheckTerm = SplitBlockAndInsertIfThen(
Cmp, InsertBefore, false, MDBuilder(*C).createBranchWeights(1,
10));
The measurements were done on SPEC 2016 lng ago,
I have no idea whether this is still a good heuristic.
I remember that the difference was not huge, but enough to justify
one extra parameter.
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 --- Comment #14 from dave.anglin at bell dot net --- On 2015-09-10 1:01 PM, ismail at i10z dot com wrote: > The patch declares the functions but those functions do not exist on > mingw-w64, > seems to be this will just fail with an undefined symbol error. The routines are in liberty and the patch assumes that that they are built. If that's not the case on mingw-w64, then they will have to be provided by some other means. Dave
[Bug bootstrap/67363] [6 Regression] r227188 breaks build for mingw-w64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67363 --- Comment #15 from İsmail Dönmez --- (In reply to dave.anglin from comment #14) > On 2015-09-10 1:01 PM, ismail at i10z dot com wrote: > > The patch declares the functions but those functions do not exist on > > mingw-w64, > > seems to be this will just fail with an undefined symbol error. > The routines are in liberty and the patch assumes that that they are > built. If that's not the > case on mingw-w64, then they will have to be provided by some other means. Ah that makes sense, thanks!
[Bug fortran/67526] ICE on missing end parenthesis in substring construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67526 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Thu Sep 10 18:07:07 2015 New Revision: 227655 URL: https://gcc.gnu.org/viewcvs?rev=227655&root=gcc&view=rev Log: 2015-09-09 Steven G. Kargl PR fortran/67526 * gfortran.dg/pr67526.f90: New test. 2015-09-09 Steven G. Kargl PR fortran/67526 * expr.c (gfc_check_init_expr): Do not dereference a NULL pointer. Added: branches/gcc-5-branch/gcc/testsuite/gfortran.dg/pr67526.f90 Modified: branches/gcc-5-branch/gcc/fortran/ChangeLog branches/gcc-5-branch/gcc/fortran/expr.c branches/gcc-5-branch/gcc/testsuite/ChangeLog
