[Bug bootstrap/81253] Flags -march and -mtune are ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81253 Philipp changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Philipp --- Yes, you are right. It is not a GNU Fortran bug; issue is resolved. Thank you very much.
[Bug tree-optimization/81248] No ipa-sra optimization for small struct / class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81248 --- Comment #7 from wilhelm.me...@hs-kl.de --- Looks like also no optimization is done for non-template function g(const uint8_t&).
[Bug c++/55203] No unused warning for variables of non-trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #16 from Jonathan Wakely --- I missed this update, sorry. (In reply to Martin Sebor from comment #15) > Jonathan, what's the next step? It sounds as though you don't think > decorating nearly every libstdc++ class makes sense. I'd really rather not do that, but we could start with std::basic_string. > Should -Wunused be > tweaked to diagnose unused variables of all types and let users deal with > the fallout for RAII classes by decorating then with attribute unused? I don't think that would be popular.
[Bug tree-optimization/81249] [8 Regression] ICE: error: incompatible types in PHI argument 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81249 --- Comment #6 from Richard Biener --- Author: rguenth Date: Fri Jun 30 08:08:33 2017 New Revision: 249831 URL: https://gcc.gnu.org/viewcvs?rev=249831&root=gcc&view=rev Log: 2017-06-30 Richard Biener PR tree-optimization/81249 * tree-vect-loop.c (vect_create_epilog_for_reduction): Convert condition reduction result to original scalar type. * g++.dg/torture/pr81249.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr81249.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug tree-optimization/81249] [8 Regression] ICE: error: incompatible types in PHI argument 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81249 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug ipa/81261] New: [8 Regression] ICE with -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81261 Bug ID: 81261 Summary: [8 Regression] ICE with -fno-guess-branch-probability Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- Probably staring from Honza's commit, I see: $ ./xg++ -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr61160-1.C -O1 -fno-guess-branch-probability /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr61160-1.C: In member function ‘virtual void* CExample::_ZThn8_N8CExample9MixinFuncEiPv(int, void*)’: /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ipa/pr61160-1.C:14:9: internal compiler error: in to_reg_br_prob_base, at profile-count.h:189 void *MixinFunc (int arg, void *arg2) ^ 0xe1d414 profile_probability::to_reg_br_prob_base() const ../../gcc/profile-count.h:189 0xf9349d estimate_bb_frequencies(bool) ../../gcc/predict.c:3558 0xf94152 rebuild_frequencies() ../../gcc/predict.c:3854 0xf77694 execute_function_todo ../../gcc/passes.c:1970 0xf76750 do_per_function ../../gcc/passes.c:1655 0xf7795e execute_todo ../../gcc/passes.c:2043 0xf77edd execute_one_ipa_transform_pass ../../gcc/passes.c:2240 0xf78018 execute_all_ipa_transforms() ../../gcc/passes.c:2276 0xba0b1f cgraph_node::expand() ../../gcc/cgraphunit.c:2042 0xba22ca expand_all_functions ../../gcc/cgraphunit.c:2185 0xba22ca symbol_table::compile() ../../gcc/cgraphunit.c:2542 0xba4a16 symbol_table::compile() ../../gcc/cgraphunit.c:2635 0xba4a16 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2632
[Bug ipa/81261] [8 Regression] ICE with -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81261 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-30 CC||hubicka at ucw dot cz Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Commit r249800.
[Bug c++/55203] No unused warning for variables of non-trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #17 from Marc Glisse --- I wonder if attributes unused / warn_unused should be automatically inherited by classes when a member or base has it (with various rules, maybe unused has priority over warn_unused). For a tuple of locks or a tuple of strings, that seems to do the right thing. For a class that contains a private internal lock, the user might need to specify warn_unused so the compiler does not guess "unused" instead. Even if that's currently useless, I still believe that decorating the relevant classes (locks, etc) with attribute unused would be good (it could be used by external tools as well).
[Bug sanitizer/81262] New: [8 Regression] verify_flow_info failed for asmgoto test-case with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81262 Bug ID: 81262 Summary: [8 Regression] verify_flow_info failed for asmgoto test-case with -fsanitize=undefined Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, hubicka at ucw dot cz, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Starting from r249070, following test-case fails: $ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/asmgoto1.C -fsanitize=unreachable -O2 -c /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/asmgoto1.C: In function ‘int bar(int)’: /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/asmgoto1.C:32:1: error: fallthru edge crosses section boundary in bb 6 } ^ during RTL pass: bbpart /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/asmgoto1.C:32:1: internal compiler error: verify_flow_info failed 0xc15932 verify_flow_info() ../../gcc/cfghooks.c:259 0x1089f20 execute_function_todo ../../gcc/passes.c:2001 0x1088e92 do_per_function ../../gcc/passes.c:1655 0x108a0a0 execute_todo ../../gcc/passes.c:2043
[Bug c++/81257] [8 Regression] ICE on invalid C++ template code: in make_typename_type, at cp/decl.c:3709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81257 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-30 CC||marxin at gcc dot gnu.org Summary|ICE on invalid C++ template |[8 Regression] ICE on |code: in|invalid C++ template code: |make_typename_type, at |in make_typename_type, at |cp/decl.c:3709 |cp/decl.c:3709 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r249752.
[Bug c++/81258] [7/8 Regression] ICE on C++1z code with invalid decomposition declaration: in cp_finish_decl, at cp/decl.c:6760
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81258 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-30 CC||marxin at gcc dot gnu.org Summary|ICE on C++1z code with |[7/8 Regression] ICE on |invalid decomposition |C++1z code with invalid |declaration: in |decomposition declaration: |cp_finish_decl, at |in cp_finish_decl, at |cp/decl.c:6760 |cp/decl.c:6760 Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r244282.
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 --- Comment #5 from Martin Liška --- Author: marxin Date: Fri Jun 30 08:51:00 2017 New Revision: 249833 URL: https://gcc.gnu.org/viewcvs?rev=249833&root=gcc&view=rev Log: Call BUILT_IN_ASAN_HANDLE_NO_RETURN before BUILT_IN_UNWIND_RESUME (PR sanitizer/81021). 2017-06-30 Martin Liska PR sanitizer/81021 * g++.dg/asan/pr81021.C: New test. 2017-06-30 Martin Liska PR sanitizer/81021 * tree-eh.c (lower_resx): Call BUILT_IN_ASAN_HANDLE_NO_RETURN before BUILT_IN_UNWIND_RESUME when ASAN is used. Added: trunk/gcc/testsuite/g++.dg/asan/pr81021.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-eh.c
[Bug sanitizer/81021] stack-use-after-scope false positive error with exceptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 Martin Liška changed: What|Removed |Added Known to work||8.0 Known to fail||7.1.0 --- Comment #6 from Martin Liška --- Fixed on trunk so far.
[Bug ipa/81261] [8 Regression] ICE with -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81261 Richard Biener changed: What|Removed |Added Version|7.0 |8.0 Target Milestone|--- |8.0
[Bug sanitizer/81262] [8 Regression] verify_flow_info failed for asmgoto test-case with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81262 Richard Biener changed: What|Removed |Added Version|7.0 |8.0 Target Milestone|--- |8.0
[Bug rtl-optimization/81020] [6/7/8 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-coalesce-vars -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81020 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-30 CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r228320. Richi, can you please take a look?
[Bug c++/55203] No unused warning for variables of non-trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 Jon Grant changed: What|Removed |Added CC||jg at jguk dot org --- Comment #18 from Jon Grant --- Hello Perhaps a derived class would do some behaviour, so better not allow inheritance. Certainly just tagging each STL class we know doesn't construct anything would allow identification of them. I wonder how cppcheck does it? Happy to pay a bounty 100 USD to get in a new release.
[Bug c++/81258] [7/8 Regression] ICE on C++1z code with invalid decomposition declaration: in cp_finish_decl, at cp/decl.c:6760
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81258 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 41653 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41653&action=edit gcc8-pr81258.patch Untested fix.
[Bug rtl-optimization/81020] [6/7/8 Regression] wrong code with -O -fno-tree-bit-ccp -fno-tree-coalesce-vars -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81020 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- Mine.
[Bug c++/54769] [Core/1111] dependent class method template not found if structure template with the same name is visible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54769 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- If it is backported, PR81257 will need to be resolved there as well.
[Bug ipa/80597] [8 Regression] internal compiler error: in compute_inline_parameters, at ipa-inline-analysis.c:3126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80597 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Martin Liška --- Fixed on trunk.
[Bug sanitizer/81262] [8 Regression] verify_flow_info failed for asmgoto test-case with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81262 --- Comment #1 from Jakub Jelinek --- Bet asm goto isn't handled correctly in fix_up_fall_thru_edges or in add_labels_and_missing_jumps. Looking at the former, I'm puzzled how it works at all, seems e.g. the cond_jump variable can hold edge for completely unrelated bb (isn't cleared like e.g. fall_thru is). I believe all the function-local vars should be moved into the FOR_EACH_BB_FN block except for cur_bb.
[Bug sanitizer/81262] [8 Regression] verify_flow_info failed for asmgoto test-case with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81262 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-06-30 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/55203] No unused warning for variables of non-trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #19 from Jonathan Wakely --- cppcheck isn't a compiler, it just does simple pattern matching and maybe uses whitelists/blacklists of types. I don't think anything it does is really relevant to GCC.
[Bug c++/81229] [8 Regression] ICE in c_tree_chain_next on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81229 --- Comment #6 from Nathan Sidwell --- Author: nathan Date: Fri Jun 30 11:40:08 2017 New Revision: 249835 URL: https://gcc.gnu.org/viewcvs?rev=249835&root=gcc&view=rev Log: PR c++/81229 * name-lookup.c (do_pushdecl): Reset IDENTIFIER_TYPE when finding a matching TYPE_DECL. * g++.dg/lookup/pr81229.C: New. Added: trunk/gcc/testsuite/g++.dg/lookup/pr81229.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/81262] [8 Regression] verify_flow_info failed for asmgoto test-case with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81262 --- Comment #2 from Jakub Jelinek --- Created attachment 41654 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41654&action=edit gcc8-pr81262.patch Untested fix.
[Bug c++/81229] [8 Regression] ICE in c_tree_chain_next on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81229 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Nathan Sidwell --- Fixed r249835.
[Bug target/80510] Optimize Power7/power8 Altivec load/stores
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80510 --- Comment #10 from Michael Meissner --- Author: meissner Date: Fri Jun 30 12:09:12 2017 New Revision: 249836 URL: https://gcc.gnu.org/viewcvs?rev=249836&root=gcc&view=rev Log: [gcc] 2017-06-30 Michael Meissner Backport from mainline 2017-06-23 Michael Meissner PR target/80510 * config/rs6000/rs6000.md (ALTIVEC_DFORM): Do not allow DImode in 32-bit, since indexed is not valid for DImode. (mov_hardfloat32): Reorder ISA 2.07 load/stores before ISA 3.0 d-form load/stores to be the same as mov_hardfloat64. (define_peephole2 for Altivec d-form load): Add 32-bit support. (define_peephole2 for Altivec d-form store): Likewise. [gcc/testsuite] 2017-06-30 Michael Meissner Backport from mainline 2017-06-23 Michael Meissner PR target/80510 * gcc.target/powerpc/pr80510-1.c: Allow test to run on 32-bit. * gcc.target/powerpc/pr80510-2.c: Likewise. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/rs6000/rs6000.md branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80510-1.c branches/gcc-6-branch/gcc/testsuite/gcc.target/powerpc/pr80510-2.c
[Bug c/81264] New: fixincludes/fixincl.c fails on DEBUG build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81264 Bug ID: 81264 Summary: fixincludes/fixincl.c fails on DEBUG build Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mario at emmenlauer dot de Target Milestone: --- fixincludes/fixincl.c reads in line 1123: fprintf (stderr, z_failed, _ttyp, p_fixd->fix_name, \ pz_fname, p_fixd->test_ct - test_ct); The variable z_failed is undefined. This is not a critical issue as it only appears if DEBUG is defined. But AFAIK its still a bug, so I wanted to report it.
[Bug ipa/81214] GCC target_clone support does not work for global functions with no references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81214 --- Comment #3 from Martin Liška --- Author: marxin Date: Fri Jun 30 13:51:19 2017 New Revision: 249840 URL: https://gcc.gnu.org/viewcvs?rev=249840&root=gcc&view=rev Log: Fix removal of ifunc (PR ipa/81214). 2017-06-30 Martin Liska PR ipa/81214 * gcc.target/i386/pr81214.c: New test. 2017-06-30 Martin Liska PR ipa/81214 * multiple_target.c (create_dispatcher_calls): Make ifunc also for function that don't have calls or are not referenced. Added: trunk/gcc/testsuite/gcc.target/i386/pr81214.c Modified: trunk/gcc/ChangeLog trunk/gcc/multiple_target.c trunk/gcc/testsuite/ChangeLog
[Bug ipa/81214] GCC target_clone support does not work for global functions with no references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81214 Martin Liška changed: What|Removed |Added Known to work||8.0 Known to fail||5.4.0, 6.3.0, 7.1.0 --- Comment #4 from Martin Liška --- Fixed on trunk so far, I'll try to do a back-port.
[Bug fortran/81265] New: allocatable coarrays in submodule subroutines wrongly identified as unallocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81265 Bug ID: 81265 Summary: allocatable coarrays in submodule subroutines wrongly identified as unallocated Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mexas at bristol dot ac.uk Target Milestone: --- Created attachment 41655 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41655&action=edit m.f90 sm.f90 m2.f90 p.f90 - 4 Fortran 2008 files Sorry I cannot yet reduce this further. m.f90 - module 1 sm.f90 - submodule of module 1 m2.f90 - module 2 p.f90 - program that uses both modules: m and m2. submodule sm has subroutine s, which is passed as one actual argument subroutine s2 from module m2. An allocatable coarray is allocated in the program p. Then subroutine s is called with s2 passed in. In s the allocatable coarray is seen as allocated, but when it is passed further to s2 from 2, in s2 it is seen as not allocated. To build/run: rat> caf -c m.f90 m2.f90 sm.f90 p.f90 rat> caf p.o m.o m2.o sm.o rat> cafrun -np 4 ./a.out ERROR: s2: coarray is not allocated ERROR: s2: coarray is not allocated ERROR: s2: coarray is not allocated ERROR: s2: coarray is not allocated ERROR STOP ERROR STOP ERROR STOP rat> rat> caf --version OpenCoarrays Coarray Fortran Compiler Wrapper (caf version 1.9.0) Copyright (C) 2015-2016 Sourcery, Inc. OpenCoarrays comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of OpenCoarrays under the terms of the BSD 3-Clause License. For more information about these matters, see the file named LICENSE. rat> caf -w caf wraps CAFC=/usr/local/bin/mpif90 rat> mpif90 --version GNU Fortran (FreeBSD Ports Collection) 7.0.1 20170326 (experimental) Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Shall I send this to OpenCoarrays instead? ifort 16 runs this program with no error.
[Bug fortran/81265] allocatable coarrays in submodule subroutines wrongly identified as unallocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81265 --- Comment #1 from Anton Shterenlikht --- On Cray seems to run fine too. Sorry for crooked rushed English. The code itself is very simple, so should be clear what's going on. But I think if I put all code in a single file, then I cannot reproduce the error anymore. Thanks!
[Bug c++/81250] C++ warnings about unused stl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81250 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Martin Sebor --- Resolving as a dupe of 55203 per comment #6. *** This bug has been marked as a duplicate of bug 55203 ***
[Bug c++/55203] No unused warning for variables of non-trivial types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55203 --- Comment #20 from Martin Sebor --- *** Bug 81250 has been marked as a duplicate of this bug. ***
[Bug target/81225] [6/7/8 Regression] ICE with -mavx512ifma -O3 -ffloat-store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81225 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Jun 30 14:52:24 2017 New Revision: 249844 URL: https://gcc.gnu.org/viewcvs?rev=249844&root=gcc&view=rev Log: PR target/81225 * config/i386/sse.md (vec_extract_lo_): For V8FI, V16FI and VI8F_256 iterators, use instead of nonimmediate_operand and instead of m for the input operand. For V8FI iterator, always split if input is a MEM. For V16FI and V8SF_256 iterators, don't test if both operands are MEM if . For VI4F_256 iterator, use instead of register_operand and instead of v for the input operand. Make sure both operands aren't MEMs for if not . * gcc.target/i386/pr81225.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr81225.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug middle-end/81172] Expected new warning option -Warray-bounds-pointer-arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81172 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-30 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from Martin Sebor --- Confirmed. There are a few bug reports for missing -Warray-bounds warning that might be worth reviewing as well (e.g., pr67872). I'm not sure distinguishing between forming an out-of-bounds pointer by (a + 5) vs dereferencing a past-the-end element by a[5] is necessary or even a good idea. My concern with having distinct options for such closely related problems is that it might be tricky to get their interaction right in cases like (a + N) and &a[N]: should that trigger -Warray-bounds or -Warray-bounds-pointer-arithmetic, what about when N is not a constant expression? Clang diagnoses the the cases where the offset or index is a constant expression (and under the expected option) but it doesn't diagnose others where the offset/index value is not a constant expression but can be determined to be out of bounds by VRP, for instance. GCC can do better, but it may not be able to distinguish between the two kinds of warnings outside the front end.
[Bug target/81266] New: FAIL: 30_threads/thread/native_handle/typesizes.cc execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81266 Bug ID: 81266 Summary: FAIL: 30_threads/thread/native_handle/typesizes.cc execution test on darwin Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: iains at gcc dot gnu.org, redi at gcc dot gnu.org, ro at gcc dot gnu.org Target Milestone: --- Host: x86_64-apple-darwin16 Target: x86_64-apple-darwin16 Build: x86_64-apple-darwin16 After revision r249217 the test 30_threads/thread/native_handle/typesizes.cc fails at run time on darwin with (it was UNSUPPORTED before this revision) terminate called after throwing an instance of 'std::runtime_error' what(): size of _Tp: 4 alignment of _Tp: 4 size of *(_Tp::native_handle_type): 4096 alignment of *(_Tp::native_handle_type): 4096
[Bug debug/81267] New: Missing DW_AT_type in DW_TAG_typedef of "typedef of typedef of void"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81267 Bug ID: 81267 Summary: Missing DW_AT_type in DW_TAG_typedef of "typedef of typedef of void" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: palves at redhat dot com Target Milestone: --- I'm writing a GDB testcase that exercises the "whatis" command. If passed a type name, that command strips one, and only one, level of typedef from the type. The test exposed missing target type info in the case of "typedef of typedef of void". I.e., with: ~~~ typedef void void_typedef1; typedef void_typedef1 void_typedef2; void_typedef1 *void_typedef1_ptr; // just to be sure the types are emitted. void_typedef2 *void_typedef2_ptr; // ditto. ~~~ We get: <1><21>: Abbrev Number: 2 (DW_TAG_typedef) <22> DW_AT_name: (indirect string, offset: 0x1bf): void_typedef1 <26> DW_AT_decl_file : 1 <27> DW_AT_decl_line : 1 <1><28>: Abbrev Number: 2 (DW_TAG_typedef) <29> DW_AT_name: (indirect string, offset: 0x1cd): void_typedef2 <2d> DW_AT_decl_file : 1 <2e> DW_AT_decl_line : 2 Notice that "void_typedef2" has no DW_AT_type pointing to "void_typedef1". Seeing this, GDB assumes that "void_typedef2" is a direct typedef to "void": (gdb) whatis void_typedef1 type = void (gdb) whatis void_typedef2 type = void The correct output in the second case above would have been: (gdb) whatis void_typedef2 type = void_typedef1 ... which is what I get if I compile the testcase with clang instead of gcc. clang (3.7) outputs: <1><44>: Abbrev Number: 4 (DW_TAG_typedef) <45> DW_AT_name: (indirect string, offset: 0x5e): void_typedef1 <49> DW_AT_decl_file : 1 <4a> DW_AT_decl_line : 1 ... <1><65>: Abbrev Number: 5 (DW_TAG_typedef) <66> DW_AT_type: <0x44> <6a> DW_AT_name: (indirect string, offset: 0x7e): void_typedef2 <6e> DW_AT_decl_file : 1 <6f> DW_AT_decl_line : 2 I.e., it only "optimizes out" DW_AT_type when the typedef is a direct typedef to void.
[Bug c++/80014] [6/7/8 Regression] Caret missing in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80014 --- Comment #6 from David Malcolm --- Author: dmalcolm Date: Fri Jun 30 15:20:55 2017 New Revision: 249845 URL: https://gcc.gnu.org/viewcvs?rev=249845&root=gcc&view=rev Log: Fix location of typeid() (PR c++/80014) gcc/cp/ChangeLog: PR c++/80014 * parser.c (cp_parser_postfix_expression): Construct a location for typeid expressions. gcc/testsuite/ChangeLog: PR c++/80014 * g++.dg/plugin/diagnostic-test-expressions-1.C (std::type_info): Add declaration. (test_typeid): New test function. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/plugin/diagnostic-test-expressions-1.C
[Bug c++/80014] [6/7/8 Regression] Caret missing in error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80014 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from David Malcolm --- Fixed on trunk by r249845, for gcc 8 onwards.
[Bug c++/81260] Error "taking address of temporary" is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81260 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-30 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||5.3.0, 6.3.0, 7.1.0, 8.0 --- Comment #1 from Martin Sebor --- Confirmed with the smaller test case below and all of 5.x, 6.x, 7.x, and 8.0. The expected warning is issued when the class is empty (in g()) but not otherwise. Interestingly, Clang only diagnoses the first call to f() in both functions, maybe because it "forgets" about the temporary as it passes through the implicitly generate copy assignment operator in the second call. $ cat t.C && gcc -S -Wall -Wextra -Wpedantic t.C void f (void*); struct A { A (int); }; struct B { B (int); int i; }; void g () { f (&(A (1))); f (&(A (1) = 1)); } void h () { f (&(B (1))); f (&(B (1) = 1)); } t.C: In function ‘void g()’: t.C:13:13: error: taking address of temporary [-fpermissive] f (&(A (1))); ^ t.C:14:17: error: taking address of temporary [-fpermissive] f (&(A (1) = 1)); ^ t.C: In function ‘void h()’: t.C:19:13: error: taking address of temporary [-fpermissive] f (&(B (1))); ^
[Bug target/81266] FAIL: 30_threads/thread/native_handle/typesizes.cc execution test on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81266 --- Comment #1 from Jonathan Wakely --- This was previously only run for GNU/Linux, Solaris and AIX, but is now enabled for all pthreads targets. I don't think this particular test will ever pass for targets where is_pointer is true.
[Bug fortran/81265] allocatable coarrays in submodule subroutines wrongly identified as unallocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81265 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-06-30 CC||pault at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed with 7.1.0 and trunk (8.0) and -fcoarray=single is enough to reproduce the problem. Note that replacing 'source=0' with e.g., 'source=42' makes the test passes, but accessing coarray gives a segfault.
[Bug c++/81259] New: Class template deduction cannot work on Constructor without parameters in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81259 Bug ID: 81259 Summary: Class template deduction cannot work on Constructor without parameters in some cases Product: gcc Version: 7.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kmp53 at sina dot com CC: webrown.cpp at gmail dot com Target Milestone: --- CC: webrown.cpp at gmail dot com template class C { public: void fn(){} }; int main(int argc,char*argv[]){ C c;//OK C{}.fn();//OK C().fn();//cannot deduce template arguments for 'C' from () }
[Bug tree-optimization/81192] [8 Regression] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81192 --- Comment #9 from Tom de Vries --- Created attachment 41656 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41656&action=edit 1 - Fix sigsegv in find_same_succ_bb Essentially the same as the fix in comment 3.
[Bug tree-optimization/81192] [8 Regression] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81192 Tom de Vries changed: What|Removed |Added Attachment #41650|0 |1 is obsolete|| --- Comment #10 from Tom de Vries --- Created attachment 41657 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41657&action=edit 2 - Don't tail-merge blocks from different loops
[Bug target/81225] [6/7 Regression] ICE with -mavx512ifma -O3 -ffloat-store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81225 Jakub Jelinek changed: What|Removed |Added Summary|[6/7/8 Regression] ICE with |[6/7 Regression] ICE with |-mavx512ifma -O3|-mavx512ifma -O3 |-ffloat-store |-ffloat-store --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/81192] [8 Regression] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81192 --- Comment #11 from Tom de Vries --- Created attachment 41658 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41658&action=edit 3 - Ignore EDGE_DFS_BACK in tail-merge This is a fix for the issue noted in comment 7: EDGE_DFS_BACK is in an undefined state during tail-merge, but taken into account when comparing edges, which causes missed merge opportunities in tail-merge. This patch fixes the issue by ignoring EDGE_DFS_BACK in tail-merge. For the example in this PR, the patch allows us to merge two latch blocks in the same loop. Previously this merge didn't happen because one bb had EDGE_DFS_BACK set on the back-edge, while the other one did not. A fix for trunk only, the previous two we probably want to back-port.
[Bug tree-optimization/81192] [8 Regression] gcc ICE at -Os on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81192 --- Comment #12 from Tom de Vries --- Currently bootstrapping and reg-testing patch series on x86_64.
[Bug libstdc++/81263] Work around CWG issue 1558 (guarantee SFINAE when using `void_t`)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81263 W E Brown changed: What|Removed |Added CC||webrown.cpp at gmail dot com --- Comment #1 from W E Brown --- I have not confirmed the report but, as the originator of the void_t technique, I do have a few comments: a) The cited CWG issue was resolved several years ago, and is in DR status. That means the exhibited code is expected to work. If it doesn't, I consider it a compiler issue, not a library issue. b) Therefore, once the compiler is fixed (if necessary), ISTM there should be no reason to use the cited alternative definition of void_t, which I first discovered and disseminated as a temporary workaround only. See my WG21 paper N3911 and/or part 2 of my metaprogramming talk at CppCon 2014. c) FWIW, while it should work as exhibited in the report, the code does not quite conform to the design of the detection idiom. I prefer to write such a 2nd template parameter as a type parameter of the form class = void_t.
[Bug tree-optimization/81162] [8 Regression] UBSAN switch triggers incorrect optimization in SLSR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81162 --- Comment #7 from Bill Schmidt --- This case comes up when we're going to replace a NEGATE_EXPR with a PLUS_EXPR or MINUS_EXPR. This is another case of an unprofitable replacement that should be avoided anyway. So I think the following fix is what we need: Index: gcc/gimple-ssa-strength-reduction.c === --- gcc/gimple-ssa-strength-reduction.c (revision 249846) +++ gcc/gimple-ssa-strength-reduction.c (working copy) @@ -2082,13 +2082,14 @@ replace_mult_candidate (slsr_cand_t c, tree basis_ types but allows for safe negation without twisted logic. */ if (wi::fits_shwi_p (bump) && bump.to_shwi () != HOST_WIDE_INT_MIN - /* It is not useful to replace casts, copies, or adds of + /* It is not useful to replace casts, copies, negates, or adds of an SSA name and a constant. */ && cand_code != SSA_NAME && !CONVERT_EXPR_CODE_P (cand_code) && cand_code != PLUS_EXPR && cand_code != POINTER_PLUS_EXPR - && cand_code != MINUS_EXPR) + && cand_code != MINUS_EXPR + && cand_code != NEGATE_EXPR) { enum tree_code code = PLUS_EXPR; tree bump_tree; This fixes the particular test. I have to head out on vacation now, but I will regstrap this and submit it when I get back if there are no objections.
[Bug debug/81267] Missing DW_AT_type in DW_TAG_typedef of "typedef of typedef of void"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81267 --- Comment #1 from Pedro Alves --- xref: https://sourceware.org/ml/gdb-patches/2017-06/msg00827.html
[Bug tree-optimization/58012] Gcc bootstrap failed with cloog-isl: undefined reference to std::istream::ignore(long)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58012 Mario Emmenlauer changed: What|Removed |Added CC||mario at emmenlauer dot de --- Comment #2 from Mario Emmenlauer --- I'm still plagued by this issue with gcc 5.4.0 and gcc 6.3.0 on CentOS 6.8 and CentOS 7.3.1611. I tried with and without my own isl 0.18.0, no difference. Was this never really resolved? Newest isl 0.18.0 has int.h only in the include/deprecated/ directory, is the patch still needed?
[Bug libstdc++/81263] Work around CWG issue 1558 (guarantee SFINAE when using `void_t`)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81263 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #2 from TC --- This is not DR1558; the issue here is declaration matching rather than SFINAE. Just having the two func definitions is sufficient to trigger the error: template using void_t = void; template * = nullptr> void func() {} template * = nullptr> void func() {} This is actually CWG 1980.
[Bug ipa/81214] GCC target_clone support does not work for global functions with no references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81214 --- Comment #5 from Michael Meissner --- The change commited in svn id 249840, does fix the problem on the PowerPC. Thanks.
[Bug target/68467] libgcc, compilation for target m68k-linux breaks in linux_atomic.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68467 --- Comment #18 from Carlos Soto --- (In reply to angelo from comment #17) > Hi Carlos, > > maybe you can try one of these 2 toolchains i prepared years ago: > > http://sysam.it/toolchains.html > > Regads, > Angelo > Hi angelo, thanks for pointing that. But unfortunately those toolchain lack a sysroot so they are not suitable for Buildroot, the tool I use to create the root fs. So, I'm stuck for the time being...
[Bug target/81268] New: [avr] Support __gcc_isr pseudo-instruction for more efficient ISR prologues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81268 Bug ID: 81268 Summary: [avr] Support __gcc_isr pseudo-instruction for more efficient ISR prologues Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target Milestone: --- GNU assembler supports the __gcc_isr pseudo-instruction, cf. https://sourceware.org/bugzilla/show_bug.cgi?id=21683 This can be used up reduce overhead in ISR prologues and epilogues due to GCC's modeling of TMP_REG and ZERO_REG as fixed regs und using cc0 to model SREG.
[Bug target/81268] [avr] Support __gcc_isr pseudo-instruction for more efficient ISR prologues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81268 Georg-Johann Lay changed: What|Removed |Added Keywords||missed-optimization Target||avr Priority|P3 |P5 Blocks||20296 Assignee|unassigned at gcc dot gnu.org |gjl at gcc dot gnu.org Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20296 [Bug 20296] Speeding up small interrupts on avr
[Bug c/81269] New: wrong color highlighting in -Wrestrict warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81269 Bug ID: 81269 Summary: wrong color highlighting in -Wrestrict warnings Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Created attachment 41659 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41659&action=edit Screenshot showing unexpected colors. While testing an enhancement to -Wrestrict for sprintf (bug 35503) I noticed some strange effects in the current implementation of the warning. For the test case below, the first argument caret are pink, the second green, the third blue, and the fourth green again. I see even more unusual behavior in my enhancement. $ cat b.c && gcc -O2 -S -Wall -Wrestrict b.c extern int sprintf (char* restrict, const char*, ...); void sink (void*); void f (void) { char d[5] = "1234"; sprintf (d, "%s %s %s", d, d, d); sink (d); } b.c: In function ‘f’: b.c:8:12: warning: passing argument 1 to restrict-qualified parameter aliases with arguments 3, 4, 5 [-Wrestrict] sprintf (d, "%s %s %s", d, d, d); ^ ~ ~ ~
[Bug c/81269] wrong color highlighting in -Wrestrict warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81269 --- Comment #1 from Martin Sebor --- Created attachment 41660 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41660&action=edit Even more unusual behavior seen in my enhancement. Attached is another screenshot, this one showing even more unusual highlighting with my (not-yet-committed) enhancement to gimple-ssa-sprintf.c.
[Bug tree-optimization/81245] [8 Regression] ICE building calculix with -Ofast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81245 Andrew Pinski changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Andrew Pinski --- Forgot to put the PR # in the changelog :). Author: pinskia Date: Fri Jun 30 20:40:38 2017 New Revision: 249854 URL: https://gcc.gnu.org/viewcvs?rev=249854&root=gcc&view=rev Log: 2017-06-30 Andrew Pinski * tree-if-conv.c (predicate_scalar_phi): Update new_stmt if fold_stmt returned true. 2017-06-30 Andrew Pinski * gcc.dg/torture/pr81245.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr81245.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-if-conv.c
[Bug c++/81257] [8 Regression] ICE on invalid C++ template code: in make_typename_type, at cp/decl.c:3709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81257 --- Comment #2 from Jason Merrill --- Author: jason Date: Fri Jun 30 21:08:53 2017 New Revision: 249855 URL: https://gcc.gnu.org/viewcvs?rev=249855&root=gcc&view=rev Log: PR c++/81257 - ICE with invalid ::template. PR c++/54769 - wrong lookup of dependent template-name. * parser.c (cp_parser_template_name): Revert part of last change. Added: trunk/gcc/testsuite/g++.dg/parse/template-keyword1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug c++/54769] [Core/1111] dependent class method template not found if structure template with the same name is visible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54769 --- Comment #8 from Jason Merrill --- Author: jason Date: Fri Jun 30 21:08:53 2017 New Revision: 249855 URL: https://gcc.gnu.org/viewcvs?rev=249855&root=gcc&view=rev Log: PR c++/81257 - ICE with invalid ::template. PR c++/54769 - wrong lookup of dependent template-name. * parser.c (cp_parser_template_name): Revert part of last change. Added: trunk/gcc/testsuite/g++.dg/parse/template-keyword1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c
[Bug ipa/81261] [8 Regression] ICE with -fno-guess-branch-probability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81261 --- Comment #2 from Jan Hubicka --- Author: hubicka Date: Fri Jun 30 21:09:13 2017 New Revision: 249856 URL: https://gcc.gnu.org/viewcvs?rev=249856&root=gcc&view=rev Log: PR ipa/81261 * tree-inline.c (expand_call_inline): Combine profile statuses. Added: trunk/gcc/testsuite/g++.dg/ipa/pr81261.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c
[Bug c++/81257] [8 Regression] ICE on invalid C++ template code: in make_typename_type, at cp/decl.c:3709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81257 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #3 from Jason Merrill --- Fixed.
[Bug c++/81257] [8 Regression] ICE on invalid C++ template code: in make_typename_type, at cp/decl.c:3709
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81257 --- Comment #4 from Jason Merrill --- Author: jason Date: Fri Jun 30 22:20:22 2017 New Revision: 249857 URL: https://gcc.gnu.org/viewcvs?rev=249857&root=gcc&view=rev Log: PR c++/54769 - wrong lookup of dependent template-name. PR c++/81257 - ICE with invalid ::template. * parser.c (cp_parser_template_name): Handle dependent object type. (cp_parser_nested_name_specifier_opt): Make template_keyword_p a parameter. (cp_parser_id_expression): Pass it. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/parse/template-keyword1.C branches/gcc-7-branch/gcc/testsuite/g++.dg/template/lookup11.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/parser.c
[Bug c++/54769] [Core/1111] dependent class method template not found if structure template with the same name is visible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54769 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|8.0 |7.2 --- Comment #10 from Jason Merrill --- The fix for 81257 made me more comfortable with backporting this to 7.
[Bug c++/54769] [Core/1111] dependent class method template not found if structure template with the same name is visible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54769 --- Comment #9 from Jason Merrill --- Author: jason Date: Fri Jun 30 22:20:22 2017 New Revision: 249857 URL: https://gcc.gnu.org/viewcvs?rev=249857&root=gcc&view=rev Log: PR c++/54769 - wrong lookup of dependent template-name. PR c++/81257 - ICE with invalid ::template. * parser.c (cp_parser_template_name): Handle dependent object type. (cp_parser_nested_name_specifier_opt): Make template_keyword_p a parameter. (cp_parser_id_expression): Pass it. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/parse/template-keyword1.C branches/gcc-7-branch/gcc/testsuite/g++.dg/template/lookup11.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/parser.c
[Bug c++/45976] optional template keyword is not accepted by g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45976 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #3 from Jason Merrill --- That template keyword is not allowed in a declarator-id, but I've fixed GCC 8 to accept it with a pedwarn.
[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- (In reply to Jim Wilson from comment #7) --- snip --- > > However, for stash_internal_unit, we have as global definitions > #define NEWUNIT_STACK_SIZE 16 > static gfc_saved_unit newunit_stack[NEWUNIT_STACK_SIZE]; > and inside the function we have > if (newunit_tos >= NEWUNIT_STACK_SIZE) That size is fairly arbitrary. Short term we can bump this limit up to some higher value. Longer term, I wonder if this needs to be more dynamic. I will get on it.
[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387 --- Comment #9 from Dominique d'Humieres --- Related to pr81195 and pr81241? Works on darwin with 8 threads.
[Bug c++/81270] New: [concepts] ill-formed code with a constrained variable declaration with multiple declarators with different deduced types not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81270 Bug ID: 81270 Summary: [concepts] ill-formed code with a constrained variable declaration with multiple declarators with different deduced types not rejected Product: gcc Version: c++-concepts Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tom at honermann dot net CC: andrew.n.sutton at gmail dot com, asutton at gcc dot gnu.org Target Milestone: --- The Concepts TS (N4674) updates § 10.1.7.4 [dcl.spec.auto] paragraph 9 (paragraph 7 in the current WP) to state: > If the init-declarator-list contains more than one init-declarator, they > shall all form declarations of variables. The type of each declared > variable is determined by placeholder type deduction (10.1.7.4.1), and if > the type that replaces the declared variable type or return type is not > the same in each deduction, the program is ill-formed. gcc 7.1.0 fails to diagnose the following code that is ill-formed due to a different type being deduced for each of the v1 and v2 declarators: $ cat t.cpp template concept bool C = true; C v1 = 1, v2 = nullptr; // Ill-formed. // Following code to demonstrate that the types of v1 and v2 are deduced // to different types. template struct is_same { static constexpr bool value = false; }; template struct is_same { static constexpr bool value = true; }; static_assert(is_same::value); static_assert(is_same::value); $ g++ --version g++ (GCC) 7.1.0 ... $ g++ -c -fconcepts t.cpp The expectation is that gcc reject the above code as it does if the declared variable type C is replaced with auto: $ cat t2.cpp auto v1 = 1, v2 = nullptr; $ g++ -c -fconcepts t2.cpp t2.cpp:1:1: error: inconsistent deduction for ‘auto’: ‘int’ and then ‘std::nullptr_t’ auto v1 = 1, v2 = nullptr; ^~~~
[Bug middle-end/81172] Expected new warning option -Warray-bounds-pointer-arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81172 --- Comment #5 from Xi Ruoyao --- (In reply to Martin Sebor from comment #4) > Clang diagnoses the the cases where the offset or index is a constant > expression (and under the expected option) but it doesn't diagnose others > where the offset/index value is not a constant expression but can be > determined to be out of bounds by VRP, for instance. GCC can do better, but > it may not be able to distinguish between the two kinds of warnings outside > the front end. I'm aware that GCC C/C++ FE convert a[x] to *(a+x) very early. But now it's very strange - why GCC -Warray-bounds doesn't warn for pointer arithmetics?
[Bug fortran/78387] OpenMP segfault/stack size exceeded writing to internal file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78387 --- Comment #10 from Jim Wilson --- newunit_stack needs to be allocated dynamically, just like the newunits array. I modified libgfortran to compute the highest value of newunit_tos, and print it when the program exits. I set NEWUNIT_STACK_SIZE to 128 so I could go up to 128 threads. weathertop:2188$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null newunit_tos_max = 8 weathertop:2188$ OMP_NUM_THREADS=16 ./a.out 2> /dev/null newunit_tos_max = 16 weathertop:2189$ OMP_NUM_THREADS=32 ./a.out 2> /dev/null newunit_tos_max = 32 weathertop:2190$ OMP_NUM_THREADS=64 ./a.out 2> /dev/null newunit_tos_max = 64 weathertop:2191$ OMP_NUM_THREADS=128 ./a.out 2> /dev/null newunit_tos_max = 128 Segmentation fault (core dumped) weathertop:2192$ So the size of newunit stack depends on the number of threads, and can be any number. If you don't want to put a hard limit of the number of threads that gfortran can support, then you need to dynamically allocate it. There is some variation from one run to the next, so using 16 threads doesn't guarantee failure, and using 8 threads doesn't guarantee success. weathertop:2192$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null newunit_tos_max = 8 weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null newunit_tos_max = 8 weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null newunit_tos_max = 8 weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null newunit_tos_max = 8 weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null newunit_tos_max = 3 weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null newunit_tos_max = 8 weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null newunit_tos_max = 5 weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null newunit_tos_max = 8 weathertop:2193$ OMP_NUM_THREADS=8 ./a.out 2> /dev/null newunit_tos_max = 8 weathertop:2193$