https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #3 from Mark Wielaard ---
(In reply to Richard Biener from comment #1)
> Err, but isn't this interpreting the dwarf from 'date'? So doesn't this
> mean that valgrind is "miscompiled" with --enable-lto rather than wrong
> debug?
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200
--- Comment #43 from Mark Wielaard ---
It looks there is now some support for a symver function attribute. But it only
accepts the single and double @ forms. This makes things a little awkward when
using a symbol foo itself for foo@@DEFAULT_VERSI
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
$ gcc --version
gcc (GCC) 10.0.1 20200430 (Red Hat 10.0.1-0.13)
This is the build of elfutils libelf with both -flto and -fanalyzer.
The
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
Reproducer:
wget https://sourceware.org/ftp/bzip2/bzip2-1.0.8.tar.gz
tar zxf bzip2-1.0.8.tar.gz
cd bzip2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54734
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58528
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #10
||mark at gcc dot gnu.org
Blocks||47819
Last reconfirmed||2020-07-16
Status|UNCONFIRMED |NEW
--- Comment #1 from Mark Wielaard ---
Replicated. With -flto added the result is a linker error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86412
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47785
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #18
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78871
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
Mark Wielaard changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Mark Wielaard -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47819
--- Comment #4 from Mark Wielaard ---
The following bugs might be added to this meta-bug. But they seemed not very
urgent because they involve non-default -g/-f debug flags:
- -flto -g -gsplit-dwarf is broken
https://gcc.gnu.org/bugzilla/show_bu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47819
Mark Wielaard changed:
What|Removed |Added
Depends on||88389, 88878, 93117, 91794,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93865
--- Comment #2 from Mark Wielaard ---
This also impacts rpm (find-debuginfo.sh) when it tries to extract the source
files from binaries compiled with LTO enabled:
https://github.com/rpm-software-management/rpm/issues/1207
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611
--- Comment #6 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #5)
> This is also one of the issues that prevent elfutils to build with LTO.
> The workaround is to compile with -Wno-error=stack-usage= added to CFLAGS:
> https://sou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70611
--- Comment #7 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #6)
> Sorry, commented on the wrong bug, the above was meant for bug #93865
Groan, I seem very confused today. That comment was fine. It was me who got
confused becaus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96328
Mark Wielaard changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from Mark Wielaa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96328
--- Comment #4 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #3)
> Created attachment 48930 [details]
> gcc11-pr96328.patch
>
> I wrote this for it (the first hunk is similar).
Yours is nicer because it fixes just the specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96328
--- Comment #6 from Mark Wielaard ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 48931 [details]
> gcc11-pr96328-alt.patch
>
> If you want, we could call the safe_previous_token also in the other spot,
> while we don't have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96407
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #6 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #5)
> I can no longer replicate the issue of the bad line numbers with gcc (GCC)
> 10.1.1 20200507 (Red Hat 10.1.1-1) on fedora 32. With either 3.15.0 or
> current valg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #7 from Mark Wielaard ---
Note that the above is in ./install/lib/valgrind/memcheck-amd64-linux
Which has .debug_line entries like:
[0x00098404] Set is_stmt to 0
[0x00098405] Advance PC by constant 17 to 0x5809993c
[0x000984
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94311
--- Comment #8 from Mark Wielaard ---
Note that VEX/priv/guest_arm64_toIR.c is fairly big (1.2M):
$ wc VEX/priv/guest_amd64_toIR.c
32655 127564 1189783 VEX/priv/guest_amd64_toIR.c
(but still less than 2^15 lines)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70517
--- Comment #6 from Mark Wielaard ---
(In reply to Christian Biesinger from comment #5)
> Using binutils from a month ago or so, this does not crash but also does not
> demangle...
Could you be slightly more specific?
Which symbol produced by wh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93608
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93608
--- Comment #3 from Mark Wielaard ---
(In reply to Ian Lance Taylor from comment #2)
> It looks like this would mean that libbacktrace needs an lzma decompressor.
> This is probably doable but is probably non-trivial. At least it doesn't
> look
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358
--- Comment #6 from Mark Wielaard 2012-08-12 20:30:36
UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > It would not be helpful, systemtap would then see no data [...]
>
> Not quite; systemtap can search the PC ranges/line tables f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53671
--- Comment #13 from Mark Wielaard 2012-08-22
11:10:21 UTC ---
[PATCH] gdb: dwarf2read.c handle DW_AT_high_pc constant form for DWARF 4+.
http://sourceware.org/ml/gdb-patches/2012-04/msg00982.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637
--- Comment #8 from Mark Wielaard ---
What happens when you run it by hand?
$ gij -cp ./libjava/testsuite/libjava.lang/sourcelocation.jar sourcelocation
10
13
15
-1 indicates "something went wrong", which is indeed not very helpful.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637
--- Comment #9 from Mark Wielaard ---
I assume this is some weirdness in the testsuite. It does indeed fail for me in
a make check, but seems to work just fine when ran by hand.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637
--- Comment #10 from Mark Wielaard ---
O wait, it is more complicated than that. My "by hand" tests were using the
interpreter. But there are multiple sourcelocation tests:
PASS: sourcelocation compilation from source
PASS: sourcelocation executi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55637
--- Comment #11 from Mark Wielaard ---
It seems somewhat related to the binutils version.
The results form comment #10 are with binutils-2.20.51.0.2-5.36.el6.x86_64
If I build and put current binutils trunk on the path the results change (for
the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42288
Mark Wielaard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50888
Mark Wielaard changed:
What|Removed |Added
CC||green at gcc dot gnu.org
--- Comment #2 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50888
--- Comment #3 from Mark Wielaard 2011-10-27 23:14:02
UTC ---
I don't think isspace() is really needed. We can just check for ' '
and maybe tab.
wow - 1999 was a long time ago
||2012-05-01
CC||mark at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Mark Wielaard 2012-05-01 15:00:01
UTC ---
I think the DW_AT_entry_pc issue was resolved by:
commit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53400
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53400
Mark Wielaard changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54181
Bug #: 54181
Summary: partial DW_TAG_class_type generated with
DW_AT_byte_size and without DW_AT_declaration
Classification: Unclassified
Product: gcc
Version: 4.7.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48041
Mark Wielaard changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36266
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52935
--- Comment #1 from Mark Wielaard 2012-04-16 07:55:35
UTC ---
GNU C 4.6.3 20120306 (Red Hat 4.6.3-2) -mtune=generic -march=x86-64 -g
produces:
[1d]structure_type
name (string) "S"
byte_size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358
Bug #: 51358
Summary: missing location
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51410
Bug #: 51410
Summary: duplicate variable DIE
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51902
Bug #: 51902
Summary: lexical_blocks inside inlined_subroutines generate
duplicate debug_ranges
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51902
--- Comment #3 from Mark Wielaard 2012-01-20 13:31:04
UTC ---
(In reply to comment #2)
> Mark, can you please look at this if it does the right thing you want from it?
Yes, this seems to do what I was thinking of. And it works on my testcases.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51902
Mark Wielaard changed:
What|Removed |Added
Attachment #26380|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83157
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82718
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #7 from Mark Wielaard ---
Is this a regression that will probably be fixed for GCC 9.1 or should we be
adding workaround to the code.
Currently elfutils won't build on distros that started using the GCC 9.0
prerelease on 32bit archit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #9 from Mark Wielaard ---
(In reply to Martin Sebor from comment #8)
> The patch I posted for the related pr88993 also relaxes this warning for
> printf and fprintf: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00224.html
>
> Like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #12 from Mark Wielaard ---
(In reply to Martin Sebor from comment #11)
> Ah, but you mentioned elfutilts, not binutils. I've now downloaded and
> built elfutils-0.175. It took a bit more effort because --disable-werror
> doesn't wor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #14 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #12)
> (In reply to Martin Sebor from comment #11)
> > Ah, but you mentioned elfutilts, not binutils. I've now downloaded and
> > built elfutils-0.175. It took a bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88835
--- Comment #17 from Mark Wielaard ---
(In reply to Martin Sebor from comment #16)
> The warning has been relaxed for GCC 9 in r269125.
Thanks, I can confirm elfutils builds fine without warnings with GCC 9 now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #22 from Mark Wielaard ---
(In reply to Eric Gallager from comment #21)
> (In reply to Mark Wielaard from comment #20)
> > https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02055.html
>
> Did this make it in? If not, have you pinged it l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90981
--- Comment #3 from Mark Wielaard ---
(In reply to Martin Liška from comment #2)
> Btw. started with r259743.
Thanks. So that is mine:
commit ac7a2c61cf2ae7fcc948724ae179ac812c12186a
Author: mark
Date: Sat Apr 28 19:54:08 2018 +
DWA
at gcc dot gnu.org |mark at gcc dot gnu.org
--- Comment #4 from Mark Wielaard ---
Created attachment 46518
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46518&action=edit
Don't emit debug_addr attribute or addr index if there is no addr table.
Testing the following patc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90981
Mark Wielaard changed:
What|Removed |Added
Component|c++ |debug
--- Comment #5 from Mark Wielaard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90981
--- Comment #6 from Mark Wielaard ---
Author: mark
Date: Wed Jul 3 13:08:01 2019
New Revision: 273008
URL: https://gcc.gnu.org/viewcvs?rev=273008&root=gcc&view=rev
Log:
PR debug/90981 Empty .debug_addr crashes -gdwarf-5 -gsplit-dwarf
Even if t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86459
--- Comment #1 from Mark Wielaard ---
Sorry I missed that testcase starting to fail. I don't currently have it in my
tree, so I assume it was added after this commit?
svn r260297 is:
commit 35a499265a9b4b31277fc540ddfbeb63fb361649
Author: mark
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86459
Mark Wielaard changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86459
--- Comment #3 from Mark Wielaard ---
Author: mark
Date: Tue Jul 10 22:44:30 2018
New Revision: 262545
URL: https://gcc.gnu.org/viewcvs?rev=262545&root=gcc&view=rev
Log:
PR debug/86459 - Fix -gsplit-dwarf -g3 gcc_assert
There was a typo in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86459
Mark Wielaard changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59051
Mark Wielaard changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
CC: aoliva at gcc dot gnu.org
Target Milestone: ---
In some situations gcc will emit the view index in DWARF as a DW_FORM_addr (or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87472
--- Comment #2 from Mark Wielaard ---
(In reply to Richard Biener from comment #1)
> Confirmed with GCC 8 and just -g3 -gsplit-dwarf. readelf isn't very verbose
> of which macro section it complains about though...
>
> Mark?
With -gsplit-dwarf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87472
--- Comment #3 from Mark Wielaard ---
(In reply to Mark Wielaard from comment #2)
> (In reply to Richard Biener from comment #1)
> > Confirmed with GCC 8 and just -g3 -gsplit-dwarf. readelf isn't very verbose
> > of which macro section it compla
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mark at gcc dot gnu.org
Target Milestone: ---
Usage of nested functions is fine unless one takes the function address and a
trampoline is generated. The trampoline often requires an executable stack.
Which is regarded as
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
> ther
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #4 from Mark Wielaard ---
I think the point of the warning is to note that executable code is generated
on the stack (which seems to always be something to warn about IMHO).
But I am fine with only enabling -Wtrampolines with -Wall f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #9 from Mark Wielaard ---
(In reply to Segher Boessenkool from comment #5)
> The documentation currently says
>
> '-Wtrampolines'
> Warn about trampolines generated for pointers to nested functions.
> A trampoline is a smal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #11 from Mark Wielaard ---
(In reply to Segher Boessenkool from comment #10)
> As I said, very many targets have no concept of "executable" at all.
> Most of the *-elf targets, most (all?) of the *-aout targets.
>
> Not all of the wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #13 from Mark Wielaard ---
(In reply to Segher Boessenkool from comment #12)
> Requiring everything on the stack to always be executable, while normally it
> is
> not, is an issue, sure.
>
> Requiring the stack to be executable when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #15 from Mark Wielaard ---
(In reply to Segher Boessenkool from comment #14)
> It is very hard to avoid the warning if you use this feature (you need to
> stop using the feature altogether!), which would disqualify it for -Wall
> imme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #17 from Mark Wielaard ---
(In reply to Segher Boessenkool from comment #16)
> Something as trivial as this
>
> ===
> void h(int (*)(void));
> void f(int x)
> {
> int g(void) { return x; }
> h(g);
> }
> ===
>
> will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #19 from Mark Wielaard ---
I think we are just talking past each other because we don't fully agree when
the warning should trigger and whether it is (trivial and/or) desirable to
avoid that specific corner case.
We do agree that nes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88088
--- Comment #20 from Mark Wielaard ---
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02055.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041
--- Comment #14 from Mark Wielaard 2012-11-17
13:27:03 UTC ---
>> dwarf2out.c: For DWARF 4+, output DW_AT_high_pc as constant offset.
>>
>>
>> This required a gdb change.
>
> Ah, that should be in http://gcc.gnu.org/gcc-4.8/change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55716
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55716
--- Comment #2 from Mark Wielaard 2012-12-17 10:16:20
UTC ---
Hmmm, it might be that it is picking up the wrong "bootclasspath" in this case.
By default it tries to use System.getProperty("sun.boot.class.path") which I
assume is set to fil
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55764
Mark Wielaard changed:
What|Removed |Added
CC||mark at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55764
--- Comment #2 from Mark Wielaard 2012-12-21 09:38:31
UTC ---
(In reply to comment #1)
> I can replicate on x86_64 with the jdom.jar from jdom-1.1.3-3.fc18.noarch but
> not with the older jdom.jar from jdom-1.1.1-1.el6.noarch
Which isn'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55764
--- Comment #3 from Mark Wielaard 2012-12-21 09:42:28
UTC ---
The crash should of course not happen, but since jdom now depends on jaxen just
including the jaxen.jar on the classpath seems to work around the issue:
./jc1 jdom.jar fhash-s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #25 from Mark Wielaard ---
(In reply to Josh Triplett from comment #23)
> (In reply to Mark Wielaard from comment #21)
> > Although in C a static const is not really like a #define
>
> Why not? Many C projects try to avoid the prepr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #28 from Mark Wielaard ---
(In reply to Panu Matilainen from comment #26)
> On main files warning on unused junk is certainly useful but static const is
> commonly and deliberately used in headers (eg for arrays such as in comment
> #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #29 from Mark Wielaard ---
(In reply to Manuel López-Ibáñez from comment #27)
> (In reply to Mark Wielaard from comment #21)
> > Although in C a static const is not really like a #define I suspect that
> > there are cases where they a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #30 from Mark Wielaard ---
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01433.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #32 from Mark Wielaard ---
Author: mark
Date: Mon Feb 22 22:42:19 2016
New Revision: 233616
URL: https://gcc.gnu.org/viewcvs?rev=233616&root=gcc&view=rev
Log:
PR28901 Add two levels for -Wunused-const-variable.
There is some controv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69911
--- Comment #1 from Mark Wielaard ---
Proposed fix: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01537.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69911
--- Comment #3 from Mark Wielaard ---
Author: mark
Date: Tue Feb 23 11:47:19 2016
New Revision: 233627
URL: https://gcc.gnu.org/viewcvs?rev=233627&root=gcc&view=rev
Log:
PR c/69911 Check main_input_filename and DECL_SOURCE_FILE are not NULL.
DE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
--- Comment #35 from Mark Wielaard ---
Note the followup patch needed for PR c/69911
https://gcc.gnu.org/viewcvs?rev=233627&root=gcc&view=rev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901
Mark Wielaard changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69945
--- Comment #1 from Mark Wielaard ---
See also this valgrind bug: https://bugs.kde.org/show_bug.cgi?id=345307
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358
--- Comment #12 from Mark Wielaard ---
Having to parse line information to skip the prologue us somewhat inconvenient.
Especially since GCC doesn't actually emit DW_LNS_set_prologue_end, you have to
use some heuristic to determine whether you hav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #53 from Mark Wielaard ---
Author: mark
Date: Fri Apr 21 09:02:03 2017
New Revision: 247056
URL: https://gcc.gnu.org/viewcvs?rev=247056&root=gcc&view=rev
Log:
libiberty: Limit demangler maximum d_print_comp recursion call depth.
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #20 from Mark Wielaard ---
Created attachment 40213
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40213&action=edit
Add is_cyclic check to d_lookup_template_argument
The patch that Marcel originally proposed tried to catch any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70909
--- Comment #22 from Mark Wielaard ---
Created attachment 40230
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40230&action=edit
d_printing mark/walk/unmark protection
(In reply to Nathan Sidwell from comment #21)
> Why doesn't a mark/walk
1 - 100 of 303 matches
Mail list logo
