[Bug target/66488] segfault on sizeof(long) < sizeof(void*) and large GCC memory usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66488 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Martin Liška --- Thanks, closing then.
[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878 Eric Botcazou changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.0 --- Comment #56 from Eric Botcazou --- > Fixed in the trunk. Does anyone care enough to backport it? I don't think that there is a need for it. Thanks for sorting this out!
[Bug tree-optimization/88105] New: Possibly infinite loop in pass_dominator::execute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88105
Bug ID: 88105
Summary: Possibly infinite loop in pass_dominator::execute
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: compile-time-hog, openmp
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-9.0.0-alpha20181118 snapshot (r266255), 8.2, 7.3, 6.3, 5.4, 4.9.4, 4.8.5
all take indefinite time compiling the following snippet at any optimization
level (except -Og) and w/ -fexceptions -fnon-call-exceptions -fopenmp
-fno-tree-fre:
int
s0 (void)
{
int g6, oh = 0;
int *a6 =
(void) a6;
#pragma omp parallel for
for (g6 = 0; g6 < 1; ++g6)
{
int zk;
for (zk = 0; zk < 1; ++zk)
{
oh += zk / (zk + 1);
for (;;)
{
}
}
a6 =
}
return oh;
}
% timeout 10 gcc-9.0.0-alpha20181118 -O1 -fexceptions -fnon-call-exceptions
-fopenmp -fno-tree-fre -c eusbqkjq.c
zsh: exit 124 timeout 10 gcc-9.0.0-alpha20181118 -O1 -fexceptions
-fnon-call-exceptions -
[Bug testsuite/88104] sparc-solaris2.11 testsuite failures due to unrecognized as option -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88104
--- Comment #2 from Martin Sebor ---
The failing tests are compile-only (don't involve the assembler), and would
pass even with a default-configured GCC. The reason why they fail is that the
large_long_double DejaGnu configuration test both compiles and assembles the
test, and the latter step fails. The following fixes it:
@@ -2664,7 +2664,7 @@ proc check_effective_target_large_long_double { }
# 0 otherwise.
proc check_effective_target_large_double { } {
-return [check_no_compiler_messages large_double object {
+return [check_no_compiler_messages large_double assembly {
int dummy[sizeof(double) > sizeof(float) ? 1 : -1];
}]
}
[Bug target/85673] ICE in create_pre_exit, at mode-switching.c:451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85673
--- Comment #2 from Arseny Solokha ---
The testcase from comment 0 doesn't fail for me anymore w/ the current trunk
snapshots (as of 266255), while the following one does w/ -mavx -O1 (-O2, -O3,
-Ofast, -Og) -fexpensive-optimizations -fschedule-insns -fselective-scheduling
-fno-dce -fno-tree-dce -fno-tree-ter --param selsched-max-lookahead=5:
int
b3 (ks)
{
int ot;
ot = (ks == 1) == (b3 (ks + 1) + 1);
(void) ot;
return ks;
}
But isn't this PR basically a duplicate of PR88070?
[Bug tree-optimization/88074] [7/8/9 Regression] g++ hangs on math expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074 --- Comment #13 from joseph at codesourcery dot com --- MPFR deals with larger exponent ranges for intermediate computations itself (MPFR functions generally set the maximum possible exponent range internally). MPC generally doesn't seem to, so quite likely setting an exponent range could show up some MPC bugs.
[Bug tree-optimization/88074] [7/8/9 Regression] g++ hangs on math expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88074 --- Comment #12 from joseph at codesourcery dot com --- Note that such issues are not unique to ctan. E.g., compiling __builtin_jn (10, 1e10) will produce such a hang. The difference is that in the ctan case the additional algorithm needed in MPC to avoid huge precision being needed for such cases would be reasonable simple, whereas fast and accurate computation of high-order Bessel functions is much harder (there's some literature on the subject, which I haven't studied in detail, but certainly additional algorithms needed there in MPFR would be much more involved).
[Bug c/88091] [9 regression] c-c++-common/Wconversion-real.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88091 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #3 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01674.html
[Bug d/88039] gdc.test/compilable/ddoc12.d FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88039 --- Comment #3 from joseph at codesourcery dot com --- On Mon, 19 Nov 2018, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > However, there's another option: C11, 6.4.2.1 General, n.71 suggests > > On systems in which linkers cannot accept extended characters, an > encoding of the universal character name may be used in forming valid > external identifiers. For example, some otherwise unused character or > sequence of characters may be used to encode the \u in a universal > character name. Extended characters may produce a long external > identifier Since we don't do any such encoding for C or C++, this is not suitable for any case where the identifiers are meant to be link-compatible with C or C++ (unless we implement such encoding for C and C++ on target OSes that need it, presumably in a way ABI-compatible with how the OSes' own compilers handle UCNs in identifiers if they support that feature, of course).
[Bug other/16615] throughout gcc docu and code numerous "can not"'s appear
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16615 --- Comment #7 from joseph at codesourcery dot com --- Note there are a few places where it's "cannot", which the most obvious find/sed might not locate. E.g. in lra-remat.c: /* Map: insn -> candidate representing it. It is null if the insn can not be used for rematerialization. */ or in reorg.c: We can not steal the delay list if one of the instructions in the current delay_list modifies the condition codes and the jump in the sequence is a conditional jump. We can not do this because we can not change the direction of the jump because the condition codes will effect the direction of the jump in the sequence. */ (found via examining the output of "grep -C1 'can$'" for following lines starting with "not" after whitespace).
[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878 --- Comment #55 from Alexandre Oliva --- Fixed in the trunk. Does anyone care enough to backport it?
[Bug ada/81878] --disable-bootstrap --enable-languages=ada fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81878 --- Comment #54 from Alexandre Oliva --- Author: aoliva Date: Tue Nov 20 00:07:47 2018 New Revision: 266290 URL: https://gcc.gnu.org/viewcvs?rev=266290=gcc=rev Log: PR81878: fix --disable-bootstrap --enable-languages=ada gnattools build machinery uses just-build xgcc and xg++ as $(CC) and $(CXX) in native builds. However, if C and C++ languages are not enabled, it won't find them. So, enable C and C++ if Ada is enabled. Most of the time, this is probably no big deal: C is always enabled anyway, and C++ is already enabled for bootstraps. We need not enable those for cross builds, however. At first I just took the logic from gnattools/configure, but found it to be lacking: it would use the just-built tools even in cross-back settings, whose tools just built for the host would not run on the build machine. So I've narrowed down the test to rely on autoconf-detected cross-ness (build->host only), but also to ensure that host matches build, and that target matches host. I've considered sourcing ada/config-lang.in from within gnattools/configure, and testing lang_requires as set by it, so as to avoid a duplication of tests that ought to remain in sync, but decided it would be too fragile, as ada/config-lang.in does not expect srcdir to refer to gnattools. for gcc/ada/ChangeLog PR ada/81878 * gcc-interface/config-lang.in (lang_requires): Set to "c c++" when gnattools wants it. for gnattools/ChangeLog PR ada/81878 * configure.ac (default_gnattools_target): Do not mistake just-built host tools as native in cross-back toolchains. * configure: Rebuilt. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/config-lang.in trunk/gnattools/ChangeLog trunk/gnattools/configure trunk/gnattools/configure.ac
[Bug rtl-optimization/71496] Two picbase loads created for libjava code on powerpc-darwin after rev 228022.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71496 --- Comment #11 from Iain Sandoe --- (In reply to Segher Boessenkool from comment #10) > Tobias: Yes, please file a new bug (with a small testcase, if possible). > Thanks! FAOD, comment #6 is the only reason to keep this open - so when a new bug is filed for the missed optimisation(s) we can close this one.
[Bug c/88091] [9 regression] c-c++-common/Wconversion-real.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88091 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Status|NEW |ASSIGNED Component|testsuite |c Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- This is due to a bug introduced in r266194.
[Bug c/52382] Atomic builtins documentation, page not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52382 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Jonathan Wakely --- (In reply to sandra from comment #5) > 7+ years later I would not recommend changing the manual node name just > to fix a dead link on a wiki page that hasn't been touched since 2012 and > that documents the status of this feature as of the GCC 4.4 release. Sure, it doesn't make sense now. Back in 2012 when texinfo changed all the names of the generated HTML pages it might have made more sense. > If > anybody wants to update the wiki, they're welcome to. Done.
[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957 --- Comment #7 from Jan Hubicka --- Author: hubicka Date: Mon Nov 19 23:27:10 2018 New Revision: 266289 URL: https://gcc.gnu.org/viewcvs?rev=266289=gcc=rev Log: PR lto/87957 * ipa-devirt.c (free_enum_values): Do not ICE on ODR vilations. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c
[Bug c++/88103] [7/8/9 Regression] Wrong value category when conditional expression result is used as object expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88103 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||5.5.0 Keywords||rejects-valid Last reconfirmed||2018-11-19 CC||jason at gcc dot gnu.org Ever confirmed|0 |1 Summary|Wrong value category when |[7/8/9 Regression] Wrong |conditional expression |value category when |result is used as object|conditional expression |expression |result is used as object ||expression Known to fail||6.5.0, 7.3.1, 8.2.1, 9.0 --- Comment #1 from Jonathan Wakely --- This compiled OK with GCC 5, but started to be rejected with r230365, "Merge C++ delayed folding branch"
[Bug rtl-optimization/71496] Two picbase loads created for libjava code on powerpc-darwin after rev 228022.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71496 --- Comment #10 from Segher Boessenkool --- Tobias: Yes, please file a new bug (with a small testcase, if possible). Thanks!
[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088 --- Comment #3 from Segher Boessenkool --- It is good that it doesn't warn if trampolines are not data. This is not documented, fwiw. It also warns if the stack is executable *anyway*, like it is for many targets. This is not useful; as documented, the point of the warning is to warn the user that the stack is made executable because some trampoline somewhere needs it. Not warn the user that there is a trampoline somewhere(*), which would be as useful as warning the user that the program source code is a multiple of six lines long, which is exactly as harmful :-P (*) Which, as you say, is not what it does anyway!
[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836 --- Comment #15 from Eric Botcazou --- > Regarding your suggestion, is there a way to get the compiler to reveal the > steps it goes through in compiling the program? All I get now is the > backtrace when it hits the error. I need to know what the compiler is doing > before that. You could break on execute_build_cfg and run the program until it is hit on the x86 and SPARC machines. Then add breakpoints on the various routines in the et-forest.c file and find out when the null pointer is created on SPARC.
[Bug c/52382] Atomic builtins documentation, page not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52382 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #5 from sandra at gcc dot gnu.org --- 7+ years later I would not recommend changing the manual node name just to fix a dead link on a wiki page that hasn't been touched since 2012 and that documents the status of this feature as of the GCC 4.4 release. If anybody wants to update the wiki, they're welcome to.
[Bug fortran/52473] CSHIFT slow - inline it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52473 --- Comment #21 from Dominique d'Humieres --- > The original test case is still slow, so I guess we should > keep this open. Which test?
[Bug driver/50250] Driver documentation on -l does not mention shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50250 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #7 from sandra at gcc dot gnu.org --- Fixed on trunk. I ended up writing a new patch from scratch rather than using the wording suggested in comment 4.
[Bug driver/50250] Driver documentation on -l does not mention shared libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50250 --- Comment #6 from sandra at gcc dot gnu.org --- Author: sandra Date: Mon Nov 19 21:53:09 2018 New Revision: 266287 URL: https://gcc.gnu.org/viewcvs?rev=266287=gcc=rev Log: 2018-11-19 Sandra Loosemore PR driver/50250 gcc/ * doc/invoke.texi (Link Options): Mention shared libraries in documentation for the -l option. Simplify discussion and point to the system linker documentation for details. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/invoke.texi
[Bug testsuite/88104] sparc-solaris2.11 testsuite failures due to unrecognized as option -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88104 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #1 from Rainer Orth --- You need to configure with --with-gnu-as if using gas: the Solaris port defaults to /bin/as. Besides, there are gcc210 and gcc211 in the cfarm where you can test Solaris 10 and 11/SPARC natively.
[Bug c++/87781] template disambiguator not after `::`, `.` or `->` is incorrectly accepted in an elaborated-type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87781 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Marek Polacek --- Fixed for GCC 9.
[Bug testsuite/88098] FAIL: gcc.dg/Wbuiltin-declaration-mismatch-4.c (test for warnings, line 80)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88098 Martin Sebor changed: What|Removed |Added Keywords||patch See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=88104 --- Comment #1 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01661.html
[Bug c++/87781] template disambiguator not after `::`, `.` or `->` is incorrectly accepted in an elaborated-type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87781 --- Comment #1 from Marek Polacek --- Author: mpolacek Date: Mon Nov 19 21:37:01 2018 New Revision: 266285 URL: https://gcc.gnu.org/viewcvs?rev=266285=gcc=rev Log: PR c++/87781 - detect invalid elaborated-type-specifier. * parser.c (cp_parser_elaborated_type_specifier): Ensure that typename follows a nested-name-specifier. * g++.dg/parse/elab3.C: New test. * g++.dg/template/crash115.C: Adjust dg-error. Added: trunk/gcc/testsuite/g++.dg/parse/elab3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/template/crash115.C
[Bug testsuite/88104] New: sparc-solaris2.11 testsuite failures due to unrecognized as option -m32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88104 Bug ID: 88104 Summary: sparc-solaris2.11 testsuite failures due to unrecognized as option -m32 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- A number of compile-only tests fail with the sparc-solaris2.11 cross-compiler on an x86_64-linux host due to what seems to be an incorrect assembler option. For example: $ make -C /ssd/build/sparc-solaris2.11/gcc-svn/gcc check-c RUNTESTFLAGS="dg.exp=Wbuiltin-declaration-mismatch-4.c ... Running /ssd/src/gcc/svn/gcc/testsuite/gcc.dg/dg.exp ... FAIL: gcc.dg/Wbuiltin-declaration-mismatch-4.c (test for excess errors) === gcc Summary === # of expected passes21 # of unexpected failures1 # of expected failures 1 /ssd/build/sparc-solaris2.11/gcc-svn/gcc/xgcc version 9.0.0 20181117 (experimental) (GCC) I think the test fails because the harness incorrectly configures the large_long_double variable (the target has support for large long double but the harness variable is set to false). The relevant snippet from gcc.log is: Executing on host: /ssd/build/sparc-solaris2.11/gcc-svn/gcc/xgcc -B/ssd/build/sparc-solaris2.11/gcc-svn/gcc/-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -c -o large_long_double9364.o large_long_double9364.c(timeout = 300) spawn -ignore SIGHUP /ssd/build/sparc-solaris2.11/gcc-svn/gcc/xgcc -B/ssd/build/sparc-solaris2.11/gcc-svn/gcc/ -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -c -o large_long_double9364.o large_long_double9364.c /ssd/build/sysroot/sparc-solaris2.11/sparc-solaris2.11/bin/as: unrecognized option '-m32' compiler exited with status 1
[Bug fortran/40196] [F03] [F08] Type parameter inquiry (str%len, a%kind) and Complex parts (z%re, z%im)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40196 --- Comment #13 from harper at msor dot vuw.ac.nz --- OK On Mon, 19 Nov 2018, marxin at gcc dot gnu.org wrote: > Date: Mon, 19 Nov 2018 11:51:27 + > From: marxin at gcc dot gnu.org > To: John Harper > Subject: [Bug fortran/40196] [F03] [F08] Type parameter inquiry (str%len, > a%kind) and Complex parts (z%re, z%im) > Resent-Date: Tue, 20 Nov 2018 00:51:55 +1300 (NZDT) > Resent-From: > > https://apac01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D40196data=02%7C01%7Cjohn.harper%40vuw.ac.nz%7Cb5d00c897cbb4ce5b3f608d64e1559dc%7Ccfe63e236951427e8683bb84dcf1d20c%7C0%7C0%7C636782250968185848sdata=MZE8e3vkP6E2081IHpNXIV7yZ1%2FmC3He%2FUYLOF57nAQ%3Dreserved=0 > > Martin Liška changed: > > What|Removed |Added > > CC||marxin at gcc dot gnu.org > > --- Comment #12 from Martin Liška --- > Can the bug be marked as resolved? > > -- > You are receiving this mail because: > You are on the CC list for the bug. > -- John Harper, School of Mathematics and Statistics Victoria Univ. of Wellington, PO Box 600, Wellington 6140, New Zealand. e-mail john.har...@vuw.ac.nz phone (+64)(4)463 5276 fax (+64)(4)463 5045
[Bug fortran/52473] CSHIFT slow - inline it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52473 --- Comment #20 from Thomas Koenig --- The original test case is still slow, so I guess we should keep this open.
[Bug c++/88103] New: Wrong value category when conditional expression result is used as object expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88103
Bug ID: 88103
Summary: Wrong value category when conditional expression
result is used as object expression
Product: gcc
Version: 8.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: okannen at gmail dot com
Target Milestone: ---
In the code below, if the conditional expression is an xvalue, and only when
this xvalue is used as the object expression in class member access, gcc treat
it as if it were an lvalue. The problem does not happen when the conditional
expression is a prvalue:
struct A {
A(int);
A&& foo() && ;
int i;
};
void free(A&&);
void test_xvalue(A a){
//No error
A&& ref = true? static_cast(a) : static_cast(a);
//No error
free(true? static_cast(a) : static_cast(a));
//Unexpected error: passing A as this discard qualifier
(true? static_cast(a) : static_cast(a)).foo();
//Unexpected error: error cannot bind rvalue reference
// of type int&& to lvalue of type int
int&& k=(true? static_cast(a) : static_cast(a)).i;
}
void test_prvalue(A a){
//No error
A&& ref = true? static_cast(a) : 1;
//No error
free(true? static_cast(a) : 1);
//No error
(true? static_cast(a) : 1).foo();
//No error
int&& k=(true? static_cast(a) : 1).i;
}
[Bug c++/88028] internal compiler error: in reshape_init_r, at cp/decl.c:6159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88028 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #7 from Marek Polacek --- Closing thus. *** This bug has been marked as a duplicate of bug 80864 ***
[Bug c++/80864] [7/8/9/ Regression] Brace-initialization of a constexpr variable of an array in a POD triggers ICE from templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80864 --- Comment #6 from Marek Polacek --- *** Bug 88028 has been marked as a duplicate of this bug. ***
[Bug c++/80864] [7/8/9/ Regression] Brace-initialization of a constexpr variable of an array in a POD triggers ICE from templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80864
--- Comment #5 from Marek Polacek ---
Another test from PR88028:
struct S {};
struct A { S s[1]; };
template
struct R { static constexpr auto h = A{S{}}; };
A foo = R::h;
[Bug tree-optimization/87025] [9 Regression] ICE in add_record, at optinfo-emit-json.cc:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87025 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from David Malcolm --- Should be fixed by r266280.
[Bug target/88070] [8/9 Regression] ICE in create_pre_exit, at mode-switching.c:438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88070 --- Comment #4 from Uroš Bizjak --- BTW: The extra blockage would crash compilation for all mode-switching targets, also in the pre-reload mode switching; the vzeroupper post-reload insertion just trips x86 target on a generic problem in the middle-end. Proposed patch: --cut here-- Index: function.c === --- function.c (revision 266278) +++ function.c (working copy) @@ -5447,13 +5447,6 @@ expand_function_end (void) if (naked_return_label) emit_label (naked_return_label); - /* @@@ This is a kludge. We want to ensure that instructions that - may trap are not moved into the epilogue by scheduling, because - we don't always emit unwind information for the epilogue. */ - if (cfun->can_throw_non_call_exceptions - && targetm_common.except_unwind_info (_options) != UI_SJLJ) -emit_insn (gen_blockage ()); - /* If stack protection is enabled for this function, check the guard. */ if (crtl->stack_protect_guard && targetm.stack_protect_runtime_enabled_p ()) stack_protect_epilogue (); --cut here--
[Bug target/44551] [missed optimization] AVX vextractf128 after vinsertf128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551 --- Comment #21 from Marc Glisse --- (In reply to Matthias Kretz from comment #20) > The original issue I meant to report is fixed. There are many more missed > optimizations in the original example, though. ok, your choice if you prefer to close it (especially if the other missed optimizations are already tracked in other bugs) or leave it open.
[Bug target/88070] [8/9 Regression] ICE in create_pre_exit, at mode-switching.c:438
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88070
--- Comment #3 from Uroš Bizjak ---
For reference:
The assert in create_pre_exit at mode-switching.c expects return copy
pair with nothing in between. However, the compiler starts mode
switching pass with the following sequence:
(insn 19 18 16 2 (set (reg:V2SF 21 xmm0)
(mem/c:V2SF (plus:DI (reg/f:DI 7 sp)
(const_int -72 [0xffb8])) [0 S8 A64]))
"pr88070.c":8 1157 {*movv2sf_internal}
(nil))
(insn 16 19 20 2 (set (reg:V2SF 0 ax [orig:91 ] [91])
(reg:V2SF 0 ax [89])) "pr88070.c":8 1157 {*movv2sf_internal}
(nil))
(insn 20 16 21 2 (unspec_volatile [
(const_int 0 [0])
] UNSPECV_BLOCKAGE) "pr88070.c":8 710 {blockage}
(nil))
(insn 21 20 23 2 (use (reg:V2SF 21 xmm0)) "pr88070.c":8 -1
(nil))
Please note how (insn 16) interferes with (insn 19)-(insn 21) return copy pair.
The culprit for this is the blockage instruction (insn 20), which
causes sched1 pass (pre reload scheduler) to skip marking (insn 19) as
unmovable instruction (as a dependent insn on return use insn), so the
scheduler is free to schedule (insn 16) between return copy pair (insn
19)-(insn 21).
The extra instruction is generated as a kludge in expand_function_end
to prevent instructions that may trap to be scheduled into function
epilogue. However, the same blockage is generated under exactly the
same conditions earlier in the expand_function_end. The first blockage
should prevent unwanted scheduling into the epilogue, so there is
actually no need for the second one.
[Bug tree-optimization/57371] Simplify (double)i != 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371 --- Comment #10 from Marc Glisse --- (In reply to Yury Gribov from comment #9) > TBH I didn't implement all Josephs suggestions (particularly my patch does > not try to optimize more under -ffast-math and friends)... Your choice if you want to reopen...
[Bug tree-optimization/31130] [7/8 Regression] VRP no longer derives range for division after negation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31130 Michael Matz changed: What|Removed |Added CC||matz at gcc dot gnu.org Summary|[7/8/9 Regression] VRP no |[7/8 Regression] VRP no |longer derives range for|longer derives range for |division after negation |division after negation --- Comment #30 from Michael Matz --- As far as I can tell this is fixed in gcc-9 (and should be in gcc-8 as well). Certainly all testcases herein are optimized as expected.
[Bug rtl-optimization/71785] Computed gotos are mostly optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71785 Segher Boessenkool changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Segher Boessenkool --- Yeah, backports didn't happen, and this was two years ago already. Closing.
[Bug libstdc++/71500] regex::icase only works on first character in a range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500 --- Comment #20 from Danila --- Can confirm that it was fixed in 8.1
[Bug c++/88102] New: Implement P0542R5, C++20 contracts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88102 Bug ID: 88102 Summary: Implement P0542R5, C++20 contracts Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jason at gcc dot gnu.org CC: andrew.n.sutton at gmail dot com Target Milestone: --- ...as revised by P1289R1. (I'm creating PRs for new features so there's some way of tracking whether someone's working on them)
[Bug libstdc++/88101] New: Implement P0528R3, C++20 cmpxchg and padding bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88101 Bug ID: 88101 Summary: Implement P0528R3, C++20 cmpxchg and padding bits Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: jason at gcc dot gnu.org Target Milestone: --- Although this paper was moved by Core at the meeting, it's a change to the library atomics clause. Do you need compiler support for this? It seems fairly straightforward to handle types for which has_unique_object_representations is false by zeroing the storage as the first step of initialization.
[Bug rtl-optimization/88033] [9 Regression] ICE on valid code at -O2 and -O3 on x86-64-linux-gnu: in remove_some_program_points_and_update_live_ranges, at lra-lives.c:1179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88033 Peter Bergner changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Peter Bergner --- Fixed.
[Bug rtl-optimization/88033] [9 Regression] ICE on valid code at -O2 and -O3 on x86-64-linux-gnu: in remove_some_program_points_and_update_live_ranges, at lra-lives.c:1179
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88033 --- Comment #4 from Peter Bergner --- Author: bergner Date: Mon Nov 19 19:35:51 2018 New Revision: 266282 URL: https://gcc.gnu.org/viewcvs?rev=266282=gcc=rev Log: gcc/ PR rtl-optimization/88033 * ira-lives.c (non_conflicting_reg_copy_p): Skip copies from a register to itself. Use HARD_REGISTER_NUM_P. gcc/testsuite/ PR rtl-optimization/88033 * gcc.target/i386/pr88033.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr88033.c Modified: trunk/gcc/ChangeLog trunk/gcc/ira-lives.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/78968] conflict between gnu's __cxa_thread_atexit and LLVM's/FreeBSD's implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968 Hannes Hauswedell changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Hannes Hauswedell --- Yes, this was fixed, thanks!
[Bug rtl-optimization/71496] Two picbase loads created for libjava code on powerpc-darwin after rev 228022.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71496 --- Comment #9 from Tobias Netzel --- Any opinion regarding my comment? Should I file a new bug for that? Without PIC enabled unconditionally saving and restoring R31 is obviously a waste of time and stack space...
[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088 --- Comment #2 from Mark Wielaard --- (In reply to Segher Boessenkool from comment #1) > This also would warn for targets where it is not an issue at all (where > trampolines are just data, or where the stack is executable anyway, or where > there is no such "executable" concept at all, for example). Do you have an example where -Wtrampolines warns unnecessarily? I might be reading the code wrong, but the trampolines warning is guarded by on_stack and targetm.calls.custom_function_descriptors != 0. So I believe it wouldn't warn in case the trampoline is generated on the heap or if the target uses descriptors for nested functions (which eliminates the need for trampolines that reside on the stack and require it to be made executable).
[Bug rtl-optimization/87718] [9 Regression] FAIL: gcc.target/i386/avx512dq-concatv2si-1.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87718 --- Comment #6 from Vladimir Makarov --- The culprit for the bad code generation is the following insn description (define_insn "*movsi_internal" [(set (match_operand:SI 0 "nonimmediate_operand" "=r,m ,*y,*y,?*y,?m,?r,?*y,*v,*v,*v,m ,?r,?*v,*k,*k ,*rm") (match_operand:SI 1 "general_operand" "g ,re,C ,*y,m ,*y,*y,r ,C ,*v,m ,*v,*v,r ,*r,*km,*k"))] Alternatives with sse regs are not considered at all (hint *) for cost calculation even if one operand is sse hard reg. And therefore sse class for another operand with pseudo is too costly. Removing the hints is not a solution. I believe we will have even more problems with GCC testsuite. So I am trying to solve it with specific treatment of moves for cost calculations. The patch I am working on solves the PR but currently creates a few GCC testsuite failures (unexpected but correct code generation). So I am continuing to work on the PR.
[Bug sanitizer/64839] libsanitizer shouldn't require
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64839 Harald van Dijk changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #20 from Harald van Dijk --- (In reply to Martin Liška from comment #19) > Can the bug be marked as resolved? Yes, sorry for missing the earlier request to do so.
[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 --- Comment #10 from nsz at gcc dot gnu.org --- it turns out the ieee_* functions are allowed in const expressions so they need to work at compile time too (see bug 78449), which of course won't work if they need runtime detection. so now compile-time and runtime behaviour of ieee_support_halting is different. so far no fortran expert clarified what is the expected semantics when you can only decide this at runtime (e.g. it might be better to always return false on targets that may not implement trapping, rather than report things inconsistently compile- vs runtime). (i think this bug can be closed, but then the other one has to be reopened).
[Bug testsuite/88098] FAIL: gcc.dg/Wbuiltin-declaration-mismatch-4.c (test for warnings, line 80)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88098 Rainer Orth changed: What|Removed |Added Target Milestone|--- |9.0
[Bug target/88100] no warning reported when value for vec_splat_{su}{8,16} would overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88100 Segher Boessenkool changed: What|Removed |Added Target|powerpc*|powerpc*-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-19 CC||segher at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Segher Boessenkool --- Confirmed. vec_splat_* do not check the range of their argument, apparently.
[Bug target/88100] New: no warning reported when value for vec_splat_{su}{8,16} would overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88100
Bug ID: 88100
Summary: no warning reported when value for
vec_splat_{su}{8,16} would overflow
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: pc at gcc dot gnu.org
Target Milestone: ---
Created attachment 45036
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45036=edit
test case
$ cat bug.c
#include
void foo() {
signed char cs0 = 0x100;
unsigned char cu0= 0x100;
signed short ss0 = 0x1;
unsigned short su0= 0x1;
signed int is0 = 0x1;
unsigned int iu0= 0x1;
vector signed char v8 = vec_splat_s8(256);
vector unsigned char v11 = vec_splat_u8(256);
vector signed short v12 = vec_splat_s16(0x1);
vector unsigned short v13 = vec_splat_u16(0x1);
vector signed int v14 = vec_splat_s32(0x1);
vector unsigned int v15 = vec_splat_u32(0x1);
}
$ gcc -c bug.c
bug.c: In function ‘foo’:
bug.c:3:21: warning: overflow in conversion from ‘int’ to ‘signed char’ changes
value from ‘256’ to ‘0’ [-Woverflow]
signed char cs0 = 0x100;
^
bug.c:4:22: warning: unsigned conversion from ‘int’ to ‘unsigned char’ changes
value from ‘256’ to ‘0’ [-Woverflow]
unsigned char cu0= 0x100;
^
bug.c:5:22: warning: overflow in conversion from ‘int’ to ‘short int’ changes
value from ‘65536’ to ‘0’ [-Woverflow]
signed short ss0 = 0x1;
^~~
bug.c:6:23: warning: unsigned conversion from ‘int’ to ‘short unsigned int’
changes value from ‘65536’ to ‘0’ [-Woverflow]
unsigned short su0= 0x1;
^~~
bug.c:7:20: warning: overflow in conversion from ‘long int’ to ‘int’ changes
value from ‘4294967296’ to ‘0’ [-Woverflow]
signed int is0 = 0x1;
^~~
bug.c:8:21: warning: unsigned conversion from ‘long int’ to ‘unsigned int’
changes value from ‘4294967296’ to ‘0’ [-Woverflow]
unsigned int iu0= 0x1;
^~~
bug.c:13:27: warning: overflow in conversion from ‘long int’ to ‘int’ changes
value from ‘4294967296’ to ‘0’ [-Woverflow]
vector signed int v14 = vec_splat_s32(0x1);
^
bug.c:14:29: warning: overflow in conversion from ‘long int’ to ‘int’ changes
value from ‘4294967296’ to ‘0’ [-Woverflow]
vector unsigned int v15 = vec_splat_u32(0x1);
^
--
Note: no warnings for the vector char and vector short types.
[Bug target/66488] segfault on sizeof(long) < sizeof(void*) and large GCC memory usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66488 --- Comment #19 from Stanisław Halik --- Works on my end. regards, sh
[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87957 --- Comment #6 from Jan Hubicka --- I think we have separate PR for this ICE. It is the ODR violation confusing the walk of duplicates. It needs to stop assuming that all duplicates are same TREE_CODE of type. I will cook up patch. Honza
[Bug fortran/53542] Diagnostic of USE-associated variables shows original instead of renamed symbol name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53542 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Dominique d'Humieres --- > Can the bug be marked as resolved? I think so.
[Bug target/58684] powerpc uses only unordered floating-point compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 --- Comment #9 from Segher Boessenkool --- It is not resolved yet no. That patch has some biggish issues still.
[Bug fortran/78746] charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746 --- Comment #13 from Dominique d'Humieres --- > Dominique: Can the bug be marked as resolved? The attached tests are still failing on trunk (9.0).
[Bug tree-optimization/78913] Probably misleading error reported by -Wformat-truncation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78913 Martin Sebor changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Martin Sebor --- I'm fine with resolving it if you are -- please reopen it (or maybe submit a new bug) if you think there's something else to fix here.
[Bug fortran/88099] New: ICE in maybe_legitimize_operand, at optabs.c:7170
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88099 Bug ID: 88099 Summary: ICE in maybe_legitimize_operand, at optabs.c:7170 Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- With -fsanitize=undefined or a test version (--enable-checking=yes) : (n2 is not a function reference due to missing "()", and not initialized) $ cat z1.f90 module m contains function n1() n1 = 3 n1 = n1 + n2 end function n2() n2 = 4 end end $ gfortran-9-20181118 -c z1.f90 -O2 $ gfortran-9-20181118 -c z1.f90 -g -O0 -Wall -Wextra -fcheck=all $ $ gfortran-9-20181118 -c z1.f90 -fsanitize=undefined during RTL pass: expand z1.f90:5:0: 5 | n1 = n1 + n2 | internal compiler error: in maybe_legitimize_operand, at optabs.c:7170 0xa4098a maybe_legitimize_operand ../../gcc/optabs.c:7169 0xa4098a maybe_legitimize_operands(insn_code, unsigned int, unsigned int, expand_operand*) ../../gcc/optabs.c:7298 0xa40b89 maybe_gen_insn(insn_code, unsigned int, expand_operand*) ../../gcc/optabs.c:7317 0xa43ed8 maybe_expand_insn(insn_code, unsigned int, expand_operand*) ../../gcc/optabs.c:7360 0x94ad5f expand_addsub_overflow ../../gcc/internal-fn.c:1005 0x9500e7 expand_UBSAN_CHECK_ADD ../../gcc/internal-fn.c:2193 0x77bd87 expand_call_stmt ../../gcc/cfgexpand.c:2622 0x77bd87 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3650 0x77bd87 expand_gimple_stmt ../../gcc/cfgexpand.c:3809 0x77dc87 expand_gimple_basic_block ../../gcc/cfgexpand.c:5845 0x7832c6 execute ../../gcc/cfgexpand.c:6450 $ gfortran-9-20181118-chk -c z1.f90 z1.f90:3:0: 3 |function n1() | Error: invalid (pointer) operands to plus/minus _2 = __result_n1.0_1 + n2; z1.f90:3:0: internal compiler error: verify_gimple failed 0xcccbdd verify_gimple_in_seq(gimple*) ../../gcc/tree-cfg.c:5082 0x9e0a45 gimplify_body(tree_node*, bool) ../../gcc/gimplify.c:13636 0x9e0d34 gimplify_function_tree(tree_node*) ../../gcc/gimplify.c:13726 0x82b6f7 cgraph_node::analyze() ../../gcc/cgraphunit.c:667 0x82e8e9 analyze_functions ../../gcc/cgraphunit.c:1126 0x82f9c2 symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2835
[Bug fortran/77382] ICE: verify_gimple failed -- expand_expr_real_1, at expr.c:9651
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77382 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #5 from G. Steinmetz --- Modified invalid code ICEs only at -O0 : $ cat z1.f90 subroutine g(x) entry h(g) end program p call g(1.0) call h(2.0) end $ gfortran-9-20181118 -c z1.f90 -O0 z1.f90:6:14: 6 |call h(2.0) | 1 Warning: Type mismatch in argument 'g' at (1); passed REAL(4) to UNKNOWN [-Wargument-mismatch] during RTL pass: expand z1.f90:5:0: 5 |call g(1.0) | internal compiler error: in expand_expr_real_1, at expr.c:9932 0x876586 expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:9926 0x76f264 expand_normal ../../gcc/expr.h:285 0x76f264 rtx_for_function_call ../../gcc/calls.c:2530 0x76f264 expand_call(tree_node*, rtx_def*, int) ../../gcc/calls.c:4031 0x87497e expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:10947 0x77c26a expand_expr ../../gcc/expr.h:279 0x77c26a expand_call_stmt ../../gcc/cfgexpand.c:2713 0x77c26a expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3650 0x77c26a expand_gimple_stmt ../../gcc/cfgexpand.c:3809 0x77dc87 expand_gimple_basic_block ../../gcc/cfgexpand.c:5845 0x7832c6 execute ../../gcc/cfgexpand.c:6450
[Bug fortran/66695] [7/8/9 Regression] [F03] ICE with binding-name equal to the name of a use-associated procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66695 G. Steinmetz changed: What|Removed |Added CC||gs...@t-online.de --- Comment #6 from G. Steinmetz --- Update : $ cat z1.f90 module m contains integer function f() end end module m2 use m contains subroutine s() bind(c, name='f') integer :: x x = f() end end $ gfortran-9-2018 -c z1.f90 z1.f90:11:0: 11 | x = f() | internal compiler error: in fold_convert_loc, at fold-const.c:2426 0x8a9b87 fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gcc/fold-const.c:2425 0x6ed255 gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool, bool) ../../gcc/fortran/trans-expr.c:9063 0x6fd58d gfc_trans_assignment_1 ../../gcc/fortran/trans-expr.c:10449 0x6bfdaf trans_code ../../gcc/fortran/trans.c:1822 0x6e7674 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6509 0x6c3b39 gfc_generate_module_code(gfc_namespace*) ../../gcc/fortran/trans.c:2216 0x67440b translate_all_program_units ../../gcc/fortran/parse.c:6112 0x67440b gfc_parse_file() ../../gcc/fortran/parse.c:6328 0x6bc89f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 --- $ cat z2.f90 module m contains integer function f() end end module m2 use m contains subroutine s() bind(c, name='f') print *, f() end end $ gfortran-9-2018 -c z2.f90 f951: Error: using result of function returning 'void'
[Bug c++/87542] [7/8 Regression] bogus error on attribute format with a named constant argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87542 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||9.0 Resolution|--- |FIXED Summary|[7/8/9 Regression] bogus|[7/8 Regression] bogus |error on attribute format |error on attribute format |with a named constant |with a named constant |argument|argument Known to fail||6.4.0, 7.3.0, 8.2.0 --- Comment #4 from Martin Sebor --- Fixed for GCC 9 in r266195. Since the patch also introduces a warning for (invalid) code that was previously silently accepted (pr87533) I'm not planning to backport it.
[Bug c/83656] missing -Wbuiltin-declaration-mismatch on declaration without prototype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83656 Martin Sebor changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Martin Sebor --- The warnings in the tests are problems in the tests. I've opened pr88098 for those. If you notice others please either add them there or open other testsuite bugs. The warning itself works as designed so let's keep this bug resolved.
[Bug testsuite/88098] FAIL: gcc.dg/Wbuiltin-declaration-mismatch-4.c (test for warnings, line 80)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88098 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-11-19 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Ever confirmed|0 |1
[Bug testsuite/88098] New: FAIL: gcc.dg/Wbuiltin-declaration-mismatch-4.c (test for warnings, line 80)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88098 Bug ID: 88098 Summary: FAIL: gcc.dg/Wbuiltin-declaration-mismatch-4.c (test for warnings, line 80) Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- The gcc.dg/Wbuiltin-declaration-mismatch-4.c test newly added in r266194 fails on 32-bit targets such as armv8l-unknown-linux-gnueabihf: https://gcc.gnu.org/ml/gcc-testresults/2018-11/msg02561.html and i686-pc-linux-gnu https://gcc.gnu.org/ml/gcc-testresults/2018-11/msg02553.html See also bug 83656 comment #8.
[Bug c++/67164] ICE: tree check: expected class ‘expression’, have ‘exceptional’ (argument_pack_select) in tree_operand_check, at tree.h:3356
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67164 --- Comment #14 from Louis Dionne --- I think so -- all the reproducers posted in this bug report can compile with GCC trunk.
[Bug sanitizer/80953] Support libsanitizer on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80953 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #11 from Eric Botcazou --- I have a bunch of sanitizer failures on SPARC/Solaris 11.3: FAIL: c-c++-common/asan/alloca_safe_access.c -O0 execution test FAIL: c-c++-common/asan/alloca_safe_access.c -O1 execution test FAIL: c-c++-common/asan/alloca_safe_access.c -O2 execution test FAIL: c-c++-common/asan/alloca_safe_access.c -O2 -flto execution test FAIL: c-c++-common/asan/alloca_safe_access.c -O2 -flto -flto-partition=none execution test FAIL: c-c++-common/asan/alloca_safe_access.c -O3 -g execution test FAIL: c-c++-common/asan/alloca_safe_access.c -Os execution test Program received signal SIGABRT, Aborted. [Switching to Thread 1 (LWP 1)] 0xff0de934 in __lwp_sigqueue () from /lib/libc.so.1 (gdb) bt #0 0xff0de934 in __lwp_sigqueue () from /lib/libc.so.1 #1 0xff082178 in raise () from /lib/libc.so.1 #2 0xff05a534 in abort () from /lib/libc.so.1 #3 0xff14bc74 in uw_init_context_1 (context=0xffbfead4, outer_cfa=0xffbff070, outer_ra=0xfe90abd0) at /homes/botcazou/gcc-head/src/libgcc/unwind-dw2.c:1602 #4 0xff14c580 in _Unwind_Backtrace (trace=0xfe90aaa0, trace_argument=0xffbff0e0) at /homes/botcazou/gcc-head/src/libgcc/unwind.inc:295 #5 0xfe90abd8 in ?? () from /homes/botcazou/gcc-head/install_sparc/lib/libasan.so.5 Backtrace stopped: previous frame identical to this frame (corrupt stack?)
[Bug middle-end/88097] Missing optimization of endian conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88097
--- Comment #2 from Daniel Fruzynski ---
Please also take a look on code which performs opposite conversion. gcc also
does not use movbe here. Both gcc and clang are not able to optimize this into
one 32-bit store, this is another possible optimization here.
void test2(Test* s, uint32_t ip)
{
s->Word1 = htons(ip >> 16);
s->Word2 = htons(ip);
}
[Bug tree-optimization/87025] [9 Regression] ICE in add_record, at optinfo-emit-json.cc:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87025 --- Comment #7 from David Malcolm --- Author: dmalcolm Date: Mon Nov 19 16:42:03 2018 New Revision: 266280 URL: https://gcc.gnu.org/viewcvs?rev=266280=gcc=rev Log: Fix -fsave-optimization-record ICE (PR tree-optimization/87025) PR tree-optimization/87025 reports an ICE within -fsave-optimization-record's optrecord_json_writer. The issue is that dump_context::begin_scope creates an optinfo of kind OPTINFO_KIND_SCOPE, but fails to call dump_context::end_any_optinfo, so the optinfo for the scope remains pending. The JSON writer would normally push a JSON array for the "scope" optinfo when the latter is emitted. However, if a dump_* call happens that doesn't flush the "scope" optinfo e.g. dump_printf (as opposed to dump_printf_loc), that dump_ call is added to the pending optinfo, and optinfo::handle_dump_file_kind changes the pending optinfo's m_kind (e.g. to OPTINFO_KIND_NOTE). Hence when the pending optinfo is eventually emitted, it isn't OPTINFO_KIND_SCOPE anymore, and hence the JSON writer doesn't create and push a JSON array for it, leading to dump_context's view of scopes getting out-of-sync with that of the JSON writer's. Later, dump_context::end_scope unconditionally tries to pop the JSON scope array, but no JSON scope array was added, leading to an assertion failure (or crash). The fix is to call dump_context::end_any_optinfo immediately after creating the scope optinfo, so that it is emitted immediately, ensuring that the JSON writer stays in-sync with the dump_context. gcc/ChangeLog: PR tree-optimization/87025 * dumpfile.c (dump_context::begin_scope): Call end_any_optinfo immediately after creating the scope optinfo. (selftest::test_pr87025): New function. (selftest::dumpfile_c_tests): Call it. * optinfo-emit-json.cc (optrecord_json_writer::pop_scope): Assert that we're not popping the top-level records array. * optinfo.cc (optinfo::handle_dump_file_kind): Assert that we're not changing the kind of a "scope" optinfo. gcc/testsuite/ChangeLog: PR tree-optimization/87025 * gcc.dg/pr87025.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr87025.c Modified: trunk/gcc/ChangeLog trunk/gcc/dumpfile.c trunk/gcc/optinfo-emit-json.cc trunk/gcc/optinfo.cc trunk/gcc/testsuite/ChangeLog
[Bug driver/49370] flags implemented in the specs file but undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49370 sandra at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||sandra at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from sandra at gcc dot gnu.org --- This has already been fixed at some point since the issue was filed.
[Bug tree-optimization/57371] Simplify (double)i != 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371 Yury Gribov changed: What|Removed |Added CC||ygribov at gcc dot gnu.org --- Comment #9 from Yury Gribov --- (In reply to Martin Liška from comment #7) > Can the bug be marked as resolved? TBH I didn't implement all Josephs suggestions (particularly my patch does not try to optimize more under -ffast-math and friends)...
[Bug target/44551] [missed optimization] AVX vextractf128 after vinsertf128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44551 --- Comment #20 from Matthias Kretz --- The original issue I meant to report is fixed. There are many more missed optimizations in the original example, though. I.e. https://godbolt.org/z/7P1o3O should compile to: use_insert_extract(): vmovdqu DATA+4(%rip), %xmm2 vmovdqu DATA+20(%rip), %xmm4 vpaddd DATA(%rip), %xmm2, %xmm0 vpaddd DATA+16(%rip), %xmm4, %xmm1 vpaddd %xmm2, %xmm0, %xmm0 vpaddd %xmm4, %xmm1, %xmm1 vmovups %xmm0, DATA(%rip) vmovups %xmm1, DATA+16(%rip) ret
[Bug libstdc++/79206] string_view operator== could do an early exit if sizes differ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79206 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|5.5 |7.0 --- Comment #4 from Jonathan Wakely --- Fixed in 7.1 and up.
[Bug tree-optimization/87025] [9 Regression] ICE in add_record, at optinfo-emit-json.cc:175
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87025 --- Comment #6 from David Malcolm --- Author: dmalcolm Date: Mon Nov 19 16:31:03 2018 New Revision: 266279 URL: https://gcc.gnu.org/viewcvs?rev=266279=gcc=rev Log: Eliminate global state from -fsave-optimization-record As work towards fixing PR tree-optimization/87025, this patch eliminates global state from optinfo-emit-json.cc in favor of adding an optional m_json_writer field to dump_context, replacing the m_forcibly_enable_optinfo flag. This allows for writing selftests for the interaction of the JSON-building code with the dumpfile.c code. In particular, the existing selftest that created optinfo instances now exercise the JSON-building code (although no JSON is actually written out). The patch also simplifies the layering by replacing optinfo::emit () with dump_context::emit_optinfo, so that dump_context has responsibility for keeping track of dump destinations. gcc/ChangeLog: PR tree-optimization/87025 * dump-context.h: Include "optinfo.h". (class optrecord_json_writer): New forward decl. (dump_context::forcibly_enable_optinfo_p): Delete. (dump_context::optinfo_enabled_p): New member function. (dump_context::optimization_records_enabled_p): New member function. (dump_context::set_json_writer): New member function. (dump_context::emit_optinfo): New member function. (dump_context::m_forcibly_enable_optinfo): Delete. (dump_context::m_json_writer): New member data. * dumpfile.c (dump_context::set_json_writer): New member function. (dump_context::finish_any_json_writer): New member function. (dump_context::end_scope): Replace call to optimization_records_maybe_pop_dump_scope with call to m_json_writer->pop_scope. (dump_context::optinfo_enabled_p): New member function. (dump_context::end_any_optinfo): Replace call to optinfo::emit with call to dump_context::emit_optinfo. (dump_context::emit_optinfo): New member function. (temp_dump_context::temp_dump_context): Replace m_forcibly_enable_optinfo with call to set_json_writer. (temp_dump_context::~temp_dump_context): Clean up any json writer. * optinfo-emit-json.cc (class optrecord_json_writer): Move to optinfo-emit-json.h (the_json_writer): Delete. (optimization_records_start): Delete. (optimization_records_finish): Delete. (optimization_records_enabled_p): Delete, in favor of dump_context::optimization_records_enabled_p. (optimization_records_maybe_record_optinfo): Delete. (optimization_records_maybe_pop_dump_scope): Delete. * optinfo-emit-json.h: Include "json.h". Delete forward decl of opt_pass. (optimization_records_start): Delete. (optimization_records_finish): Delete. (optimization_records_enabled_p): Delete. (optimization_records_maybe_record_optinfo): Delete. (optimization_records_maybe_pop_dump_scope): Delete. (class optrecord_json_writer): Move here from optinfo-emit-json.cc. * optinfo.cc (optinfo::emit_for_opt_problem): Replace call to optinfo::emit with call to dump_context::emit_optinfo. (optinfo::emit): Delete, in favor of dump_context::emit_optinfo. (optinfo_enabled_p): Delete, in favor of dump_context::optinfo_enabled_p. (optinfo_wants_inlining_info_p): Update for conversion o optimization_records_enabled_p to a member function of dump_context. * optinfo.h (optinfo_enabled_p): Delete, in favor of dump_context::optinfo_enabled_p. (optinfo::emit): Delete, in favor of dump_context::emit_optinfo. * toplev.c: Include "dump-context.h". (compile_file): Replace call to optimization_records_finish with dump_context::finish_any_json_writer. (do_compile): Replace call to optimization_records_start with conditionally creating a optrecord_json_writer for the dump_context. Modified: trunk/gcc/ChangeLog trunk/gcc/dump-context.h trunk/gcc/dumpfile.c trunk/gcc/optinfo-emit-json.cc trunk/gcc/optinfo-emit-json.h trunk/gcc/optinfo.cc trunk/gcc/optinfo.h trunk/gcc/toplev.c
[Bug middle-end/88097] Missing optimization of endian conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88097 --- Comment #1 from Daniel Fruzynski --- I also tried to swap Word1 and Word2 fields in structure to see what will happen. It turned out that gcc with -O3 -mmovbe generates code without movbe: [asm] test(Test*): movzx eax, WORD PTR [rdi+2] movzx edx, WORD PTR [rdi] rorw $8, ax rorw $8, dx sal eax, 16 movzx edx, dx or eax, edx ret [/asm] clang generates code with movbe: [asm] test(Test*): # @test(Test*) movbe cx, word ptr [rdi + 2] shl ecx, 16 movbe ax, word ptr [rdi] movzx eax, ax or eax, ecx ret [/asm]
[Bug rtl-optimization/87246] [7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246
--- Comment #4 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #3)
> Started with r233107.
>
> Slightly adjusted testcase:
>
> __int128 a;
> int b;
>
> void
> bar (__int128 *x)
> {
> if (*x != 0)
> {
> a = 0;
> b = b <= *x;
> }
> }
>
> void
> foo (unsigned int x)
> {
> bar (x + 1);
> }
>
> This is on
> (mem:TI (zero_extend:DI (plus:SI (reg/v:SI 91 [ x ]) (const_int 1 [0x1]
> which matches the predicate of the *movti_internal instruction -
> general_operand, but the selected alternative needs offsettable memory.
> LRA attempts:
> (mem:DI (plus:DI (zero_extend:DI (plus:SI (reg/v:SI 91 [ x ])
> (const_int 1 [0x1])))
> (const_int 8 [0x8])) [1 *_3+8 S8 A64])
> but that isn't a valid offsettable address, it should have instead forced
> the zero_extend into a register.
>
> Or should some reload hook in the backend tell LRA that it should do that if
> it wants an offsettable address out of that?
This should be handled in ix86_secondary_reload TARGET_SECONDARY_RELOAD hook,
which has the code to handle
/* Double-word spills from general registers to non-offsettable memory
references (zero-extended addresses) require special handling. */
via reload_noff_{load,store} patterns.
[Bug c/46636] attribute aligned is documented as using bytes, uses addressable units instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46636 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #5 from sandra at gcc dot gnu.org --- Summarizing the discussion here, I think this is a code bug rather than a documentation bug.
[Bug libstdc++/80624] char_traits::eof() doesn't meet requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80624 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #4 from Jonathan Wakely --- Fixed for 8.1 and up, although it might need to be revisited as the "fix" is nearly as surprising as the bug itself.
[Bug rtl-optimization/78952] Combine does not convert 8-bit sign-extract to a zero-extract for QImode operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78952 Uroš Bizjak changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-11-19 Ever confirmed|0 |1 --- Comment #6 from Uroš Bizjak --- (In reply to Martin Liška from comment #5) > Uros: Can the bug be marked as resolved? The patch implements the workaround for x86 targets, so it depends if we want the transformation in the middle-end or not.
[Bug c++/71448] pointer relational comparison fails inside constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71448 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |6.2
[Bug debug/87039] [8 Regression] DW_OP_fbreg used without a frame base on a C++ code w/ -fopenmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87039 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression]|[8 Regression] DW_OP_fbreg |DW_OP_fbreg used without a |used without a frame base |frame base on a C++ code w/ |on a C++ code w/ -fopenmp |-fopenmp| --- Comment #6 from Jakub Jelinek --- Fixed on the trunk (so far).
[Bug libstdc++/71500] regex::icase only works on first character in a range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71500 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.0 --- Comment #19 from Jonathan Wakely --- Yes, I think it's all fixed now. Comment 0 and comment 3 are fixed from 7.1, but comment 15 isn't fixed until 8.1
[Bug tree-optimization/88071] [8 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88071 Jakub Jelinek changed: What|Removed |Added Summary|[8/9 Regression] ICE: |[8 Regression] ICE: |verify_gimple failed|verify_gimple failed |(error: dead STMT in EH |(error: dead STMT in EH |table) |table) --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug middle-end/88097] New: Missing optimization of endian conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88097
Bug ID: 88097
Summary: Missing optimization of endian conversion
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: bugzi...@poradnik-webmastera.com
Target Milestone: ---
I have found some old code network code which looked like this:
[code]
#include
#include
struct Test
{
uint16_t Word1;
uint16_t Word2;
};
uint32_t test(Test* ip)
{
return ((ntohs(ip->Word1) << 16) | ntohs(ip->Word2));
}
[/code]
gcc 8.2 compiles it in following way (with -O3):
[asm]
test(Test*):
movzx eax, WORD PTR [rdi]
movzx edx, WORD PTR [rdi+2]
rorw $8, ax
rorw $8, dx
sal eax, 16
movzx edx, dx
or eax, edx
ret
[/asm]
clang 7.0.0 recognizes that both 16-bit fields are next to each other, so
32-bit byte swap can be used:
[asm]
test(Test*): # @test(Test*)
mov eax, dword ptr [rdi]
bswap eax
ret
[/asm]
And this is with -mmovbe added:
[asm]
test(Test*): # @test(Test*)
movbe eax, dword ptr [rdi]
ret
[/asm]
[Bug libstdc++/70745] Wrong handling of regex_constant::match_not_eow and regex_constant::match_not_bow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70745 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #4 from Jonathan Wakely --- Yes, I think this is fixed in 7.1 and up. Tim, please reopen if there was more work you wanted to do.
[Bug libstdc++/63345] Multiple undefined behaviors (static_cast<>) in libstdc++-v3/include/bits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63345 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=66017 Resolution|--- |FIXED Target Milestone|--- |6.0 --- Comment #13 from Jonathan Wakely --- Yes, all fixes should be present in gcc-6.1 and up.
[Bug rtl-optimization/87246] [7/8/9 Regression] ICE in decompose_normal_address, at rtlanal.c:6379
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87246
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
||jakub at gcc dot gnu.org,
||uros at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Started with r233107.
Slightly adjusted testcase:
__int128 a;
int b;
void
bar (__int128 *x)
{
if (*x != 0)
{
a = 0;
b = b <= *x;
}
}
void
foo (unsigned int x)
{
bar (x + 1);
}
This is on
(mem:TI (zero_extend:DI (plus:SI (reg/v:SI 91 [ x ]) (const_int 1 [0x1]
which matches the predicate of the *movti_internal instruction -
general_operand, but the selected alternative needs offsettable memory.
LRA attempts:
(mem:DI (plus:DI (zero_extend:DI (plus:SI (reg/v:SI 91 [ x ])
(const_int 1 [0x1])))
(const_int 8 [0x8])) [1 *_3+8 S8 A64])
but that isn't a valid offsettable address, it should have instead forced the
zero_extend into a register.
Or should some reload hook in the backend tell LRA that it should do that if it
wants an offsettable address out of that?
[Bug c/88088] -Wtrampolines should be enabled by -Wall (or -Wextra)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088 Segher Boessenkool changed: What|Removed |Added CC||segher at gcc dot gnu.org --- Comment #1 from Segher Boessenkool --- This also would warn for targets where it is not an issue at all (where trampolines are just data, or where the stack is executable anyway, or where there is no such "executable" concept at all, for example).
[Bug debug/65771] ICE (in loc_list_from_tree, at dwarf2out.c:14964) on arm-linux-gnueabihf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65771 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|5.5 |6.0 --- Comment #20 from Ramana Radhakrishnan --- Fixed for GCC 6 from the timeline here. Wont fix for GCC 5.
[Bug fortran/68426] Simplification of SPREAD with a derived type element is unimplemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68426 --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to Martin Liška from comment #3) > Can the bug be marked as resolved? No.
[Bug fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 Jerry DeLisle changed: What|Removed |Added Last reconfirmed|2016-11-14 00:00:00 |2018-11-19 Known to work||8.2.1, 9.0 --- Comment #28 from Jerry DeLisle --- I am not getting a clean patch apply to gcc-7-branch yet. Updated known to work.
[Bug target/53440] [arm] generic thunk code fails for method which uses '...'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53440 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #10 from Ramana Radhakrishnan --- Fixed for GCC 7.
[Bug tree-optimization/43721] Failure to optimise (a/b) and (a%b) into single __aeabi_idivmod call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #12 from Ramana Radhakrishnan --- Fixed in GCC7 then.
[Bug driver/44933] --help=common undocumented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44933
sandra at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC||sandra at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from sandra at gcc dot gnu.org ---
This problem has been fixed at some point since the bug was filed. gcc --help
now prints
--help={common|optimizers|params|target|warnings|[^]{joined|separate|undocumented}}[,...].
and -fdump- is listed by gcc --help=common.
[Bug sanitizer/88022] Support dynamic shadow offset in ASan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88022 --- Comment #5 from chefmax at gcc dot gnu.org --- (In reply to Martin Liška from comment #4) > Agree with Jakub that if really not necessary, I wouldn't complicate > libsanitizer. My point was that we won't need to complicate libsanitizer -- almost all necessary code is already there, just need to enable it for Linux. > Slowness is nicely seen in your table Maxim: > https://github.com/google/sanitizers/issues/837#issuecomment-322519336 > > Can you Maximum more describe which difficulties do you see using > libsanitizer on 32-bit ARM target? AFAIR we had problems with PIE binaries on ARM (and we still have them). Anyways, if you don't interested, I'm not insist on implementing this feature in GCC. Just be informed that sanitizer runtime is almost ready for this to be implemented.
[Bug middle-end/87836] ICE in cc1 for gcc-6.5.0 with SPARC hardware
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836 --- Comment #14 from Gary Mills --- Regarding your suggestion, is there a way to get the compiler to reveal the steps it goes through in compiling the program? All I get now is the backtrace when it hits the error. I need to know what the compiler is doing before that.
