[Bug libfortran/83811] fortran 'e' format broken for single digit exponents
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83811 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-14 Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jerry DeLisle --- Further investigation is showing me that the buffer containing the float string is wrong before it goes into build_float_string. Ths means it has something to do with snprintf. In the wrong output case with write(s, '(1pe5.0e1)') 1.e-4, the buffer contains "+1.e-0" with nprinted=7. This indicates we have an off by 1 like error here.
[Bug target/80870] [7 Regression] ICE building 7.1.0 sh-elf crosscompiler on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80870 --- Comment #3 from Anders Montonen --- Current GCC 7 branch (r256652) fails with the "fancy_abort" errors from bug 82091 using Xcode 9.2 (clang-900.0.39.2). GCC 7.2.0 and trunk fail with the same errors. In file included from ../../gcc/gcc/config/sh/sh_optimize_sett_clrt.cc:30: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/vector:266: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__bit_reference:15: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/algorithm:640: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:629: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/typeinfo:205:2: error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'? _VSTD::abort(); ^~~ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__config:392:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ ../../gcc/gcc/system.h:725:13: note: 'fancy_abort' declared here extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN; ^ In file included from ../../gcc/gcc/config/sh/sh_optimize_sett_clrt.cc:30: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/vector:266: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__bit_reference:15: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/algorithm:640: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:639: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/stdexcept:195:4: error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'? _VSTD::abort(); ^~~ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__config:392:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ ../../gcc/gcc/system.h:725:13: note: 'fancy_abort' declared here extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN; ^ In file included from ../../gcc/gcc/config/sh/sh_optimize_sett_clrt.cc:30: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/vector:266: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__bit_reference:15: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/algorithm:640: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:639: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/stdexcept:206:4: error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'? _VSTD::abort(); ^~~ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__config:392:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ ../../gcc/gcc/system.h:725:13: note: 'fancy_abort' declared here extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN; ^ In file included from ../../gcc/gcc/config/sh/sh_optimize_sett_clrt.cc:30: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/vector:266: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__bit_reference:15: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/algorithm:640: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/memory:639: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/stdexcept:217:4: error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'? _VSTD::abort(); ^~~ /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__config:392:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE
[Bug tree-optimization/83819] [meta-bug] missing strlen optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-14 CC||egallager at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Gallager --- Confirmed that this is a useful meta-bug grouping.
[Bug libstdc++/83601] std::regex_replace C++14 conformance issue: escaping in SED mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83601 Tim Shen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tim Shen --- Mark as fixed.
[Bug libstdc++/83601] std::regex_replace C++14 conformance issue: escaping in SED mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83601 --- Comment #2 from Tim Shen --- Author: timshen Date: Sun Jan 14 00:48:30 2018 New Revision: 256654 URL: https://gcc.gnu.org/viewcvs?rev=256654&root=gcc&view=rev Log: PR libstdc++/83601 * include/bits/regex.tcc (regex_replace): Fix escaping in sed. * testsuite/28_regex/algorithms/regex_replace/char/pr83601.cc: Tests. * testsuite/28_regex/algorithms/regex_replace/wchar_t/pr83601.cc: Tests. Added: trunk/libstdc++-v3/testsuite/28_regex/algorithms/regex_replace/char/pr83601.cc trunk/libstdc++-v3/testsuite/28_regex/algorithms/regex_replace/wchar_t/pr83601.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex.tcc
[Bug c++/83588] [6/7/8 Regression] struct with two flexible arrays causes an internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83588
Martin Sebor changed:
What|Removed |Added
Keywords|accepts-invalid |
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-14
CC||msebor at gcc dot gnu.org
Summary|Struct with two flexible|[6/7/8 Regression] struct
|arrays causes an internal |with two flexible arrays
|compiler error |causes an internal compiler
||error
Ever confirmed|0 |1
Known to fail||6.4.0, 7.2.0, 8.0
--- Comment #1 from Martin Sebor ---
Confirmed with GCC 6, 7, and 8. Bisection points to r231665. Initialization
of objects with flexible array members is accepted for compatibility with GCC.
$ cat pr83588.C && gcc -S -Wall pr83588.C.
struct Foo
{
int i, a[], b[];
};
struct Foo t = {1, {0, 0, 0}, {0, 0, 0}};
pr83588.C:6:41: internal compiler error: in output_constructor_regular_field,
at varasm.c:5155
struct Foo t = {1, {0, 0, 0}, {0, 0, 0}};
^
0x16c5a99 output_constructor_regular_field
/ssd/src/gcc/git/gcc/varasm.c:5155
0x16c6729 output_constructor
/ssd/src/gcc/git/gcc/varasm.c:5438
0x16c5090 output_constant
/ssd/src/gcc/git/gcc/varasm.c:4965
0x16baa3d assemble_variable_contents
/ssd/src/gcc/git/gcc/varasm.c:2134
0x16bb549 assemble_variable(tree_node*, int, int, int)
/ssd/src/gcc/git/gcc/varasm.c:2310
0x16d555e varpool_node::assemble_decl()
/ssd/src/gcc/git/gcc/varpool.c:590
0xcad84b output_in_order
/ssd/src/gcc/git/gcc/cgraphunit.c:2385
0xcae001 symbol_table::compile()
/ssd/src/gcc/git/gcc/cgraphunit.c:2623
0xcae2c1 symbol_table::finalize_compilation_unit()
/ssd/src/gcc/git/gcc/cgraphunit.c:2717
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/83830] New: has_unique_object_representations_v is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83830 Bug ID: 83830 Summary: has_unique_object_representations_v is missing Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: rs2740 at gmail dot com Target Milestone: --- libstdc++ has the trait but not the _v form, which was added by the editor per NB comment US-9 on the C++17 CD, see https://github.com/cplusplus/draft/commit/97058f9cc925cd9a9e818545cad4e1c198d714cb.
[Bug c++/83596] ['17] can't use member pointer result of a constexpr function as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83596 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-14 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Sebor --- Without studying this too deeply I'll confirm this report based on other compilers (including Clang, EDG, and MSVC) accepting the code.
[Bug c++/83614] deduction failure for template-template argument with trailing template parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83614
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-01-13
CC||msebor at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||5.4.0, 6.4.0, 7.2.0, 8.0
--- Comment #1 from Martin Sebor ---
Confirmed. All recent GCC versions reject the snippet with the error below
(please remember to include compiler output in bug reports about diagnostics --
see https://gcc.gnu.org/bugs for details). Other compilers besides Clang
compile the code (EDG and MSVC).
pr83614.C: In function ‘int main()’:
pr83614.C:18:10: error: no matching function for call to ‘foo(Y&)’
foo(y); // error: X does not match A
^
pr83614.C:10:6: note: candidate: ‘template class A, class ...
Ts> void foo(Y)’
void foo(Y ) { }
^~~
pr83614.C:10:6: note: template argument deduction/substitution failed:
pr83614.C:18:10: note: template argument ‘X’ does not match ‘A’
foo(y); // error: X does not match A
^
[Bug target/80865] broken compilation on Mac OS X 10.5 / powerpc: unrecognizable insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80865 --- Comment #12 from Iain Sandoe --- (In reply to Eric Gallager from comment #11) > (In reply to Iain Sandoe from comment #9) > > (In reply to Christian Cornelssen from comment #7) > > > I have made the time-consuming effort of building and testing gcc-7.2.0 > > > with > > > varying subsets of the four patchsets proposed with attachment 42124 > > > [details] > > > [details]. > > > > Thanks for doing this! > > > > I have building work going on here (to repair water damage to my office) and > > temporarily had to relocate - at present, I don't have access to my PPC > > Darwin machines. Hopefully, the works will complete in a month or so, and > > i'll be back to normal (please be patient - but I don't believe another 7.x > > release is scheduled in that time). > > Has the work completed yet? actually, there were a lot of complications and I'm still relocated - however, the work finished just before Xmas, and we're now working to re-do the network wiring, etc. Hopefully, by the end of this month.. not had any Darwin cycles for a while (and still no access to the PPC machines) :( .. later in Feb perhaps.
[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824 Rainer Orth changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Rainer Orth --- Fixed for GCC 8.1.
[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824 --- Comment #16 from Rainer Orth --- Author: ro Date: Sat Jan 13 21:01:27 2018 New Revision: 256650 URL: https://gcc.gnu.org/viewcvs?rev=256650&root=gcc&view=rev Log: Allow for lack of VM_MEMORY_OS_ALLOC_ONCE on Mac OS X (PR sanitizer/82824) PR sanitizer/82824 * lsan/lsan_common_mac.cc: Cherry-pick upstream r322437. Modified: trunk/libsanitizer/ChangeLog trunk/libsanitizer/lsan/lsan_common_mac.cc
[Bug fortran/82007] DTIO write format stored in a string leads to severe errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82007 --- Comment #7 from Jerry DeLisle --- Author: jvdelisle Date: Sat Jan 13 20:41:00 2018 New Revision: 256649 URL: https://gcc.gnu.org/viewcvs?rev=256649&root=gcc&view=rev Log: 2018-01-13 Jerry DeLisle PR fortran/82007 * resolve.c (resolve_transfer): Delete code looking for 'DT' format specifiers in format strings. Set formatted to true if a format string or format label is present. * trans-io.c (get_dtio_proc): Likewise. (transfer_expr): Fix whitespace. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-io.c
[Bug fortran/83823] [8 Regression] Character length issues with PACK()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83823 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org Target Milestone|--- |8.0
[Bug fortran/83829] New: Implement runtime checks for DT format specifier and allignment with effective items
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83829 Bug ID: 83829 Summary: Implement runtime checks for DT format specifier and allignment with effective items Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at gcc dot gnu.org Target Milestone: --- As discussed on the gfortran mailing list, we need to hadle the case where a User Defined Derived Type Procedure is provided for formatted I/O but the user chooses not to use it by omitting the 'DT' specifier in a format string. See thread here: https://gcc.gnu.org/ml/fortran/2018-01/msg00032.html. The patch for pr82007 eliminates the rejecting of valid code.
[Bug fortran/78814] ICE in symbol_rank, at fortran/interface.c:1265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78814 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |6.5 --- Comment #6 from kargl at gcc dot gnu.org --- Fixed on 6-branch, 7-branch, and trunk. Thanks for bug report.
[Bug fortran/78814] ICE in symbol_rank, at fortran/interface.c:1265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78814 --- Comment #5 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Jan 13 19:12:32 2018 New Revision: 256647 URL: https://gcc.gnu.org/viewcvs?rev=256647&root=gcc&view=rev Log: 2012-01-13 Steven G. Kargl Backport from mainline PR fortran/78814 * interface.c (symbol_rank): Check for NULL pointer. 2012-01-13 Steven G. Kargl Backport from mainline PR fortran/78814 * gfortran.dg/interface_40.f90: New testcase. Added: branches/gcc-6-branch/gcc/testsuite/gfortran.dg/interface_40.f90 Modified: branches/gcc-6-branch/gcc/fortran/ChangeLog branches/gcc-6-branch/gcc/fortran/interface.c branches/gcc-6-branch/gcc/testsuite/ChangeLog
[Bug c++/83817] [8 Regression] internal compiler error: tree check: expected call_expr, have aggr_init_expr in tsubst_copy_and_build, at cp/pt.c:17822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83817 Martin Sebor changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-13 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||8.0 --- Comment #2 from Martin Sebor --- Confirmed with an x6_64-linux compiler so it's not target-specific. Also confirming that 7.2 compiles it successfully so it is a GCC 8 regression.
[Bug fortran/78814] ICE in symbol_rank, at fortran/interface.c:1265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78814 --- Comment #4 from kargl at gcc dot gnu.org --- Author: kargl Date: Sat Jan 13 18:58:56 2018 New Revision: 256646 URL: https://gcc.gnu.org/viewcvs?rev=256646&root=gcc&view=rev Log: 2012-01-13 Steven G. Kargl Backport from mainline PR fortran/78814 * interface.c (symbol_rank): Check for NULL pointer. 2012-01-13 Steven G. Kargl Backport from mainline PR fortran/78814 * gfortran.dg/interface_40.f90: New testcase. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/interface_40.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/interface.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug debug/81155] [8 Regression] Debug make check regressions in GCC 8.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81155 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- The GDB missing feature/bug worked around for GCC 8, hopefully GDB will be fixed soon and we can remove the workaround at some point.
[Bug fortran/83744] ICE in ../../gcc/gcc/fortran/dump-parse-tree.c:3093 while using -fc-prototypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83744 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Thomas Koenig --- Fixed on trunk, closing.
[Bug fortran/83744] ICE in ../../gcc/gcc/fortran/dump-parse-tree.c:3093 while using -fc-prototypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83744 --- Comment #5 from Thomas Koenig --- Author: tkoenig Date: Sat Jan 13 18:22:36 2018 New Revision: 256645 URL: https://gcc.gnu.org/viewcvs?rev=256645&root=gcc&view=rev Log: 2018-01-13 Thomas Koenig PR fortran/83744 * dump-parse-tree.c (get_c_type_name): Remove extra line. Change for loop to use declaration in for loop. Handle BT_LOGICAL and BT_CHARACTER. (write_decl): Add where argument. Fix indentation. Replace assert with error message. Add typename to warning in comment. (write_type): Adjust locus to call of write_decl. (write_variable): Likewise. (write_proc): Likewise. Replace assert with error message. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c
[Bug c++/47226] [C++0x] GCC doesn't expand template parameter pack that appears in a lambda-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226 --- Comment #16 from Martin Sebor --- *** Bug 83793 has been marked as a duplicate of this bug. ***
[Bug c++/83793] Pack expansion outside of lambda containing the pack incorrectly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83793 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Martin Sebor --- Resolving as a dupe of pr47226 based on comment #2. *** This bug has been marked as a duplicate of bug 47226 ***
[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824 --- Comment #15 from Dominique d'Humieres --- > That's the value of VM_MEMORY_OS_ALLOC_ONCE on Mac OS X 10.9 and up. Thanks!
[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- That's the value of VM_MEMORY_OS_ALLOC_ONCE on Mac OS X 10.9 and up.
[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824 --- Comment #13 from Dominique d'Humieres --- > See the PR URL fieldd. Found, thanks! Out of curiosity, why 73 in 'kSanitizerVmMemoryOsAllocOnce = 73'?
[Bug c++/83778] [8 regression] g++.dg/ext/altivec-cell-2.C fails starting with r256448
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83778 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed.
[Bug c/83801] [8 Regression][avr] String constant in __flash not put into .progmem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Jakub Jelinek --- Fixed.
[Bug c/83801] [8 Regression][avr] String constant in __flash not put into .progmem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83801 --- Comment #11 from Jakub Jelinek --- Author: jakub Date: Sat Jan 13 17:00:43 2018 New Revision: 256608 URL: https://gcc.gnu.org/viewcvs?rev=256608&root=gcc&view=rev Log: PR c/83801 * c-tree.h (decl_constant_value_1): Add a bool argument. * c-typeck.c (decl_constant_value_1): Add IN_INIT argument, allow returning a CONSTRUCTOR if it is true. Use error_operand_p. (decl_constant_value): Adjust caller. * c-fold.c (c_fully_fold_internal): If in_init, pass true to decl_constant_value_1 as IN_INIT. Otherwise, punt if decl_constant_value returns initializer that has BLKmode or array type. (c_fully_fold_internal) : Fold if !lval. * gcc.dg/pr83801.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr83801.c Modified: trunk/gcc/c/ChangeLog trunk/gcc/c/c-fold.c trunk/gcc/c/c-tree.h trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824 --- Comment #12 from ro at CeBiTec dot Uni-Bielefeld.DE --- See the PR URL fieldd.
[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824 --- Comment #11 from Dominique d'Humieres --- > Revised patch posted. Where?
[Bug c/51628] __attribute__((packed)) is unsafe in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628 --- Comment #37 from H.J. Lu --- Created attachment 43120 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43120&action=edit Add -Waddress-of-packed-member to C/C++ FE Please try this.
[Bug sanitizer/82825] [8 regression] Many libsanitizer tests FAIL: dyld: Symbol not found: ___lsan_default_options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82825 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- A patch has been approved upstream: https://reviews.llvm.org/D41346. Will post to gcc-patches once it has been installed. Rainer
[Bug sanitizer/82825] [8 regression] Many libsanitizer tests FAIL: dyld: Symbol not found: ___lsan_default_options
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82825 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-01-13 Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Rainer Orth --- Mine.
[Bug sanitizer/82824] [8 regression] libsanitizer fails to build: VM_MEMORY_OS_ALLOC_ONCE undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82824 Rainer Orth changed: What|Removed |Added URL|https://gcc.gnu.org/ml/gcc- |https://gcc.gnu.org/ml/gcc- |patches/2017-11/msg01061.ht |patches/2018-01/msg01166.ht |ml |ml Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org --- Comment #10 from Rainer Orth --- Revised patch posted.
[Bug fortran/83744] ICE in ../../gcc/gcc/fortran/dump-parse-tree.c:3093 while using -fc-prototypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83744 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org --- Comment #4 from Thomas Koenig --- Looks straightforward...
[Bug fortran/27766] [meta-bug] -fbounds-check related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766 Bug 27766 depends on bug 52162, which changed state. Bug 52162 Summary: Bogus -fcheck=bounds with realloc on assignment to unallocated LHS https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52162 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/52162] Bogus -fcheck=bounds with realloc on assignment to unallocated LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52162 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from Paul Thomas --- Hi Dominique, Thanks for bringing this to my attention. Fixed on trunk. Paul
[Bug fortran/83622] [8 Regression] Wrong code with derived type and -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83622 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Paul Thomas --- Fixed as 'obvious'. Paul
[Bug fortran/83622] [8 Regression] Wrong code with derived type and -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83622 --- Comment #8 from Paul Thomas --- Author: pault Date: Sat Jan 13 13:52:34 2018 New Revision: 256607 URL: https://gcc.gnu.org/viewcvs?rev=256607&root=gcc&view=rev Log: 2018-01-13 Paul Thomas PR fortran/52162 * trans-expr.c (gfc_trans_scalar_assign): Flag is_alloc_lhs if the rhs expression is neither an elemental nor a conversion function. PR fortran/83622 * trans-array.c (is_pointer_array): Remove unconditional return of false for -fopenmp. 2018-01-13 Paul Thomas PR fortran/52162 * gfortran.dg/bounds_check_19.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_19.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/52162] Bogus -fcheck=bounds with realloc on assignment to unallocated LHS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52162 --- Comment #14 from Paul Thomas --- Author: pault Date: Sat Jan 13 13:52:34 2018 New Revision: 256607 URL: https://gcc.gnu.org/viewcvs?rev=256607&root=gcc&view=rev Log: 2018-01-13 Paul Thomas PR fortran/52162 * trans-expr.c (gfc_trans_scalar_assign): Flag is_alloc_lhs if the rhs expression is neither an elemental nor a conversion function. PR fortran/83622 * trans-array.c (is_pointer_array): Remove unconditional return of false for -fopenmp. 2018-01-13 Paul Thomas PR fortran/52162 * gfortran.dg/bounds_check_19.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_19.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/83803] Using -fc-prototypes on modules with empty dummy arg lists does not close paren.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83803 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Thomas Koenig --- Ficed, closing.
[Bug fortran/83803] Using -fc-prototypes on modules with empty dummy arg lists does not close paren.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83803 --- Comment #5 from Thomas Koenig --- Author: tkoenig Date: Sat Jan 13 13:23:31 2018 New Revision: 256606 URL: https://gcc.gnu.org/viewcvs?rev=256606&root=gcc&view=rev Log: 2018-01-13 Thomas Koenig PR fortran/83803 * dump-parse-tree.c (write_proc): Always emit closing parenthesis for functions. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c
[Bug fortran/83803] Using -fc-prototypes on modules with empty dummy arg lists does not close paren.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83803 --- Comment #4 from Thomas Koenig --- (In reply to emsr from comment #3) > Created attachment 43110 [details] > patchlet (untested) I actually came up with exactly the same patch independently :-) I will commit this as obvious to trunk and 7-branch.
[Bug target/83828] New: FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83828 Bug ID: 83828 Summary: FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com CC: pavel.v.chupin at gmail dot com Target Milestone: --- On Skylake server with AVX512, I got: FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntd-1.c execution test FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntd-1.c execution test FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test FAIL: gcc.target/i386/avx512vpopcntdqvl-vpopcntq-1.c execution test FAIL: gcc.target/i386/avx512vpopcntdq-vpopcntd-1.c execution test FAIL: gcc.target/i386/avx512vpopcntdq-vpopcntd-1.c execution test FAIL: gcc.target/i386/avx512vpopcntdq-vpopcntq-1.c execution test FAIL: gcc.target/i386/avx512vpopcntdq-vpopcntq-1.c execution test
[Bug target/80870] [7 Regression] ICE building 7.1.0 sh-elf crosscompiler on macOS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80870 --- Comment #2 from Oleg Endo --- Could you please try it out with the latest GCC 7 branch and see if the problem is still there?
[Bug other/82530] RTEMS 4.12 SH build failure on FreeBSD 11.1 (clang) with an error in sh_optimize_sett_clrt.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82530 Oleg Endo changed: What|Removed |Added CC||olegendo at gcc dot gnu.org Component|target |other --- Comment #1 from Oleg Endo --- Hm, this looks like some compatibility issue of the build system's C++ std lib and GCC source in general.
[Bug ada/36939] Build Failure Ada SH2e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36939 Oleg Endo changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #23 from Oleg Endo --- *** Bug 83810 has been marked as a duplicate of this bug. ***
[Bug target/83810] sh: s-scaval.adb:103:07: warning: "IV_Ilf" overlays smaller object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83810 Oleg Endo changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||olegendo at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Oleg Endo --- The SH target option -m4-single-only forces all doubles to be 32 bit floats. Some SH variants (e.g. SH2E) have only 32 bit float hardware and all doubles are forced to be 32 bit floats. See also PR 36939. *** This bug has been marked as a duplicate of bug 36939 ***
[Bug rtl-optimization/83827] New: vector load/store with struct in registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83827
Bug ID: 83827
Summary: vector load/store with struct in registers
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: glisse at gcc dot gnu.org
Target Milestone: ---
Target: x86_64-*-*
(first seen with complex numbers, quite likely a dup of some other vector PR,
could be target instead of rtl-opt)
typedef double vec __attribute__((vector_size(16)));
struct A { double a, b; };
vec f(A x){
vec v = { x.a, x.b };
return v;
}
A add(A x, A y){
return { x.a+y.a, x.b+y.b };
}
In f, we build v with
_1 = x.a;
_2 = x.b;
v_4 = {_1, _2};
while in add, we do
vect__1.2_10 = MEM[(double *)&x];
vect__2.5_11 = MEM[(double *)&y];
vect__3.6_12 = vect__1.2_10 + vect__2.5_11;
MEM[(double *)&D.2881] = vect__3.6_12;
The first version yields (g++ -O3 -march=skylake) the nice
vunpcklpd %xmm1, %xmm0, %xmm0
while add has the lengthy
vmovq %xmm0, -40(%rsp)
vmovq %xmm1, -32(%rsp)
vmovapd -40(%rsp), %xmm5
vmovq %xmm2, -24(%rsp)
vmovq %xmm3, -16(%rsp)
vaddpd -24(%rsp), %xmm5, %xmm4
vmovaps %xmm4, -40(%rsp)
vmovsd -32(%rsp), %xmm1
vmovsd -40(%rsp), %xmm0
With -O2, we also turn
A g(vec x){
return { x[0], x[1] };
}
into the nice
vunpckhpd %xmm0, %xmm0, %xmm1
(this PR is independent of whether it was a good idea or not for SLP to
vectorize add)
[Bug tree-optimization/54422] Merge adjacent stores of elements of a vector (or loads)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54422 Marc Glisse changed: What|Removed |Added Status|NEW |RESOLVED Known to work||8.0 Resolution|--- |FIXED --- Comment #2 from Marc Glisse --- All versions give a single vmovups now.
[Bug c++/83825] [8 Regression] ICE on invalid C++ code with shadowed identifiers: in operator[], at vec.h:826
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83825 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-13 CC||jakub at gcc dot gnu.org, ||nathan at gcc dot gnu.org Version|unknown |8.0 Target Milestone|--- |8.0 Summary|ICE on invalid C++ code |[8 Regression] ICE on |with shadowed identifiers: |invalid C++ code with |in operator[], at vec.h:826 |shadowed identifiers: in ||operator[], at vec.h:826 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r252005.
[Bug c++/83824] [6/7/8 Regression] ICE on invalid C++ code with alignas: in chainon, at tree.c:3037
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83824 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-01-13 CC||jakub at gcc dot gnu.org Version|unknown |8.0 Target Milestone|--- |6.5 Summary|ICE on invalid C++ code |[6/7/8 Regression] ICE on |with alignas: in chainon, |invalid C++ code with |at tree.c:3037 |alignas: in chainon, at ||tree.c:3037 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Not that recent, started with r193029 when alignas parsing has been added before the type.
[Bug c++/83793] Pack expansion outside of lambda containing the pack incorrectly rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83793 --- Comment #2 from Jonathan Wakely --- Looks like a dup of PR 47226 which is already fixed on trunk, but I don't think the recent overhaul of lambda expression handling is suitable to be backported.
[Bug c++/82560] [7/8 Regression] Temporary object created as a default argument not destructed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82560 Jonathan Wakely changed: What|Removed |Added CC||pdziepak at quarnos dot org --- Comment #8 from Jonathan Wakely --- *** Bug 83802 has been marked as a duplicate of this bug. ***
[Bug c++/83802] Caller doesn't destroy default argument passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83802 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Jonathan Wakely --- Yes, reverting r253822 on the branch makes the bug come back, so dup. *** This bug has been marked as a duplicate of bug 82560 ***
[Bug c++/83802] Caller doesn't destroy default argument passed to a constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83802 --- Comment #3 from Jonathan Wakely --- Maybe Nathan's patch for PR 82560 ?
