[Bug testsuite/82997] [8 regression] gcc.dg/cpp/sysmac1.c and gcc.dg/cpp/macsyntx.c fail starting with r254707
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82997 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Nov 17 07:42:28 2017 New Revision: 254857 URL: https://gcc.gnu.org/viewcvs?rev=254857=gcc=rev Log: PR testsuite/82997 * gcc.dg/cpp/macsyntx.c (var1, rest): Don't expect "requires at least one" warning. * gcc.dg/cpp/sysmac1.c (foo): Likewise. * gcc.dg/cpp/macsyntx2.c: New test. * gcc.dg/cpp/sysmac3.c: New test. * gcc.dg/cpp/sysmac3.h: New file. Added: trunk/gcc/testsuite/gcc.dg/cpp/macsyntx2.c trunk/gcc/testsuite/gcc.dg/cpp/sysmac3.c trunk/gcc/testsuite/gcc.dg/cpp/sysmac3.h Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cpp/macsyntx.c trunk/gcc/testsuite/gcc.dg/cpp/sysmac1.c
[Bug c++/83028] New: Incorrect -Wsequence-point warning in correct C++17 code with new evaluation order rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83028 Bug ID: 83028 Summary: Incorrect -Wsequence-point warning in correct C++17 code with new evaluation order rules Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ixsci at yandex dot ru Target Milestone: --- Compiling the following code: #include using namespace std; int main() { int i = 0; cout << i++ << " " << i++ << "\n"; }; with the latest gcc (compiled on wandbox.org) and -std=c++1z gives the following warning: operation on 'i' may be undefined [-Wsequence-point] cout << i++ << " " << i++ << "\n"; But there should be no warnings since both modifications are sequenced and the result is well defined.
[Bug libstdc++/66689] comp_ellint_3 and ellint_3 return garbage values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66689 --- Comment #5 from Ed Smith-Rowland <3dw4rd at verizon dot net> --- in other news I've switched to boost to test this.
[Bug libstdc++/66689] comp_ellint_3 and ellint_3 return garbage values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66689 --- Comment #4 from Ed Smith-Rowland <3dw4rd at verizon dot net> --- My last comment is nuts. I was thrown by the fact that GSL, against which I've been testing, and the Carlson papers that form the basis if the implementation use the +nu convention. I must change this. This is a huge bug.
[Bug middle-end/78809] Inline strcmp with small constant strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809 --- Comment #21 from Jeffrey A. Law --- Author: law Date: Fri Nov 17 05:32:05 2017 New Revision: 254856 URL: https://gcc.gnu.org/viewcvs?rev=254856=gcc=rev Log: 2017-11-15 Qing ZhaoPR middle-end/78809 * gimple-fold.c (gimple_fold_builtin_string_compare): Add handling of replacing call to strncmp with corresponding call to strcmp when meeting conditions. PR middle-end/78809 * gcc.dg/strcmpopt_1.c: New test. Added: trunk/gcc/testsuite/gcc.dg/strcmpopt_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/testsuite/ChangeLog
[Bug ada/83027] New: Hang when attaching a SIGINT handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83027 Bug ID: 83027 Summary: Hang when attaching a SIGINT handler Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: porton at narod dot ru Target Milestone: --- Created attachment 42630 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42630=edit The source reprising the bug Extract attached bug.zip into an empty directory. Run make compile ./obj/simple_test The command simple_test hangs. The most wonderful thing is that if I do not compile it (as "make compile" does) as an .a library imported when linking simple_test, but put all source into a single directory and run "gnatmake simple_test", then the error does not happen (but Program_Error is raised as it should be accordingly the docs, because pragma Unreserve_All_Interrupts is not in effect in this example code). Another weird thing that it happens with SIGINT but not with SIGTERM nor with SIGCHLD. The bug also does not happen if I remove "with Ada.Text_IO;". GCC 7.2.0.
[Bug fortran/25829] [F03] Asynchronous IO support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829 --- Comment #33 from Jerry DeLisle --- (In reply to Janne Blomqvist from comment #32) > Interestingly, Linux 4.14 contains a way to avoid a context switch to a > threadpool in case the data is already in the page cache: > https://kernelnewbies.org/Linux_4.14#head- > 8c8861fbded3e87631ab06bcd511f5f0d8bfa220 > > Might be an interesting optimization sometime in the future.. It is interesting that I was reading this very webpage myself today looking at 4.14 feature. I am pretty sure we can hand off the I/O to the OS. I am not so sure how one checks the status of the operaton. This is what wait should do, wait for completion.
[Bug libfortran/78549] [8 Regression] Very slow formatted internal file output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549 --- Comment #23 from Jerry DeLisle --- Well, instrumenting a little bit I see that delete_root is getting called many many many times. So, every call to newunit_alloc is assigning a new unit number which is getting added to the treap and never reused in anyway. The result of this is that at the end of the program when any units left on the treap are deleted, we loop through over one million deletes. So I now have a better idea of what we need to do.
[Bug fortran/83021] [7 Regression] gfortran segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83021 --- Comment #3 from Dominique d'Humieres --- > > Could you please provide the file(s) needed to generate > > local_field_module.mod? > > I suspect the source code in question is the same as ... This file is not enough to generate local_field_module.mod. You have to provide a self contained reproducer otherwise the PR will be closed as INVALID.
[Bug tree-optimization/82950] possible strlen optimization for memcmp/strcmp of arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82950 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=78809 --- Comment #3 from Martin Sebor --- An even simpler test case: void g (void) { const char a[] = "abc"; const char b[] = "abcd"; if (!__builtin_strcmp (a, b)) __builtin_abort (); } See also bug 78809.
[Bug fortran/82996] ICE and segfault with derived type finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996 --- Comment #8 from neil.n.carlson at gmail dot com --- > If I remove 'elemental' for 'subroutine foo_destroy', the segfault is gone. In that case the final procedure doesn't match the array component and wouldn't be called. I suspect that is why the segfault is gone.
[Bug fortran/83021] [7 Regression] gfortran segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83021 Zaak changed: What|Removed |Added CC||zbeekman at gmail dot com --- Comment #2 from Zaak --- I suspect the source code in question is the same as https://github.com/sourceryinstitute/OpenCoarrays/blob/8eab16936fb958746575f5c9580ba521320e0444/src/tests/integration/pde_solvers/coarrayBurgers/local_field.F90
[Bug fortran/82996] ICE and segfault with derived type finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996 Dominique d'Humieres changed: What|Removed |Added Blocks||37336 --- Comment #7 from Dominique d'Humieres --- > I think Dominique swapped 2 and 3. Indeed! If I compile the tests in comment 0 or 1 with '-fsanitize=address,undefined', I get at run time an error of the kind: pr82996.f90:17: runtime error: member access within misaligned address 0x1000e3e7620c for type 'struct foo', which requires 8 byte alignment 0x1000e47d2bec: note: pointer points here ASAN:DEADLYSIGNAL = ==3427==ERROR: AddressSanitizer: SEGV on unknown address 0x12001c8fa57d (pc 0x00010796507b bp 0x7ffee84cd9c0 sp 0x7ffee84cd150 T0) #0 0x10796507a in wrap_write.part.20 (/opt/gcc/gcc7wr/lib/libasan.4.dylib+0x2507a) #1 0x109224d2e in __sanitizer::IsAccessibleMemoryRange(unsigned long, unsigned long) (/opt/gcc/gcc7wr/lib/libubsan.0.dylib+0x17d2e) AddressSanitizer can not provide additional info. SUMMARY: AddressSanitizer: SEGV (/opt/gcc/gcc7wr/lib/libasan.4.dylib+0x2507a) in wrap_write.part.20 ==3427==ABORTING Program received signal SIGABRT: Process abort signal. If I remove 'elemental' for 'subroutine foo_destroy', the segfault is gone. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 [Bug 37336] [F03] Finish derived-type finalization
[Bug tree-optimization/83026] missing strlen optimization for strcmp of unequal strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83026 Martin Sebor changed: What|Removed |Added Keywords||missed-optimization See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=82950 --- Comment #1 from Martin Sebor --- See also pr82950 for a related enhancement.
[Bug tree-optimization/83026] New: missing strlen optimization for strcmp of unequal strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83026 Bug ID: 83026 Summary: missing strlen optimization for strcmp of unequal strings Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- Here's another strcmp optimization opportunity. When strlen() determines that two strings are of unequal length it's safe to assume they do not compare equal. Therefore, in the function below, the conditional with the the strcmp() call can be folded into false. $ cat c.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout c.c void g (const char *a, const char *b) { if (__builtin_strlen (a) == __builtin_strlen (b)) return; if (!__builtin_strcmp (a, b)) __builtin_abort (); } ;; Function g (g, funcdef_no=0, decl_uid=1892, cgraph_uid=0, symbol_order=0) g (const char * a, const char * b) { long unsigned int _1; long unsigned int _2; int _3; [local count: 1]: _1 = __builtin_strlen (a_5(D)); _2 = __builtin_strlen (b_6(D)); if (_1 == _2) goto ; [20.97%] else goto ; [79.03%] [local count: 7903]: _3 = __builtin_strcmp (a_5(D), b_6(D)); if (_3 == 0) goto ; [0.04%] else goto ; [99.96%] [count: 0]: __builtin_abort (); [local count: 9997]: return; }
[Bug driver/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83016 --- Comment #5 from Eric Botcazou --- Created attachment 42629 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42629=edit Tentative fix The patch makes sure g++ is only used to link and not to compile Ada stuff.
[Bug driver/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83016 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED CC|ebotcazou at gcc dot gnu.org | Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- Fixing.
[Bug tree-optimization/53805] combine_comparisons changes trapping behavior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53805 --- Comment #11 from Marc Glisse --- (In reply to Richard Biener from comment #3) > > I am happy to relabel this bug (or file a new one if you prefer) as a missed > > optimization. > > I'd say open a new one. For reference, that's PR 53806.
[Bug libstdc++/82366] std::regex constructor called from shared library throws std::bad_cast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366 --- Comment #5 from spamdrop at fodvo dot org --- Taking Johnathan's recommendation on Sept 29, I rebuilt the entire app, all libaries etc using -D_GLIBCXX_USE_CXX11_ABI=0 Carefully isolating the libs and LD_LIBRARY_PATH. Using ABI=0, the program runs fine. When I repeat the exact same steps without the ABI=0 define, the program throws the std::bad_cast error.
[Bug libstdc++/83025] xfstream::open with char* gets caught on C++17 path overload.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83025 --- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> --- Created attachment 42628 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42628=edit patch... enable_if with is_class_v.
[Bug libstdc++/83025] New: xfstream::open with char* gets caught on C++17 path overload.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83025 Bug ID: 83025 Summary: xfstream::open with char* gets caught on C++17 path overload. Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: 3dw4rd at verizon dot net Target Milestone: --- Created attachment 42627 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42627=edit Example showing error. Compile with -std=c++17 char* filename = "test.txt" std::ofstream unit; unit.open(filename); when compiled with C++17 gives: /home/ed/bin/include/c++/8.0.0/fstream: In instantiation of ‘decltype ((void)(((std::basic_ofstream<_CharT, _Traits>*)this)->std::basic_ofstream<_CharT, _Traits>::_M_filebuf.open(__s, __mode))) std::basic_ofstream<_CharT, _Traits>::open(const _Path&, std::ios_base::openmode) [with _Path = char*; _CharT = char; _Traits = std::char_traits; decltype ((void)(((std::basic_ofstream<_CharT, _Traits>*)this)->std::basic_ofstream<_CharT, _Traits>::_M_filebuf.open(__s, __mode))) = void; std::ios_base::openmode = std::_Ios_Openmode]’: err.cpp:18:27: required from here /home/ed/bin/include/c++/8.0.0/fstream:895:13: error: request for member ‘c_str’ in ‘__s’, which is of non-class type ‘char* const’ { open(__s.c_str(), __mode); }
[Bug c++/79092] template: type ignored if value already instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79092 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #6 from Jason Merrill --- Fixed for GCC 8.
[Bug middle-end/83022] malloc & memset -> calloc is not always an optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022 --- Comment #2 from Nathan Sidwell --- Yes, this is a measurable degradation in going from gcc 4.9 -> 5.0 with myrocks DB. Apparently 25% more queries/sec with gcc 4.9 (I think it's from a benchmark). Profiling (by others) has fingered this optimization. I am in the process of implementing a check to see if the only condition between the malloc and memset is 'ptr != 0'. I noticed the crazy default probabilities during investigating this. I think that's really a second-order problem.
[Bug fortran/83012] [8 Regression] Simply contiguous pointer function not recognized as contiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83012 --- Comment #2 from Thomas Koenig --- Created attachment 42626 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42626=edit patch that appears to work This seems to work, let's see if it survives regression testing.
[Bug fortran/82996] ICE and segfault with derived type finalization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996 Ondřej Čertík changed: What|Removed |Added CC||ondrej.certik at gmail dot com --- Comment #6 from Ondřej Čertík --- The finalizers are the most serious problem with gfortran for us. Every other bug we can workaround one way or another it seems, but the finalizers are very hard to workaround, one essentially has to comment them out, not just in our code, but also in all dependencies, and even then that introduces memory leaks. What exactly is the problem? Is this a bug in the gfortran frontend, or something more fundamental? Is this a relatively simple fix for somebody who understands the internals, or would this require a significant time investment and redesign of the code?
[Bug c++/83024] ICE in build_address, at cp/typeck.c:5623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83024 --- Comment #1 from Guille --- I have tested the unsimplified version of this code, and it ICEs on every version *after* gcc-8-20170827.
[Bug c++/83024] New: ICE in build_address, at cp/typeck.c:5623
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83024 Bug ID: 83024 Summary: ICE in build_address, at cp/typeck.c:5623 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: guille at berkeley dot edu Target Milestone: --- The following short code ICEs on $ c++ -v Using built-in specs. COLLECT_GCC=c++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/8.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../configure --enable-languages=c,c++ --disable-multilib Thread model: posix gcc version 8.0.0 20171112 (experimental) (GCC) Code that triggers ICE follows: --- #include template struct __optional: std::optional { __optional()= default; __optional(T&& t) : std::optional (std::move(t)) {} operator bool () const { return (bool)(const std::optional&)*this; } // <- omit this line and it compiles fine }; struct A : __optional { static __optional parse(auto& q) { return A{}; } }; int main() { int q; auto p = A::parse(q); return 0; } ICE message follows: - $ c++ -fconcepts -std=c++1z tt.c -o tt tt.c: In static member function ‘static __optional A::parse(auto:1&)’: tt.c:14:12: internal compiler error: in build_address, at cp/typeck.c:5623 return A{}; ^ 0x931657 build_address(tree_node*) ../../gcc/cp/typeck.c:5623 0x6fe147 add_function_candidate ../../gcc/cp/call.c:2166 0x6ffa87 add_candidates ../../gcc/cp/call.c:5522 0x6fab4e add_candidates ../../gcc/cp/call.c:5433 0x6fab4e build_user_type_conversion_1 ../../gcc/cp/call.c:3849 0x6fc4f9 implicit_conversion ../../gcc/cp/call.c:1897 0x6f80a0 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int) ../../gcc/cp/call.c:10559 0x94a905 check_return_expr(tree_node*, bool*) ../../gcc/cp/typeck.c:9218 0x8ee65e finish_return_stmt(tree_node*) ../../gcc/cp/semantics.c:893 0x843bd5 cp_parser_jump_statement ../../gcc/cp/parser.c:12483 0x843bd5 cp_parser_statement ../../gcc/cp/parser.c:10897 0x844b30 cp_parser_statement_seq_opt ../../gcc/cp/parser.c:11348 0x844c07 cp_parser_compound_statement ../../gcc/cp/parser.c:11302 0x85e2b1 cp_parser_function_body ../../gcc/cp/parser.c:21837 0x85e2b1 cp_parser_ctor_initializer_opt_and_function_body ../../gcc/cp/parser.c:21874 0x860ea6 cp_parser_function_definition_after_declarator ../../gcc/cp/parser.c:26765 0x8620fc cp_parser_late_parsing_for_member ../../gcc/cp/parser.c:27645 0x851c59 cp_parser_class_specifier_1 ../../gcc/cp/parser.c:22728 0x853221 cp_parser_class_specifier ../../gcc/cp/parser.c:22754 0x853221 cp_parser_type_specifier ../../gcc/cp/parser.c:16818 Please submit a full bug report,
[Bug fortran/25829] [F03] Asynchronous IO support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829 --- Comment #32 from Janne Blomqvist --- Interestingly, Linux 4.14 contains a way to avoid a context switch to a threadpool in case the data is already in the page cache: https://kernelnewbies.org/Linux_4.14#head-8c8861fbded3e87631ab06bcd511f5f0d8bfa220 Might be an interesting optimization sometime in the future..
[Bug middle-end/83022] malloc & memset -> calloc is not always an optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022 --- Comment #1 from Marc Glisse --- I am pretty sure this was discussed when the patch was reviewed. IIRC the original patch was specifically pattern-matching if(p!=0) (with p the result of malloc) as the only acceptable condition between malloc and memset for this transformation, but the move to the strlen pass made that inconvenient and it was decided that always doing the transformation was ok (I hope I am not rewriting history). If there is a way to check the probability of reaching the call to memset from the call to malloc (preferably conditional to the fact that malloc returned something != 0), that could be checked before generating calloc, but that may not be easy... (compare the local count of the 2 BBs? That's 1 and 3300 here, but I see you have already filed PR 83023 to improve it) Did you actually hit a measurable slowdown in a real application?
[Bug other/53742] bad assembler output when compiling with LTO and PGO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53742 Eric Gallager changed: What|Removed |Added Status|WAITING |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |INVALID --- Comment #11 from Eric Gallager --- (In reply to Martin Liška from comment #10) > Is the issue still valid? No response since you asked so I'm guessing not.
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 Bug 45375 depends on bug 48724, which changed state. Bug 48724 Summary: Lto build of mozilla dies at lto-wrapper: error trying to exec 'make -j1': execvp: No such file or directory https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48724 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME
[Bug lto/48724] Lto build of mozilla dies at lto-wrapper: error trying to exec 'make -j1': execvp: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48724 Eric Gallager changed: What|Removed |Added Status|NEW |RESOLVED CC||egallager at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #9 from Eric Gallager --- (In reply to Jan Hubicka from comment #8) > This no longer happens with recent Firefox builds, but I think it was rather > fixed at Firefox buildsystem... That sounds like WORKSFORME then.
[Bug ipa/60243] IPA is slow on large cgraph tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #15 from Eric Gallager --- (In reply to Jan Hubicka from comment #14) > Author: hubicka > Date: Fri Mar 28 19:50:28 2014 > New Revision: 208916 > > URL: http://gcc.gnu.org/viewcvs?rev=208916=gcc=rev > Log: > PR ipa/60243 > * ipa-inline.c (want_inline_small_function_p): Short circuit large > functions; reorganize to make cheap checks first. > (inline_small_functions): Do not estimate growth when dumping; > it is expensive. > * ipa-inline.h (inline_summary): Add min_size. > (growth_likely_positive): New function. > * ipa-inline-analysis.c (dump_inline_summary): Add min_size. > (set_cond_stmt_execution_predicate): Cleanup. > (estimate_edge_size_and_time): Compute min_size. > (estimate_calls_size_and_time): Likewise. > (estimate_node_size_and_time): Likewise. > (inline_update_overall_summary): Update min_size. > (do_estimate_edge_time): Likewise. > (do_estimate_edge_size): Update. > (do_estimate_edge_hints): Update. > (growth_likely_positive): New function. > > Modified: > trunk/gcc/ChangeLog > trunk/gcc/ipa-inline-analysis.c > trunk/gcc/ipa-inline.c > trunk/gcc/ipa-inline.h Did this fix it?
[Bug target/82748] ICE with __builtin_fabsq and __float128 in copy_to_mode_reg, at explow.c:612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82748 --- Comment #4 from Michael Meissner --- Author: meissner Date: Thu Nov 16 20:29:52 2017 New Revision: 254846 URL: https://gcc.gnu.org/viewcvs?rev=254846=gcc=rev Log: [gcc] 2017-11-16 Michael MeissnerBack port from trunk 2017-11-16 Michael Meissner * config/rs6000/rs6000.c (rs6000_expand_builtin): Do not do the switch statement mapping KF built-ins to TF built-ins if we don't have the proper ISA 3.0 assembler support. Back port from trunk 2017-11-14 Michael Meissner * config/rs6000/rs6000-c.c (is_float128_p): New helper function. (rs6000_builtin_type_compatible): Treat _Float128 and long double as being compatible if -mabi=ieeelongdouble. * config/rs6000/rs6000-builtin.def (BU_FLOAT128_HW_1): New macros to setup float128 built-ins with hardware support. (BU_FLOAT128_HW_2): Likewise. (BU_FLOAT128_HW_3): Likewise. (BU_FLOAT128_HW_VSX_1): Likewise. (BU_FLOAT128_HW_VSX_2): Likewise. (scalar_extract_expq): Change float128 built-in functions to accommodate having both KFmode and TFmode functions. Use the KFmode variant as the default. (scalar_extract_sigq): Likewise. (scalar_test_neg_qp): Likewise. (scalar_insert_exp_q): Likewise. (scalar_insert_exp_qp): Likewise. (scalar_test_data_class_qp): Likewise. (sqrtf128_round_to_odd): Delete processing the round to odd built-in functions as special built-in functions, and define them as float128 built-ins. Use the KFmode variant as the default. (truncf128_round_to_odd): Likewise. (addf128_round_to_odd): Likewise. (subf128_round_to_odd): Likewise. (mulf128_round_to_odd): Likewise. (divf128_round_to_odd): Likewise. (fmaf128_round_to_odd): Likewise. * config/rs6000/rs6000.c (rs6000_expand_binop_builtin): Add support for KFmode and TFmode xststdcqp calls. (rs6000_expand_builtin): If long double is IEEE 128-bit floating point, switch the built-in handlers for the get/set float128 exponent, get float128 mantissa, float128 test built-ins, and the float128 round to odd built-in functions. Eliminate creating the float128 round to odd built-in functions as special built-ins. (rs6000_init_builtins): Eliminate special creation of the float128 round to odd built-in functions. * config/rs6000/vsx.md (xsxexpqp_): Change float128 built-in function insns to support both TFmode and KFmode variants. (xsxsigqp_): Likewise. (xsiexpqpf_): Likewise. (xsiexpqp_): Likewise. (xststdcqp_): Likewise. (xststdcnegqp_): Likewise. (xststdcqp_): Likewise. Back port from trunk 2017-11-06 Michael Meissner PR target/82748 * config/rs6000/rs6000-builtin.def (BU_FLOAT128_1): Delete float128 helper macros, which are no longer used after deleting the old 'q' built-in functions, and moving the round to odd built-in functions to being special built-in functions. (BU_FLOAT128_2): Likewise. (BU_FLOAT128_1_HW): Likewise. (BU_FLOAT128_2_HW): Likewise. (BU_FLOAT128_3_HW): Likewise. (FABSQ): Delete old 'q' built-in functions. (COPYSIGNQ): Likewise. (SQRTF128_ODD): Move round to odd built-in functions to be special built-in functions, so that we can handle -mabi=ieeelongdouble. (TRUNCF128_ODD): Likewise. (ADDF128_ODD): Likewise. (SUBF128_ODD): Likewise. (MULF128_ODD): Likewise. (DIVF128_ODD): Likewise. (FMAF128_ODD): Likewise. * config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Map old 'q' built-in names to 'f128'. * config/rs6000/rs6000.c (rs6000_fold_builtin): Remove folding the old 'q' built-in functions, as the machine independent code for 'f128' built-in functions handles this. (rs6000_expand_builtin): Add expansion for float128 round to odd functions, keying off on -mabi=ieeelongdouble of whether to use the KFmode or TFmode variant. (rs6000_init_builtins): Initialize the _Float128 round to odd built-in functions. * doc/extend.texi (PowerPC Built-in Functions): Document the old _Float128 'q' built-in functions are now mapped into the new 'f128' built-in functions. [gcc/testsuite] 2017-11-16 Michael Meissner Back port from trunk 2017-11-16 Michael Meissner * gcc.target/powerpc/bfp/bfp.exp: Look for *.c files, not *.c* files to prevent ~ files from getting
[Bug target/79845] rs6000: make code in rs6000.c more i18n-friendly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79845 --- Comment #4 from Michael Meissner --- Author: meissner Date: Thu Nov 16 20:29:52 2017 New Revision: 254846 URL: https://gcc.gnu.org/viewcvs?rev=254846=gcc=rev Log: [gcc] 2017-11-16 Michael MeissnerBack port from trunk 2017-11-16 Michael Meissner * config/rs6000/rs6000.c (rs6000_expand_builtin): Do not do the switch statement mapping KF built-ins to TF built-ins if we don't have the proper ISA 3.0 assembler support. Back port from trunk 2017-11-14 Michael Meissner * config/rs6000/rs6000-c.c (is_float128_p): New helper function. (rs6000_builtin_type_compatible): Treat _Float128 and long double as being compatible if -mabi=ieeelongdouble. * config/rs6000/rs6000-builtin.def (BU_FLOAT128_HW_1): New macros to setup float128 built-ins with hardware support. (BU_FLOAT128_HW_2): Likewise. (BU_FLOAT128_HW_3): Likewise. (BU_FLOAT128_HW_VSX_1): Likewise. (BU_FLOAT128_HW_VSX_2): Likewise. (scalar_extract_expq): Change float128 built-in functions to accommodate having both KFmode and TFmode functions. Use the KFmode variant as the default. (scalar_extract_sigq): Likewise. (scalar_test_neg_qp): Likewise. (scalar_insert_exp_q): Likewise. (scalar_insert_exp_qp): Likewise. (scalar_test_data_class_qp): Likewise. (sqrtf128_round_to_odd): Delete processing the round to odd built-in functions as special built-in functions, and define them as float128 built-ins. Use the KFmode variant as the default. (truncf128_round_to_odd): Likewise. (addf128_round_to_odd): Likewise. (subf128_round_to_odd): Likewise. (mulf128_round_to_odd): Likewise. (divf128_round_to_odd): Likewise. (fmaf128_round_to_odd): Likewise. * config/rs6000/rs6000.c (rs6000_expand_binop_builtin): Add support for KFmode and TFmode xststdcqp calls. (rs6000_expand_builtin): If long double is IEEE 128-bit floating point, switch the built-in handlers for the get/set float128 exponent, get float128 mantissa, float128 test built-ins, and the float128 round to odd built-in functions. Eliminate creating the float128 round to odd built-in functions as special built-ins. (rs6000_init_builtins): Eliminate special creation of the float128 round to odd built-in functions. * config/rs6000/vsx.md (xsxexpqp_): Change float128 built-in function insns to support both TFmode and KFmode variants. (xsxsigqp_): Likewise. (xsiexpqpf_): Likewise. (xsiexpqp_): Likewise. (xststdcqp_): Likewise. (xststdcnegqp_): Likewise. (xststdcqp_): Likewise. Back port from trunk 2017-11-06 Michael Meissner PR target/82748 * config/rs6000/rs6000-builtin.def (BU_FLOAT128_1): Delete float128 helper macros, which are no longer used after deleting the old 'q' built-in functions, and moving the round to odd built-in functions to being special built-in functions. (BU_FLOAT128_2): Likewise. (BU_FLOAT128_1_HW): Likewise. (BU_FLOAT128_2_HW): Likewise. (BU_FLOAT128_3_HW): Likewise. (FABSQ): Delete old 'q' built-in functions. (COPYSIGNQ): Likewise. (SQRTF128_ODD): Move round to odd built-in functions to be special built-in functions, so that we can handle -mabi=ieeelongdouble. (TRUNCF128_ODD): Likewise. (ADDF128_ODD): Likewise. (SUBF128_ODD): Likewise. (MULF128_ODD): Likewise. (DIVF128_ODD): Likewise. (FMAF128_ODD): Likewise. * config/rs6000/rs6000-c.c (rs6000_cpu_cpp_builtins): Map old 'q' built-in names to 'f128'. * config/rs6000/rs6000.c (rs6000_fold_builtin): Remove folding the old 'q' built-in functions, as the machine independent code for 'f128' built-in functions handles this. (rs6000_expand_builtin): Add expansion for float128 round to odd functions, keying off on -mabi=ieeelongdouble of whether to use the KFmode or TFmode variant. (rs6000_init_builtins): Initialize the _Float128 round to odd built-in functions. * doc/extend.texi (PowerPC Built-in Functions): Document the old _Float128 'q' built-in functions are now mapped into the new 'f128' built-in functions. [gcc/testsuite] 2017-11-16 Michael Meissner Back port from trunk 2017-11-16 Michael Meissner * gcc.target/powerpc/bfp/bfp.exp: Look for *.c files, not *.c* files to prevent ~ files from getting
[Bug bootstrap/82856] --enable-maintainter-mode broken by incompatiblity of gcc's required automake and modern Perl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82856 --- Comment #7 from Thomas Koenig --- Author: tkoenig Date: Thu Nov 16 20:24:00 2017 New Revision: 254845 URL: https://gcc.gnu.org/viewcvs?rev=254845=gcc=rev Log: 2017-11-16 Thomas KoenigPR bootstrap/82856 * doc/install.texi: Document incompatibility of Perl >=5.6.26 with the required version of automake 1.11.6. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
[Bug tree-optimization/82946] member pointer defeats strlen optimization involving a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82946 --- Comment #6 from Martin Sebor --- (In reply to rguent...@suse.de from comment #5) > This means you can very well replace memcpy with strcpy if you know > there's a '\0' in and only in the right place. Sure, except when dealing with a string literal we know that the source is a string literal and not a pointer representation disguised as a sequence of bytes. The optimization I'm referring to is specifically for string literals: unsigned g (struct A *a) { strcpy (a->d, "123"); // here we have a literal, not the representation of a pointer return strlen (a->d); // a->d must be a valid pointer } > We certainly have to treat literal pointers encoded in any form > conservatively. I don't see how they are against any standard. There's > other clearly "valid" optimizations missing in GCC that look more > important to implement. The C and C++ standards are clear as to what are valid pointer values and how they can come about. Copying the representation from an arbitrary constant of an incompatible type into a pointer object is certainly not one of them. I.e., this: const char a[] = "123"; char *p; memcpy (, a, sizeof p); strlen (p); is undefined, but this is of course valid: const char a[4] = "123"; char *p; char *q = a; memcpy (, , sizeof p); strlen (p); because it just copies the representation of what's known to be a valid pointer value into another pointer object of a compatible type. The point is that the bytes of no string literal can also be a valid pointer value, even if it happens to have the same representation as one, and this can be exploited to allow the optimization above. It will not invalidate any correct programs. It would be not only invalid but downright silly for a program to represent valid addresses as string literals. Embedded programs of course do hardcode pointer values, but not in string literals: they hardcode them as integers, e.g., void *my_register = (void*)0x123; but never like so: char my_register[] = "123";
[Bug c++/79092] template: type ignored if value already instantiated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79092 --- Comment #5 from Jason Merrill --- Author: jason Date: Thu Nov 16 20:13:48 2017 New Revision: 254843 URL: https://gcc.gnu.org/viewcvs?rev=254843=gcc=rev Log: PR c++/79092 - non-type args of different types are different * tree.c (cp_tree_equal): Check the type of constants. * pt.c (unify) [TEMPLATE_PARM_INDEX]: Handle UNIFY_ALLOW_INTEGER when comparing to previously deduced argument. (maybe_convert_nontype_argument): New. (convert_nontype_argument): Call it. (tsubst_copy_and_build): Handle partial instantiation of IMPLICIT_CONV_EXPR. (unify): Ignore type when deducing from array bound. (dependent_type_p_r): Handle DEFERRED_NOEXCEPT. (value_dependent_expression_p): Any type-dependent expression is value-dependent. Handle IMPLICIT_CONV_EXPR. * cp-tree.h (IMPLICIT_CONV_EXPR_NONTYPE_ARG): New. * mangle.c (write_template_arg): Strip IMPLICIT_CONV_EXPR. Added: trunk/gcc/testsuite/g++.dg/cpp1z/nontype-auto12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/mangle.c trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c
[Bug driver/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83016 Eric Botcazou changed: What|Removed |Added Severity|normal |minor
[Bug target/62011] False Data Dependency in popcnt instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011 Andrew Senkevich changed: What|Removed |Added CC||andrew.n.senkevich at gmail dot co ||m --- Comment #17 from Andrew Senkevich --- (In reply to Travis Downs from comment #16) > Also, this is fixed for Skylake for tzcnt and lzcnt but not popcnt. How to confirm it? As I see it is fixed for popcnt. Could you show some reproducer?
[Bug middle-end/83023] New: branch probabilities pessimize malloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83023 Bug ID: 83023 Summary: branch probabilities pessimize malloc Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- Created attachment 42625 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42625=edit exemplar on x86_64 compiled with -O2 -fdump-tree-all, the ma.cc.046t.profile_estimate contains: r_5 = malloc (s_3(D)); if (r_5 != 0B) goto ; [53.47%] else goto ; [46.53%] That's a pretty inaccurate guess at the behaviour of malloc!
[Bug fortran/83021] [7 Regression] gfortran segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83021 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2017-11-16 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Could you please provide the file(s) needed to generate local_field_module.mod? Revision r254377 for the 7 branch is OK.
[Bug fortran/83017] DO CONCURRENT not parallelizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017 --- Comment #12 from Dominique d'Humieres --- > Please use -fopt-info-loop to verify the loop is parallelized. You have > to use -floop-parallelize-all as well due to the cost model issue. If I use the commented loop I get with/without the patch % gfc -Ofast -ftree-parallelize-loops=4 -fopt-info-loop pr83017_db.f90 pr83017_db.f90:28:0: note: loop with 5 iterations completely unrolled (header execution count 379) pr83017_db.f90:26:0: note: loop with 5 iterations completely unrolled (header execution count 1515) pr83017_db.f90:38:0: note: loop with 5 iterations completely unrolled (header execution count 1515) pr83017_db.f90:18:0: note: loop with 4 iterations completely unrolled (header execution count 379) pr83017_db.f90:15:0: note: loop with 5 iterations completely unrolled (header execution count 379) pr83017_db.f90:47:0: note: parallelizing inner loop 6 pr83017_db.f90:24:0: note: basic block vectorized pr83017_db.f90:47:0: note: basic block vectorized % time ./a.out PI 2.98875999 PI 3.14159274 4.027u 0.015s 0:01.02 395.0%0+0k 0+0io 7pf+0w i.e., a loop is parallelized, and with -floop-parallelize-all % gfc -Ofast -ftree-parallelize-loops=4 -floop-parallelize-all -fopt-info-loop pr83017_db.f90 pr83017_db.f90:28:0: note: loop with 5 iterations completely unrolled (header execution count 379) pr83017_db.f90:26:0: note: loop with 5 iterations completely unrolled (header execution count 1515) pr83017_db.f90:38:0: note: loop with 5 iterations completely unrolled (header execution count 1515) pr83017_db.f90:18:0: note: loop with 4 iterations completely unrolled (header execution count 379) pr83017_db.f90:15:0: note: loop with 5 iterations completely unrolled (header execution count 379) pr83017_db.f90:26:0: note: parallelizing outer loop 3 pr83017_db.f90:24:0: note: basic block vectorized % time ./a.out PI 2.98876095 PI 3.14159274 4.152u 0.011s 0:04.16 100.0%0+0k 0+0io 0pf+0w i.e., the report says the loop is parallelized, but this is not reflected at run time (for the original test as well).
[Bug c++/82781] [6/7/8 Regression] Vector extension operators return wrong result in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82781 --- Comment #3 from Jakub Jelinek --- Created attachment 42624 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42624=edit gcc8-pr82781.patch Untested fix.
[Bug middle-end/83022] New: malloc & memset -> calloc is not always an optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83022 Bug ID: 83022 Summary: malloc & memset -> calloc is not always an optimization Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- Created attachment 42623 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42623=edit exemplar We like to optimize malloc followed by memset into a calloc call. Even when the memset is conditional. That's well formed, but pessimizes, and noticeable when the size is large and we do unnecessary clearing. The attached example, compiled on x86_64 with -O results in: _Z1mmb: movl$1, %esi jmp calloc But, it causes a noticeable performance regression, as 'c' is false sufficiently often and 's' is large sufficiently often.
[Bug web/78315] "Changes" don't explain what "LRA" is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78315 --- Comment #2 from Eric Gallager --- The "Changes" page for gcc-7 at least says now that LRA is "(a new local register allocator)"; is that enough?
[Bug fortran/83021] New: [7 Regression] gfortran segfault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83021 Bug ID: 83021 Summary: [7 Regression] gfortran segfault Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Target Milestone: --- Created attachment 42622 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42622=edit test case [forwarded from https://bugs.debian.org/881918] seen building open-coarrays with the gcc-7-branch 20171115, not seen on the branch 20171001 $ gfortran global_field.f90 -fcoarray=lib global_field.f90:126:0: lhs%values(:) = rhs%state() internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Program received signal SIGSEGV, Segmentation fault. 0x0067a16f in gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*) () (gdb) bt #0 0x0067a16f in gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*) () #1 0x0067cf7a in gfc_conv_expr_descriptor(gfc_se*, gfc_expr*) () #2 0x006a6572 in ?? () #3 0x006b9814 in gfc_conv_intrinsic_function(gfc_se*, gfc_expr*) () #4 0x006a0895 in ?? () #5 0x00696a3b in gfc_apply_interface_mapping(gfc_interface_mapping*, gfc_se*, gfc_expr*) () #6 0x0066ee45 in gfc_set_loop_bounds_from_array_spec(gfc_interface_mapping*, gfc_se*, gfc_array_spec*) () #7 0x0069f37e in gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) () #8 0x006a087d in ?? () #9 0x0067c239 in ?? () #10 0x0067cdf6 in gfc_conv_loop_setup(gfc_loopinfo*, locus*) () #11 0x006a32e0 in ?? () #12 0x00668b10 in ?? () #13 0x0068de98 in gfc_generate_function_code(gfc_namespace*) () #14 0x0066c86a in gfc_generate_module_code(gfc_namespace*) () #15 0x0062229c in gfc_parse_file() () #16 0x00665630 in ?? () #17 0x00a7ac6f in ?? () #18 0x0059923a in toplev::main(int, char**) () #19 0x0059b5eb in main ()
[Bug c++/82781] [6/7/8 Regression] Vector extension operators return wrong result in constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82781 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- I'll have a look.
[Bug debug/83010] [AARCH64] DW_AT_location is not emitted for thread local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83010 --- Comment #3 from Yao Qi --- (In reply to Jakub Jelinek from comment #2) > From quick look, it seems gas/ld just doesn't have corresponding support, so > that would need to be written first. There is R_AARCH64_TLS_DTPREL64 > relocation, wonder if that might do the job if gas has some way to emit that > relocation. Yes, beside gcc, something is needed in ld too. Clang emits DW_AT_location for TLS variable, but ld failed to link, $ ./clang+llvm-5.0.0-aarch64-linux-gnu/bin/clang -g 4.c -o 4.exe /usr/bin/ld: /tmp/4-767da1.o(.debug_info+0x37): R_AARCH64_ABS64 used with TLS symbol a_thread_local but gold is ok, $ ./clang+llvm-5.0.0-aarch64-linux-gnu/bin/clang -fuse-ld=gold -g 4.c -o 4.exe <1><2a>: Abbrev Number: 2 (DW_TAG_variable) <2b> DW_AT_name: (indirect string, offset: 0x3e): a_thread_local <2f> DW_AT_type: <0x40> <33> DW_AT_external: 1 <33> DW_AT_decl_file : 1 <34> DW_AT_decl_line : 2 <35> DW_AT_location: 10 byte block: e 0 0 0 0 0 0 0 0 e0 (DW_OP_const8u: 0 0; DW_OP_GNU_push_tls_address or DW_OP_HP_unknown)
[Bug c++/82799] [8 Regression] -Wunused-but-set-variable false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82799 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-16 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r253266.
[Bug fortran/82904] [7/8 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:261
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82904 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug fortran/82976] [8 Regression] Error: non-trivial conversion at assignment since r254526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82976 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/82977] [8 Regression] AddressSanitizer: heap-use-after-free in strlen_optimize_stmt .././../gcc/tree-ssa-strlen.c:2971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82977 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- The regression is fixed, the other issues still need work.
[Bug fortran/83012] [8 Regression] Simply contiguous pointer function not recognized as contiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83012 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 63441, which changed state. Bug 63441 Summary: incorrect "array subscript is below/above array bounds" diagnostic https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63441 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME
[Bug middle-end/63441] incorrect "array subscript is below/above array bounds" diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63441 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||5.4.0, 6.4.0, 7.1.0, 8.0 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=63477 Resolution|--- |WORKSFORME --- Comment #3 from Martin Sebor --- Just like with pr63477, I cannot reproduce the warning with this test case in GCC 8.0 anymore (despite what I said in comment #2), or 7-branch, or 6-branch, or even 5-branch. Just like in pr63477, bisection also points to r220157 (gcc 5.0.0) as the fix. So I'll assume that what I saw in comment #2 was some transient fluke and resolve this as worksforsome (based on comment #1 and #2 saying it would make sense to diagnose this).
[Bug debug/83010] [AARCH64] DW_AT_location is not emitted for thread local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83010 --- Comment #2 from Jakub Jelinek --- >From quick look, it seems gas/ld just doesn't have corresponding support, so that would need to be written first. There is R_AARCH64_TLS_DTPREL64 relocation, wonder if that might do the job if gas has some way to emit that relocation.
[Bug fortran/83017] DO CONCURRENT not parallelizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017 --- Comment #11 from rguenther at suse dot de --- On November 16, 2017 5:42:02 PM GMT+01:00, "dominiq at lps dot ens.fr"wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017 > >--- Comment #10 from Dominique d'Humieres >--- >> Created attachment 42621 [details] >> updated patch > >AFAICT the patch does not fix the problem: > >without the patch > > PI 2.98876095 > PI 3.14159274 >4.742u 0.015s 0:04.77 99.5% 0+0k 0+0io 36pf+0w > >with the patch > > PI 2.98876095 > PI 3.14159274 >4.782u 0.012s 0:04.80 99.7% 0+0k 0+0io 0pf+0w Please use - fopt-info-loop to verify the loop is parallelized. You have to use - floop-parallelize-all as well due to the cost model issue. It might be we employ the same cost model at runtime.
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 63477, which changed state. Bug 63477 Summary: [6/7/8 Regression] Bogus warning with -O3 -Warray-bounds: array subscript is above array bounds https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63477 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/63477] [6/7/8 Regression] Bogus warning with -O3 -Warray-bounds: array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63477 --- Comment #2 from Martin Sebor --- Author: msebor Date: Thu Nov 16 16:48:36 2017 New Revision: 254833 URL: https://gcc.gnu.org/viewcvs?rev=254833=gcc=rev Log: PR middle-end/63477 - Bogus warning with -O3 -Warray-bounds: array subscript is above array bounds gcc/testsuite/ChangeLog: PR middle-end/63477 * gcc.dg/pr63477.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr63477.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug middle-end/63477] [6/7/8 Regression] Bogus warning with -O3 -Warray-bounds: array subscript is above array bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63477 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Known to work||8.0 Resolution|--- |FIXED Known to fail|8.0 | --- Comment #3 from Martin Sebor --- Strangely, I cannot reproduce this warning anymore with GCC 8. Bisection points to r220157 (gcc 5.0.0) as the revision that fixed it. I've added the test case to the test suite in r254833 and with that I'm resolving this bug as fixed. Please reopen it if the problem reappears.
[Bug fortran/83017] DO CONCURRENT not parallelizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017 --- Comment #10 from Dominique d'Humieres --- > Created attachment 42621 [details] > updated patch AFAICT the patch does not fix the problem: without the patch PI 2.98876095 PI 3.14159274 4.742u 0.015s 0:04.77 99.5% 0+0k 0+0io 36pf+0w with the patch PI 2.98876095 PI 3.14159274 4.782u 0.012s 0:04.80 99.7% 0+0k 0+0io 0pf+0w
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 59124, which changed state. Bug 59124 Summary: [6 Regression] Wrong warnings "array subscript is above array bounds" https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/59124] [6 Regression] Wrong warnings "array subscript is above array bounds"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59124 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||msebor at gcc dot gnu.org Resolution|--- |FIXED Known to fail||8.0 --- Comment #47 from Martin Sebor --- None of the test cases here except for the one in comment #41 triggers -Warray-bounds with GCC 8.0. According to comments #42 and #43 the warning for the test case in comment #41 is a true positive. I'll go ahead and resolve this as fixed. I suggest to open a separate bug for any new/outstanding issues in this area to make it easier to track each separately.
[Bug debug/83010] [AARCH64] DW_AT_location is not emitted for thread local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83010 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jgreenhalgh at gcc dot gnu.org, ||ktkachov at gcc dot gnu.org, ||rearnsha at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That is because the aarch64 backend doesn't define TARGET_ASM_OUTPUT_DWARF_DTPREL hook. Either the assembler lacks the corresponding support, or just the backend doesn't define it even if it could.
[Bug tree-optimization/82588] missing -Warray-bounds on a excessively large index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82588 Martin Sebor changed: What|Removed |Added Known to work||8.0 Target Milestone|--- |8.0 Known to fail||5.4.0, 6.4.0, 7.2.0
[Bug c/68325] missing -Warray-bounds on a negative subscript into a flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68325 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||8.0 Resolution|--- |FIXED Target Milestone|--- |8.0 Known to fail||5.4.0, 6.4.0, 7.2.0 --- Comment #2 from Martin Sebor --- Fixed in r254830. GCC now issues the warnings below for the test case in comment #0: z.c: In function ‘foo’: z.c:7:16: warning: array subscript -2147483647 is below array bounds of ‘int[99]’ [-Warray-bounds] return s.a [-__INT_MAX__]; ^~ z.c: In function ‘bar’: z.c:12:17: warning: array subscript -2147483647 is below array bounds of ‘int[99]’ [-Warray-bounds] return p->a [-__INT_MAX__]; ~^~
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 82588, which changed state. Bug 82588 Summary: missing -Warray-bounds on a excessively large index https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82588 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/82588] missing -Warray-bounds on a excessively large index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82588 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=82455 Resolution|--- |FIXED --- Comment #5 from Martin Sebor --- The -Warrray-bounds part of the issue has been fixed in r254830. GCC now issues the warnings below for the test case in comment #0: a.c: In function ‘f1’: a.c:17:11: warning: array subscript 4611686018427387904 is above array bounds of ‘int[]’ [-Warray-bounds] return a[__SIZE_MAX__ / sizeof (int) + 1]; // missing -Warray-bounds ~^ a.c: In function ‘f2’: a.c:22:14: warning: array subscript 9223372036854775807 is above array bounds of ‘char[]’ [-Warray-bounds] return a->a[__SIZE_MAX__ / 2]; // missing -Warray-bounds ^~ The out-of-bounds offset is still not diagnosed. It's the subject of a separate bug (pr82455).
[Bug tree-optimization/82583] missing -Warray-bounds on out-of-bounds inner indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82583 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed in r254830. GCC now issues the warnings below for the test case in comment #0: a.c: In function ‘f’: a.c:6:12: warning: array subscript 4 is above array bounds of ‘int[4]’ [-Warray-bounds] p->a[1].a[4] = 1; ~^~~ a.c: In function ‘g’: a.c:11:7: warning: array subscript 2 is above array bounds of ‘struct A[2]’ [-Warray-bounds] p->a[2].a[3] = 1; ^~~
[Bug tree-optimization/56456] [meta-bug] bogus/missing -Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56456 Bug 56456 depends on bug 82583, which changed state. Bug 82583 Summary: missing -Warray-bounds on out-of-bounds inner indices https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82583 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/82588] missing -Warray-bounds on a excessively large index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82588 --- Comment #4 from Martin Sebor --- Author: msebor Date: Thu Nov 16 16:12:36 2017 New Revision: 254830 URL: https://gcc.gnu.org/viewcvs?rev=254830=gcc=rev Log: PR tree-optimization/82588 - missing -Warray-bounds on a excessively large index PR tree-optimization/82583 - missing -Warray-bounds on out-of-bounds inner indic gcc/ChangeLog: PR tree-optimization/82588 PR tree-optimization/82583 * tree-vrp.c (check_array_ref): Handle flexible array members, string literals, and inner indices. (search_for_addr_array): Add detail to diagnostics. gcc/testsuite/ChangeLog: PR tree-optimization/82588 PR tree-optimization/82583 * c-c++-common/Warray-bounds.c: New test. * gcc.dg/Warray-bounds-11.c: Adjust. * gcc.dg/Warray-bounds-22.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Warray-bounds.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-22.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/Warray-bounds-11.c trunk/gcc/tree-vrp.c
[Bug tree-optimization/82583] missing -Warray-bounds on out-of-bounds inner indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82583 --- Comment #3 from Martin Sebor --- Author: msebor Date: Thu Nov 16 16:12:36 2017 New Revision: 254830 URL: https://gcc.gnu.org/viewcvs?rev=254830=gcc=rev Log: PR tree-optimization/82588 - missing -Warray-bounds on a excessively large index PR tree-optimization/82583 - missing -Warray-bounds on out-of-bounds inner indic gcc/ChangeLog: PR tree-optimization/82588 PR tree-optimization/82583 * tree-vrp.c (check_array_ref): Handle flexible array members, string literals, and inner indices. (search_for_addr_array): Add detail to diagnostics. gcc/testsuite/ChangeLog: PR tree-optimization/82588 PR tree-optimization/82583 * c-c++-common/Warray-bounds.c: New test. * gcc.dg/Warray-bounds-11.c: Adjust. * gcc.dg/Warray-bounds-22.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Warray-bounds.c trunk/gcc/testsuite/gcc.dg/Warray-bounds-22.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/Warray-bounds-11.c trunk/gcc/tree-vrp.c
[Bug fortran/69455] [6/7/8 Regression] [F08] Assembler error(s) when using intrinsic modules in two BLOCK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69455 Ev Drikos changed: What|Removed |Added CC||drikosev at gmail dot com --- Comment #12 from Ev Drikos --- Is there any chance to see this patch? Thanks, Ev. Drikos
[Bug c++/83020] New: ('17) Class template constructor call skipped with no error when substitution fails in default argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83020 Bug ID: 83020 Summary: ('17) Class template constructor call skipped with no error when substitution fails in default argument Product: gcc Version: 7.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: oremanj at mit dot edu Target Milestone: --- The below C++ program is ill-formed, but gcc 7.1 and 7.2 accept it in C++17 mode, and emit code that simply doesn't call the constructor of Whoops at all. This is reproducible if the constructor is defined out-of-line as well; there's no reference to Whoops in the generated assembly. In C++14 mode or with gcc 6.3, the error is correctly diagnosed. $ cat t.cc struct NoDefault { int val = 1234; NoDefault(int v) : val(v) {} }; template struct Whoops { const char *str; T obj; Whoops(const char *s, T v = T()) : str(s), obj(v) {} }; const char *test() { return Whoops("hi").str; } $ g++-7 -O3 -std=c++17 -Wall -c t.cc && objdump -d t.o t.o: file format elf64-x86-64 Disassembly of section .text: <_Z4testv>: 0: 31 c0 xor%eax,%eax 2: c3 retq $ g++-7 -O0 -std=c++17 -Wall -c t.cc && objdump -d t.o t.o: file format elf64-x86-64 Disassembly of section .text: <_Z4testv>: 0: 55 push %rbp 1: 48 89 e5mov%rsp,%rbp 4: 5d pop%rbp 5: c3 retq $ g++-7 -v Using built-in specs. COLLECT_GCC=g++-7 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 7.2.0-12+hrtdeb8u1' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=gcc4-compatible --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-initfini-array Thread model: posix gcc version 7.2.1 20171025 (Debian 7.2.0-12)
[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878 --- Comment #18 from Eric Botcazou --- > all-gnattools: configure-gnattools > @: $(MAKE); $(unstage) > @r=`${PWD_COMMAND}`; export r; \ > s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \ > $(HOST_EXPORTS) \ > (cd $(HOST_SUBDIR)/gnattools && \ > $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS) > $(STAGE1_FLAGS_TO_PASS) \ > $(TARGET-gnattools)) > > so it builds for the host. But when bootstrapping we want to build it > similar to if it were a target library, that is, with the just built GCC. Yes, that's what happens, i.e. the CXX passed to gnattools is CXX_FOR_TARGET. > So, > > host_modules= { module= gnattools; }; > > is technically not correct. Not sure how it works during bootstrap, I'd have > expected that the host compiler is used as well (gnattools is not > bootstrapped). This would simply break, because the gnattools really need to be bootstrapped as they generally cannot be built by the host compiler. Quite puzzling indeed.
[Bug rtl-optimization/80818] LRA clobbers live hard reg clobbered during rematerialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80818 Andreas Krebbel changed: What|Removed |Added Priority|P3 |P2 --- Comment #8 from Andreas Krebbel --- Hi Vladimir. What do you think about the additional patch?
[Bug c++/83018] To support creation of header-only C++ libraries with SIMD optimization and dynamic dispatch, allow all x86 intrinsics regardless of target instruction set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83018 Richard Biener changed: What|Removed |Added Target||x86_64-*-* i?86-*-* Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Richard Biener --- You need to guard affected code portions with #pragma GCC target ("avx2") for example.
[Bug middle-end/83019] [8 Regression] Compiler dumps predictions with -nan%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83019 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0 Summary|Compiler dumps predictions |[8 Regression] Compiler |with -nan% |dumps predictions with ||-nan%
[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878 --- Comment #17 from Richard Biener --- (In reply to Eric Botcazou from comment #16) > This also breaks 'make all-gnattools' in a bootstrap build: > > g++ -std=gnu++98 -static-libstdc++ -static-libgcc -I- -I../rts -I. > -I/home/eric/svn/gcc/gcc/ada -static-libstdc++ -static-libgcc -DIN_GCC -g > -O2 -W -Wall -o ../../gnatmake b_gnatm.o a-except.o ali.o ali-util.o > aspects.o s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o > debug.o elists.o einfo.o errout.o erroutc.o errutil.o err_vars.o fmap.o > fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o > i-c.o i-cstrin.o krunch.o lib.o make.o makeusg.o make_util.o namet.o > nlists.o opt.o osint.o osint-m.o output.o restrict.o rident.o s-exctab.o > s-secsta.o s-stalib.o s-stoele.o scans.o scng.o sdefault.o sfn_scan.o > s-purexc.o s-htable.o scil_ll.o sem_aux.o sinfo.o sinput.o sinput-c.o > snames.o stand.o stringt.o styleg.o stylesw.o system.o validsw.o switch.o > switch-m.o table.o targparm.o tempdir.o tree_io.o types.o uintp.o uname.o > urealp.o usage.o widechar.o ../link.o ../targext.o ../../ggc-none.o > ../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a > ../rts/libgnat.a ../../../libbacktrace/.libs/libbacktrace.a > ../../../libiberty/libiberty.a -no-pie -ldl > g++: error: unrecognized command line option ‘-no-pie’ > ../gcc-interface/Makefile:2221: recipe for target '../../gnatmake' failed > make[2]: *** [../../gnatmake] Error 1 > make[2]: Leaving directory '/home/eric/build/gcc/native/gcc/ada/tools' > Makefile:188: recipe for target 'gnattools-native' failed > make[1]: *** [gnattools-native] Error 2 > make[1]: Leaving directory '/home/eric/build/gcc/native/gnattools' > Makefile:13917: recipe for target 'all-gnattools' failed > make: *** [all-gnattools] Error 2 > > During the bootstrap, CXX is set to /home/eric/build/gcc/native/./gcc/xg++ > -B/home/eric/build/gcc/native/./gcc/ so this still works. Hmm, all-gnattools does all-gnattools: configure-gnattools @: $(MAKE); $(unstage) @r=`${PWD_COMMAND}`; export r; \ s=`cd $(srcdir); ${PWD_COMMAND}`; export s; \ $(HOST_EXPORTS) \ (cd $(HOST_SUBDIR)/gnattools && \ $(MAKE) $(BASE_FLAGS_TO_PASS) $(EXTRA_HOST_FLAGS) $(STAGE1_FLAGS_TO_PASS) \ $(TARGET-gnattools)) so it builds for the host. But when bootstrapping we want to build it similar to if it were a target library, that is, with the just built GCC. So, host_modules= { module= gnattools; }; is technically not correct. Not sure how it works during bootstrap, I'd have expected that the host compiler is used as well (gnattools is not bootstrapped).
[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #24 from Nathan Sidwell --- Fixed r254823.
[Bug c++/82836] [8 Regression] ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82836 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Nathan Sidwell --- Fixed r254823.
[Bug c++/82836] [8 Regression] ICE on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82836 --- Comment #1 from Nathan Sidwell --- Author: nathan Date: Thu Nov 16 14:54:54 2017 New Revision: 254823 URL: https://gcc.gnu.org/viewcvs?rev=254823=gcc=rev Log: [PATCH] New lang hook https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01340.html PR c++/82836 PR c++/82737 * tree.h (COPY_DECL_RTL): Rename parms for clarity. (SET_DECL_ASSEMBLER_NAME): Forward to overwrite_decl_assembler_name. (COPY_DECL_ASSEMBLER_NAME): Rename parms for clarity. (overwrite_decl_assembler_name): Declare. * tree.c (overwrite_decl_assembler_name): New. * langhooks-def.h (lhd_overwrite_decl_assembler_name): Declare. (LANG_HOOKS_OVERWRITE_DECL_ASSEMBLER_NAME): Provide default. (LANG_HOOKS_INITIALIZER): Add it. * langhooks.h (struct lang_hooks): Add overwrite_decl_assembler_name. * langhooks.c (lhd_set_decl_assembler_name): Use SET_DECL_ASSEMBLER_NAME. (lhd_overwrite_decl_assembler_name): Default implementation. PR c++/82836 PR c++/82737 * cp-objcp-common.h (LANG_HOOKS_OVERWRITE_DECL_ASSEMBLER_NAME): Override. * cp-tree.h (overwrite_mangling): Declare. * decl2.c (struct mangled_decl_hash): Entries are deletable. (overwrite_mangling): New. PR c++/82836 PR c++/82737 * g++.dg/pr82836.C: New. Added: trunk/gcc/testsuite/g++.dg/pr82836.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-objcp-common.h trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/langhooks-def.h trunk/gcc/langhooks.c trunk/gcc/langhooks.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.h
[Bug c++/82737] [ICE] Compiler segfault on compilation of a certain file (full cause unknown) (file too large for upload, link provided)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82737 --- Comment #23 from Nathan Sidwell --- Author: nathan Date: Thu Nov 16 14:54:54 2017 New Revision: 254823 URL: https://gcc.gnu.org/viewcvs?rev=254823=gcc=rev Log: [PATCH] New lang hook https://gcc.gnu.org/ml/gcc-patches/2017-11/msg01340.html PR c++/82836 PR c++/82737 * tree.h (COPY_DECL_RTL): Rename parms for clarity. (SET_DECL_ASSEMBLER_NAME): Forward to overwrite_decl_assembler_name. (COPY_DECL_ASSEMBLER_NAME): Rename parms for clarity. (overwrite_decl_assembler_name): Declare. * tree.c (overwrite_decl_assembler_name): New. * langhooks-def.h (lhd_overwrite_decl_assembler_name): Declare. (LANG_HOOKS_OVERWRITE_DECL_ASSEMBLER_NAME): Provide default. (LANG_HOOKS_INITIALIZER): Add it. * langhooks.h (struct lang_hooks): Add overwrite_decl_assembler_name. * langhooks.c (lhd_set_decl_assembler_name): Use SET_DECL_ASSEMBLER_NAME. (lhd_overwrite_decl_assembler_name): Default implementation. PR c++/82836 PR c++/82737 * cp-objcp-common.h (LANG_HOOKS_OVERWRITE_DECL_ASSEMBLER_NAME): Override. * cp-tree.h (overwrite_mangling): Declare. * decl2.c (struct mangled_decl_hash): Entries are deletable. (overwrite_mangling): New. PR c++/82836 PR c++/82737 * g++.dg/pr82836.C: New. Added: trunk/gcc/testsuite/g++.dg/pr82836.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-objcp-common.h trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl2.c trunk/gcc/langhooks-def.h trunk/gcc/langhooks.c trunk/gcc/langhooks.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.h
[Bug driver/83016] gnat1: warning: command line option ‘-nostdinc++’ is valid for C++/ObjC++ but not for Ada
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83016 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-11-16 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Eric Botcazou --- Known old problem, gnatlink is invoked with: /home/eric/build/gcc/native/gcc/ada/tools/gnatclean.ali ../../gnatlink -v gnatcmd -o ../../gnat \ --GCC="/home/eric/build/gcc/native/./gcc/xg++ -B/home/eric/build/gcc/native/./gcc/ -nostdinc++ -nostdinc++ -I/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/include/x86_64-suse-linux -I/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/include -I/home/eric/svn/gcc/libstdc++-v3/libsupc++ -I/home/eric/svn/gcc/libstdc++-v3/include/backward -I/home/eric/svn/gcc/libstdc++-v3/testsuite/util -L/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/src -L/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/src/.libs -L/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/libsupc++/.libs -B/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/src/.libs -B/home/eric/build/gcc/native/x86_64-suse-linux/libstdc++-v3/libsupc++/.libs -B/home/eric/install/gcc/x86_64-suse-linux/bin/ -B/home/eric/install/gcc/x86_64-suse-linux/lib/ -isystem /home/eric/install/gcc/x86_64-suse-linux/include -isystem /home/eric/install/gcc/x86_64-suse-linux/sys-include-static-libstdc++ -static-libgcc -I- -I../rts -I. -I/home/eric/svn/gcc/gcc/ada -static-libstdc++ -static-libgcc " ../link.o ../targext.o ../../ggc-none.o ../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a ../rts/libgnat.a ../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a -no-pie
[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878 --- Comment #16 from Eric Botcazou --- This also breaks 'make all-gnattools' in a bootstrap build: g++ -std=gnu++98 -static-libstdc++ -static-libgcc -I- -I../rts -I. -I/home/eric/svn/gcc/gcc/ada -static-libstdc++ -static-libgcc -DIN_GCC -g -O2 -W -Wall -o ../../gnatmake b_gnatm.o a-except.o ali.o ali-util.o aspects.o s-casuti.o alloc.o atree.o binderr.o butil.o casing.o csets.o debug.o elists.o einfo.o errout.o erroutc.o errutil.o err_vars.o fmap.o fname.o fname-uf.o fname-sf.o gnatmake.o gnatvsn.o hostparm.o interfac.o i-c.o i-cstrin.o krunch.o lib.o make.o makeusg.o make_util.o namet.o nlists.o opt.o osint.o osint-m.o output.o restrict.o rident.o s-exctab.o s-secsta.o s-stalib.o s-stoele.o scans.o scng.o sdefault.o sfn_scan.o s-purexc.o s-htable.o scil_ll.o sem_aux.o sinfo.o sinput.o sinput-c.o snames.o stand.o stringt.o styleg.o stylesw.o system.o validsw.o switch.o switch-m.o table.o targparm.o tempdir.o tree_io.o types.o uintp.o uname.o urealp.o usage.o widechar.o ../link.o ../targext.o ../../ggc-none.o ../../libcommon-target.a ../../libcommon.a ../../../libcpp/libcpp.a ../rts/libgnat.a ../../../libbacktrace/.libs/libbacktrace.a ../../../libiberty/libiberty.a -no-pie -ldl g++: error: unrecognized command line option ‘-no-pie’ ../gcc-interface/Makefile:2221: recipe for target '../../gnatmake' failed make[2]: *** [../../gnatmake] Error 1 make[2]: Leaving directory '/home/eric/build/gcc/native/gcc/ada/tools' Makefile:188: recipe for target 'gnattools-native' failed make[1]: *** [gnattools-native] Error 2 make[1]: Leaving directory '/home/eric/build/gcc/native/gnattools' Makefile:13917: recipe for target 'all-gnattools' failed make: *** [all-gnattools] Error 2 During the bootstrap, CXX is set to /home/eric/build/gcc/native/./gcc/xg++ -B/home/eric/build/gcc/native/./gcc/ so this still works.
[Bug middle-end/83019] Compiler dumps predictions with -nan%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83019 Uroš Bizjak changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #1 from Uroš Bizjak --- Adding CC.
[Bug middle-end/83019] New: Compiler dumps predictions with -nan%
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83019 Bug ID: 83019 Summary: Compiler dumps predictions with -nan% Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target Milestone: --- Recent patch caused some dumps to dump -nam%. One example is gcc.dg/graphite/interchange-12.c, which generates: ./cc1 -O2 -ffast-math -floop-nest-optimize -fdump-tree-graphite-all interchange-12.c interchange-12.c.150t.graphite: ... Predictions for bb 29 first match heuristics: 99.0% exec 0 (estimated locally) hit 0 (estimated locally) (-nan%) combined heuristics: 99.0% exec 0 (estimated locally) hit 0 (estimated locally) (-nan%) loop iterations heuristics of edge 29->28: 1.0% exec 0 (estimated locally) hit 0 (estimated locally) (-nan%) Predictions for bb 30 1 edges in bb 30 predicted to even probabilities Predictions for bb 28 first match heuristics: 99.0% exec 0 (estimated locally) hit 0 (estimated locally) (-nan%) combined heuristics: 99.0% exec 0 (estimated locally) hit 0 (estimated locally) (-nan%) loop iterations heuristics of edge 28->22: 1.0% exec 0 (estimated locally) hit 0 (estimated locally) (-nan%) ... The above dump was generated with x86_64-linux-gnu host. This is problematic with hosts (e.g. alpha) that require -mieee when dealing with NaNs, resulting in several ICEs [1]. The cause is the division 0/0 in: Program received signal SIGFPE, Arithmetic exception. 0x0001207a4ee4 in dump_prediction (file=0x121665bf0, predictor=, probability=, bb=0x299df48, reason=, ep_edge=) at /space/homedirs/uros/gcc-svn/trunk/gcc/predict.c:750 750 fprintf (file, " (%.1f%%)", e->count ().to_gcov_type() * 100.0 (gdb) bt #0 0x0001207a4ee4 in dump_prediction (file=0x121665bf0, predictor=, probability=, bb=0x299df48, reason=, ep_edge=) at /space/homedirs/uros/gcc-svn/trunk/gcc/predict.c:750 #1 0x0001207af424 in combine_predictions_for_bb (bb=0x299df48, dry_run=) at /space/homedirs/uros/gcc-svn/trunk/gcc/predict.c:1 270 #2 0x0001207b23d0 in tree_estimate_probability (dry_run=) at /space/homedirs/uros/gcc-svn/trunk/gcc/predict.c:2819 #3 0x000120f6bf24 in graphite_transform_loops () at /space/homedirs/uros/gcc-svn/trunk/gcc/graphite.c:425 #4 0x000120f6d374 in graphite_transforms (fun=0x12120fc31) at /space/homedirs/uros/gcc-svn/trunk/gcc/graphite.c:447 #5 (anonymous namespace)::pass_graphite_transforms::execute (this=0x121665bf0, fun=0x12120fc31) at /space/homedirs/uros/gcc-svn/trunk/gcc/graphite.c: 524 #6 0x00012078b038 in execute_one_pass (pass=0x1214fe7c0) at /space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2497 #7 0x00012078bc08 in execute_pass_list_1 (pass=0x1214fe7c0) at /space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2586 #8 0x00012078bc24 in execute_pass_list_1 (pass=0x1214fe760) at /space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2587 #9 0x00012078bc24 in execute_pass_list_1 (pass=0x1214fe400) at /space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2587 #10 0x00012078bc24 in execute_pass_list_1 (pass=0x1214fd070) at /space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2587 #11 0x00012078bca4 in execute_pass_list (fn=, pass=0x12120fc31) at /space/homedirs/uros/gcc-svn/trunk/gcc/passes.c:2597 #12 0x000120363804 in cgraph_node::expand (this=0x29c8000) at /space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2139 #13 0x0001203652a0 in expand_all_functions () at /space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2275 #14 symbol_table::compile (this=) at /space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2623 #15 0x00012036874c in compile (this=0x28a4000) at /space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2682 #16 symbol_table::finalize_compilation_unit (this=0x28a4000) at /space/homedirs/uros/gcc-svn/trunk/gcc/cgraphunit.c:2716 #17 0x0001208a695c in compile_file () at /space/homedirs/uros/gcc-svn/trunk/gcc/toplev.c:480 #18 0x00012013ae90 in do_compile () at /space/homedirs/uros/gcc-svn/trunk/gcc/toplev.c:2060 #19 toplev::main (this=0x11fdff040, argc=, argv=) at /space/homedirs/uros/gcc-svn/trunk/gcc/toplev.c:2195 #20 0x00012013cf60 in main (argc=, argv=0x11fdff168) at /space/homedirs/uros/gcc-svn/trunk/gcc/main.c:39 (gdb) list 745 bb->count.dump (file); 746 if (e) 747 { 748 fprintf (file, " hit "); 749 e->count ().dump (file); 750 fprintf (file, " (%.1f%%)", e->count ().to_gcov_type() * 100.0 751/ bb->count.to_gcov_type ()); 752 } 753 } 754 [1] https://gcc.gnu.org/ml/gcc-testresults/2017-11/msg01330.html
[Bug c++/83018] New: To support creation of header-only C++ libraries with SIMD optimization and dynamic dispatch, allow all intrinsics regardless of target architecture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83018 Bug ID: 83018 Summary: To support creation of header-only C++ libraries with SIMD optimization and dynamic dispatch, allow all intrinsics regardless of target architecture Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: kerukuro at gmail dot com Target Milestone: --- Visual C++ already does this. Using Visual C++, I can use e.g. AVX2 intrinsics in a program compiled with SSE2 target architecture and dispatch to that code path dynamically if CPU supports AVX2. GCC requires compiling separate object files to achieve that, which is not possible for header-only libraries.
[Bug fortran/83017] DO CONCURRENT not parallelizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #9 from Richard Biener --- Created attachment 42621 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42621=edit updated patch
[Bug fortran/83017] DO CONCURRENT not parallelizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017 --- Comment #8 from Richard Biener --- Created attachment 42620 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42620=edit patch Otherwise untested patch. Note ivdep is mapped to safelen which isn't useful for parallelization given safelen perserves forward dependences.
[Bug fortran/83017] DO CONCURRENT not parallelizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017 --- Comment #7 from Richard Biener --- If I "fix" GCC to consider the loop you annotate parallel: do concurrent (i = 1:nsplit) pi(i) = sum(compute( low(i), high(i) )) end do then we arrive at computing 4 iterations of that loop and with 2 threads and MIN_PER_THREAD 100 (arbitrary define) we run into if (!flag_loop_parallelize_all && !oacc_kernels_p && ((estimated != -1 && estimated <= (HOST_WIDE_INT) n_threads * MIN_PER_THREAD) /* Do not bother with loops in cold areas. */ || optimize_loop_nest_for_size_p (loop))) continue; (estimated is 4). With -floop-parallelize-all I then get: > ./f951 -quiet t.f90 -Ofast -ftree-parallelize-loops=2 > -fdump-tree-parloops-details -floop-parallelize-all -fopt-info-loop t.f90:28:0: note: loop with 5 iterations completely unrolled (header execution count 375) t.f90:26:0: note: loop with 5 iterations completely unrolled (header execution count 1500) t.f90:38:0: note: loop with 5 iterations completely unrolled (header execution count 1500) t.f90:18:0: note: loop with 4 iterations completely unrolled (header execution count 375) t.f90:15:0: note: loop with 5 iterations completely unrolled (header execution count 375) t.f90:26:0: note: parallelizing outer loop 3 t.f90:24:0: note: basic block vectorized t.f90:41:0: note: basic block vectorized t.f90:41:0: note: basic block vectorized yay.
[Bug fortran/83017] DO CONCURRENT not parallelizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017 --- Comment #6 from rguenther at suse dot de --- On November 16, 2017 2:22:50 PM GMT+01:00, cfztol at hotmail dot comwrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017 > >--- Comment #5 from Christian Felter --- >Okay, sounds like there is hope. By the way, the problem also exists >without a >function call. Declaring > > real, dimension(nsplit) :: tmp > >and replacing the loop with > > do concurrent (i = 1:nsplit) > > tmp = 0 > do j = low(i), high(i) > k = mod( j, nsplit ) + 1 > tmp(k) = tmp(k) + (-1)**(j+1) / real( 2*j-1 ) > end do > pi(i) = sum(tmp) > > end do > >also inhibits parallelization. What does do concurrent guarantee?
[Bug c++/83000] Constraints for union-templates do not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83000 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #1 from ensadc at mailnesia dot com --- Possible duplicate of issue 67217
[Bug c++/83003] Using the detection idiom and void_t causes an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83003 ensadc at mailnesia dot com changed: What|Removed |Added CC||ensadc at mailnesia dot com --- Comment #3 from ensadc at mailnesia dot com --- There doesn't even need to be a specialization of Zod. template class, class = void> struct dtect1 { enum { value = 0 }; }; template class TT> struct dtect1 { enum { value = 1 }; }; template struct Zod { }; template using Zod_t = typename Zod::type; static_assert(!dtect1::value, ""); Zod_t z2; // !!
[Bug fortran/83017] DO CONCURRENT not parallelizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017 --- Comment #5 from Christian Felter --- Okay, sounds like there is hope. By the way, the problem also exists without a function call. Declaring real, dimension(nsplit) :: tmp and replacing the loop with do concurrent (i = 1:nsplit) tmp = 0 do j = low(i), high(i) k = mod( j, nsplit ) + 1 tmp(k) = tmp(k) + (-1)**(j+1) / real( 2*j-1 ) end do pi(i) = sum(tmp) end do also inhibits parallelization.
[Bug sanitizer/83014] ICE in pretty-print with -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83014 --- Comment #6 from Martin Liška --- Sorry, but I can't reproduce on linux with cross compiler for mingw32.
[Bug fortran/83017] DO CONCURRENT not parallelizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017 --- Comment #4 from rguenther at suse dot de --- On November 16, 2017 1:22:37 PM GMT+01:00, cfztol at hotmail dot comwrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017 > >--- Comment #3 from Christian Felter --- >Ultimately, I wanted to compute k like this > >k = permutation( j ) > >where permutation is a 1D array of integers (from 1 to 4, e.g. [ 1, 4, >2, 1, 3, >... etc] ). This would allow an easy way of parallelizing the so-called >"finite >element assembly procedure". But I guess, this case is even harder. >Clearly, I >must have misunderstood the requirements for DO CONCURRENT... Maybe >they could >be relaxed ? It's more an optimization pass issue or the frontend not communicating guarantees for dependencies downstream. Might be a bit tricky for function calls.
[Bug fortran/83017] DO CONCURRENT not parallelizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83017 --- Comment #3 from Christian Felter --- Ultimately, I wanted to compute k like this k = permutation( j ) where permutation is a 1D array of integers (from 1 to 4, e.g. [ 1, 4, 2, 1, 3, ... etc] ). This would allow an easy way of parallelizing the so-called "finite element assembly procedure". But I guess, this case is even harder. Clearly, I must have misunderstood the requirements for DO CONCURRENT... Maybe they could be relaxed ?
[Bug c++/79331] ICE on valid C++14 code (with initialized lambda capture) on x86_64-linux-gnu: in canonicalize_component_ref, at gimplify.c:2451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79331 Nathan Sidwell changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Nathan Sidwell --- This is the same as 81574 and now fixed: PR c++/81574 * lambda.c (lambda_capture_field_type): Function references are always catured by reference.