[Bug demangler/105039] rust demangler stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105039 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nick Clifton --- Patch applied.
[Bug demangler/105039] rust demangler stack overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105039 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #1 from Nick Clifton --- Proposed patch submitted here: https://gcc.gnu.org/pipermail/gcc-patches/2022-March/592244.html
[Bug demangler/98886] stack overflow in cxxfilt, demangle_type, rust-demangle.c:854
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98886 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #12 from Nick Clifton --- Fixed on mainline.
[Bug demangler/99935] Stack exhaustion demangling rust mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Nick Clifton --- Fixed on mainline.
[Bug demangler/98886] stack overflow in cxxfilt, demangle_type, rust-demangle.c:854
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98886 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #10 from Nick Clifton --- A patch to fix this problem has been proposed on gcc-patches: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589277.html
[Bug demangler/99935] Stack exhaustion demangling rust mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935 --- Comment #9 from Nick Clifton --- A revised patch to fix this PR has been prroposed on gcc-patches: https://gcc.gnu.org/pipermail/gcc-patches/2022-January/589277.html
[Bug demangler/99188] cxxfilt may exist a uaf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99188 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #8 from Nick Clifton --- (In reply to Michael Matz from comment #7) > Actually, it _is_ fixed. This problem report is about version 2.26, which > is many > years old. Current versions don't have this problem, at the very least when > the problematic code was removed whole-sale in late 2018/early 2019. Just checked - the problem is fixed in 2.27 and all later versions
[Bug demangler/99935] Stack exhaustion demangling rust mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935 --- Comment #3 from Nick Clifton --- (In reply to Jonathan Wakely from comment #2) > This patch breaks MinGW, see PR 101779 But it can be fixed by: https://sourceware.org/bugzilla/show_bug.cgi?id=28207
[Bug demangler/101779] Compilation of rust-demangle.c fails on MinGW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101779 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #4 from Nick Clifton --- Note - this bug has been reported and fixed in the binutils copy of the libiberty sources: https://sourceware.org/bugzilla/show_bug.cgi?id=28207
[Bug demangler/100968] libiberty: stuck in infinite loop in nm-new while demangling rust symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100968 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #1 from Nick Clifton --- Created attachment 51156 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51156=edit Proposed patch I think that this PR is a duplicate of 99935. The patch for that PR (attached here) also fixes this problem.
[Bug demangler/99935] Stack exhaustion demangling rust mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935 --- Comment #1 from Nick Clifton --- Created attachment 50777 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50777=edit Proposed patch Here is a possible patch for the problem, adding a recursion limit to the demangle_path() function. Note - a variation of this bug appears to have been reported on the Ubuntu mailing lists with a different reproducer: https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1925348
[Bug demangler/100177] New: Rust demangler tests fail on big-endian hosts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100177 Bug ID: 100177 Summary: Rust demangler tests fail on big-endian hosts Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: nickc at gcc dot gnu.org Target Milestone: --- The rust portion of the libiberty testsuite fails when run on a big-endian host: ./test-demangle < ./libiberty/testsuite/rust-demangle-expected FAIL at line 222, options --format=rust: in: _RMCs4fqI2P2rA04_13const_genericINtB0_4CharKc76_E out: > FAIL at line 285, options --format=auto: in: _RMCs4fqI2P2rA04_13const_genericINtB0_4CharKc76_E out: > ./test-demangle: 68 tests, 2 failures The same failures do not happen when the tests are run on a little endian host. This problem appears to have existed for at least a few months and was recently reported on the binutils bugzilla system: https://sourceware.org/bugzilla/show_bug.cgi?id=27751
[Bug demangler/99935] New: Stack exhaustion demangling rust mangled name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99935 Bug ID: 99935 Summary: Stack exhaustion demangling rust mangled name Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: nickc at gcc dot gnu.org Target Milestone: --- The rust demangler can be pushed into an infinite loop, triggering stack exhaustion: % cat pr27963 # Reproduced from binutils PR 27963. # Note - the expected output is wrong. It is just there as a placeholder. --format=rust _RIMBALO_suB_I__Z5printi fred % valgrind ./testsuite/test-demangle < pr27963 [...] ==429737== Stack overflow in thread #1: can't grow stack to 0x1ffe001000 [...] =429737== Stack overflow in thread #1: can't grow stack to 0x1ffe001000 ==429737==at 0x410BA7: demangle_path (rust-demangle.c:742) [...] Segmentation fault (core dumped)
[Bug demangler/88629] Regression lead to Heap-buffer-overflow problem in function d_expression_1 in cp-demangle.c, as demonstrated by c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88629 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #13 from Nick Clifton --- (In reply to prajwapa from comment #12) > Could you please let me know, in which binutils version is this fixed? Not really. I can confirm that the test cases do not fail when tested with binutils 2.35 (with sanitization enabled) and with any binutils all the way back to 2.30 if sanitization is not enabled. Given that the bug was reported in 2018-12 and assuming that it was fixed at some point in the 6 months after that, then the nearest binutils release that would have included the fix is 2.33. I hope that this helps. Cheers Nick
[Bug other/89394] libiberty :stack overflow in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89394 --- Comment #10 from Nick Clifton --- (In reply to Trupti Pardeshi from comment #9) > May I know, in which version of binutils this fix is available? 2.35. Which should be available in August, all being well. Cheers Nick PS. The fix is already in the mainline development code, so you can always clone the repository and build your own toolchain.
[Bug target/85978] config/frv/frv.c: 3 * iffy code in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85978 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Nick Clifton --- Hi David, I think that it will be better to add the missing break statements and allow the nested switches to correctly exit to the end of the function. In that way the code is clearly only looking for costs that are better than the default HIGH_COST. Cheers Nick
[Bug target/85978] config/frv/frv.c: 3 * iffy code in switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85978 --- Comment #2 from Nick Clifton --- Author: nickc Date: Mon Sep 30 15:27:14 2019 New Revision: 276306 URL: https://gcc.gnu.org/viewcvs?rev=276306=gcc=rev Log: Fix compile time warning about building the FRV backend by adding missing break statements to the switches in frv_register_move_cost. PR target/85978 * config/frv/frv.c (frv_register_move_cost): Add break statements to avoid falling through to the wrong cases. Tidy code. Modified: trunk/gcc/ChangeLog trunk/gcc/config/frv/frv.c
[Bug target/59205] config/iq2000/iq2000.c:2188: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59205 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Nick Clifton --- Hi David, It is obvious that this function never actually did anything worthwhile, so I have decided to just remove it entirely and allow gcc's generic section selection code to be used instead. Cheers Nick
[Bug other/89863] [meta-bug] Issues that static analyzers (cppcheck, clang-static-analyzer) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 59205, which changed state. Bug 59205 Summary: config/iq2000/iq2000.c:2188: possible cut'n'paste error ? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59205 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/59205] config/iq2000/iq2000.c:2188: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59205 --- Comment #2 from Nick Clifton --- Author: nickc Date: Mon Sep 30 15:18:14 2019 New Revision: 276304 URL: https://gcc.gnu.org/viewcvs?rev=276304=gcc=rev Log: Remove the iq2000_select_section function the iq2000 backend - it never provided any useful functionality. PR target/59205 * config/iq2000/iq2000.c (iq2000_select_section): Delete. (TARGET_ASM_SELECT_SECTION): Remove definition. (TARGET_HAVE_SWITCHABLE_BSS_SECTIONS): Allow definition. Modified: trunk/gcc/ChangeLog trunk/gcc/config/iq2000/iq2000.c
[Bug plugins/90924] lto-plugin/lto-plugin.c heap memory corruption due to insufficient sanitization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90924 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #12 from Nick Clifton --- Hi Tanaya, (In reply to Tanaya Patil from comment #11) > May I know if Binutils-2.31 is also affected and requires this fix? Any > heads up will be appreciated. Yes it is. As is 2.32 as well. I have however updated the binutils mainline sources so version 2.33, which is due out soon, will contain the fix. Cheers Nick
[Bug demangler/88783] integer overflow in libiberty, heap overflow will be triggered in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88783 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |MOVED --- Comment #2 from Nick Clifton --- Hi tfx, Thank you vert much for reporting this bug. Unfortunately the binutils project does not maintain the libiberty library (which contains the cplus-dem.c source file). Instead this is handled by the gcc project. So please could you refile your bug report on the gcc bugzilla system: https://gcc.gnu.org/bugzilla/enter_bug.cgi?product=gcc Thank you. Cheers Nick
[Bug libstdc++/90045] [9 Regression] fails to build a rx-elf cross toolchain with C++ enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90045 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #13 from Nick Clifton --- FYI - I have now checked in a patch to the RX assembler which fixes this problem. Martin - I will leave it to you to verify that the build now works (since I am lazy, and it is the start of a long weekend) but if there are problems please let me know. Cheers Nick
[Bug other/89395] libiberty: heap buffer overflow in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89395 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Nick Clifton --- The patch recently applied for PR 89394 also appears to fix this PR.
[Bug other/89394] libiberty :stack overflow in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89394 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Nick Clifton --- The patch has now been committed.
[Bug other/89394] libiberty :stack overflow in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89394 --- Comment #7 from Nick Clifton --- Author: nickc Date: Wed Apr 10 14:44:47 2019 New Revision: 270258 URL: https://gcc.gnu.org/viewcvs?rev=270258=gcc=rev Log: Fix a stack exhaustion bug in libiberty's demangler when decoding a pathalogically constructed mangled name. PR 89394 * cp-demangle.c (cplus_demangle_fill_name): Reject negative lengths. (d_count_templates_scopes): Replace num_templates and num_scopes parameters with a struct d_print_info pointer parameter. Adjust body of the function accordingly. Add recursion counter and check that the recursion limit is not reached. (d_print_init): Pass dpi parameter to d_count_templates_scopes. Reset recursion counter afterwards, unless the recursion limit was reached. Modified: trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c
[Bug target/90028] On Intel Skylake (-march=native) generated avx512 instruction can be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90028 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #17 from Nick Clifton --- (In reply to Jakub Jelinek from comment #8) > Fedora binutils-2.31.1-24.fc29.x86_64 has the bug, haven't checked upstream > 2.31.1 nor which exact patch fixed it. FYI - binutils-2.31.1-25.fc29.x86_64 now contains the patch. Cheers Nick
[Bug other/89394] libiberty :stack overflow in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89394 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-03-21 CC||nickc at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Nick Clifton --- I have proposed a patch to fix this bug: https://gcc.gnu.org/ml/gcc-patches/2019-03/msg01048.html
[Bug demangler/88539] A memory leak issue was discovered in cplus-dem.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88539 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |WONTFIX --- Comment #3 from Nick Clifton --- Sorry, but a leak of 10 bytes is just not serious enough to be worth worrying about. Especially when these programs do not run continuously but instead terminate shortly after they are invoked.
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Nick Clifton --- fixed by increasing the recursion limit to 2048.
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 --- Comment #8 from Nick Clifton --- Author: nickc Date: Tue Dec 11 11:59:53 2018 New Revision: 267020 URL: https://gcc.gnu.org/viewcvs?rev=267020=gcc=rev Log: Fix a failure in the libiberty testsuite by increasing the demangle recursion limit to 2048. PR 88409 * demangle.h (DEMANGLE_RECURSION_LIMIT): Increase to 2048. Modified: trunk/include/ChangeLog trunk/include/demangle.h
[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675 --- Comment #8 from Nick Clifton --- (In reply to Tanaya Patil from comment #7) > Should we expect this fix to be in Binutil 2.32? Yes. :-)
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 --- Comment #5 from Nick Clifton --- (In reply to H.J. Lu from comment #4) > I am expecting that > > [hjl@gnu-cfl-1 libiberty]$ c++filt > _ZN4modc6parser8sequenceINS_9astParser13LocatedParserINS0_9ParserRefINS2_UlRN > S2_16TokenParserInputEE_EINS0_14OptionalParserINS2_18ListParserTemplateIL > NS_6tokens5Token4TypeE4EXadL_ZNSD_Ut_13parenthesized6ParserINS4_INS0_6Par > serIS5_NS_3ast10ExpressionENSA_INS4_INS2_22OneOfKeywordsToTParserINSJ > _5StyleEEENS0_14SequenceParserIS5_INS0_18ExactElementParserIS5_EENSA_ISM_ > ENS0_14RepeatedParserINS4_INS0_15TransformParserINSU_IS5_INS4_INSP_INSJ_1 > 0Annotation12RelationshipESX_EEENS2_UlNS2_3LocES12_ONS_5MaybeISK_EEE19_EE > EEELb0EENSU_INS0_17ExtractParserTypeIT_E9InputTypeEINS0_8MaybeRefIS1F_E4T > ypeEDpNS1I_IT0_E4TypeOS1F_DpOS1L_ > > continues to work. Does it work with your patch? No. But "c++filt -r " will work. Is that string an example of a real world mangled symbol name, or was it just invented to test the demangler ?
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
Nick Clifton changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Nick Clifton ---
(In reply to H.J. Lu from comment #2)
Hi H.J.
> > The attached patch resolves the problem by adding a --no-recurse-limit
> > option to the demangler testser and then using it for the problematic
> > test case. I felt that this was a better solution than raising the
> > recursion limit, as it means that the limit detecting code will actually
> > be exercised by the testsuite.
> This will cause a regression since this input will fail now.
Umm, sorry ? The change means that the old behaviour of the demangler
is restored. Ie the recursion limit is not enforced, and thus the test
will behave exactly as it used to do.
Unless you mean that there would be a problem if the test input (or
something similar) is ever generated by the compilation of a real-world
program. In which case I agree, there would be a problem. But are you
ever going to get a real-world mangled version of:
modc::parser::ParserRef::Parser::Style>
>
> >::InputType,
modc::parser::MaybeRef&&)#21}>::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>::Parser > > > >::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>
>::Parser::Style> > > >::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>,
modc::astParser::LocatedParser
> > > >::Type,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >,
false>::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >, false> >::Type>
modc::parser::sequence
>,
modc::parser::OptionalParser::Parser > > >,
modc::astParser::LocatedParser
>::Parser::Style> > >,
modc::parser::SequenceParser,
modc::astParser::LocatedParser
> > >,
modc::parser::RepeatedParser::Parser::Style>
>::Parser >
>::Parser::Annotation::Relationship> >,
modc::parser::ExactElementParser> >,
modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}> >, false>
>(modc::astParser::{lambda(modc::astParser::Loc, modc::parser::RepeatedParser,
modc::Maybe&&)#21}&&,
(modc::parser::ExtractParserType
> >&&)...)
I would have thought that that would be extremely unlikely. Am I wrong ?
[Bug other/88409] [9 Regression] FAIL at line 4429, options --format=gnu-v3:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #1 from Nick Clifton --- Created attachment 45184 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45184=edit Proposed patch *sigh* Yes, I forgot to run the libiberty testsuite, and of course there is one test that actually breaches the demangling limit. The attached patch resolves the problem by adding a --no-recurse-limit option to the demangler testser and then using it for the problematic test case. I felt that this was a better solution than raising the recursion limit, as it means that the limit detecting code will actually be exercised by the testsuite. Currently waiting for review of the patch...
[Bug demangler/82890] Demangler segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82890 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Nick Clifton --- Fixed by commit 266886.
[Bug demangler/85122] Stack Overflow(Stack Exhaustion) in demangle related functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85122 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Nick Clifton --- Fixed by commit 266886.
[Bug other/86656] Issues found with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 85122, which changed state. Bug 85122 Summary: Stack Overflow(Stack Exhaustion) in demangle related functions https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85122 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 Nick Clifton changed: What|Removed |Added Status|WAITING |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #13 from Nick Clifton --- Fixed by commit 266886.
[Bug c++/87350] NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #8 from Nick Clifton --- Fixed by commit 266886
[Bug demangler/87681] Recursive Stack Overflow within function d_name, d_encoding, and d_local_name in cp-demangle.c, as demonstrated by "nm -C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87681 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Fixed by commit 266886.
[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Nick Clifton --- Fixed by commit 266886.
[Bug c++/87636] Infinite Recursive Stack Frames in cp-demangle.c in libiberty(function cplus_demangle_type, d_bare_function_type, d_function_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87636 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Nick Clifton --- Fixed by commit 266886.
[Bug demangler/87620] NULL deref in iterate_demangle_function (117536819)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87620 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Nick Clifton --- Fixed by commit 266886.
[Bug demangler/86664] Demangler segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86664 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Fixed by commit 266886.
[Bug demangler/85454] Multiple memory corruptions in objdump / C++ name demangler (binuitils-2.30-15ubuntu1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85454 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Nick Clifton --- Fixed with commit 266886.
[Bug other/86656] Issues found with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 85454, which changed state. Bug 85454 Summary: Multiple memory corruptions in objdump / C++ name demangler (binuitils-2.30-15ubuntu1) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85454 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug demangler/85452] Stack-Overflow in nm-new / C++ name demangler (binuitils-2.30-15ubuntu1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85452 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #1 from Nick Clifton --- Fixed with commit 266886
[Bug demangler/85373] Ice in demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85373 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- Fixed with commit 266886.
[Bug c++/87335] The stack overflow in function cplus_demangle_type in cp-demangle.c:2565 (c++filt -t)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87335 --- Comment #12 from Nick Clifton --- Author: nickc Date: Fri Dec 7 10:33:30 2018 New Revision: 266886 URL: https://gcc.gnu.org/viewcvs?rev=266886=gcc=rev Log: Add a recursion limit to libiberty's demangling code. The limit is enabled by default, but can be disabled via a new demangling option. include * demangle.h (DMGL_NO_RECURSE_LIMIT): Define. (DEMANGLE_RECURSION_LIMIT): Define PR 87681 PR 87675 PR 87636 PR 87350 PR 87335 libiberty * cp-demangle.h (struct d_info): Add recursion_level field. * cp-demangle.c (d_function_type): Add recursion counter. If the recursion limit is reached and the check is not disabled, then return with a failure result. (cplus_demangle_init_info): Initialise the recursion_level field. (d_demangle_callback): If the recursion limit is enabled, check for a mangled string that is so long that there is not enough stack space for the local arrays. * cplus-dem.c (struct work): Add recursion_level field. (squangle_mop_up): Set the numb and numk fields to zero. (work_stuff_copy_to_from): Handle the case where a btypevec or ktypevec field is NULL. (demangle_nested_args): Add recursion counter. If the recursion limit is not disabled and reached, return with a failure result. Modified: trunk/include/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/cp-demangle.h trunk/libiberty/cplus-dem.c
[Bug demangler/87681] Recursive Stack Overflow within function d_name, d_encoding, and d_local_name in cp-demangle.c, as demonstrated by "nm -C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87681 --- Comment #1 from Nick Clifton --- Author: nickc Date: Fri Dec 7 10:33:30 2018 New Revision: 266886 URL: https://gcc.gnu.org/viewcvs?rev=266886=gcc=rev Log: Add a recursion limit to libiberty's demangling code. The limit is enabled by default, but can be disabled via a new demangling option. include * demangle.h (DMGL_NO_RECURSE_LIMIT): Define. (DEMANGLE_RECURSION_LIMIT): Define PR 87681 PR 87675 PR 87636 PR 87350 PR 87335 libiberty * cp-demangle.h (struct d_info): Add recursion_level field. * cp-demangle.c (d_function_type): Add recursion counter. If the recursion limit is reached and the check is not disabled, then return with a failure result. (cplus_demangle_init_info): Initialise the recursion_level field. (d_demangle_callback): If the recursion limit is enabled, check for a mangled string that is so long that there is not enough stack space for the local arrays. * cplus-dem.c (struct work): Add recursion_level field. (squangle_mop_up): Set the numb and numk fields to zero. (work_stuff_copy_to_from): Handle the case where a btypevec or ktypevec field is NULL. (demangle_nested_args): Add recursion counter. If the recursion limit is not disabled and reached, return with a failure result. Modified: trunk/include/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/cp-demangle.h trunk/libiberty/cplus-dem.c
[Bug c++/87636] Infinite Recursive Stack Frames in cp-demangle.c in libiberty(function cplus_demangle_type, d_bare_function_type, d_function_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87636 --- Comment #3 from Nick Clifton --- Author: nickc Date: Fri Dec 7 10:33:30 2018 New Revision: 266886 URL: https://gcc.gnu.org/viewcvs?rev=266886=gcc=rev Log: Add a recursion limit to libiberty's demangling code. The limit is enabled by default, but can be disabled via a new demangling option. include * demangle.h (DMGL_NO_RECURSE_LIMIT): Define. (DEMANGLE_RECURSION_LIMIT): Define PR 87681 PR 87675 PR 87636 PR 87350 PR 87335 libiberty * cp-demangle.h (struct d_info): Add recursion_level field. * cp-demangle.c (d_function_type): Add recursion counter. If the recursion limit is reached and the check is not disabled, then return with a failure result. (cplus_demangle_init_info): Initialise the recursion_level field. (d_demangle_callback): If the recursion limit is enabled, check for a mangled string that is so long that there is not enough stack space for the local arrays. * cplus-dem.c (struct work): Add recursion_level field. (squangle_mop_up): Set the numb and numk fields to zero. (work_stuff_copy_to_from): Handle the case where a btypevec or ktypevec field is NULL. (demangle_nested_args): Add recursion counter. If the recursion limit is not disabled and reached, return with a failure result. Modified: trunk/include/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/cp-demangle.h trunk/libiberty/cplus-dem.c
[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87675 --- Comment #5 from Nick Clifton --- Author: nickc Date: Fri Dec 7 10:33:30 2018 New Revision: 266886 URL: https://gcc.gnu.org/viewcvs?rev=266886=gcc=rev Log: Add a recursion limit to libiberty's demangling code. The limit is enabled by default, but can be disabled via a new demangling option. include * demangle.h (DMGL_NO_RECURSE_LIMIT): Define. (DEMANGLE_RECURSION_LIMIT): Define PR 87681 PR 87675 PR 87636 PR 87350 PR 87335 libiberty * cp-demangle.h (struct d_info): Add recursion_level field. * cp-demangle.c (d_function_type): Add recursion counter. If the recursion limit is reached and the check is not disabled, then return with a failure result. (cplus_demangle_init_info): Initialise the recursion_level field. (d_demangle_callback): If the recursion limit is enabled, check for a mangled string that is so long that there is not enough stack space for the local arrays. * cplus-dem.c (struct work): Add recursion_level field. (squangle_mop_up): Set the numb and numk fields to zero. (work_stuff_copy_to_from): Handle the case where a btypevec or ktypevec field is NULL. (demangle_nested_args): Add recursion counter. If the recursion limit is not disabled and reached, return with a failure result. Modified: trunk/include/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/cp-demangle.h trunk/libiberty/cplus-dem.c
[Bug c++/87350] NULL-Pointer problem in cplus-dem.c when executing program c++filt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87350 --- Comment #7 from Nick Clifton --- Author: nickc Date: Fri Dec 7 10:33:30 2018 New Revision: 266886 URL: https://gcc.gnu.org/viewcvs?rev=266886=gcc=rev Log: Add a recursion limit to libiberty's demangling code. The limit is enabled by default, but can be disabled via a new demangling option. include * demangle.h (DMGL_NO_RECURSE_LIMIT): Define. (DEMANGLE_RECURSION_LIMIT): Define PR 87681 PR 87675 PR 87636 PR 87350 PR 87335 libiberty * cp-demangle.h (struct d_info): Add recursion_level field. * cp-demangle.c (d_function_type): Add recursion counter. If the recursion limit is reached and the check is not disabled, then return with a failure result. (cplus_demangle_init_info): Initialise the recursion_level field. (d_demangle_callback): If the recursion limit is enabled, check for a mangled string that is so long that there is not enough stack space for the local arrays. * cplus-dem.c (struct work): Add recursion_level field. (squangle_mop_up): Set the numb and numk fields to zero. (work_stuff_copy_to_from): Handle the case where a btypevec or ktypevec field is NULL. (demangle_nested_args): Add recursion counter. If the recursion limit is not disabled and reached, return with a failure result. Modified: trunk/include/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/cp-demangle.h trunk/libiberty/cplus-dem.c
[Bug rtl-optimization/70681] [7/8/9 Regression] FAIL: gcc.dg/ira-shrinkwrap-prep-2.c gcc.dg/pr10474.c on arm and powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70681 --- Comment #10 from Nick Clifton --- (In reply to Martin Liška from comment #9) > Nick: Any update on this PR? Gosh no. I must admit that I had totally forgotten about this PR. I am not sure what state it is in now. I doubt if it is important for gcc-7 anymore, and I have no idea how relevant it is to gcc-8 or -9. Probably the easiest thing to do would be to close it and let it be reopened if anyone cares enough to do so.
[Bug c/84195] newlines in deprecated diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84195 Nick Clifton changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Nick Clifton --- (In reply to Martin) > Can the bug be marked as resolved? Yup - closing.
[Bug middle-end/31377] wrap_help error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31377 --- Comment #3 from Nick Clifton --- Hi George, (In reply to George Ellery from comment #0) > room = columns - 3 - MAX (col_width, item_width); > if (room > columns) > room = columns - 3 - MAX (col_width, item_width); > if (room < 0) Doh! Yes this was my mistake. I do not have approval rights to this code, but personally I would consider your fix as "obvious" and so hope that it can be committed without much fuss. Cheers Nick
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86813, which changed state. Bug 86813 Summary: xstormy16 port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86813 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/86813] xstormy16 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86813 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- I have defined TARGET_HAVE_SPECULATION_SAFE_VALUE as speculation_safe_value_not_needed.
[Bug target/86813] xstormy16 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86813 --- Comment #1 from Nick Clifton --- Author: nickc Date: Thu Aug 2 16:13:32 2018 New Revision: 263266 URL: https://gcc.gnu.org/viewcvs?rev=263266=gcc=rev Log: PR target/86813 * config/stormy16/stormy16.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/stormy16/stormy16.c
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86810, which changed state. Bug 86810 Summary: v850 port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86810 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/86810] v850 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86810 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- I have defined TARGET_HAVE_SPECULATION_SAFE_VALUE as speculation_safe_value_not_needed.
[Bug target/86810] v850 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86810 --- Comment #1 from Nick Clifton --- Author: nickc Date: Thu Aug 2 15:57:06 2018 New Revision: 263264 URL: https://gcc.gnu.org/viewcvs?rev=263264=gcc=rev Log: PR target/86810 * config/v850/v850.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/v850/v850.c
[Bug target/86803] rx port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86803 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- I have defined TARGET_HAVE_SPECULATION_SAFE_VALUE as speculation_safe_value_not_needed.
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86803, which changed state. Bug 86803 Summary: rx port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86803 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/86803] rx port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86803 --- Comment #1 from Nick Clifton --- Author: nickc Date: Thu Aug 2 14:35:10 2018 New Revision: 263263 URL: https://gcc.gnu.org/viewcvs?rev=263263=gcc=rev Log: PR target/86803 * config/rx/rx.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rx/rx.c
[Bug target/86797] msp430 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86797 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- I have defined TARGET_HAVE_SPECULATION_SAFE_VALUE as speculation_safe_value_not_needed.
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86797, which changed state. Bug 86797 Summary: msp430 port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86797 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/86797] msp430 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86797 --- Comment #1 from Nick Clifton --- Author: nickc Date: Thu Aug 2 14:02:32 2018 New Revision: 263259 URL: https://gcc.gnu.org/viewcvs?rev=263259=gcc=rev Log: PR target/86797 * config/msp430/msp430.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/msp430/msp430.c
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86791, which changed state. Bug 86791 Summary: mcore port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86791 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/86791] mcore port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86791 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- I have defined TARGET_HAVE_SPECULATION_SAFE_VALUE as speculation_safe_value_not_needed.
[Bug target/86791] mcore port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86791 --- Comment #1 from Nick Clifton --- Author: nickc Date: Thu Aug 2 13:30:40 2018 New Revision: 263258 URL: https://gcc.gnu.org/viewcvs?rev=263258=gcc=rev Log: PR target/86791 * config/mcore/mcore.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mcore/mcore.c
[Bug target/86789] m32r port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86789 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- I have defined TARGET_HAVE_SPECULATION_SAFE_VALUE as speculation_safe_value_not_needed.
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86789, which changed state. Bug 86789 Summary: m32r port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86789 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/86789] m32r port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86789 --- Comment #1 from Nick Clifton --- Author: nickc Date: Thu Aug 2 12:31:29 2018 New Revision: 263256 URL: https://gcc.gnu.org/viewcvs?rev=263256=gcc=rev Log: PR target/86789 * config/m32r/m32r.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/m32r/m32r.c
[Bug target/86787] iq2000 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86787 --- Comment #2 from Nick Clifton --- Author: nickc Date: Thu Aug 2 12:14:52 2018 New Revision: 263255 URL: https://gcc.gnu.org/viewcvs?rev=263255=gcc=rev Log: PR target/86787 * config/iq2000/iq2000.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/iq2000/iq2000.c
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86782, which changed state. Bug 86782 Summary: frv port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86782 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/86782] frv port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86782 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- I have defined TARGET_HAVE_SPECULATION_SAFE_VALUE speculation_safe_value_not_needed
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86787, which changed state. Bug 86787 Summary: iq2000 port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86787 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/86787] iq2000 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86787 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Nick Clifton --- I have defined TARGET_HAVE_SPECULATION_SAFE_VALUE as speculation_safe_value_not_needed
[Bug target/86782] frv port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86782 --- Comment #1 from Nick Clifton --- Author: nickc Date: Thu Aug 2 11:46:06 2018 New Revision: 263254 URL: https://gcc.gnu.org/viewcvs?rev=263254=gcc=rev Log: PR target/86782 * config/frv/frv.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/frv/frv.c
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86781, which changed state. Bug 86781 Summary: fr30 port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86781 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug target/86781] fr30 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86781 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Nick Clifton --- I have defined TARGET_HAVE_SPECULATION_SAFE_VALUE as speculation_safe_value_not_needed.
[Bug target/86781] fr30 port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86781 --- Comment #1 from Nick Clifton --- Author: nickc Date: Thu Aug 2 11:24:47 2018 New Revision: 263253 URL: https://gcc.gnu.org/viewcvs?rev=263253=gcc=rev Log: PR target/86781 * config/fr30/fr30.c (TARGET_HAVE_SPECULATION_SAFE_VALUE): Define to speculation_safe_value_not_needed. Modified: trunk/gcc/ChangeLog trunk/gcc/config/fr30/fr30.c
[Bug testsuite/86170] New test case gcc.c-torture/compile/pr84195.c added in r261633 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86170 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Nick Clifton --- Hi Guys, Well this was interesting. The test was in fact performing perfectly. It was testing for control characters in user warning messages and failing because gcc was failing to convert them into escape sequences. The real problem was that for some reason my patch to actually fix PR 84195 had not been applied to the tree. I am not sure why it had not gone in, but reapplied it and committed the change, so everything should be working now. Cheers Nick
[Bug c/84195] newlines in deprecated diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84195 --- Comment #7 from Nick Clifton --- Author: nickc Date: Mon Jun 18 10:39:01 2018 New Revision: 261697 URL: https://gcc.gnu.org/viewcvs?rev=261697=gcc=rev Log: Ensure that control characters in user supplied error and warning messages are escaped. PR 84195 * tree.c (escaped_string): New class. Converts an unescaped string into its escaped equivalent. (warn_deprecated_use): Use the new class to convert the deprecation message, if present. (test_escaped_strings): New self test. (test_c_tests): Add test_escaped_strings. Modified: trunk/gcc/ChangeLog trunk/gcc/tree.c
[Bug c/84195] newlines in deprecated diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84195 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from Nick Clifton --- A revised form of the patch has now been apoplied.
[Bug c/84195] newlines in deprecated diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84195 --- Comment #4 from Nick Clifton --- Author: nickc Date: Fri Jun 15 15:25:16 2018 New Revision: 261633 URL: https://gcc.gnu.org/viewcvs?rev=261633=gcc=rev Log: Force user provided warning and error messages to only occupy one line. PR 84195 gcc:* tree.c (escaped_string): New class. Converts an unescaped string into its escaped equivalent. (warn_deprecated_use): Use the new class to convert the deprecation message, if present. (test_escaped_strings): New self test. (test_c_tests): Add test_escaped_strings. * doc/extend.texi (deprecated): Add a note that the deprecation message is affected by the -fmessage-length option, and that control characters will be escaped. (#pragma GCC error): Document this pragma. (#pragma GCC warning): Likewise. * doc/invoke.texi (-fmessage-length): Document this option's effect on the #warning and #error preprocessor directives and the deprecated attribute. testsuite; * gcc.c-torture/compile/pr84195.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr84195.c Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog
[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847 --- Comment #16 from Nick Clifton --- Hi H.J. (In reply to H.J. Lu from comment #15) > It should be fixed in linker. OK - so how does the linker distinguish between a file that only contains debug information, none of which is needed, and a file that only contains debug information of which some/all actually is needed ? Cheers Nick
[Bug lto/84847] [8 Regression] Incompatibility between early LTO debug and "-Wl,--gc-sections" leads to corrupt DWARF debuginfo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84847 --- Comment #14 from Nick Clifton --- Created attachment 43643 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43643=edit Proposed patch Hi Guys. Here is a possible patch, although it is a bit hackish. Richard might not like it because it changes gcc/lto-wrapper.c rather than the linker, but I honestly think that the linker is doing the right thing in this case. Cheers Nick
[Bug target/84145] Wrong CET options processing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84145 Nick Clifton changed: What|Removed |Added CC||nickc at gcc dot gnu.org --- Comment #1 from Nick Clifton --- I have proposed a small patch to rework the error checking: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00179.html
[Bug target/68028] [6/7/8 regression] Compilation error "lto1: error: target attribute or pragma changes single precision floating point" with LTO on PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68028
Nick Clifton changed:
What|Removed |Added
CC||nickc at gcc dot gnu.org
--- Comment #9 from Nick Clifton ---
Created attachment 43318
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43318=edit
Proposed patch
Hi Guys,
Richard was right - there is code that sets extra flags based upon the setting
of -mcpu. In fact it is just before the code he mentioned:
/* For the E500 family of cores, reset the single/double FP flags to let us
check that they remain constant across attributes or pragmas. */
switch (rs6000_cpu)
{
case PROCESSOR_PPC8540:
case PROCESSOR_PPC8548:
case PROCESSOR_PPCE500MC:
case PROCESSOR_PPCE500MC64:
case PROCESSOR_PPCE5500:
case PROCESSOR_PPCE6500:
rs6000_single_float = 0;
rs6000_double_float = 0;
break;
default:
break;
}
This has lead me to propose the attached patch. Basically what it does is to
tell the rs6000 backend that when it is operating in LTO mode, it should trust
the function attributes and not the command line.
My assumption here is that if there are any discrepancies between real
function attributes (ie not ones generated for LTO) and the command line,
then these will have been detected and reported during the original
compilation.
What do people think ? Is the patch OK ?
Cheers
Nick
[Bug tree-optimization/82518] [8 regression] gfortran.fortran-torture/execute/in-pack.f90 fails on armeb since r252917
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82518 --- Comment #8 from Nick Clifton --- Hi Aldy, > Do we have a way of testing armeb, either through a simulator or through > some aarch64 with magic flags? GDB has an ARM simulator which is OK unless you need to test some of the newer features like scalable vector instructions. Just compile your code as normal and then build an armeb targeted version of gdb. Cheers Nick
[Bug target/80993] [msp430] __attribute__((interrupt)) should imply __attribute__((used))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80993 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Nick Clifton --- Patch applied.
[Bug target/80993] [msp430] __attribute__((interrupt)) should imply __attribute__((used))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80993 --- Comment #2 from Nick Clifton --- Author: nickc Date: Tue Aug 29 13:20:54 2017 New Revision: 251410 URL: https://gcc.gnu.org/viewcvs?rev=251410=gcc=rev Log: PR target/80993 * gcc/config/msp430/msp430.c (msp430_attr): Mark interrupt handlers as used. Added: trunk/gcc/testsuite/gcc.target/msp430/pr80993.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/msp430/msp430.c
[Bug target/78818] msp430 persistent attribute is not applied correctly in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78818 --- Comment #2 from Nick Clifton --- Author: nickc Date: Thu Jun 15 13:38:52 2017 New Revision: 249222 URL: https://gcc.gnu.org/viewcvs?rev=249222=gcc=rev Log: Fix problems with the MSP430 port's handling of persistent data. PR target/78818 gcc * config/msp430/msp430.c (msp430_data_attr): Check that it's possible for a variable to have a section before checking if the section has a name. Set section to.persistent if persistent attribute is set. Warn if .persistent attribute is used on an automatic variable. tests * gcc.target/msp430/pr78818-real.c: New template for tests. * gcc.target/msp430/pr78818-auto.c: New test. * gcc.target/msp430/pr78818-data-region.c: New test. * gcc.target/msp430/pr78818-data-sec.c: New test. * gcc.target/msp430/pr78818-auto-warn.c: New test. Added: trunk/gcc/testsuite/gcc.target/msp430/pr78818-auto-warn.c trunk/gcc/testsuite/gcc.target/msp430/pr78818-auto.c trunk/gcc/testsuite/gcc.target/msp430/pr78818-data-region.c trunk/gcc/testsuite/gcc.target/msp430/pr78818-data-sec.c trunk/gcc/testsuite/gcc.target/msp430/pr78818-real.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/msp430/msp430.c trunk/gcc/testsuite/ChangeLog
[Bug target/78838] msp430 option -mcode-region=either, -ffunction-sections, and interrupt function attributes cause incorrect section to be created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78838 --- Comment #3 from Nick Clifton --- Author: nickc Date: Tue May 30 10:49:29 2017 New Revision: 248674 URL: https://gcc.gnu.org/viewcvs?rev=248674=gcc=rev Log: PR target/78838 gcc * config/msp430/msp430.c (gen_prefix): Return NULL when section name is .lowtext. (has_section_name): New function. testsuite * gcc.target/msp430/interrupt_fn_placement.c: New test. Added: trunk/gcc/testsuite/gcc.target/msp430/interrupt_fn_placement.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/msp430/msp430.c trunk/gcc/testsuite/ChangeLog
[Bug target/69880] Linking Windows resource + implicit 'default-manifest.o' creates bad .exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69880 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Nick Clifton --- Excellent - in which case I will close this PR.
[Bug target/69880] Linking Windows resource + implicit 'default-manifest.o' creates bad .exe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69880 --- Comment #17 from Nick Clifton --- Hi Guys, (In reply to Eduard Braun from comment #15) > > Setting status to resolved/fixed. > > I don't think this is merged yet! > There's only a patch MINGW-packages, if this works out it should be fixed > upstream! I was waiting for confirmation that the patch worked before applying it. In the meantime however a linker bug report was filed which I think was effectively covering the same problem: https://sourceware.org/bugzilla/show_bug.cgi?id=20193 That bug has been fixed by a patch, and I think that that patch might also fix the problem reported here. Please could somebody check and let me know ? Cheers Nick
[Bug rtl-optimization/77770] [5/6/7 Regression] Internal compiler error on source which compiles with earlier versions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Nick Clifton changed: What|Removed |Added Status|NEW |ASSIGNED CC||nickc at gcc dot gnu.org --- Comment #6 from Nick Clifton --- Potential patch posted: https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01949.html
