[Bug jit/66074] gcc_jit_result_get_code returns a void*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66074 --- Comment #2 from Eric Gallager --- David, are you the assignee on this because you're actually working on it, or just because that's the default for bugs filed under the "jit" component?
[Bug go/52357] 64bit-out.go and go.test/test/cmplxdivide.go time out on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52357 Eric Gallager changed: What|Removed |Added Status|WAITING |SUSPENDED --- Comment #6 from Eric Gallager --- (In reply to Eric Gallager from comment #5) > (In reply to Ian Lance Taylor from comment #3) > > The 64bit-out.go case appears to be similar. It is also a generated file, > > and it also takes a long time to compile. The register allocator is not > > quite as dominant, only 43% of compilation time. In any case I will revisit > > 64bit-out when and if cmplxdivide is fixed. > > Has cmplxdivide been fixed yet? No reply; changing to SUSPENDED since this isn't really a case where closing as INVALID (due to lack of response) is applicable
[Bug jit/64196] No automated test coverage for debugging of JIT-generated code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64196 --- Comment #3 from Eric Gallager --- (In reply to Eric Gallager from comment #2) > (In reply to David Malcolm from comment #0) > > gcc/jit/docs/intro/tutorial04.rst shows an example of debugging, > > single-stepping through JIT-generated code in gdb [1]. > > > > This was all tested by hand. We don't yet have any automated test coverage > > to verify that this works. > > > > [1]: built HTML version of this currently here: > > https://dmalcolm.fedorapeople.org/gcc/libgccjit-api-docs/intro/tutorial04. > > html#single-stepping-through-the-generated-code > > Are you still working on this? Guess not; unassigning
[Bug c++/46476] Missing Warning about unreachable code after return [-Wunreachable-code-return]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46476 Eric Gallager changed: What|Removed |Added Blocks||89863 --- Comment #17 from Eric Gallager --- (In reply to David Binderman from comment #16) > (In reply to Manuel López-Ibáñez from comment #14) > > But the main barrier for this is not technical or acceptance, it is > > leadership and human resources. > > And the usual time and money. There are plenty of static analysers out there. > Unless it is substantially better, why write another one ? > > My favourite static analyser, cppcheck, says this for the original code: > > $ ~/cppcheck/trunk/cppcheck --enable=all bug46476.cc > [bug46476.cc:5]: (style) Statements following return, break, continue, goto > or throw will never be executed. > [bug46476.cc:11]: (style) Statements following return, break, continue, goto > or throw will never be executed. > [bug46476.cc:8]: (style) The function 'bar' is never used. > [bug46476.cc:2]: (style) The function 'foo' is never used. > $ > > which pretty much does the job. > > Running the same static analyser over the source code of a recent gcc > found 22 occurrences of this kind of problem. > > Here they are: > > $ fgrep "Statements following" cppcheck.20170617.out > [trunk/gcc/c/c-decl.c:3211]: (style) Statements following return, break, > continue, goto or throw will never be executed. > [trunk/gcc/fortran/arith.c:2009]: (style) Statements following return, > break, continue, goto or throw will never be executed. > [trunk/libbacktrace/dwarf.c:2709]: (style) Statements following return, > break, continue, goto or throw will never be executed. > [trunk/libbacktrace/dwarf.c:2758]: (style) Statements following return, > break, continue, goto or throw will never be executed. > [trunk/libbacktrace/dwarf.c:2892]: (style) Statements following return, > break, continue, goto or throw will never be executed. > [trunk/libbacktrace/dwarf.c:3025]: (style) Statements following return, > break, continue, goto or throw will never be executed. > [trunk/libbacktrace/elf.c:448]: (style) Statements following return, break, > continue, goto or throw will never be executed. > [trunk/libbacktrace/elf.c:493]: (style) Statements following return, break, > continue, goto or throw will never be executed. > [trunk/libbacktrace/elf.c:967]: (style) Statements following return, break, > continue, goto or throw will never be executed. > [trunk/libbacktrace/fileline.c:64]: (style) Statements following return, > break, continue, goto or throw will never be executed. > [trunk/libbacktrace/fileline.c:75]: (style) Statements following return, > break, continue, goto or throw will never be executed. > [trunk/libbacktrace/pecoff.c:499]: (style) Statements following return, > break, continue, goto or throw will never be executed. > [trunk/libbacktrace/pecoff.c:564]: (style) Statements following return, > break, continue, goto or throw will never be executed. > [trunk/libbacktrace/pecoff.c:931]: (style) Statements following return, > break, continue, goto or throw will never be executed. > [trunk/libcilkrts/runtime/cilk_fiber.cpp:968]: (style) Statements following > return, break, continue, goto or throw will never be executed. > [trunk/libcilkrts/runtime/scheduler.c:2468]: (style) Statements following > return, break, continue, goto or throw will never be executed. > [trunk/libcilkrts/runtime/scheduler.c:2550]: (style) Statements following > return, break, continue, goto or throw will never be executed. > [trunk/libcilkrts/runtime/scheduler.c:2439]: (style) Statements following > return, break, continue, goto or throw will never be executed. > [trunk/libffi/src/dlmalloc.c:3877]: (style) Statements following return, > break, continue, goto or throw will never be executed. > [trunk/libgomp/error.c:90]: (style) Statements following return, break, > continue, goto or throw will never be executed. > [trunk/libgomp/libgomp-plugin.c:79]: (style) Statements following return, > break, continue, goto or throw will never be executed. > [trunk/libobjc/error.c:41]: (style) Statements following return, break, > continue, goto or throw will never be executed. > $ > > Most of them seem to be in libbacktrace. I could look deeper into these > and generate some bug reports. That's the usual way to provoke gcc developers > into developing a new warning: show that the gcc source code would benefit > from it. Dunno how I missed this when I created the new cppcheck meta-bug; adding this as a dependency for it now Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 [Bug 89863] [meta-bug] Issues that cppcheck finds that gcc misses
[Bug debug/42065] DWARF .debug_macinfo contains unused macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42065 --- Comment #5 from Eric Gallager --- (In reply to Eric Gallager from comment #4) > If -feliminate-unused-debug-symbols and/or -feliminate-unused-debug-types > start removing these, I'd want them to turn on -Wunused-macros automatically > for me as well so I can know about it Does the EnabledBy() thing in .opt files work across the -f/-W option prefix boundary, or are only warnings able to enable other warnings?
[Bug c++/77449] False ambiguity for variadic function with non-deduced template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77449 Eric Gallager changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-04-01 Ever confirmed|0 |1 --- Comment #3 from Eric Gallager --- (In reply to Roland B from comment #2) > (In reply to Eric Gallager from comment #1) > > As a human reader who doesn't know C++ very well I'd consider it to be > > ambiguous, too... maybe as a compromise the error could be downgraded to a > > warning? > > "int" is more specified than "typename Check", see also > http://stackoverflow.com/a/39295906/2173029 > > g++ agrees to this under pretty much all circumstances, except this one with > a parameter pack. OK I'll take your word for it then, I guess, and confirm it... adding the "rejects-valid" keyword because that's what it sounds like it is
[Bug middle-end/89725] [8/9 Regression] ICE in get_fnname_from_decl, at varasm.c:1723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89725 --- Comment #11 from bin cheng --- In case of data reference has more access functions than loop_nest of data dependence analysis, we need to skip/ignore access functions corresponding loops not in the loop_nest. So far this only happens in loop interchange since we want to reuse data references collected in outer loop. During computing classic dist/dir vector, we need to avoid out-of-bound memory access. Univariate SCEV can be simply bypassed by checking the loop/chrec_variable as patch in comment #7. Of course, add_other_self_distances needs to be handled as well. On the other hand, bypassing multivariate would be harder and the impact is not yet clear, however, we can take another strategy handling SCEV of outer loop as invariant (symbol) to loop_nest during dependence analysis. As a matter of fact, current code already does in various places, i.e, with calling to evolution_function_is_invariant_rec_p etc. After scanning, I think the only piece missing is in analyze_miv_subscript. I am testing a patch.
[Bug c++/89898] New: invalid function template definition with non-type class argument accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89898
Bug ID: 89898
Summary: invalid function template definition with non-type
class argument accepted
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
In the following, the invalid function template definition is accepted in c++2a
mode:
$ cat z.C && gcc -c -Wall -std=c++2a z.C
struct A { };
template struct X { };
template > void f () { } // invalid
[Bug debug/89792] gcc generates wrong debug information at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89792 Qirun Zhang changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Qirun Zhang --- Fixed in r269961.
[Bug debug/89791] gcc generates wrong debug information at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89791 Qirun Zhang changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Qirun Zhang --- Fixed in r269961.
[Bug c++/89878] same specializations on a zero-initialized struct object as a non-type parameter treated as distinct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89878
Martin Sebor changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #1 from Martin Sebor ---
The converse of accepting multiple definitions of the same symbol is that valid
redeclarations of the same symbol are rejected as shown in the test case below:
$ cat z.C && gcc -c -Wall -std=c++2a z.C
struct A1 { char c[5]; };
template struct B { };
typedef B A_A;
typedef B A_AZ___;
typedef BA_AZZ__;
typedef B A_AZZZ_;
typedef B A_A;
extern A_A same_type_B_A1_A;
extern A_AZ___ same_type_B_A1_A;
extern A_AZZ__ same_type_B_A1_A;
extern A_AZZZ_ same_type_B_A1_A;
extern A_A same_type_B_A1_A;
z.C:12:16: error: conflicting declaration ‘A_AZ___ same_type_B_A1_A’
12 | extern A_AZ___ same_type_B_A1_A;
|^~~~
z.C:11:16: note: previous declaration as ‘A_A same_type_B_A1_A’
11 | extern A_A same_type_B_A1_A;
|^~~~
z.C:13:16: error: conflicting declaration ‘A_AZZ__ same_type_B_A1_A’
13 | extern A_AZZ__ same_type_B_A1_A;
|^~~~
z.C:11:16: note: previous declaration as ‘A_A same_type_B_A1_A’
11 | extern A_A same_type_B_A1_A;
|^~~~
z.C:14:16: error: conflicting declaration ‘A_AZZZ_ same_type_B_A1_A’
14 | extern A_AZZZ_ same_type_B_A1_A;
|^~~~
z.C:11:16: note: previous declaration as ‘A_A same_type_B_A1_A’
11 | extern A_A same_type_B_A1_A;
|^~~~
z.C:15:16: error: conflicting declaration ‘A_A same_type_B_A1_A’
15 | extern A_A same_type_B_A1_A;
|^~~~
z.C:11:16: note: previous declaration as ‘A_A same_type_B_A1_A’
11 | extern A_A same_type_B_A1_A;
|^~~~
[Bug debug/88882] gcc generates wrong debug information at -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2 --- Comment #2 from Qirun Zhang --- Bisection points to r216247.
[Bug rtl-optimization/88730] [8 Regression] gcc generates wrong debug information at -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88730 --- Comment #4 from Qirun Zhang --- Bisection points to r254888.
[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 --- Comment #15 from Thomas Koenig --- (In reply to Thomas Koenig from comment #14) > https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01478.html > might also cure this one, without source I cannot tell. No, it does not help.
[Bug fortran/35276] Doc should described how to compile mixed-language programs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35276 Thomas Koenig changed: What|Removed |Added Status|WAITING |NEW --- Comment #6 from Thomas Koenig --- (In reply to Eric Gallager from comment #5) > (In reply to Jürgen Reuter from comment #4) > > It seems that at least Thomas and Dominique believe that this can be closed. > > with which status? We need to extend that chapter with the new status for gcc 9 after Paul's fixes have all gone in. After that, I we should close this as FIXED.
[Bug c++/89852] [9 Regression] ICE: unexpected expression of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89852 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed.
[Bug c++/89852] [9 Regression] ICE: unexpected expression of kind implicit_conv_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89852
--- Comment #4 from Marek Polacek ---
Author: mpolacek
Date: Sun Mar 31 20:37:22 2019
New Revision: 270048
URL: https://gcc.gnu.org/viewcvs?rev=270048=gcc=rev
Log:
PR c++/89852 - ICE with C++11 functional cast with { }.
* constexpr.c (fold_non_dependent_expr_template): New static function
broken out of...
(fold_non_dependent_expr): ...here.
(fold_non_dependent_init): New function.
* cp-tree.h (fold_non_dependent_init): Declare.
* typeck2.c (massage_init_elt): Call fold_non_dependent_init instead
of fold_non_dependent_expr. Don't call maybe_constant_init.
* g++.dg/cpp0x/initlist115.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/initlist115.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog
[Bug fortran/85868] Subarray of a pointer array associated with a pointer dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85868 anlauf at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=52351 --- Comment #7 from anlauf at gcc dot gnu.org --- PR52351 (Wrong bounds when passing an array section to an intent-in pointer dummy) is related to this one.
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #21 from anlauf at gcc dot gnu.org --- (In reply to DIL from comment #20) > Thanks for fixing this bug! Sorry, I have not had time yet to create a > reduced non-trivial test case. Would you still like to add it later if I > make it? If yes, should I just attach it later to this closed bug report? Just attach it to this PR. I'll try to take care of it.
[Bug fortran/88139] ICE in get_c_type_name, at fortran/dump-parse-tree.c:3047
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88139 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #5) > (In reply to kargl from comment #4) > > I had a patch for this, but lost it when committing my last 10 patches. > > Thankfully, there are mailing list archives. See > > https://gcc.gnu.org/ml/fortran/2018-12/msg00038.html > > for the patch. Steve, do you plan to submit it before it bit-rots?
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #20 from DIL --- (In reply to anlauf from comment #19) > Fixed on trunk and all open branches (7/8). > > Closing, as no reduced run-time testcase was provided. > Please reopen or create a new PR if an issue is found. > > Thanks for the report! Thanks for fixing this bug! Sorry, I have not had time yet to create a reduced non-trivial test case. Would you still like to add it later if I make it? If yes, should I just attach it later to this closed bug report?
[Bug tree-optimization/46590] long compile time with -O2 and many loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46590 --- Comment #48 from Thomas Koenig --- The test case from comment#5 and comment#6 has regressed for M7/8/9: $ time gfortran-4.8 -O1 gener-4.f90 real0m11.509s user0m11.356s sys 0m0.148s $ time gfortran-7 -O1 gener-4.f90 real0m23.630s user0m23.475s sys 0m0.142s $ time gfortran-8 -O1 gener-4.f90 real0m23.702s user0m23.356s sys 0m0.335s $ time gfortran -O1 gener-4.f90 real0m24.708s user0m24.577s sys 0m0.107s (where gfortran is a recent trunk, without checking). About half the time is spent in df live regs, with another big chunk in tree copy headers: $ gfortran -O1 -ftime-report gener-4.f90 Time variable usr sys wall GGC phase setup: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 182 kB ( 0%) phase parsing : 0.30 ( 1%) 0.02 ( 8%) 0.32 ( 1%) 18037 kB ( 11%) phase opt and generate : 23.81 ( 99%) 0.24 ( 92%) 24.06 ( 99%) 143289 kB ( 89%) callgraph construction : 0.04 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 4980 kB ( 3%) ipa function summary : 0.05 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 1414 kB ( 1%) ipa inlining heuristics: 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%) ipa pure const : 0.00 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) cfg construction : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 890 kB ( 1%) cfg cleanup: 0.05 ( 0%) 0.00 ( 0%) 0.08 ( 0%) 0 kB ( 0%) trivially dead code: 0.04 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 kB ( 0%) df scan insns : 0.07 ( 0%) 0.00 ( 0%) 0.07 ( 0%) 0 kB ( 0%) df multiple defs : 0.04 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 0 kB ( 0%) df reaching defs : 0.97 ( 4%) 0.01 ( 4%) 0.99 ( 4%) 0 kB ( 0%) df live regs : 0.24 ( 1%) 0.00 ( 0%) 0.21 ( 1%) 0 kB ( 0%) df live regs : 12.11 ( 50%) 0.01 ( 4%) 12.03 ( 49%) 0 kB ( 0%) df use-def / def-use chains: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) df reg dead/unused notes : 0.24 ( 1%) 0.00 ( 0%) 0.24 ( 1%) 2811 kB ( 2%) register information : 0.02 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) alias analysis : 0.06 ( 0%) 0.00 ( 0%) 0.08 ( 0%) 2048 kB ( 1%) alias stmt walking : 1.55 ( 6%) 0.06 ( 23%) 1.65 ( 7%) 92 kB ( 0%) register scan : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 189 kB ( 0%) rebuild jump labels: 0.01 ( 0%) 0.00 ( 0%) 0.02 ( 0%) 0 kB ( 0%) parser (global): 0.30 ( 1%) 0.02 ( 8%) 0.32 ( 1%) 18037 kB ( 11%) inline parameters : 0.04 ( 0%) 0.00 ( 0%) 0.03 ( 0%) 513 kB ( 0%) tree gimplify : 0.07 ( 0%) 0.01 ( 4%) 0.08 ( 0%) 13934 kB ( 9%) tree eh: 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 0 kB ( 0%) tree CFG construction : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 5209 kB ( 3%) tree CFG cleanup : 0.34 ( 1%) 0.01 ( 4%) 0.37 ( 2%) 1697 kB ( 1%) tree copy propagation : 0.03 ( 0%) 0.00 ( 0%) 0.04 ( 0%) 0 kB ( 0%) tree PTA : 0.21 ( 1%) 0.00 ( 0%) 0.22 ( 1%) 1269 kB ( 1%) tree PHI insertion : 0.00 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 2644 kB ( 2%) tree SSA rewrite : 0.05 ( 0%) 0.00 ( 0%) 0.05 ( 0%) 3119 kB ( 2%) tree SSA other : 0.01 ( 0%) 0.02 ( 8%) 0.03 ( 0%) 0 kB ( 0%) tree SSA incremental : 0.08 ( 0%) 0.00 ( 0%) 0.10 ( 0%) 4729 kB ( 3%) tree operand scan : 0.04 ( 0%) 0.01 ( 4%) 0.06 ( 0%) 3526 kB ( 2%) dominator optimization : 0.27 ( 1%) 0.01 ( 4%) 0.23 ( 1%) 5850 kB ( 4%) tree SRA : 0.13 ( 1%) 0.00 ( 0%) 0.14 ( 1%) 562 kB ( 0%) tree CCP : 0.32 ( 1%) 0.01 ( 4%) 0.30 ( 1%) 1226 kB ( 1%) tree reassociation : 0.01 ( 0%) 0.00 ( 0%) 0.00 ( 0%) 0 kB ( 0%) tree FRE : 0.60 ( 2%) 0.02 ( 8%) 0.59 ( 2%) 2505 kB ( 2%) tree code sinking : 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 60 kB ( 0%) tree linearize phis: 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%) 2 kB ( 0%) tree backward propagate: 0.01 ( 0%) 0.00 ( 0%) 0.01 ( 0%)
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #19 from anlauf at gcc dot gnu.org --- Fixed on trunk and all open branches (7/8). Closing, as no reduced run-time testcase was provided. Please reopen or create a new PR if an issue is found. Thanks for the report!
[Bug rtl-optimization/89528] Wrong debug info generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89528 Qirun Zhang changed: What|Removed |Added CC||qrzhang at gatech dot edu --- Comment #2 from Qirun Zhang --- Bisection points to r217125.
[Bug fortran/85797] ICE in gfc_element_size, at fortran/target-memory.c:126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on trunk and open branches (7/8). Thanks for the report!
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #18 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 31 19:21:37 2019 New Revision: 270047 URL: https://gcc.gnu.org/viewcvs?rev=270047=gcc=rev Log: 2019-03-31 Harald Anlauf Backport from trunk PR fortran/83515 PR fortran/85797 * trans-types.c (gfc_typenode_for_spec): Handle conversion for procedure pointers. * target-memory.c (gfc_element_size): Handle size determination for procedure pointers. PR fortran/83515 PR fortran/85797 * gfortran.dg/pr85797.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr85797.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/target-memory.c branches/gcc-7-branch/gcc/fortran/trans-types.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/85797] ICE in gfc_element_size, at fortran/target-memory.c:126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797 --- Comment #8 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 31 19:21:37 2019 New Revision: 270047 URL: https://gcc.gnu.org/viewcvs?rev=270047=gcc=rev Log: 2019-03-31 Harald Anlauf Backport from trunk PR fortran/83515 PR fortran/85797 * trans-types.c (gfc_typenode_for_spec): Handle conversion for procedure pointers. * target-memory.c (gfc_element_size): Handle size determination for procedure pointers. PR fortran/83515 PR fortran/85797 * gfortran.dg/pr85797.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr85797.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/target-memory.c branches/gcc-7-branch/gcc/fortran/trans-types.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/85797] ICE in gfc_element_size, at fortran/target-memory.c:126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797 --- Comment #7 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 31 19:08:23 2019 New Revision: 270046 URL: https://gcc.gnu.org/viewcvs?rev=270046=gcc=rev Log: 2019-03-31 Harald Anlauf PR fortran/83515 PR fortran/85797 * trans-types.c (gfc_typenode_for_spec): Handle conversion for procedure pointers. * target-memory.c (gfc_element_size): Handle size determination for procedure pointers. PR fortran/83515 PR fortran/85797 * gfortran.dg/pr85797.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr85797.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/target-memory.c branches/gcc-8-branch/gcc/fortran/trans-types.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #17 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 31 19:08:23 2019 New Revision: 270046 URL: https://gcc.gnu.org/viewcvs?rev=270046=gcc=rev Log: 2019-03-31 Harald Anlauf PR fortran/83515 PR fortran/85797 * trans-types.c (gfc_typenode_for_spec): Handle conversion for procedure pointers. * target-memory.c (gfc_element_size): Handle size determination for procedure pointers. PR fortran/83515 PR fortran/85797 * gfortran.dg/pr85797.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr85797.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/target-memory.c branches/gcc-8-branch/gcc/fortran/trans-types.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/52763] Warning if compare between enum and non-enum type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52763
--- Comment #10 from Eric Gallager ---
(In reply to Martin Sebor from comment #8)
> Clang warns when an enum object is compared to a constant that's out of the
> most restricted range of the enum's type. The warning is in -Wall. It
> doesn't warn when the object is compared to a constant that doesn't
> correspond to any of the type's enumerators. I can see that being useful to
> some (carefully written) projects but suspect it could be quite noisy for
> many others.
>
> $ cat t.C && clang++ -S -Wall -Wextra t.C
> enum E { NONE = 0, ONE = 1, TWO = 2 };
>
> bool f (E e)
> {
> return e == 3; // no warning here
> }
>
> bool g (E e)
> {
> return e == 4;
> }
>
>
> t.C:10:12: warning: comparison of constant 4 with expression of type 'E' is
> always false [-Wtautological-constant-out-of-range-compare]
> return e == 4;
> ~ ^ ~
> 1 warning generated.
Would it make sense for GCC to just reuse -Wenum-compare for this case instead
of adding a new -Wtautological-constant-out-of-range-compare flag?
[Bug c++/89897] New: suggest header for SIGABRT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89897
Bug ID: 89897
Summary: suggest header for SIGABRT
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jg at jguk dot org
Target Milestone: ---
Could g++ suggest header for SIGABRT?
just includes I saw in the file. But anyway, I was
compiling as
#1 with x86-64 gcc (trunk)
: In function 'int main()':
:6:18: error: 'SIGABRT' was not declared in this scope
6 | std::cout << SIGABRT;
| ^~~
Compiler returned: 1
//#include
#include
int main()
{
std::cout << SIGABRT;
}
and C version
//#include
int main()
{
return SIGABRT;
}
#1 with x86-64 gcc 8.3
: In function 'main':
:5:12: error: 'SIGABRT' undeclared (first use in this function)
return SIGABRT;
^~~
:5:12: note: each undeclared identifier is reported only once for each
function it appears in
Compiler returned: 1
[Bug fortran/83515] ICE: Invalid expression in gfc_element_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515 --- Comment #16 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 31 18:33:51 2019 New Revision: 270045 URL: https://gcc.gnu.org/viewcvs?rev=270045=gcc=rev Log: 2019-03-31 Harald Anlauf PR fortran/83515 PR fortran/85797 * trans-types.c (gfc_typenode_for_spec): Handle conversion for procedure pointers. * target-memory.c (gfc_element_size): Handle size determination for procedure pointers. PR fortran/83515 PR fortran/85797 * gfortran.dg/pr85797.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr85797.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/85797] ICE in gfc_element_size, at fortran/target-memory.c:126
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85797 --- Comment #6 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 31 18:33:51 2019 New Revision: 270045 URL: https://gcc.gnu.org/viewcvs?rev=270045=gcc=rev Log: 2019-03-31 Harald Anlauf PR fortran/83515 PR fortran/85797 * trans-types.c (gfc_typenode_for_spec): Handle conversion for procedure pointers. * target-memory.c (gfc_element_size): Handle size determination for procedure pointers. PR fortran/83515 PR fortran/85797 * gfortran.dg/pr85797.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr85797.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog
[Bug c/78736] enum warnings in GCC (request for -Wenum-conversion to be added)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78736 Eric Gallager changed: What|Removed |Added Blocks||87403 Summary|enum warnings in GCC|enum warnings in GCC ||(request for ||-Wenum-conversion to be ||added) --- Comment #8 from Eric Gallager --- (In reply to Eric Gallager from comment #7) > Prathamesh has submitted a patch to the gcc-patches mailing list that still > needs to be reviewed for this bug: > https://gcc.gnu.org/ml/gcc-patches/2017-07/msg00514.html Retitling to clarify which enum warning in particular this bug is about adding Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403 [Bug 87403] [Meta-bug] Issues that suggest a new warning
[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960 --- Comment #13 from Thomas Koenig --- With -O2, the combiner takes up quite a lot of time: $ time gfortran -ftime-report -g0 -O2 -fdefault-integer-8 -c fe_objective.f90 alias stmt walking : 15.75 ( 4%) 0.11 ( 5%) 15.89 ( 4%) 2 kB ( 0%) dead store elim2 : 10.49 ( 2%) 0.33 ( 16%) 10.82 ( 3%) 1578727 kB ( 35%) combiner : 346.20 ( 81%) 0.89 ( 44%) 347.17 ( 81%) 2701135 kB ( 60%) TOTAL : 428.68 2.01430.83 4504484 kB With -O1, this now has as biggest consumers of cycles alias stmt walking : 11.80 ( 31%) 0.04 ( 13%) 11.78 ( 31%) 2 kB ( 0%) integrated RA : 5.61 ( 15%) 0.06 ( 20%) 5.67 ( 15%) 34896 kB ( 10%) LRA hard reg assignment: 4.69 ( 12%) 0.00 ( 0%) 4.69 ( 12%) 0 kB ( 0%) TOTAL : 37.68 0.30 38.00 364905 kB which does not look too bad (and memory consumption has remained constant). Note that this is with checking enabled.
[Bug debug/89529] Wrong debug info generated at -Og [gcc-trunk]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89529 Qirun Zhang changed: What|Removed |Added CC||qrzhang at gatech dot edu --- Comment #3 from Qirun Zhang --- Bisection points to r235905
[Bug fortran/42958] Weird temporary array allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42958
--- Comment #26 from Thomas Koenig ---
(In reply to Dominique d'Humieres from comment #25)
> > If you find anything still missing in the library, please let me know.
> > I thought I had converted everything to the macros, which are fairly
> > easy to change, but I may be mistaken.
>
> Is there anything left? or could this PR be closed as FIXED?
We still do
{
if ((real(kind=4)[0:] * restrict) a.data != 0B)
{
__builtin_free ((void *) a.data);
(real(kind=4)[0:] * restrict) a.data = 0B;
}
}
Also, we have space array descriptor fields now, so for GCC 10, we
can finally implement the "allocated" flag.
[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 Thomas Koenig changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=87352 --- Comment #14 from Thomas Koenig --- https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01478.html might also cure this one, without source I cannot tell.
[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352 --- Comment #14 from Jeremy Sanders --- Created attachment 46064 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46064=edit Patch to instrument gfortran for test case
[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352 --- Comment #13 from Jeremy Sanders --- Created attachment 46063 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46063=edit log (minor edits) from instrumentation patch
[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352 --- Comment #12 from Jeremy Sanders --- Thomas - unfortunately I don't have a copy of what I did. I think reverting this patch fixes the problem though: https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/fortran/resolve.c?r1=254427=254426=254427 Sorry - I left out the allocate statements in the test case. Do you want me to fix the test case? I've not fixed the problem, but I've been putting debugging statements into the code to try to understand what is going on. Please see the attached log file and print patch. What appears to happen is that generate_finalization_wrapper for testmodule_Evtlistlist_type calls finalize_component for evtlistlist_type. This in turn calls finalize_component for each member of evtlist_type. For N members, N gfc_code objects are created (See the code pointers in the log). Here my program has members p00, p01, p02 and p03. When these code objects are then interpreted in gfc_trans_deallocate structure_alloc_comps does a deallocation for each of the members. This leads to the N^2 behaviour as the is a gfc_code object made for each member, and each of these code objects does a deallocation of all members.
[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352 Thomas Koenig changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |tkoenig at gcc dot gnu.org
[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352
--- Comment #11 from Thomas Koenig ---
(In reply to Thomas Koenig from comment #10)
> This patch
>
> Index: class.c
> ===
> --- class.c (Revision 269895)
> +++ class.c (Arbeitskopie)
> @@ -1031,11 +1031,13 @@ finalize_component (gfc_expr *expr, gfc_symbol *de
> }
>else
> {
> +#if 0
>gfc_component *c;
>
>for (c = comp->ts.u.derived->components; c; c = c->next)
> finalize_component (e, comp->ts.u.derived, c, stat, fini_coarray,
> code,
> sub_ns);
> +#endif
>gfc_free_expr (e);
> }
> }
>
> leads to a reduction in the compile time, but a segfault in the
> test case.
... but then the test case lacks a few ALLOCATE statements to be valid :-)
[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352
--- Comment #10 from Thomas Koenig ---
This patch
Index: class.c
===
--- class.c (Revision 269895)
+++ class.c (Arbeitskopie)
@@ -1031,11 +1031,13 @@ finalize_component (gfc_expr *expr, gfc_symbol *de
}
else
{
+#if 0
gfc_component *c;
for (c = comp->ts.u.derived->components; c; c = c->next)
finalize_component (e, comp->ts.u.derived, c, stat, fini_coarray, code,
sub_ns);
+#endif
gfc_free_expr (e);
}
}
leads to a reduction in the compile time, but a segfault in the
test case.
[Bug d/88462] All D execution tests FAIL on Solaris/SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88462 --- Comment #13 from ibuclaw at gcc dot gnu.org --- Author: ibuclaw Date: Sun Mar 31 14:34:41 2019 New Revision: 270043 URL: https://gcc.gnu.org/viewcvs?rev=270043=gcc=rev Log: d: Fix run-time SIGSEGV reading ModuleInfo.flags() The current forced alignment is not necessary, and is problematic on targets that have strict alignment rules. gcc/d/ChangeLog: 2019-03-31 Iain Buclaw PR d/88462 * modules.cc (layout_moduleinfo_fields): Properly align ModuleInfo, instead of forcing alignment to be 1. Modified: trunk/gcc/d/ChangeLog trunk/gcc/d/modules.cc
[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352 --- Comment #9 from Thomas Koenig --- I think this is a high-priority bug that we should try to fix before the GCC 9 release. Some discussion here: https://gcc.gnu.org/ml/fortran/2019-03/msg00124.html Jeremy, you mentioned that you commented out a loop in finalize_component. Could you put a patch here to see exactly what you did?
[Bug lto/89896] -flto=4 is confused by presence of 'all.c' in a local directory. -flto=1 is not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89896 Sergei Trofimovich changed: What|Removed |Added Summary|-flto=4 is confused by |-flto=4 is confused by |presence of all.o in a |presence of 'all.c' in a |local directory. -flto=1 is |local directory. -flto=1 is |not.|not. --- Comment #1 from Sergei Trofimovich --- It seems that 'all.c' is actual trigger, not 'all.o'.
[Bug fortran/78674] [cleanup] merge gfc_convert_type_warn and gfc_convert_chartype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78674 --- Comment #3 from Dominique d'Humieres --- > Patch at https://gcc.gnu.org/ml/fortran/2016-12/msg00045.html Any reason why this patch has never been pinged?
[Bug lto/89896] New: -flto=4 is confused by presence of all.o in a local directory. -flto=1 is not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89896
Bug ID: 89896
Summary: -flto=4 is confused by presence of all.o in a local
directory. -flto=1 is not.
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: slyfox at inbox dot ru
CC: marxin at gcc dot gnu.org
Target Milestone: ---
The bug is originally discovered by Fabio Coatti in
https://bugs.gentoo.org/682018.
There isl-0.21 fails to link when built with CFLAGS="-O2 -flto=4 -pipe"
LDFLAGS="${CFLAGS}". The trigger is all.c file name in isl source three. It
gets translated to all.o.
Here is the minimal reproducer:
$ cat foo.bash
#!/bin/bash
export LANG=C
cc=gcc
mk() {
local flag=$1
rm -rf -- *.o *.so*
${cc} ${flag} -fPIC -c all.c -o all.o
${cc} ${flag} -fPIC -c isl.c -o isl.o
# Note: all.o is not used here and yet in interferes with -flto=4
${cc} ${flag} -fPIC -shared isl.o -o libisl.so
}
# empty files are enough to trigger a bug
touch all.c isl.c
echo "=== -flto=1 (works) ==="
mk "-flto=1"
echo "=== -flto=4 (fails) ==="
mk "-flto=4"
Running:
$ ./foo.bash
=== -flto=1 (works) ===
=== -flto=4 (fails) ===
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../lib64/../lib64/Scrt1.o: in
function `_start':
/usr/src/debug/sys-libs/glibc-2.29-r1/glibc-2.29/csu/../sysdeps/x86_64/start.S:104:
undefined reference to `main'
collect2: error: ld returned 1 exit status
make: *** [: all] Error 1
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Note: all.o is never passed to gcc as an input. And yet it's presence
interferes with the driver.
[Bug rtl-optimization/89895] New: Unable to sink high half of widening multiply out of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89895
Bug ID: 89895
Summary: Unable to sink high half of widening multiply out of
loop
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: lkml at sdf dot org
Target Milestone: ---
This is part of gcc's general problem with double-word values, but
I was encouraged to submit a PR, since it's a particularly simple but
real-world-applicable test case.
Lemire's algorithm for uniform random number generation in a range
(https://arxiv.org/abs/1805.10941) has the following core:
static uint64_t __attribute__((noinline)) get_random_u64(void);
u64 get_random_range(uint64_t range, uint64_t lim)
{
unsigned __int128 prod;
do {
prod = (unsigned __int128)range * get_random_u64();
} while ((uint64_t)prod < lim);
return prod >> 64;
}
(In practice, get_random_u64() would be inlined, but I've left it
out of line for exposition.)
GCC's isn't sinking generation of the high half of the product out
of the loop. This particularly applies on platforms with a separate
multiply-high instruction like alpha:
$L9:
bsr $26,get_random_u64 !samegp
mulq $0,$9,$1
umulh $0,$9,$0
cmpule $10,$1,$1
beq $1,$L9
and PowerPC:
.L12:
bl get_random_u64
mulld 9,3,31
mulhdu 3,3,31
cmpld 7,30,9
bgt+ 7,.L12
But is also applies to MIPS, where the mfhi could be sunk out of the
loop:
.L10:
jal get_random_u64
nop
dmultu $2,$17
mflo$2
sltu$6,$2,$16
bne $6,$0,.L10
mfhi$3
In this case, there's nothing *better* to do in the delay slot than mfhi,
but that's kind of an accident.
The code I'd hope to see is
Alpha:
$L9:
bsr $26,get_random_u64
mulq $0,$9,$1
cmpule $10,$1,$1
beq $1,$L9
umulh $0,$9,$0
PowerPC:
.L12:
bl get_random_u64
mulld 9,3,31
cmpld 7,30,9
bgt+ 7,.L12
mulhdu 3,3,31
and (when the mulditi3 expander is added) MIPS r6:
.L10:
balcget_random_u64
dmulu $3, $2, $17
sltu$3, $3, $16
bnezc $3, .L10
dmuhu $2, $2, $17
In these cases, since the low-half multiply is the last multiply in
the loop, the high half will still catch the hardware-optimized case
for both halves of a multiply.
