[Bug fortran/89981] New: [8/9 Regression] gfortran -pedantic rejects code in 8.3.1 that is accepted with 8.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89981 Bug ID: 89981 Summary: [8/9 Regression] gfortran -pedantic rejects code in 8.3.1 that is accepted with 8.3.0 Product: gcc Version: 8.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: doko at debian dot org Target Milestone: --- Created attachment 46091 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46091=edit test case works with r269936 on the gcc-8-branch, fails with r270110, and on the trunk: $ gfortran -c -pedantic sadmvnt.f sadmvnt.f:80:15: INFORM = MVNNIT( N, CORREL, LOWER, UPPER, INFIN, INFIS, D, E ) 1 Error: More actual than formal arguments in procedure call at (1) sadmvnt.f:1432:15: INFORM = MVTNIT( N, NU, CORREL, LOWER, UPPER, INFIN, INFIS, D, E ) 1 Error: Type mismatch in argument 'w' at (1); passed INTEGER(4) to REAL(8)
[Bug bootstrap/89980] [9 Regression] bootstrap failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-05 Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- It is caused by r270155.
[Bug bootstrap/89980] New: [9 Regression] bootstrap failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89980 Bug ID: 89980 Summary: [9 Regression] bootstrap failed Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: msebor at gcc dot gnu.org Target Milestone: --- Target: x86-64, i386 On x86, r270158 failed to bootstrap: build/gengtype \ -S ../../src-trunk/gcc -I gtyp-input.list -w tmp-gtype.statemake[6]: *** [Makefile:2642: s-gtype] Segmentation fault (core dumped) make[6]: *** Waiting for unfinished jobs ../../src-trunk/gcc/fortran/gfortran.texi:2753: warning: @ref node name should not contain `:' rm fsf-funding.pod gcov.pod gfdl.pod gpl.pod cpp.pod gcc.pod gcov-dump.pod gfortran.pod gcov-tool.pod make[6]: Leaving directory '/export/gnu/import/git/gcc-test-ia32corei7/bld/gcc' make[5]: *** [Makefile:4699: all-stage2-gcc] Error 2 make[5]: Leaving directory '/export/gnu/import/git/gcc-test-ia32corei7/bld' make[4]: *** [Makefile:23216: stage2-bubble] Error 2 make[4]: Leaving directory '/export/gnu/import/git/gcc-test-ia32corei7/bld' make[3]: *** [Makefile:23420: bootstrap] Error 2 r270151 is OK.
[Bug c++/89948] [9 Regression] ICE in fold_convert_loc, at fold-const.c:2430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89948 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jason Merrill --- Fixed.
[Bug c++/89966] [9 Regression] non-type template argument rejects sizeof operator result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89966 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Jason Merrill --- Fixed.
[Bug c++/89948] [9 Regression] ICE in fold_convert_loc, at fold-const.c:2430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89948 --- Comment #1 from Jason Merrill --- Author: jason Date: Fri Apr 5 02:52:23 2019 New Revision: 270161 URL: https://gcc.gnu.org/viewcvs?rev=270161=gcc=rev Log: PR c++/89948 - ICE with break in statement-expr. * constexpr.c (cxx_eval_statement_list): Jumping out of a statement-expr is non-constant. Added: trunk/gcc/testsuite/g++.dg/ext/stmtexpr23.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug c++/86932] [8 Regression] Empty non-type template parameter pack not considered for SFINAE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86932 --- Comment #6 from Jason Merrill --- Author: jason Date: Fri Apr 5 02:50:52 2019 New Revision: 270160 URL: https://gcc.gnu.org/viewcvs?rev=270160=gcc=rev Log: PR c++/89966 - error with non-type auto tparm. My patch for PR 86932 broke this testcase by passing tf_partial to coerce_template_template_parms, which prevented do_auto_deduction from actually replacing the auto. * pt.c (do_auto_deduction): Clear tf_partial. Added: trunk/gcc/testsuite/g++.dg/cpp1z/nontype-auto15.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/89966] [9 Regression] non-type template argument rejects sizeof operator result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89966 --- Comment #1 from Jason Merrill --- Author: jason Date: Fri Apr 5 02:50:52 2019 New Revision: 270160 URL: https://gcc.gnu.org/viewcvs?rev=270160=gcc=rev Log: PR c++/89966 - error with non-type auto tparm. My patch for PR 86932 broke this testcase by passing tf_partial to coerce_template_template_parms, which prevented do_auto_deduction from actually replacing the auto. * pt.c (do_auto_deduction): Clear tf_partial. Added: trunk/gcc/testsuite/g++.dg/cpp1z/nontype-auto15.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/86986] [7/8/9 Regression] Unexpected errors for template parameter pack in a template template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86986 --- Comment #4 from Jason Merrill --- Author: jason Date: Fri Apr 5 02:50:18 2019 New Revision: 270159 URL: https://gcc.gnu.org/viewcvs?rev=270159=gcc=rev Log: PR c++/86986 - ICE with TTP with parameter pack. Three separate issues were breaking this testcase. One, we were trying to look at the type of a template template parameter to see if it's a valid non-type template parameter. Two, we were treating a parameter pack named in the type of a template parameter pack of a TTP pack as being one of the packs expanded by the outer pack. Three, we weren't supplying all the necessary levels of template arguments when TTP matching. * pt.c (coerce_template_parameter_pack): Only look at the type of a non-type parameter pack. (fixed_parameter_pack_p_1): Don't recurse into the type of a non-type parameter pack. (coerce_template_template_parms): Call add_outermost_template_args. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic-ttp9.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/89914] [9 Regression] ICE in nothrow_spec_p, at cp/except.c:1238
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89914 Paolo Carlini changed: What|Removed |Added Status|NEW |ASSIGNED CC|paolo.carlini at oracle dot com| Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #4 from Paolo Carlini --- Mine.
[Bug fortran/79842] i18n: subword translation in "Can't use the same %smodule"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79842 --- Comment #3 from Roland Illig --- Any progress on this one? To me it sounds like it were quite easy to fix.
[Bug fortran/84382] add command-line options -std=gnu2003 and -std=gnu2008 for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to janus from comment #2) > (In reply to Dominique d'Humieres from comment #1) > > Fortran is not C! > > True. Fortran is not C is not C++. The main difference wrt this PR is > possibly that the latter two have a large enough user base, so that a > significant amount of people actually use the options mentioned above. > How do you propose to enforce a certain standard and allow GNU extensions? For example, -std=gnu2003 would enforce Fortran 2003, but allow GNU extensions. The problem is that gfortran allows several extensions that violate the standard. A simple example is program foo integer :: i = z'1234' print *, i end program foo % gfcx -o z a.f90 && ./z 4660 % gfcx -o z -std=f2003 a.f90 && ./z a.f90:2:18: 2 | integer :: i = z'1234' | 1 Error: GNU Extension: BOZ literal at (1) outside a DATA statement and outside INT/REAL/DBLE/CMPLX gfortran even allows extensions that aren't caught by the -std options and are not document! program foo integer :: i = 42 print '(i0)', i + z'1234' end program foo %gfcx -o z a.f90 && ./z 4702 % gfcx -o z -std=f2003 a.f90 && ./z 4702 I think it will becomes a endless discussion on what should and should not be covered under -std=gnu2003. What we have now seems to be the most reasonable approach (with the available man power to address problem). Either a user wants GNU Fortran (ie., -std=gnu, the default behavior) or a user wants a stricter adherence to a particular standard. (For the record, I plan to remove both of the above extensions in 10.0). > > WTF? > > Giving that questions back to you, Dominique: WTF? Which problem do you > think you solve by closing PRs that have not been fixed? Yeah, I saw Dominique's comment #1, and thought that it might be a tad bit over-the-top given the quality and quantity of your contributions to gfortran.
[Bug ipa/89924] [missed-optimization] Function not de-virtualized within the same TU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89924 --- Comment #5 from Eyal Rozenberg --- (In reply to Jan Hubicka from comment #3) > The reason why we do not devirtualize is that only information about Aint is > the type of function parameter "Only"? :-) > and we do not believe it implies the type of > memory location it points to because there is no read or anything from that > pointer before it is casted to struct A* and pointer of a given type does > not need to necessarily point to memory location of the same type unless you > dereference it. > > Is it really valid to devirtualize here? IANALL, but yes. You're using terms like "belief" and talk about speculative inference based on partial evidence. Why? foo_virtual gets a pointer to an Aint. Why should the compiler needs to second-guess this?
[Bug c++/71487] sorry, unimplemented: mangling offset_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71487
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2016-06-26 00:00:00 |2019-4-4
CC||msebor at gcc dot gnu.org
Known to fail||8.3.0, 9.0
--- Comment #4 from Martin Sebor ---
No change in GCC 8 or 9:
pr71487.C: In instantiation of ‘void PropertyMatcher::operator()(U) [with
U = std::__cxx11::basic_string; F = long unsigned int
(std::__cxx11::basic_string::*)() const; T = int]’:
pr71487.C:30:34: required from here
pr71487.C:15:39: warning: comparison of integer expressions of different
signedness: ‘long unsigned int’ and ‘int’ [-Wsign-compare]
15 | std::cout << ((actual.*memfun)() == expected) << std::endl;
| ^~~~
pr71487.C: In instantiation of ‘decltype (Property((&
std::__cxx11::basic_string::size), declval())) HasLength(T) [with T =
int]’:
pr71487.C:31:1: required from here
pr71487.C:25:6: sorry, unimplemented: mangling offset_ref
25 | auto HasLength(T expected) -> decltype(Property(::string::size,
declval())) {
| ^
[Bug c++/89974] ICE on a definition of a non-type specialization on a struct object with pointer to member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89974 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Martin Sebor --- Fixed via r270155.
[Bug c++/89878] same specializations on a zero-initialized struct object as a non-type parameter treated as distinct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89878 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #4 from Martin Sebor --- Fixed in r270155.
[Bug c++/47488] sorry, unimplemented: string literal in function template signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47488 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 Known to fail||4.6.0, 4.8.5, 4.9.4, 5.4.0, ||6.4.0, 7.3.0, 8.3.0 --- Comment #16 from Martin Sebor --- Fixed in GCC 9.
[Bug c++/89833] [9 Regression] sorry, unimplemented: string literal in function template signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89833 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Sebor --- Fixed in r270155.
[Bug c++/89974] ICE on a definition of a non-type specialization on a struct object with pointer to member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89974 --- Comment #1 from Martin Sebor --- Author: msebor Date: Thu Apr 4 23:10:23 2019 New Revision: 270155 URL: https://gcc.gnu.org/viewcvs?rev=270155=gcc=rev Log: PR c++/89974 - ICE on a definition of a non-type specialization on a struct object with pointer to member function PR c++/89878 - same specializations on a zero-initialized struct object as a non-type parameter treated as distinct PR c++/89833 - sorry, unimplemented: string literal in function template signature PR c++/47488 - sorry, unimplemented: string literal in function template signature gcc/cp/ChangeLog: PR c++/89974 PR c++/89878 PR c++/89833 PR c++/47488 * decl.c (reshape_init_array_1): Strip trailing zero-initializers from arrays of trivial type and known size. * mangle.c (write_expression): Convert braced initializer lists to STRING_CSTs. (write_expression): Trim trailing zero-initializers from arrays of trivial type. (write_template_arg_literal): Mangle strings the same as braced initializer lists. gcc/testsuite/ChangeLog: PR c++/89974 PR c++/89878 PR c++/89833 PR c++/47488 * gcc/testsuite/g++.dg/abi/mangle69.C: New test. * gcc/testsuite/g++.dg/abi/mangle70.C: New test. * gcc/testsuite/g++.dg/abi/mangle71.C: New test. * gcc/testsuite/g++.dg/abi/mangle72.C: New test. * gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C: New test. * gcc/testsuite/g++.dg/cpp2a/nontype-class15.C: New test. * gcc/testsuite/g++.dg/cpp2a/nontype-class16.C: New test. * gcc/testsuite/g++.dg/init/array51.C: New test. Added: trunk/gcc/testsuite/g++.dg/abi/mangle69.C trunk/gcc/testsuite/g++.dg/abi/mangle70.C trunk/gcc/testsuite/g++.dg/abi/mangle71.C trunk/gcc/testsuite/g++.dg/abi/mangle72.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class15.C trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class16.C trunk/gcc/testsuite/g++.dg/init/array51.C trunk/gcc/testsuite/g++.dg/template/nontype29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog
[Bug c++/47488] sorry, unimplemented: string literal in function template signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47488 --- Comment #15 from Martin Sebor --- Author: msebor Date: Thu Apr 4 23:10:23 2019 New Revision: 270155 URL: https://gcc.gnu.org/viewcvs?rev=270155=gcc=rev Log: PR c++/89974 - ICE on a definition of a non-type specialization on a struct object with pointer to member function PR c++/89878 - same specializations on a zero-initialized struct object as a non-type parameter treated as distinct PR c++/89833 - sorry, unimplemented: string literal in function template signature PR c++/47488 - sorry, unimplemented: string literal in function template signature gcc/cp/ChangeLog: PR c++/89974 PR c++/89878 PR c++/89833 PR c++/47488 * decl.c (reshape_init_array_1): Strip trailing zero-initializers from arrays of trivial type and known size. * mangle.c (write_expression): Convert braced initializer lists to STRING_CSTs. (write_expression): Trim trailing zero-initializers from arrays of trivial type. (write_template_arg_literal): Mangle strings the same as braced initializer lists. gcc/testsuite/ChangeLog: PR c++/89974 PR c++/89878 PR c++/89833 PR c++/47488 * gcc/testsuite/g++.dg/abi/mangle69.C: New test. * gcc/testsuite/g++.dg/abi/mangle70.C: New test. * gcc/testsuite/g++.dg/abi/mangle71.C: New test. * gcc/testsuite/g++.dg/abi/mangle72.C: New test. * gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C: New test. * gcc/testsuite/g++.dg/cpp2a/nontype-class15.C: New test. * gcc/testsuite/g++.dg/cpp2a/nontype-class16.C: New test. * gcc/testsuite/g++.dg/init/array51.C: New test. Added: trunk/gcc/testsuite/g++.dg/abi/mangle69.C trunk/gcc/testsuite/g++.dg/abi/mangle70.C trunk/gcc/testsuite/g++.dg/abi/mangle71.C trunk/gcc/testsuite/g++.dg/abi/mangle72.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class15.C trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class16.C trunk/gcc/testsuite/g++.dg/init/array51.C trunk/gcc/testsuite/g++.dg/template/nontype29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89833] [9 Regression] sorry, unimplemented: string literal in function template signature
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89833 --- Comment #4 from Martin Sebor --- Author: msebor Date: Thu Apr 4 23:10:23 2019 New Revision: 270155 URL: https://gcc.gnu.org/viewcvs?rev=270155=gcc=rev Log: PR c++/89974 - ICE on a definition of a non-type specialization on a struct object with pointer to member function PR c++/89878 - same specializations on a zero-initialized struct object as a non-type parameter treated as distinct PR c++/89833 - sorry, unimplemented: string literal in function template signature PR c++/47488 - sorry, unimplemented: string literal in function template signature gcc/cp/ChangeLog: PR c++/89974 PR c++/89878 PR c++/89833 PR c++/47488 * decl.c (reshape_init_array_1): Strip trailing zero-initializers from arrays of trivial type and known size. * mangle.c (write_expression): Convert braced initializer lists to STRING_CSTs. (write_expression): Trim trailing zero-initializers from arrays of trivial type. (write_template_arg_literal): Mangle strings the same as braced initializer lists. gcc/testsuite/ChangeLog: PR c++/89974 PR c++/89878 PR c++/89833 PR c++/47488 * gcc/testsuite/g++.dg/abi/mangle69.C: New test. * gcc/testsuite/g++.dg/abi/mangle70.C: New test. * gcc/testsuite/g++.dg/abi/mangle71.C: New test. * gcc/testsuite/g++.dg/abi/mangle72.C: New test. * gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C: New test. * gcc/testsuite/g++.dg/cpp2a/nontype-class15.C: New test. * gcc/testsuite/g++.dg/cpp2a/nontype-class16.C: New test. * gcc/testsuite/g++.dg/init/array51.C: New test. Added: trunk/gcc/testsuite/g++.dg/abi/mangle69.C trunk/gcc/testsuite/g++.dg/abi/mangle70.C trunk/gcc/testsuite/g++.dg/abi/mangle71.C trunk/gcc/testsuite/g++.dg/abi/mangle72.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class15.C trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class16.C trunk/gcc/testsuite/g++.dg/init/array51.C trunk/gcc/testsuite/g++.dg/template/nontype29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89878] same specializations on a zero-initialized struct object as a non-type parameter treated as distinct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89878 --- Comment #3 from Martin Sebor --- Author: msebor Date: Thu Apr 4 23:10:23 2019 New Revision: 270155 URL: https://gcc.gnu.org/viewcvs?rev=270155=gcc=rev Log: PR c++/89974 - ICE on a definition of a non-type specialization on a struct object with pointer to member function PR c++/89878 - same specializations on a zero-initialized struct object as a non-type parameter treated as distinct PR c++/89833 - sorry, unimplemented: string literal in function template signature PR c++/47488 - sorry, unimplemented: string literal in function template signature gcc/cp/ChangeLog: PR c++/89974 PR c++/89878 PR c++/89833 PR c++/47488 * decl.c (reshape_init_array_1): Strip trailing zero-initializers from arrays of trivial type and known size. * mangle.c (write_expression): Convert braced initializer lists to STRING_CSTs. (write_expression): Trim trailing zero-initializers from arrays of trivial type. (write_template_arg_literal): Mangle strings the same as braced initializer lists. gcc/testsuite/ChangeLog: PR c++/89974 PR c++/89878 PR c++/89833 PR c++/47488 * gcc/testsuite/g++.dg/abi/mangle69.C: New test. * gcc/testsuite/g++.dg/abi/mangle70.C: New test. * gcc/testsuite/g++.dg/abi/mangle71.C: New test. * gcc/testsuite/g++.dg/abi/mangle72.C: New test. * gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C: New test. * gcc/testsuite/g++.dg/cpp2a/nontype-class15.C: New test. * gcc/testsuite/g++.dg/cpp2a/nontype-class16.C: New test. * gcc/testsuite/g++.dg/init/array51.C: New test. Added: trunk/gcc/testsuite/g++.dg/abi/mangle69.C trunk/gcc/testsuite/g++.dg/abi/mangle70.C trunk/gcc/testsuite/g++.dg/abi/mangle71.C trunk/gcc/testsuite/g++.dg/abi/mangle72.C trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-array19.C trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class15.C trunk/gcc/testsuite/g++.dg/cpp2a/nontype-class16.C trunk/gcc/testsuite/g++.dg/init/array51.C trunk/gcc/testsuite/g++.dg/template/nontype29.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/mangle.c trunk/gcc/testsuite/ChangeLog
[Bug c++/89974] ICE on a definition of a non-type specialization on a struct object with pointer to member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89974 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-04 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1
[Bug middle-end/89957] ICE calling strnlen with an int128_t bound in a known range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89957 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #3 from Martin Sebor --- Fixed via r270154.
[Bug middle-end/89957] ICE calling strnlen with an int128_t bound in a known range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89957 --- Comment #2 from Martin Sebor --- Author: msebor Date: Thu Apr 4 22:38:10 2019 New Revision: 270154 URL: https://gcc.gnu.org/viewcvs?rev=270154=gcc=rev Log: PR middle-end/89957 - ICE calling strnlen with an int128_t bound in a known range PR middle-end/89911 - [9 Regression] ICE in get_attr_nonstring_decl gcc/ChangeLog: PR middle-end/89957 PR middle-end/89911 * builtins.c (expand_builtin_strnlen): Make sure wi::ltu_p operands have the same precision since the function crashes otherwise. * calls.c (maybe_warn_nonstring_arg): Avoid assuming strnlen() call has non-zero arguments. gcc/testsuite/ChangeLog: PR middle-end/89957 PR middle-end/89911 * gcc.dg/Wstringop-overflow-13.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-13.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/calls.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/89911] [9 Regression] ICE in get_attr_nonstring_decl, at calls.c:1502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89911 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed via r270154.
[Bug middle-end/89911] [9 Regression] ICE in get_attr_nonstring_decl, at calls.c:1502
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89911 --- Comment #3 from Martin Sebor --- Author: msebor Date: Thu Apr 4 22:38:10 2019 New Revision: 270154 URL: https://gcc.gnu.org/viewcvs?rev=270154=gcc=rev Log: PR middle-end/89957 - ICE calling strnlen with an int128_t bound in a known range PR middle-end/89911 - [9 Regression] ICE in get_attr_nonstring_decl gcc/ChangeLog: PR middle-end/89957 PR middle-end/89911 * builtins.c (expand_builtin_strnlen): Make sure wi::ltu_p operands have the same precision since the function crashes otherwise. * calls.c (maybe_warn_nonstring_arg): Avoid assuming strnlen() call has non-zero arguments. gcc/testsuite/ChangeLog: PR middle-end/89957 PR middle-end/89911 * gcc.dg/Wstringop-overflow-13.c: New test. Added: trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-13.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/calls.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/89934] [8 Regression] ICE on a call with fewer arguments to strncpy declared without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Sebor --- Patch backported to GCC 8 via r270153.
[Bug middle-end/89934] [8 Regression] ICE on a call with fewer arguments to strncpy declared without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934 --- Comment #8 from Martin Sebor --- Author: msebor Date: Thu Apr 4 22:16:11 2019 New Revision: 270153 URL: https://gcc.gnu.org/viewcvs?rev=270153=gcc=rev Log: Backport from 9.0. PR middle-end/89934 - ICE on a call with fewer arguments to strncpy declared without prototype gcc/ChangeLog: PR middle-end/89934 * gimple-ssa-warn-restrict.c (builtin_access::builtin_access): Bail out if the number of arguments is less than expected. gcc/testsuite/ChangeLog: PR middle-end/89934 * gcc.dg/Wrestrict-19.c: New test. * gcc.dg/Wrestrict-5.c: Add comment. Remove unused code. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/Wrestrict-19.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/gimple-ssa-warn-restrict.c branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/gcc/testsuite/gcc.dg/Wrestrict-5.c
[Bug debug/55585] compile time hog at -O1 -fboundscheck -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55585 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Dominique d'Humieres --- % time gfortran-fsf-5 -c -g -O1 -fbounds-check pr55585.f90 74.868u 1.625s 1:16.58 99.8%0+0k 0+0io 26pf+0w % time gfortran-fsf-6 -c -g -O1 -fbounds-check pr55585.f90 4.470u 0.159s 0:04.64 99.5% 0+0k 0+0io 5pf+0w % time gfortran-fsf-7 -c -g -O1 -fbounds-check pr55585.f90 4.344u 0.167s 0:04.53 99.3% 0+0k 0+0io 4pf+0w % time gfortran -c -g -O1 -fbounds-check pr55585.f90 gfortran-fsf-6 is gcc version 6.5.0. So the "significant slowdowns at -O1 -fbounds-check" seems to have been fixed since at least 6.5. Closing.
[Bug middle-end/89934] [8 Regression] ICE on a call with fewer arguments to strncpy declared without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934 Martin Sebor changed: What|Removed |Added Summary|[9 Regression] ICE on a |[8 Regression] ICE on a |call with fewer arguments |call with fewer arguments |to strncpy declared without |to strncpy declared without |prototype |prototype Known to fail||8.3.0 --- Comment #7 from Martin Sebor --- Fixed in GCC 9 in r270152.
[Bug middle-end/89934] [9 Regression] ICE on a call with fewer arguments to strncpy declared without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934 --- Comment #6 from Martin Sebor --- Author: msebor Date: Thu Apr 4 21:59:49 2019 New Revision: 270152 URL: https://gcc.gnu.org/viewcvs?rev=270152=gcc=rev Log: PR middle-end/89934 - ICE on a call with fewer arguments to strncpy declared without prototype gcc/ChangeLog: PR middle-end/89934 * gimple-ssa-warn-restrict.c (builtin_access::builtin_access): Bail out if the number of arguments is less than expected. gcc/testsuite/ChangeLog: PR middle-end/89934 * gcc.dg/Wrestrict-19.c: New test. * gcc.dg/Wrestrict-5.c: Add comment. Remove unused code. Added: trunk/gcc/testsuite/gcc.dg/Wrestrict-19.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-warn-restrict.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/Wrestrict-5.c
[Bug libstdc++/89979] subtract_with_carry_engine incorrect carry flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89979 --- Comment #1 from Christoph Conrads --- There is no attachment with the preprocessed code demonstrating the problem because the this code is 1.2 MB large.
[Bug libstdc++/89979] New: subtract_with_carry_engine incorrect carry flag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89979 Bug ID: 89979 Summary: subtract_with_carry_engine incorrect carry flag Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: g...@christoph-conrads.name Target Milestone: --- Created attachment 46090 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46090=edit The initial state in combination with the incorrect carry computation makes the PRNG enter the unescapable all zero state. The carry inside `std::subtract_with_carry_engine` is computed incorrectly if word_size == std::numeric_limits::digits. The bug can be triggered neither by std::ranlux24 nor by std::ranlux48. The bug occurs with GCC 7.3.0, GCC 8.2.0, and Clang when using the GNU Standard C++ Library shipping with GCC 7.3.0. $ gcc --version gcc (Gentoo 7.3.0-r3 p1.4) 7.3.0 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. $ g++-7.3.0 -Wextra -Wall -std=c++11 -pedantic -v -save-temps ~/libstdcxx-swc-bug.cpp Using built-in specs. COLLECT_GCC=g++-7.3.0 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-7.3.0-r3/work/gcc-7.3.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/7.3.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/7.3.0/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 7.3.0-r3 p1.4' --disable-esp --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --disable-multilib --with-multilib-list=m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx --enable-vtable-verify --enable-libvtv --enable-lto --without-isl --enable-libsanitizer --enable-default-pie --enable-default-ssp Thread model: posix gcc version 7.3.0 (Gentoo 7.3.0-r3 p1.4) COLLECT_GCC_OPTIONS='-Wextra' '-Wall' '-std=c++11' '-Wpedantic' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus -E -quiet -v -D_GNU_SOURCE /home/starfish/libstdcxx-swc-bug.cpp -mtune=generic -march=x86-64 -std=c++11 -Wextra -Wall -Wpedantic -fpch-preprocess -o libstdcxx-swc-bug.ii ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/x86_64-pc-linux-gnu /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/g++-v7/backward /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-Wextra' '-Wall' '-std=c++11' '-Wpedantic' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/libexec/gcc/x86_64-pc-linux-gnu/7.3.0/cc1plus -fpreprocessed libstdcxx-swc-bug.ii -quiet -dumpbase libstdcxx-swc-bug.cpp -mtune=generic -march=x86-64 -auxbase libstdcxx-swc-bug -Wextra -Wall -Wpedantic -std=c++11 -version -o libstdcxx-swc-bug.s GNU C++11 (Gentoo 7.3.0-r3 p1.4) version 7.3.0 (x86_64-pc-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++11 (Gentoo 7.3.0-r3 p1.4) version 7.3.0 (x86_64-pc-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.2, MPFR version 3.1.6, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 09ac773f85349e020b5b36ead38f9924 COLLECT_GCC_OPTIONS='-Wextra' '-Wall' '-std=c++11' '-Wpedantic' '-v' '-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/as -v --64 -o libstdcxx-swc-bug.o libstdcxx-swc-bug.s GNU assembler version 2.30.0 (x86_64-pc-linux-gnu) using BFD
[Bug tree-optimization/89582] Suboptimal code generated for floating point struct in -O3 compare to -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89582
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
--- Comment #7 from Jeffrey A. Law ---
The same value in different locations (say an integer register and fp register)
is represented as the PARALLEL of the two locations. Various ports do this
already.
The value of the expression can also be a @code{parallel} RTX@. This is
used when an argument is passed in multiple locations. The mode of the
@code{parallel} should be the mode of the entire argument. The
@code{parallel} holds any number of @code{expr_list} pairs; each one
describes where part of the argument is passed. In each
@code{expr_list} the first operand must be a @code{reg} RTX for the hard
register in which to pass this part of the argument, and the mode of the
register RTX indicates how large this part of the argument is. The
second operand of the @code{expr_list} is a @code{const_int} which gives
the offset in bytes into the entire argument of where this part starts.
As a special exception the first @code{expr_list} in the @code{parallel}
RTX may have a first operand of zero. This indicates that the entire
argument is also stored on the stack.
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929 --- Comment #10 from Nikolay Bogoychev --- (In reply to H.J. Lu from comment #9) > (In reply to Martin Liška from comment #8) > > Ok, let me first focus on the functional part of the patch. > > If I'm correct feature_list in get_builtin_code_for_version function should > > be basically aligned with isa_names_table in fold_builtin_cpu. Difference is > > following: > > > > +"avx5124fmaps" > > +"avx5124vnniw" > > +"avx512bitalg" > > +"avx512bw" > > +"avx512cd" > > +"avx512dq" > > +"avx512er" > > +"avx512ifma" > > +"avx512pf" > > +"avx512vbmi" > > +"avx512vbmi2" > > +"avx512vl" > > +"avx512vnni" > > +"avx512vpopcntdq" > > +"cmov" > > +"gfni" > > +"vpclmulqdq" > > > > Adding that should be possible, but one needs to define a priorities of > > these as seen here: > > > > ``` > > /* Priority of i386 features, greater value is higher priority. This is > > used to decide the order in which function dispatch must happen. For > > instance, a version specialized for SSE4.2 should be checked for > > dispatch > > before a version for SSE3, as SSE4.2 implies SSE3. */ > > enum feature_priority > > ``` > > > > H.J. can you please help me with the priorities? > > What do we gain with these extra target attributes for function > multiversioning? Hey, tl;dr We are able to target specific processors and not crash on Knight's Mill and Knight's landing. The problem is that AVX-512 has a 1 subversions https://en.wikipedia.org/wiki/AVX-512#CPUs_with_AVX-512 Some of them completely overlap (eg VL DQ and BW), however others are limited to specific processors. We are developing an application that uses a lot of intrinsics and we are targetting several different architectures. We rely on instructions that are included in AVX512BW and if we target the closest available working thing (AVX512F), we crash with illegal instruction on Knight's Landing and Knight's Mill processors (which should use the AVX2 codepath instead). We are also about to add some VNNI code for upcoming Intel processors and we would need a function version for those, because AVX512F is too broad. Cheers, Nick
[Bug fortran/84382] add command-line options -std=gnu2003 and -std=gnu2008 for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382 janus at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW --- Comment #2 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #1) > Fortran is not C! True. Fortran is not C is not C++. The main difference wrt this PR is possibly that the latter two have a large enough user base, so that a significant amount of people actually use the options mentioned above. > WTF? Giving that questions back to you, Dominique: WTF? Which problem do you think you solve by closing PRs that have not been fixed?
[Bug fortran/41650] [Cleanup] Use gfc_expr_attr in resolve_allocate_expr/resolve_deallocate_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41650 janus at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|NEW Resolution|INVALID |--- --- Comment #4 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #3) > > Is this still valid? Definitely still valid. Apart from a pure cleanup, there might even be cases where 'is_abstract' is not set correctly (should be checked!). > No answer, closing as INVALID. Please leave bugs alone that you don't understand. Reopening ...
[Bug target/89399] [7/8 Regression] ICE: RTL check: expected code 'set', 'clobber' or 'clobber_high', have 'parallel' in combine_reaching_defs, at ree.c:783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89399 Jeffrey A. Law changed: What|Removed |Added Summary|[7/8/9 Regression] ICE: RTL |[7/8 Regression] ICE: RTL |check: expected code 'set', |check: expected code 'set', |'clobber' or|'clobber' or |'clobber_high', have|'clobber_high', have |'parallel' in |'parallel' in |combine_reaching_defs, at |combine_reaching_defs, at |ree.c:783 |ree.c:783 --- Comment #7 from Jeffrey A. Law --- Fixed on the trunk. Backporting to the release branches would certainly be possible if someone were to trip over this issue in real world situations.
[Bug target/89399] [7/8/9 Regression] ICE: RTL check: expected code 'set', 'clobber' or 'clobber_high', have 'parallel' in combine_reaching_defs, at ree.c:783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89399 --- Comment #6 from Jeffrey A. Law --- Author: law Date: Thu Apr 4 20:52:16 2019 New Revision: 270151 URL: https://gcc.gnu.org/viewcvs?rev=270151=gcc=rev Log: PR rtl-optimization/89399 * ree.c (combine_set_extension): Use single_set rather than digging into PATTERN for items on the candidate list. (combine_reaching_defs): Likewise. PR rtl-optimization/89399 * gcc.c-torture/compile/pr89399.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr89399.c Modified: trunk/gcc/ChangeLog trunk/gcc/ree.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/89904] [9 regression] ICE in gfortran starting with r270045
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89904 --- Comment #21 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #20) > Patch here: > > https://gcc.gnu.org/ml/fortran/2019-04/msg3.html Patch applied to trunk so far. Unfortunately, I had the wrong PR in the ChangeLog (PR89004). :-( Sorry for that. I should get that right for the backports. Will wait for a couple of days to see if there is further fallout.
[Bug c++/89978] New: Extraneous template keyword not rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89978
Bug ID: 89978
Summary: Extraneous template keyword not rejected
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: vincent.lextrait at gmail dot com
Target Milestone: ---
The compiler does not reject the following:
struct A{
void f(){}
};
struct B{
static A& n(){
return *new A();
}
};
template
struct C{
void g(){
T::n().template f();
}
};
int main(){
(new C())->g();
}
Function A::f is not template.
[Bug d/89004] mtype.c:2329:33: error: comparison of integer expressions of different signedness: ‘int’ and ‘size_t’ {aka ‘long unsigned int’} [-Werror=sign-compare]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89004 --- Comment #2 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Thu Apr 4 20:38:33 2019 New Revision: 270150 URL: https://gcc.gnu.org/viewcvs?rev=270150=gcc=rev Log: 2019-04-04 Harald Anlauf PR fortran/89004 * check.c (gfc_check_transfer): Reject procedures as actual arguments for SOURCE and MOLD of TRANSFER intrinsic. PR fortran/89004 * gfortran.dg/pr85797.f90: Adjust testcase. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr85797.f90
[Bug target/89967] Inefficient code generation for vld2q_lane_u8 under aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89967 Andrew Pinski changed: What|Removed |Added Keywords||ra Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-04 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- There are two seperate issues which is causing the inefficient code. One is the first set of mov should really be movi; I don't know why the constant formation was moved out of the loop. The second issue is the register allocation is not doing a good job for OImode, there are some clobber rtl there which might be getting in the way; I have not looked into or understand why the clobber rtl is needed.
[Bug c++/87366] [7/8/9 Regression] SFINAE trait as template parameter causes incorrect application of trait to other areas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87366 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/89877] [ARC] miscompilation due to missing cc clobber in longlong.h: add_ssaaaa()/sub_ddmmss()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89877 Vineet Gupta changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Vineet Gupta --- Marking as fixed, please backport to gcc-8-stable ! Thx, -Vineet
[Bug debug/89905] gcc generates wrong debug information at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89905 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=78685 --- Comment #3 from Eric Gallager --- (In reply to Richard Biener from comment #1) > > Doing the suggested resetting "fixes" the issue (gdb prints ). > "fixes" being in scare-quotes because that really just turns it into bug 78685
[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929 --- Comment #9 from H.J. Lu --- (In reply to Martin Liška from comment #8) > Ok, let me first focus on the functional part of the patch. > If I'm correct feature_list in get_builtin_code_for_version function should > be basically aligned with isa_names_table in fold_builtin_cpu. Difference is > following: > > +"avx5124fmaps" > +"avx5124vnniw" > +"avx512bitalg" > +"avx512bw" > +"avx512cd" > +"avx512dq" > +"avx512er" > +"avx512ifma" > +"avx512pf" > +"avx512vbmi" > +"avx512vbmi2" > +"avx512vl" > +"avx512vnni" > +"avx512vpopcntdq" > +"cmov" > +"gfni" > +"vpclmulqdq" > > Adding that should be possible, but one needs to define a priorities of > these as seen here: > > ``` > /* Priority of i386 features, greater value is higher priority. This is > used to decide the order in which function dispatch must happen. For > instance, a version specialized for SSE4.2 should be checked for > dispatch > before a version for SSE3, as SSE4.2 implies SSE3. */ > enum feature_priority > ``` > > H.J. can you please help me with the priorities? What do we gain with these extra target attributes for function multiversioning?
[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883 Eric Gallager changed: What|Removed |Added Depends on|89936 | --- Comment #6 from Eric Gallager --- (In reply to Roland Illig from comment #5) > I wouldn't classify bug 89936 as trivial as it strongly recommends to write > a linter, and that might take a while. Especially since the GCC project > seems to avoid these consistency linters; at least that's my impression from > the last few years as the German translator. As I said in bug 89936, there > are quite a few inconsistencies in the messages that could easily be caught > by a linter. ok, removed Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89936 [Bug 89936] wrong punctuation in tree-profile.c
[Bug web/89964] Remove the "First, you must pick a product on which to enter a bug:" page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89964 --- Comment #3 from Eric Gallager --- I suggested splitting the bugzillas into 2 in bug 29304 comment 4 but Andrew seemed to think it was ok to keep them together
[Bug c/89968] attribute packed fails to reduce char vector member alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89968 --- Comment #2 from Andrew Pinski --- One problem is the order of the attributes applying here. vector_size applies after all the others as that is the order in the program.
[Bug c++/89966] [9 Regression] non-type template argument rejects sizeof operator result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89966 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-04 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug web/89964] Remove the "First, you must pick a product on which to enter a bug:" page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89964 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-04 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Eric Gallager --- Confirmed.
[Bug c++/89937] For example code, which is valid as either C or C++, optimization seems much better for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89937 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=64875 --- Comment #7 from Eric Gallager --- bug 64875 seems relevant here
[Bug c++/89948] [9 Regression] ICE in fold_convert_loc, at fold-const.c:2430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89948 Jason Merrill changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-04 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug middle-end/89977] New: missing -Wstringop-overflow with an out-of-bounds int128_t range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89977
Bug ID: 89977
Summary: missing -Wstringop-overflow with an out-of-bounds
int128_t range
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
Additional testing of the patch for pr89957 exposed the following:
GCC diagnoses the buffer overflow in f() below but fails to diagnose the same
buffer overflow in g(). The get_range_info() function returns VR_VARYING for
the int128_t variable in g().
$ cat z.c && gcc -S -O2 -Wall -Wextra -fdump-tree-optimized=/dev/stdout z.c
char a[3];
__attribute__ ((noipa))
void f (int n)
{
if (n < 7)
n = 7;
__builtin_memset (a, 0, n);
}
__attribute__ ((noipa))
void g (__int128_t n)
{
if (n < 7)
n = 7;
__builtin_memset (a, 0, n);
}
z.c: In function ‘f’:
z.c:8:3: warning: ‘__builtin_memset’ forming offset [4, 7] is out of the bounds
[0, 3] of object ‘a’ with type ‘char[3]’ [-Warray-bounds]
8 | __builtin_memset (a, 0, n);
| ^~
z.c:1:6: note: ‘a’ declared here
1 | char a[3];
| ^
;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=1)
__attribute__((noipa, noinline, noclone, no_icf))
f (int n)
{
long unsigned int _1;
[local count: 1073741824]:
n_3 = MAX_EXPR ;
_1 = (long unsigned int) n_3;
__builtin_memset (, 0, _1); [tail call]
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1910, cgraph_uid=2, symbol_order=2)
__attribute__((noipa, noinline, noclone, no_icf))
g (__int128 n)
{
long unsigned int _1;
[local count: 1073741824]:
n_3 = MAX_EXPR ;
_1 = (long unsigned int) n_3;
__builtin_memset (, 0, _1); [tail call]
return;
}
[Bug middle-end/89975] Compile-time hog w/ large values of --param uninlined-function-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89975 --- Comment #1 from Andrew Pinski --- The param is there to limit compile time after all.
[Bug target/89955] riscv.h improperly defines STARTFILE_PREFIX_SPEC spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955 Jim Wilson changed: What|Removed |Added CC||wilson at gcc dot gnu.org --- Comment #2 from Jim Wilson --- There should not be a problem working with the sysroot, because as Andreas mentioned, the paths are relative to the sysroot base. This does require cooperation from the C library though. If the C library isn't installing itself into the same directories that the compiler is searching, then you will have problems. You can either fix the C library or fix gcc, so that the set of dirs used are the same. Or add a bunch of symbolic links to connect the two together. The scheme specified by STARTFILE_PREFIX_SPEC is a reasonable one. I don't think it is officially documented as part of the psABI, but I think it makes sense for this scheme to be the default. linux glibc already has support to install in the right dirs, and presumably the freebsd C library is also installing in the right dirs. This support also works for embedded elf toolchains, though in practice it doesn't get used because we use the multilib support for newlib, and hence we end up using multilib paths instead of the paths specified by STARTFILE_PREFIX_SPEC. But it is there if someone wants to use it. I think if you don't want to use this scheme, and won't be supporting more than one ABI, then you should just override it for your OS. If you can't override it for your OS, then we would have to copy this value into linux.h, freebsd.h, and elf.h. Oh, and maybe rtems.h too. That would be a little inconvenient.
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #39 from Iain Sandoe --- (In reply to Erik Schnetter from comment #38) > (In reply to Iain Sandoe from comment #36) > > (In reply to Jürgen Reuter from comment #35) > > > The latest fix doesn't work. It fails at the darwin-driver.c. So yes, all > > > the files mentioned before have to be modified, asan_mac.cc, > > > sanitizer_mac.cc, > > > sanitizer_platform_limits_posix.cc, darwin-driver.c > > > > that's not how fix includes work; > > the idea is to make a change such that the includes can be used "normally" > > (which isn't 'modify every use site' ;) ) > > > > grep says that ucred.h is included from a *lot* of places in the SDK, so > > "just fixing bootstrap" isn't enough, we need a fix that works when building > > user code too. > > I originally assumed that fixincluded files would come first in the include > search path, so that correcting the offending file prevents all problems. > That doesn't seem to be the case -- only files included from user code seem > to see the fixincluded files, whereas system files don't see them. Is this > correct? If so, that certainly makes it difficult to correct a problem, > since this would require all header files that (transitively) include the > offending header file also need to be fixincluded. I'm sure I misunderstand > something here. no, you haven't missed anything - have you examined the output in gcc/includes-fixed and checked that the changes you expect have been made? you can examine the order of the search paths for the includes (look at the output of gcc -v) > > I note that there is __APPLE_API_STRICT_CONFORMANCE which gates the > > __APPLE_ABI_UNSTABLE .. perhaps this should be investigated? > > I missed this. I'll have a look.
[Bug middle-end/89970] [8/9 Regression] ICE in dispatch_function_versions, at config/i386/i386.c:32347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89970 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-04 Component|c |middle-end Target Milestone|--- |8.4 Ever confirmed|0 |1 --- Comment #2 from Uroš Bizjak --- Confirmed as a problem in the middle-end.
[Bug c/89970] [8/9 Regression] ICE in dispatch_function_versions, at config/i386/i386.c:32347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89970 --- Comment #1 from Uroš Bizjak --- Hits assert in i386.c, dispatch_function_versions: /* At least one more version other than the default. */ num_versions = fndecls->length (); gcc_assert (num_versions >= 2); But... this just asserts on the data, passed via target hook from middle-end.
[Bug rtl-optimization/89528] Wrong debug info generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89528 --- Comment #4 from Alexandre Oliva --- Created attachment 46089 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46089=edit candidate patch Here's what I'm testing
[Bug c++/89976] New: missing uninitialized warning: laundering via passing object through a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89976
Bug ID: 89976
Summary: missing uninitialized warning: laundering via passing
object through a function
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nok.raven at gmail dot com
Target Milestone: ---
// case 1 - https://godbolt.org/z/02zu_3
struct X
{
int x, y;
X() : y(0) {}
};
X foo()
{
X x;
return x;
}
int main()
{
X x = foo();
return x.x;
}
// case 2 - https://godbolt.org/z/ev4Fs4
struct X
{
int x;
};
struct Y : X
{
int y;
Y() {}
};
Y foo()
{
Y x;
return x;
}
int main()
{
Y x = foo();
return x.x;
}
// case 3 - https://godbolt.org/z/LZvtcU
struct X
{
int x;
};
struct Y
{
Y() {}
};
struct Z : X, Y
{
int z;
};
Z foo()
{
Z x;
return x;
}
int main()
{
Z x = foo();
return x.x;
}
[Bug middle-end/89975] New: Compile-time hog w/ large values of --param uninlined-function-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89975 Bug ID: 89975 Summary: Compile-time hog w/ large values of --param uninlined-function-insns Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: compile-time-hog Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- 9.0.0-alpha20190331 snapshot (r270048) takes inordinate, though finite, time to compile gcc/testsuite/g++.dg/warn/Wzero-as-null-pointer-constant-2.C w/ -O1 --param uninlined-function-insns=20. perf top: 60.53% cc1plus [.] estimate_calls_size_and_time 10.24% cc1plus [.] estimate_size_after_inlining 5.80% cc1plus [.] sreal::operator/ 4.95% cc1plus [.] predicate::evaluate 4.63% cc1plus [.] profile_count::to_sreal_scale 3.49% cc1plus [.] cgraph_edge::sreal_frequency 3.27% cc1plus [.] update_callee_keys 2.50% cc1plus [.] can_inline_edge_by_limits_p 1.52% cc1plus [.] sreal::operator* 0.69% cc1plus [.] sreal::operator+ 0.60% cc1plus [.] cgraph_node::get_availability 0.35% cc1plus [.] want_inline_small_function_p 0.27% cc1plus [.] sreal::shift_right 0.18% cc1plus [.] cgraph_edge::maybe_hot_p 0.18% cc1plus [.] edge_badness 0.17% cc1plus [.] symtab_node::ultimate_alias_target_1 and much later: 68.20% cc1plus [.] df_live_bb_local_compute 10.12% cc1plus [.] df_live_set_all_dirty 7.83% libc-2.29.so [.] memset 7.46% cc1plus [.] bitmap_set_bit 2.07% cc1plus [.] df_live_alloc 1.51% cc1plus [.] df_rd_transfer_function 1.06% cc1plus [.] df_count_refs 0.62% cc1plus [.] bitmap_elt_clear_from 0.40% cc1plus [.] bitmap_clear 0.20% cc1plus [.] df_live_local_compute 0.15% cc1plus [.] df_reorganize_refs_by_reg 0.12% cc1plus [.] move_loop_invariants 0.10% cc1plus [.] df_worklist_dataflow 0.05% cc1plus [.] bitmap_bit_p 0.03% cc1plus [.] may_trap_p_1 0.03% cc1plus [.] et_splay 0.02% cc1plus [.] df_rd_simulate_one_insn 0.02% cc1plus [.] bitmap_copy Is this something to expect w/ large values of --param uninlined-function-insns?
[Bug c++/89923] printf format check and char8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923 --- Comment #3 from Florian Weimer --- But the precedent with wchar_t is that the type of the format string determines the type of the %s arguments. I'm not sure if that's a good precedent, but it's what we have today.
[Bug c++/89923] printf format check and char8_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89923 --- Comment #2 from Tom Honermann --- I think my preferred fix to this is to introduce new length modifiers for the "%s" conversion specifier for all of char8_t, char16_t, and char32_t.
[Bug c++/89974] New: ICE on a definition of a non-type specialization on a struct object with pointer to member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89974
Bug ID: 89974
Summary: ICE on a definition of a non-type specialization on a
struct object with pointer to member function
Product: gcc
Version: 9.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: ---
The following C++ 2a program causes an ICE. An equivalent program using a
pointer to member data compiles successfully. I came across this while testing
my patch for pr47488, pr89833, and pr89876.
$ cat z.C && gcc -c -O2 -Wall -Wextra -std=c++2a z.C
struct A { void (A::*p)(); };
template struct X { };
X x;
z.C:3:9: internal compiler error: canonical types differ for identical types
‘void (A::*)()’ and ‘void (A::*)()’
3 | X x;
| ^
0xb7ba72 comptypes(tree_node*, tree_node*, int)
/src/gcc/git-svn/gcc/cp/typeck.c:1479
0x9b0829 find_substitution
/src/gcc/git-svn/gcc/cp/mangle.c:692
0x9b8840 write_type
/src/gcc/git-svn/gcc/cp/mangle.c:2054
0x9c10a7 write_template_arg_literal
/src/gcc/git-svn/gcc/cp/mangle.c:3357
0x9bd561 write_expression
/src/gcc/git-svn/gcc/cp/mangle.c:2890
0x9bfdcd write_expression
/src/gcc/git-svn/gcc/cp/mangle.c:3150
0x9bfdcd write_expression
/src/gcc/git-svn/gcc/cp/mangle.c:3150
0x9c572f mangle_template_parm_object(tree_node*)
/src/gcc/git-svn/gcc/cp/mangle.c:4267
0xa8c265 get_template_parm_object
/src/gcc/git-svn/gcc/cp/pt.c:6702
0xa8e048 convert_nontype_argument
/src/gcc/git-svn/gcc/cp/pt.c:7160
0xa91795 convert_template_argument
/src/gcc/git-svn/gcc/cp/pt.c:8070
0xa93370 coerce_template_parms
/src/gcc/git-svn/gcc/cp/pt.c:8547
0xa93a65 coerce_innermost_template_parms
/src/gcc/git-svn/gcc/cp/pt.c:8666
0xa96177 lookup_template_class_1
/src/gcc/git-svn/gcc/cp/pt.c:9357
0xa9885d lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
/src/gcc/git-svn/gcc/cp/pt.c:9716
0xb240c0 finish_template_type(tree_node*, tree_node*, int)
/src/gcc/git-svn/gcc/cp/semantics.c:3312
0xa223e1 cp_parser_template_id
/src/gcc/git-svn/gcc/cp/parser.c:16479
0xa2f9be cp_parser_class_name
/src/gcc/git-svn/gcc/cp/parser.c:23274
0xa0d6d7 cp_parser_qualifying_entity
/src/gcc/git-svn/gcc/cp/parser.c:6693
0xa0c6cd cp_parser_nested_name_specifier_opt
/src/gcc/git-svn/gcc/cp/parser.c:6379
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/89973] [9 Regression] ICE in check_address_or_pointer_of_packed_member, at c-family/c-warn.c:2769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89973 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-04-04 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |9.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Will fix.
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #38 from Erik Schnetter --- (In reply to Iain Sandoe from comment #36) > (In reply to Jürgen Reuter from comment #35) > > The latest fix doesn't work. It fails at the darwin-driver.c. So yes, all > > the files mentioned before have to be modified, asan_mac.cc, > > sanitizer_mac.cc, > > sanitizer_platform_limits_posix.cc, darwin-driver.c > > that's not how fix includes work; > the idea is to make a change such that the includes can be used "normally" > (which isn't 'modify every use site' ;) ) > > grep says that ucred.h is included from a *lot* of places in the SDK, so > "just fixing bootstrap" isn't enough, we need a fix that works when building > user code too. I originally assumed that fixincluded files would come first in the include search path, so that correcting the offending file prevents all problems. That doesn't seem to be the case -- only files included from user code seem to see the fixincluded files, whereas system files don't see them. Is this correct? If so, that certainly makes it difficult to correct a problem, since this would require all header files that (transitively) include the offending header file also need to be fixincluded. I'm sure I misunderstand something here. > I note that there is __APPLE_API_STRICT_CONFORMANCE which gates the > __APPLE_ABI_UNSTABLE .. perhaps this should be investigated? I missed this. I'll have a look. -erik
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #37 from Erik Schnetter --- (In reply to Jürgen Reuter from comment #35) > The latest fix doesn't work. It fails at the darwin-driver.c. So yes, all > the files mentioned before have to be modified, asan_mac.cc, > sanitizer_mac.cc, > sanitizer_platform_limits_posix.cc, darwin-driver.c Did you regenerate the autogenerated fixinclude files? The patch only contains the manual changes (according to GCC's patch submission guidelines). You need to run "./genincludes" (?) in the "fixinclude" directory. -erik
[Bug fortran/55591] strict-aliasing & Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55591
--- Comment #8 from Dominique d'Humieres ---
Testing the updated patch
--- ../_clean/gcc/fortran/options.c 2019-03-11 15:11:11.0 +0100
+++ gcc/fortran/options.c 2019-04-04 18:55:50.0 +0200
@@ -166,6 +166,8 @@ gfc_init_options (unsigned int decoded_o
set_default_std_flags ();
+ flag_strict_aliasing = -1;
+
/* Initialize cpp-related options. */
gfc_cpp_init_options (decoded_options_count, decoded_options);
gfc_diagnostics_init ();
@@ -266,6 +268,10 @@ gfc_post_options (const char **pfilename
sorry ("%<-fexcess-precision=standard%> for Fortran");
flag_excess_precision_cmdline = EXCESS_PRECISION_FAST;
+ /* By default use strict-aliasing semantics. */
+ if (flag_strict_aliasing == -1)
+flag_strict_aliasing = 1;
+
/* Fortran allows associative math - but we cannot reassociate if
we want traps or signed zeros. Cf. also flag_protect_parens. */
if (flag_associative_math == -1)
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #36 from Iain Sandoe --- (In reply to Jürgen Reuter from comment #35) > The latest fix doesn't work. It fails at the darwin-driver.c. So yes, all > the files mentioned before have to be modified, asan_mac.cc, > sanitizer_mac.cc, > sanitizer_platform_limits_posix.cc, darwin-driver.c that's not how fix includes work; the idea is to make a change such that the includes can be used "normally" (which isn't 'modify every use site' ;) ) grep says that ucred.h is included from a *lot* of places in the SDK, so "just fixing bootstrap" isn't enough, we need a fix that works when building user code too. I note that there is __APPLE_API_STRICT_CONFORMANCE which gates the __APPLE_ABI_UNSTABLE .. perhaps this should be investigated?
[Bug fortran/87919] Incorrect fortran handling of -fno-* options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87919 --- Comment #4 from Dominique d'Humieres --- What is the status of this PR? Is it FIXED or not?
[Bug c++/89973] New: [9 Regression] ICE in check_address_or_pointer_of_packed_member, at c-family/c-warn.c:2769
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89973 Bug ID: 89973 Summary: [9 Regression] ICE in check_address_or_pointer_of_packed_member, at c-family/c-warn.c:2769 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20190113 and 20190120 : $ cat z1.cc constexpr int a(); template constexpr void *b = a(); $ g++-9-20190331 -c z1.cc z1.cc:2:43: internal compiler error: Segmentation fault 2 | template constexpr void *b = a(); | ^ 0xb849bf crash_signal ../../gcc/toplev.c:326 0x797a68 check_address_or_pointer_of_packed_member ../../gcc/c-family/c-warn.c:2769 0x797a68 check_and_warn_address_or_pointer_of_packed_member ../../gcc/c-family/c-warn.c:2875 0x7327ba convert_for_assignment ../../gcc/cp/typeck.c:9094 0x732ad2 convert_for_initialization(tree_node*, tree_node*, tree_node*, int, impl_conv_rhs, tree_node*, int, int) ../../gcc/cp/typeck.c:9190 0x738828 digest_init_r ../../gcc/cp/typeck2.c:1272 0x73a150 digest_init_flags(tree_node*, tree_node*, int, int) ../../gcc/cp/typeck2.c:1285 0x73a150 store_init_value(tree_node*, tree_node*, vec**, int) ../../gcc/cp/typeck2.c:824 0x640d5d check_initializer ../../gcc/cp/decl.c:6523 0x642d5c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) ../../gcc/cp/decl.c:7090 0x6be6b9 cp_parser_init_declarator ../../gcc/cp/parser.c:20525 0x6c0c94 cp_parser_single_declaration ../../gcc/cp/parser.c:28266 0x6c0e6c cp_parser_template_declaration_after_parameters ../../gcc/cp/parser.c:27858 0x6c1477 cp_parser_explicit_template_declaration ../../gcc/cp/parser.c:28104 0x6c1477 cp_parser_template_declaration_after_export ../../gcc/cp/parser.c:28123 0x6c3fe9 cp_parser_declaration ../../gcc/cp/parser.c:13185 0x6c462e cp_parser_translation_unit ../../gcc/cp/parser.c:4698 0x6c462e c_parse_file() ../../gcc/cp/parser.c:41180 0x781cf0 c_common_parse_file() ../../gcc/c-family/c-opts.c:1156
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864 --- Comment #35 from Jürgen Reuter --- The latest fix doesn't work. It fails at the darwin-driver.c. So yes, all the files mentioned before have to be modified, asan_mac.cc, sanitizer_mac.cc, sanitizer_platform_limits_posix.cc, darwin-driver.c
[Bug fortran/89844] CFI_setpointer produces wrong descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89844 --- Comment #3 from Dominique d'Humieres --- > This PR seems also fixed by revision r270037. Is a new test needed? If yes, would it help if I do the packaging?
[Bug c/89972] New: [8/9 Regression] ICE in expand_call, at calls.c:4229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89972
Bug ID: 89972
Summary: [8/9 Regression] ICE in expand_call, at calls.c:4229
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with gcc-8 (before 20180525) :
$ cat z1.c
struct S {
long a[0] __attribute__ ((aligned (32)));
};
void foo ()
{
struct S b;
f (8.0L, b);
}
$ gcc-9-20190331 -c z1.c
z1.c: In function 'foo':
z1.c:7:3: warning: implicit declaration of function 'f'
[-Wimplicit-function-declaration]
7 | f (8.0L, b);
| ^
z1.c:7:3: note: the ABI for passing parameters with 32-byte alignment has
changed in GCC 4.6
7 | f (8.0L, b);
| ^~~
during RTL pass: expand
z1.c:7:3: internal compiler error: in expand_call, at calls.c:4229
0x6b5fb5 expand_call(tree_node*, rtx_def*, int)
../../gcc/calls.c:4227
0x7bd95e expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
../../gcc/expr.c:11032
0x6c6e9a expand_expr
../../gcc/expr.h:279
0x6c6e9a expand_call_stmt
../../gcc/cfgexpand.c:2724
0x6c6e9a expand_gimple_stmt_1
../../gcc/cfgexpand.c:3691
0x6c6e9a expand_gimple_stmt
../../gcc/cfgexpand.c:3850
0x6cba07 expand_gimple_basic_block
../../gcc/cfgexpand.c:5886
0x6ce096 execute
../../gcc/cfgexpand.c:6509
[Bug fortran/89969] [OPENACC] private clause does not work with fortran automatic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89969 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |WAITING Last reconfirmed||2019-04-04 CC||cesar at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Cannot test the problem on my mac.
[Bug c++/89937] For example code, which is valid as either C or C++, optimization seems much better for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89937 --- Comment #6 from Walt Karas --- Yes, very sorry, I didn't realize inline was so different in C, and I also didn't read the generated machine code carefully enough. It does seem extremely surprising that, for C, the body of an inline function is ignored without any warning.
[Bug c/89971] New: [8/9 Regression] ICE: unspellable token PADDING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89971 Bug ID: 89971 Summary: [8/9 Regression] ICE: unspellable token PADDING Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Started with gcc-8 (before 20180525) : $ cat z1.c #define a(...) int b /##__VA_OPT__(c); a() $ gcc-9-20190331 -c z1.c z1.c:2:1: internal compiler error: unspellable token PADDING 2 | a() | ^ 0x6543ea c_cpp_diagnostic(cpp_reader*, cpp_diagnostic_level, cpp_warning_reason, rich_location*, char const*, __va_list_tag (*) [1]) ../../gcc/c-family/c-common.c:6319 0x1291f42 cpp_diagnostic ../../libcpp/errors.c:75 0x12920c6 cpp_error(cpp_reader*, cpp_diagnostic_level, char const*, ...) ../../libcpp/errors.c:89 0x129b0bd cpp_spell_token(cpp_reader*, cpp_token const*, unsigned char*, bool) ../../libcpp/lex.c:3298 0x129ca87 cpp_token_as_text(cpp_reader*, cpp_token const*) ../../libcpp/lex.c:3314 0x12a210a paste_tokens ../../libcpp/macro.c:821 0x12a5590 paste_all_tokens ../../libcpp/macro.c:898 0x12a5590 cpp_get_token_1 ../../libcpp/macro.c:2712 0x664bed c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) ../../gcc/c-family/c-lex.c:405 0x5fcc60 c_lex_one_token ../../gcc/c/c-parser.c:249 0x6094f4 c_parser_peek_token(c_parser*) ../../gcc/c/c-parser.c:436 0x6094f4 c_parser_next_token_is ../../gcc/c/c-parser.h:167 0x6094f4 c_parser_direct_declarator_inner ../../gcc/c/c-parser.c:3790 0x61d8d1 c_parser_declaration_or_fndef ../../gcc/c/c-parser.c:1999 0x623a53 c_parser_external_declaration ../../gcc/c/c-parser.c:1653 0x624519 c_parser_translation_unit ../../gcc/c/c-parser.c:1534 0x624519 c_parse_file() ../../gcc/c/c-parser.c:19854 0x66ba20 c_common_parse_file() ../../gcc/c-family/c-opts.c:1156
[Bug c/89970] New: [8/9 Regression] ICE in dispatch_function_versions, at config/i386/i386.c:32347
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89970
Bug ID: 89970
Summary: [8/9 Regression] ICE in dispatch_function_versions, at
config/i386/i386.c:32347
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started with gcc-8 (before 20180525) :
$ cat z1.c
__attribute__((target_clones ("default", "default")))
void f () {}
$ gcc-7 -c z1.c
$
$ gcc-9-20190331 -c z1.c
during IPA pass: targetclone
z1.c: In function 'f.resolver':
z1.c:2:1: internal compiler error: in dispatch_function_versions, at
config/i386/i386.c:32347
2 | void f () {}
| ^~~~
0xd32d02 dispatch_function_versions
../../gcc/config/i386/i386.c:32347
0xd32d02 ix86_generate_version_dispatcher_body
../../gcc/config/i386/i386.c:32714
0x1219c66 create_dispatcher_calls
../../gcc/multiple_target.c:97
0x1219c66 ipa_target_clone
../../gcc/multiple_target.c:509
0x1219c66 execute
../../gcc/multiple_target.c:541
[Bug fortran/84382] add command-line options -std=gnu2003 and -std=gnu2008 for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84382 Dominique d'Humieres changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |WAITING Last reconfirmed||2019-04-04 Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Dominique d'Humieres --- Fortran is not C! WTF?
[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893 --- Comment #21 from 康 珊 --- All of the experiments were did in according to the build steps I just gave to you.
[Bug c++/65608] [meta-bug] friend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608 Bug 65608 depends on bug 65619, which changed state. Bug 65619 Summary: friend declaration with template template parameter not recognized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65619 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/65619] friend declaration with template template parameter not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65619 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED CC||paolo.carlini at oracle dot com Resolution|--- |FIXED --- Comment #3 from Paolo Carlini --- Done.
[Bug c++/65619] friend declaration with template template parameter not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65619 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Apr 4 15:49:30 2019 New Revision: 270146 URL: https://gcc.gnu.org/viewcvs?rev=270146=gcc=rev Log: 2019-04-04 Paolo Carlini PR c++/65619 * g++.dg/template/friend67.C: New. Added: trunk/gcc/testsuite/g++.dg/template/friend67.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961 --- Comment #3 from Cristian Morales Vega --- I have just took a look inside one of the intermediate format .gcov files and didn't see any "current_working_directory". There is a full path "file" variable though. Not sure if that's what you mean. In any case anything inside the .gcov files would not solve my issue. My problem is that all the .gcov files are being created in the same directory and the .gcov files themselves get overwritten. So I have ./CMakeFiles/.dir/src/error.cpp.o ./CMakeFiles/.dir/src/error.cpp.gcda ./CMakeFiles/.dir/src/error.cpp.gcno ./test/CMakeFiles/catch_tests.dir/error.cpp.o ./test/CMakeFiles/catch_tests.dir/error.cpp.gcda ./test/CMakeFiles/catch_tests.dir/error.cpp.gcno And a single "error.cpp.gcda.gcov" file since cmake has run /usr/bin/gcov -x -i -o /CMakeFiles/.dir/src /CMakeFiles/cmake_target_name.dir/src/error.cpp.gcda and /usr/bin/gcov -x -i -o /test/CMakeFiles/catch_tests.dir /test/CMakeFiles/catch_tests.dir/error.cpp.gcda from the same directory, put all the files in a flat tarball and sent it to a CDash server. So I need the file names written to my hard drive to be different (i.e. -x to have effect).
[Bug rtl-optimization/89528] Wrong debug info generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89528 Alexandre Oliva changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |aoliva at gcc dot gnu.org --- Comment #3 from Alexandre Oliva --- DCE drops the dead call to j() after inserting debug temps that reference the return value of the call, but it fails to adjust/reset the debug temp. Looking into how to fix it...
[Bug debug/89530] Wrong debug informations for C array generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89530 --- Comment #10 from Alexandre Oliva --- We'd need to add VTA notes to addressable objects, that currently only get older var-tracking treatment. It's usually enough, because, being addressable, they can't really change locations, and, because of pointers and aliasing, VTA proper would be tricky for them. In this case, in which the dead assignments are through a reference to the object proper, rather than through a pointer, it wouldn't be too hard, but VTA is kind of all-or-nothing on a per-object basis. I don't have concrete plans to address this.
[Bug fortran/89969] New: [OPENACC] private clause does not work with fortran automatic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89969 Bug ID: 89969 Summary: [OPENACC] private clause does not work with fortran automatic array Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: abidh at codesourcery dot com Target Milestone: --- Please look at the test case below. It uses an automatic array in private clause. With -fopenacc and ptx offloading, the resultant executable crashes at run time with the following error: libgomp: cuStreamSynchronize error: an illegal memory access was encountered subroutine crash1(ngas) implicit none integer, intent(in ) :: ngas integer, dimension(ngas) :: automatic_array integer :: ilay !$acc parallel loop private(automatic_array) do ilay = 1 , ngas automatic_array(ilay) = ilay end do end subroutine crash1 program main implicit none integer :: ngas = 10 call crash1(ngas) end program main
[Bug c++/65608] [meta-bug] friend issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65608 Bug 65608 depends on bug 61327, which changed state. Bug 61327 Summary: Problem with friend template object https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61327 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/61327] Problem with friend template object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61327 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Paolo Carlini --- Done.
[Bug c++/61327] Problem with friend template object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61327 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Thu Apr 4 15:38:05 2019 New Revision: 270145 URL: https://gcc.gnu.org/viewcvs?rev=270145=gcc=rev Log: 2019-04-04 Paolo Carlini PR c++/61327 * g++.dg/cpp0x/friend4.C: New. * g++.dg/cpp0x/friend5.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/friend4.C trunk/gcc/testsuite/g++.dg/cpp0x/friend5.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #34 from Erik Schnetter ---
Here is an updated version of the patch that fixincludes both
and , and does not need to touch any
sources files in GCC any more:
Index: fixincludes/inclhack.def
===
--- fixincludes/inclhack.def (revision 270127)
+++ fixincludes/inclhack.def (working copy)
@@ -1298,6 +1298,69 @@ fix = {
};
/*
+ * macOS 10.14.4 uses the C _Atomic keyword in C++
+ * code, and this file is included by .
+ */
+fix = {
+hackname = darwin_sysctl3__Atomic;
+mach = "*-*-darwin18.5.*";
+files = sys/sysctl.h;
+select= "#include ";
+
+c_fix = wrap;
+
+c_fix_arg = <<- _EOArg_
+
+ #if defined(__cplusplus) && __cplusplus >= 201103L
+# define _Atomic volatile
+ #endif
+
+ _EOArg_;
+
+c_fix_arg = <<- _EOArg_
+
+ #if defined(__cplusplus) && __cplusplus >= 201103L
+ # undef _Atomic
+ #endif
+
+ _EOArg_;
+
+test_text = "#include \n";
+};
+
+
+/*
+ * macOS 10.14.4 uses the C _Atomic keyword in C++
+ * code.
+ */
+fix = {
+hackname = darwin_ucred__Atomic;
+mach = "*-*-darwin18.5.*";
+files = sys/ucred.h;
+select= "_Atomic";
+
+c_fix = wrap;
+
+c_fix_arg = <<- _EOArg_
+
+ #if defined(__cplusplus) && __cplusplus >= 201103L
+# define _Atomic volatile
+ #endif
+
+ _EOArg_;
+
+c_fix_arg = <<- _EOArg_
+
+ #if defined(__cplusplus) && __cplusplus >= 201103L
+ # undef _Atomic
+ #endif
+
+ _EOArg_;
+
+test_text = "#include \n";
+};
+
+/*
* For the AAB_darwin7_9_long_double_funcs fix to be useful,
* you have to not use "" includes.
*/
--
Erik Schnetter
http://www.perimeterinstitute.ca/personal/eschnetter/
[Bug debug/89529] Wrong debug info generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89529 --- Comment #4 from Alexandre Oliva --- Yeah, consumer issue, GDB can't deal with location views yet, so it can't tell apart the views just before the return from that at the return proper. It's actually a textbook situation of the kind that led me to introduce view numbering.
[Bug c/89968] attribute packed fails to reduce char vector member alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89968 Martin Sebor changed: What|Removed |Added Keywords||ABI, diagnostic See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=59220 --- Comment #1 from Martin Sebor --- See also pr59220 for a related bug.
[Bug c/89968] New: attribute packed fails to reduce char vector member alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89968
Bug ID: 89968
Summary: attribute packed fails to reduce char vector member
alignment
Product: gcc
Version: 9.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: ---
>From the following discussion: https://gcc.gnu.org/ml/gcc/2019-04/msg00030.html
The following test case shows that GCC fails to reduce the alignment of a char
vector member. Clang and ICC succeed and return the expected values from the
two functions (1088 and 64, respectively).
$ cat z.c && gcc -c -O2 -Wall -fdump-tree-optimized=/dev/stdout z.c
struct S
{
char c;
__attribute__ ((aligned (64), packed, vector_size (1024))) char v;
};
int f (void) { return sizeof (struct S); }
int g (void) { return __alignof__ (struct S); }
z.c:4:3: warning: ‘packed’ attribute ignored for field of type ‘char’
[-Wattributes]
4 | __attribute__ ((aligned (64), packed, vector_size (1024))) char v;
| ^
;; Function f (f, funcdef_no=0, decl_uid=1909, cgraph_uid=1, symbol_order=0)
f ()
{
[local count: 1073741824]:
return 2048; ;; Expected 1088
}
;; Function g (g, funcdef_no=1, decl_uid=1912, cgraph_uid=2, symbol_order=1)
g ()
{
[local count: 1073741824]:
return 1024; ;; Expected 64
}
[Bug gcov-profile/89961] When "--intermediate-format" is used "--preserve-paths"/"--hash-filenames" is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89961 --- Comment #2 from Martin Liška --- Note that the intermediate format provides 'current_working_directory' value that should be easily used to distinguish among same files in different folders? Does it work for you?
[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #33 from Erik Schnetter ---
Here is an updated version of the patch that fixincludes both
and , and does not need to touch any sources
files in GCC any more:
Index: fixincludes/inclhack.def
===
--- fixincludes/inclhack.def (revision 270127)
+++ fixincludes/inclhack.def (working copy)
@@ -1298,6 +1298,69 @@ fix = {
};
/*
+ * macOS 10.14.4 uses the C _Atomic keyword in C++
+ * code, and this file is included by .
+ */
+fix = {
+hackname = darwin_sysctl3__Atomic;
+mach = "*-*-darwin18.5.*";
+files = sys/sysctl.h;
+select= "#include ";
+
+c_fix = wrap;
+
+c_fix_arg = <<- _EOArg_
+
+ #if defined(__cplusplus) && __cplusplus >= 201103L
+# define _Atomic volatile
+ #endif
+
+ _EOArg_;
+
+c_fix_arg = <<- _EOArg_
+
+ #if defined(__cplusplus) && __cplusplus >= 201103L
+ # undef _Atomic
+ #endif
+
+ _EOArg_;
+
+test_text = "#include \n";
+};
+
+
+/*
+ * macOS 10.14.4 uses the C _Atomic keyword in C++
+ * code.
+ */
+fix = {
+hackname = darwin_ucred__Atomic;
+mach = "*-*-darwin18.5.*";
+files = sys/ucred.h;
+select= "_Atomic";
+
+c_fix = wrap;
+
+c_fix_arg = <<- _EOArg_
+
+ #if defined(__cplusplus) && __cplusplus >= 201103L
+# define _Atomic volatile
+ #endif
+
+ _EOArg_;
+
+c_fix_arg = <<- _EOArg_
+
+ #if defined(__cplusplus) && __cplusplus >= 201103L
+ # undef _Atomic
+ #endif
+
+ _EOArg_;
+
+test_text = "#include \n";
+};
+
+/*
* For the AAB_darwin7_9_long_double_funcs fix to be useful,
* you have to not use "" includes.
*/
-erik
--
Erik Schnetter
http://www.perimeterinstitute.ca/personal/eschnetter/
[Bug c++/56643] Failure to match noexcept specifier of friend template function in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56643 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #6 from Paolo Carlini --- Done.
