https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #23 from Mark Wielaard ---
Created attachment 40231
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40231&action=edit
Check output with d_printing.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #25 from Mark Wielaard ---
(In reply to Markus Trippelsdorf from comment #24)
> (In reply to Mark Wielaard from comment #22)
> > Created attachment 40230 [details]
> > d_printing mark/walk/unmark protection
> >
> > (In reply to Natha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
Mark Wielaard changed:
What|Removed |Added
Attachment #40230|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #32 from Mark Wielaard ---
(In reply to Nathan Sidwell from comment #27)
> I think the symbols containing 'Ul' should demangle -- they're lambdas and
> I'd expect my patch to fix those.
I applied your patch first and two more demangl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #34 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #26)
> Created attachment 40233 [details]
> d_print_comp with 1 level of recursion protection
>
> This is the variant that allows 1 level of recursion (with an xxx ??
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #35 from Mark Wielaard ---
(In reply to Marcel Böhme from comment #31)
> Hi Mark,
>
> Your patch looks good to me. One more thing: It seems that our patches
> evaluate these two mangled strings differently. Is it because of Nathan's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #36 from Mark Wielaard ---
(In reply to Markus Trippelsdorf from comment #33)
> (In reply to Mark Wielaard from comment #32)
> > - PR70517
> > _ZSt4moveIRZN11tconcurrent6futureIvE4thenIZ5awaitIS2_EDaOT_EUlRKS6_E_EENS1_IN
> > St5decayI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78252
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70517
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
Depends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68700
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
Depends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62279
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61805
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68383
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
Depends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67264
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
Depends
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #38 from Mark Wielaard ---
For reference the symbols in comment #4 and the reduced case from comment #14
are fixed by the patch proposed for Bug 78252 - C++ demangler crashes with
infinite recursion with lambda (auto).
The patch prop
||mark at gcc dot gnu.org
Resolution|DUPLICATE |---
--- Comment #4 from Mark Wielaard ---
The patch proposed form bug 70909 does prevent the infinite recursion, but that
doesn't help demangling the symbol. See the comments in bug #70909 which
sugges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61460
--- Comment #3 from Mark Wielaard ---
The patch proposed in bug #70909 does prevent the infinite recursiong crashing
the demangler. But it doesn't demangle the symbol (just rejects it).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
Mark Wielaard changed:
What|Removed |Added
Attachment #40233|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #42 from Mark Wielaard ---
(In reply to Markus Trippelsdorf from comment #41)
> (In reply to Mark Wielaard from comment #40)
> > But I still haven't figured out why we need to allow 2 levels of recursion
> > for some of the cases. See
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
gcc (GCC) 7.0.1 20170209 (experimental)
$ cat t.c
#include
char *
gettext (char *__msgid)
{
return __msgid;
}
char *
fill (char *buf, size_t len, int count)
{
if (snprintf (buf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79448
--- Comment #3 from Mark Wielaard ---
A "workaround" for the example given in the description is to just pick some
arbitrary number you know wouldn't get exceeded. e.g:
/* To help -Wformat-truncation=2 pretend the "count"
translation will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79448
--- Comment #5 from Mark Wielaard ---
(In reply to Martin Sebor from comment #4)
> Ouch. When its size argument is zero, a snprintf call is a request to
> compute the size of output without actually writing any into the destination
> (which may
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #43 from Mark Wielaard ---
See also this discussion on gcc-patches:
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00089.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #49 from Mark Wielaard ---
(In reply to Pedro Alves from comment #48)
> GDB is released separately from binutils though, and GDB 8.0 is going to
> branch very soon. IWBN to have this in the binutils-gdb repo by then.
Trying to integ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #50 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #49)
> (In reply to Pedro Alves from comment #48)
> > GDB is released separately from binutils though, and GDB 8.0 is going to
> > branch very soon. IWBN to have this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #51 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #50)
> (In reply to Mark Wielaard from comment #49)
> > (In reply to Pedro Alves from comment #48)
> > > GDB is released separately from binutils though, and GDB 8.0 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78497
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78497
--- Comment #7 from Mark Wielaard ---
The workaround is to use gcc -C --save-temps ... to pass-through all comments
to the temp files. Maybe -C should be the default with --save-temps?
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
Created attachment 42470
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42470&action=edit
reduced code example from elfutils libelf/elf_begin.c
Given the attached e.c build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82718
--- Comment #1 from Mark Wielaard ---
Created attachment 42471
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42471&action=edit
preprocessed e.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82718
--- Comment #2 from Mark Wielaard ---
Created attachment 42472
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42472&action=edit
generated assembler e.s
assembler produced with gcc (GCC) 8.0.0 20171024 (experimental)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82718
--- Comment #5 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 42474 [details]
> gcc8-pr82718.patch
>
> Untested fix.
Works for me. elfutils builds with this patch and gcc -O2 -gdwarf-5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82718
--- Comment #6 from Mark Wielaard ---
Building elfutils with -g -O2 -gdwarf-5 still fails without this patch with
current gcc trunk (just in a different file libdwfl/realloc.c instead of
elf_begin.c as reported originally). Using the proposed pat
IRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
For this program:
#include
#include
int
main (int argc, char **argv)
{
size_t size = argc;
printf ("size:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61460
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #9 from Mark Wielaard ---
(In reply to Markus Trippelsdorf from comment #8)
> This is what it should look like: [...]
How did you demangle that input string?
With the proposed patch the mangled string is rejected by the libiberty
dem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #11 from Mark Wielaard ---
(In reply to Markus Trippelsdorf from comment #10)
> The symbol was demangled with libcxxabi's demangler.
> The other two demanglers reject it.
Thanks. Do you know which demangler is correct for this input
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16063
--- Comment #6 from Mark Wielaard ---
Posted a patch:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01198.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54774
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28767
--- Comment #5 from Mark Wielaard ---
Some discussion of the patch in comment #4 can be found here:
http://gcc.gnu.org/ml/gcc-patches/2011-05/threads.html#00225
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38757
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38757
--- Comment #5 from Mark Wielaard ---
Patch has been discussed on the patches list a couple of times in the past, but
not yet applied:
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00858.html
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00991.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60885
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60885
--- Comment #2 from Mark Wielaard ---
I think this is caused by the following in add_type_attribute:
if (code == ERROR_MARK
/* Handle a special case. For functions whose return type is void, we
generate *no* type attribute. (No
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60833
--- Comment #1 from Mark Wielaard ---
Confirmed with GNU C++ 4.10.0 20140417 (experimental). GCC doesn't emit the
typedef for tbase because it is unused. It will emit the typedef for tbase when
it is used for a variable like tbase y. But even then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16063
--- Comment #7 from Mark Wielaard ---
Author: mark
Date: Wed May 21 15:44:59 2014
New Revision: 210717
URL: http://gcc.gnu.org/viewcvs?rev=210717&root=gcc&view=rev
Log:
PR debug/16063. Add DW_AT_type to DW_TAG_enumeration.
Add a new lang-hook t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38757
--- Comment #6 from Mark Wielaard ---
Current 4.9 rebased version of the patch is here:
http://pkgs.fedoraproject.org/cgit/gcc.git/tree/gcc49-pr38757.patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59051
Mark Wielaard changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60782
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56974
--- Comment #3 from Mark Wielaard ---
There is DWARFv5 proposal for this now:
http://dwarfstd.org/ShowIssue.php?issue=131105.1
This adds DW_AT_reference[_qualifier] and DW_AT_rvalue_reference[_qualifier] as
attributes to DW_TAG_subprogram or DW_T
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56563
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56563
--- Comment #2 from Mark Wielaard ---
Jakub proposed a patch:
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg01166.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56563
Mark Wielaard changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43053
--- Comment #1 from Mark Wielaard ---
Same inconsistency with current g++ (GCC) 4.9.0 20140219 (experimental)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57369
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56740
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641
--- Comment #6 from Mark Wielaard ---
Note that if we add:
const foo g(x);
It comes out with just one const_type added:
[60]variable
name (string) "g"
decl_file(data1) 1
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
Currently to get pedantic format warning, like for the usage of deprecated old
'Z', 'q', etc gnu_printf modifiers, you need to give both -Wpedantic and
-Wformat. But this ena
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17308
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #8 from Mark Wielaard ---
Submitted a patch:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00847.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #9 from Mark Wielaard ---
Author: mark
Date: Mon Sep 14 09:49:47 2015
New Revision: 227742
URL: https://gcc.gnu.org/viewcvs?rev=227742&root=gcc&view=rev
Log:
PR28901 -Wunused-variable ignores unused const initialised variables in C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65040
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239
--- Comment #6 from Mark Wielaard ---
It looks like for some reason Darwin defaults to some ancient (v2) strict
version of DWARF. Please try adding -gno-strict-dwarf -gdwarf-4 to
gcc/testsuite/g++.dg/debug/dwarf2/deleted-member-function.C dg-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38757
--- Comment #7 from Mark Wielaard ---
Author: mark
Date: Fri Nov 21 16:00:06 2014
New Revision: 217934
URL: https://gcc.gnu.org/viewcvs?rev=217934&root=gcc&view=rev
Log:
PR debug/38757 gcc does not emit DW_LANG_C99.
For C and C++ add the langua
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38757
--- Comment #8 from Mark Wielaard ---
Author: mark
Date: Wed Nov 26 11:05:20 2014
New Revision: 218077
URL: https://gcc.gnu.org/viewcvs?rev=218077&root=gcc&view=rev
Log:
PR debug/38757 continued. Handle C11, C++11 and C++14.
Add experimental (m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38757
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60782
--- Comment #3 from Mark Wielaard ---
Author: mark
Date: Mon Dec 8 22:32:23 2014
New Revision: 218496
URL: https://gcc.gnu.org/viewcvs?rev=218496&root=gcc&view=rev
Log:
DWARFv5 Emit DW_TAG_atomic_type for C11 _Atomic.
This implements the DW_TA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59051
--- Comment #2 from Mark Wielaard ---
Author: mark
Date: Tue Aug 19 11:50:55 2014
New Revision: 214143
URL: https://gcc.gnu.org/viewcvs?rev=214143&root=gcc&view=rev
Log:
Emit DW_tag_restrict_type for restrict-qualified pointers.
gcc/ChangeLog
: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Take the following program:
/* LTO sometimes outputs __unknown__ for an unsigned int argument type. */
/* { dg-do run } */
/* { dg-options "-g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16063
Mark Wielaard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63300
--- Comment #2 from Mark Wielaard ---
Sorry about that. I added an explicit testcases
(gcc/testsuite/gcc.dg/guality/const-volatile.c and
gcc/testsuite/gcc.dg/guality/restrict.c) explicitly to catch such issue. But
apparently they didn't trigger t
at gcc dot gnu.org |mark at gcc dot gnu.org
--- Comment #3 from Mark Wielaard ---
Proposed fix: https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01723.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239
--- Comment #2 from Mark Wielaard ---
Author: mark
Date: Sun Oct 5 15:25:03 2014
New Revision: 215901
URL: https://gcc.gnu.org/viewcvs?rev=215901&root=gcc&view=rev
Log:
PR debug/63239 Add DWARF representation for C++11 deleted member function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63243
Bug 63243 depends on bug 63239, which changed state.
Bug 63239 Summary: DWARF does not represent C++ deleted methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63239
Mark Wielaard changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #15 from Mark Wielaard ---
(In reply to Andi Kleen from comment #14)
> I'm building a current Linux kernel with allyesconfig, and this new warning
> causes
> 1383(!) new warnings in the build.
>
> I think this should be revisited and
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
$ gcc --version
gcc (GCC) 6.0.0 20160123 (experimental)
svn co svn://svn.valgrind.org/valgrind/trunk valgrind
cd valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68986
--- Comment #5 from Mark Wielaard ---
Thanks for finding the duplicate and creating a small reproducer. This is
indeed a GCC 6 regression. valgrind builds fine with gcc (GCC) 5.3.1 20151207
(Red Hat 5.3.1-2) but fails with gcc (GCC) 6.0.0 2016012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #21 from Mark Wielaard ---
Sorry, I forgot about this bug still being open.
It isn't clear to me whether the issues seen in the kernel sources are
a) just legitimate and should be fixed
(like comment #16 seem to imply)
b) thousand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47866
Mark Wielaard changed:
What|Removed |Added
CC|mark at gcc dot gnu.org |mark at codesourcery dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48041
Summary: dwarf2out emits unnecessary null byte in empty
.debug_abbrev section
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48045
Summary: dwarf2out emits CU with DW_AT_stmt_list to empty line
table
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48045
--- Comment #1 from Mark Wielaard 2011-03-09 23:04:09
UTC ---
The previous patch is wrong, it should depend on either a .loc or a .line
output. I had misunderstood when the DW_AT_stmt_list was really necessary. Also
there was some debate on wheth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48041
--- Comment #1 from Mark Wielaard 2011-03-25 09:35:44
UTC ---
Author: mark
Date: Fri Mar 25 09:35:41 2011
New Revision: 171441
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171441
Log:
PR debug/48041
* dwarf2out.c (output_abbrev_section)
||FIXED
AssignedTo|unassigned at gcc dot |mark at gcc dot gnu.org
|gnu.org |
--- Comment #2 from Mark Wielaard 2011-03-28 09:10:09
UTC ---
Patch committed.
||mark at gcc dot gnu.org
--- Comment #7 from Mark Wielaard 2011-04-21 15:33:09
UTC ---
We discussed this a bit on the elfutils list WRT the dwarflint checks we have.
And the consensus seems to be that it is more convenient to actually have an
.aranges entry for each CU.
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63238
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98875
Mark Wielaard changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99490
--- Comment #5 from Mark Wielaard ---
I don't believe it is a requirement to generate a separate .debug_rnglists.dwo
section, the spec says the same data can be provided in the .debug_rnglists
section and gdb and elfutils handle that just fine fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488
--- Comment #3 from Mark Wielaard ---
So gcc/dwarf2out.c creates it as:
#define DEBUG_STR_SECTION_FLAGS \
(HAVE_GAS_SHF_MERGE && flag_merge_debug_strings \
? SECTION_DEBUG | SECTION_MERGE | SECT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99488
--- Comment #8 from Mark Wielaard ---
On Mon, 2021-03-15 at 12:21 +, jakub at gcc dot gnu.org wrote:
> --- Comment #7 from Jakub Jelinek ---
> [43] .debug_line_str MIPS_DWARF ecf07bf 0066e6 01
> MS
> 0 0 1
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92442
Mark Wielaard changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355
--- Comment #11 from Mark Wielaard ---
I don't understand why the .debug sections are compared in this case.
But if they are then the diff comes from this gas issue:
https://sourceware.org/bugzilla/show_bug.cgi?id=26740
Even though unused gas -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97355
--- Comment #15 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #14)
> In any case, the change to use -gdwarf-* by default even when not compiling
> just assembly was based on the assumption that gas would in that case pretty
> muc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97541
--- Comment #5 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #4)
> # 82 "s-atocou.adb" 1
> isn't a .file assignment though.
> As I said earlier, if we don't want to revert the r11-3693 change and be
> able to specify -gdwarf-5 et
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188
--- Comment #4 from Mark Wielaard ---
Note that I can replicate it with the instructions in the description and gcc
git: gcc (GCC) 11.0.0 20200916 (experimental)
$ /opt/local/install/gcc/bin/gcc -g -O2 -fanalyzer -c bzip2.c 2>&1 | head -25
bzip2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188
--- Comment #6 from Mark Wielaard ---
Created attachment 49291
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49291&action=edit
Output for gcc -Wanalyzer-too-complex -g -O2 -fanalyzer -c bzip2.c
(In reply to David Malcolm from comment #5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95188
--- Comment #10 from Mark Wielaard ---
Created attachment 49293
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49293&action=edit
supergraph
> Mark: please can you add -fdump-analyzer-supergraph to the arguments and
> attach > the bzip2.c.
101 - 200 of 303 matches
Mail list logo
