https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837
--- Comment #4 from Tom Tromey ---
(In reply to Jakub Jelinek from comment #3)
> And perhaps we could also try to optimize the DW_FORM_sdata cases if there
> is no ambiguity (e.g. for 8-bit signed contexts with negative value
> DW_FORM_data1 co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837
--- Comment #1 from Tom Tromey ---
Also there was an old thread about this:
https://lists.dwarfstd.org/pipermail/dwarf-discuss/2010-July/000862.html
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I recently found out that LLVM will use DW_FORM_data*, expecting
the debugger to sign-extend the value when the desired type or
context is "signed" and also the desired resul
iority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Some standard functions and methods aren't too interesting to step into.
E.g., std::unique_ptr::get.
Perhaps the libstdc++ gdb helper code coul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54696
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49565
--- Comment #13 from Tom Tromey ---
(In reply to anlauf from comment #12)
> After reading this ancient thread, I don't see anything left to do. Closing.
GCC still emits
<1>: Abbrev Number: 1 (DW_TAG_base_type)
DW_AT_byte_size : 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977
--- Comment #13 from Tom Tromey ---
This is fixed on trunk now.
I think that means it'll be in GCC 14... ?
Which maybe I shouldn't have done according to the current status.
Anyway, I'm not sure any more how gcc manages bugs, so I don't
know if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #39 from Tom Tromey ---
(In reply to Lukas Grätz from comment #36)
> > #2 0x004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44,
> > d=,
> > e=, f= > reading variable: value has been optimized out>, g=48, h=49) at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977
Tom Tromey changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tromey at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8188
--- Comment #6 from Tom Tromey ---
I wanted to mention -- I don't particularly care if this
attribute goes away or not (assuming it indeed doesn't
negatively affect gdb), but I do dispute the idea that
DWARF proscribes which attributes may or may
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8188
--- Comment #5 from Tom Tromey ---
The uses in gdb seem to all be for the old v2 C++ ABI.
Removing them might break that code, but OTOH that code
is untested, probably already broken, and anyway long
since obsolete.
Note that Rust+LLVM use this a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178
--- Comment #7 from Tom Tromey ---
(In reply to David Blaikie from comment #6)
> Ideally that'd be detected by looking at the abbreviation table, rather than
> the augmentation string - if parent info is necessary for a usage of the
> table, tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178
--- Comment #5 from Tom Tromey ---
(In reply to David Blaikie from comment #4)
I don't remember filing this bug. At the time maybe I thought it
would be worthwhile to have "end to end" .debug_names generation,
that is, to try to have the index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9346
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67801
--- Comment #4 from Tom Tromey ---
This was fixed by
commit 92456a4e5658e138e2cea79e390e3306b07685b0
Author: H.J. Lu
Date: Tue Aug 31 07:14:47 2021 -0700
libffi: Sync with libffi 3.4.2
Merged commit: f9ea41683444ebe11cfa45b052238997
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44126
--- Comment #7 from Tom Tromey ---
I happened to be looking in this area and I see that gcc still
generates the old, incorrect form.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49475
--- Comment #4 from Tom Tromey ---
Note that ifort implemented this and gdb supports that now.
See https://sourceware.org/bugzilla/show_bug.cgi?id=22497
for some info.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
In gdb we don't generally want -Wswitch-enum, because there are many
switches where it's not appropriate. However, for a subset of switch
statements, it is ni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94845
--- Comment #10 from Tom Tromey ---
See also bug #49130 and bug #49537, which we filed when
gdb hit these same problems.
++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
While refactoring gdb -- changing a function to a method --
I accidentally introduced a self-assign, because the function
used local variables that had the same name as the class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
--- Comment #8 from Tom Tromey ---
This behavior can also be affected by the choice of linker,
see bug #91239.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87432
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239
--- Comment #3 from Tom Tromey ---
Created attachment 52836
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52836&action=edit
test program
I thought I'd upload the sources. You can just untar.
Compile with "gcc -g3 -O0 r.cc z.cc -o z"
If y
||tromey at gcc dot gnu.org
--- Comment #2 from Tom Tromey ---
I separately discovered this problem when debugging an apparent gdb
slowdown, which I tracked down to a pathological .debug_macro section --
but only when I switched to using 'mold' to link.
> So how does a testc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67590
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65763
Tom Tromey changed:
What|Removed |Added
CC||townsend at astro dot wisc.edu
--- Comment
||tromey at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #4 from Tom Tromey ---
The patch here, that was reported as fixing the problem,
was fixed in bug #65763.
*** This bug has been marked as a duplicate of bug 65763 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63792
Tom Tromey changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
Tom Tromey changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128
--- Comment #8 from Tom Tromey ---
*** Bug 96240 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96240
Tom Tromey changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128
Tom Tromey changed:
What|Removed |Added
CC||skunk at iskunk dot org
--- Comment #7 from
|--- |DUPLICATE
CC||tromey at gcc dot gnu.org
--- Comment #6 from Tom Tromey ---
This is a dup.
I think libcc1 has to be built shared.
So if you want --disable-shared, also use --disable-libcc1.
Maybe libcc1 should disable itself -- something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96240
Tom Tromey changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128
Tom Tromey changed:
What|Removed |Added
CC||570070308 at qq dot com
--- Comment #6 from
||tromey at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Tom Tromey ---
I think this is a dup.
libcc1 has to be built shared. Maybe it should automatically
disable itself, I don't know; but otherwise you can --disable-libcc1
i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669
--- Comment #8 from Tom Tromey ---
(In reply to David Binderman from comment #7)
> Could this bug be marked as fixed, then ?
Yes, but I don't really know the GCC rules about closing reports
any more, so someone else probably ought to handle it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79531
--- Comment #3 from Tom Tromey ---
(In reply to Andrew Pinski from comment #2)
> Which seems ok, unless I am missing something.
Looks good to me too, IMO you could close this bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100435
--- Comment #2 from Tom Tromey ---
(In reply to Richard Biener from comment #1)
> I think it's just an omission and indeed a bug.
I can write a patch easily enough, but I don't have a good way to test it.
: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I noticed that the libcpp hash tables in libcpp/files.c use
htab_hash_string, but compare filenames with filename_cmp.
This by itself is not a bug, in the sense that it can&#
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94845
--- Comment #8 from Tom Tromey ---
(In reply to rob...@ocallahan.org from comment #7)
> So gdb reads DW_AT_name "func", parses it, reserializes it to
> "func", and uses that?
Yeah. (Actually it's even worse than that, because at least one
compi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94845
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #6
: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
DWARF 5 includes a new index section, .debug_names.
GCC should emit this with -gdwarf-5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63792
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781
--- Comment #24 from Tom Tromey ---
(In reply to David Crocker from comment #23)
> I need this feature too. Instead of waiting several more years for an
> all-singing all-dancing solution, PLEASE can we have a simple solution that
> allows me to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509
Tom Tromey changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509
--- Comment #3 from Tom Tromey ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547388.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509
Tom Tromey changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tromey at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
--- Comment #7 from Tom Tromey ---
(In reply to Asher Gordon from comment #6)
> (In reply to Tom Tromey from comment #5)
> > Since this warning is intended to work like sparse, introducing
> > a divergence here would seem to make the feature less
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935
Tom Tromey changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93988
--- Comment #2 from Tom Tromey ---
(In reply to Richard Biener from comment #1)
> I wonder if there is (or should be) sth like DW_ATE_unsupported ... using
> DW_ATE_lo_user is indeed unfortunate but not wrong per-se. Adding
> a DW_ATE_GNU_comple
: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Consider this test case:
_Complex int x = 23i;
Compile with -g and examine the resulting DWARF:
<1><31>: Abbrev Number: 3 (DW_TAG_base_type)
<32>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93458
--- Comment #4 from Tom Tromey ---
> BTW, did you include ?
>
> (FAOD: it would still be broken if you did, but ISTM we might at some point
> add a hint that if the traits can't be found, you probably forgot that).
The code was exactly as writ
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
GCC accepts extended forms of constant expression.
An example that came up recently was:
const int a = 5;
const int b = a;
IIUC the standard permits the compiler to accept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93458
Tom Tromey changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1 from Tom
: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I'm using git master gcc from today.
I tried a simple coroutine program:
int func(int *x) {
for (int i = 0; i < 23; ++i)
co_yield x[i];
}
Compiling causes gcc to ICE:
murgatroyd. .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57612
--- Comment #4 from Tom Tromey ---
(In reply to H. Peter Anvin from comment #2)
> I would like to second this request, however, I would like to request that
> it issues a warning rather than an error. It can always be promoted to an
> error via
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61257
--- Comment #6 from Tom Tromey ---
(In reply to Eric Gallager from comment #4)
> (In reply to Sergei Trofimovich from comment #3)
> > (In reply to Sergei Trofimovich from comment #2)
> > > Having explicit flags like --enable-systemtap / --disable
rmal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Consider this test case:
struct x
{
int a : 5;
int b : 2;
};
struct x x;
Compile with -g -c and then examine the DWARF.
For x::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91330
--- Comment #1 from Tom Tromey ---
This is pretty easy to fix in gcc/jit/docs/conf.py:
diff --git a/gcc/jit/docs/conf.py b/gcc/jit/docs/conf.py
index 3e630db47ef..1224bdcc07d 100644
--- a/gcc/jit/docs/conf.py
+++ b/gcc/jit/docs/conf.py
@@ -244,7
onent: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Looking at the "dir" entry for the JIT, I see:
murgatroyd. grep jit install/share/info/dir
* libgccjit: (libgccjit.info). One line description of project.
I
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
This test case comes from https://sourceware.org/bugzilla/show_bug.cgi?id=20020
Consider:
template
struct foo
{
static constexpr bool is_always_lock_free = true;
};
int
nent: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
This test case comes from this blog post:
https://nfrechette.github.io/2019/05/08/sign_flip_optimization/
(which also says that clang 8 performs this op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935
--- Comment #10 from Tom Tromey ---
I have been looking at this again recently, for Ada, and now
I think perhaps the approach that GCC takes should be preferred.
At first I was thinking maybe the compiler could linearize
the members of the emitt
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I'm using the system gcc on Fedora 29:
gcc (GCC) 8.2.1 20180801 (Red Hat 8.2.1-2)
Consider this source:
struct s {
int f;
};
int x
++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Apologies for the vagueness of this bug. I ran across a
pull request that mentions that gcc will sometimes emit an erroneous
'sr' mangling:
https://github.com/gimli-rs/cpp_dem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #14 from Tom Tromey ---
(In reply to Jonathan Wakely from comment #8)
> Something like __builtin_unreachable() to say "trust me" would be nice, but
> I can't think how to do it.
How about an attribute that can be attached to the memb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
--- Comment #10 from Tom Tromey ---
Also I think all the test suite changes never really worked.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
--- Comment #9 from Tom Tromey ---
Created attachment 45413
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45413&action=edit
ancient patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
--- Comment #8 from Tom Tromey ---
Sorry about the extreme delay on this.
I think my patch has long since bit-rotted, but I can attach it for
reference. I believe my assignment situation got sorted out so this
should be fine to read and/or copy
++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Consider this source:
int Foo;
struct Foo
{
int a;
};
extern int f(Foo x);
gcc (I'm using 8.2.1 from Fedora 28) says:
q.cc:8:14: warning: ‘f’ initialized and dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65158
Tom Tromey changed:
What|Removed |Added
Status|WAITING |REOPENED
--- Comment #2 from Tom Tromey --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87104
--- Comment #13 from Tom Tromey ---
(In reply to pipcet from comment #12)
> So I think the performance difference is really significant for Emacs; my
> plan is to test all three versions on other programs, make sure the code
> works for C bitfie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87062
--- Comment #1 from Tom Tromey ---
Analysis in the comments there puts the blame on -ftree-slp-vectorize
++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I'm filing this on behalf of someone who posted this bug on reddit.
https://www.reddit.com/r/cpp/comments/99e1ri/interesting_gcc_optimizer_bug/
Copying text from there:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87003
--- Comment #2 from Tom Tromey ---
I don't really know the best thing to do.
I see your point about graceful failure being a useful
feature, in cases where the result of some gcc-jit function
is passed as an argument to another one.
Maybe there
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
The function gcc_jit_context_get_builtin_function is not documented.
Assignee: dmalcolm at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Currently all blocks must be terminated either with a jump or a return.
I think it should also be possible to terminate a block with
a call to a noreturn function. But, there is no way
Assignee: dmalcolm at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Many functions in libgccjit.h take a pointer argument,
and it isn't clear which of these can be NULL and which cannot.
It would be a bit helpful if the nonnull attribute were ap
onent: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
gcc-jit has gcc_jit_context_new_rvalue_from_int and
gcc_jit_context_new_rvalue_from_long, but on some platforms
long might be 32 bits, but a program could still use int64_t
or lon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #17 from Tom Tromey ---
The results in comment #13 seem to be missing some compilations --
I would have expected to see more files from libcpp in there.
As it is I only see directives.o and line-map.o.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935
--- Comment #9 from Tom Tromey ---
(In reply to Pierre-Marie de Rodat from comment #8)
> Understood, thank you for the notice! As we have to tweak the spec one way
> or another for Ada, I suggest indeed we keep the way things are implemented
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935
--- Comment #7 from Tom Tromey ---
For Rust I ended up following the letter of the standard, so I'm going
to follow this in the gdb patches as well. That said, gdb can be adapted
to work with either approach, so it's not strictly necessary to ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935
--- Comment #3 from Tom Tromey ---
(In reply to Pierre-Marie de Rodat from comment #2)
> Thinking more about it, the rule that the discriminant entry must be a child
> of the variant part entry sounds suspicious to me.
TBH this did not make sens
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Joel Brobecker sent me an Ada test case so that I could see a real-life
example of the use of DW_TAG_variant_part (in support of some Rust
stuff I'm doing elsewhere).
For this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
--- Comment #10 from Tom Tromey ---
I ran into this again, went to file a bug, and then found that
I'd already filed the bug...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81431
--- Comment #1 from Tom Tromey ---
Also related is bug 55837.
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I would like gcc to emit a warning when a constructor does not
initialize a POD member; and in particular I'd like this not to
be tied to -Wuninitialized.
Hav
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I saw an error when building firefox with gcc 6.3.1 (fedora 25 system gcc):
/home/tromey/firefox-git/gecko/js/src/frontend/EitherParser.h:253:13: error:
ignoring attributes
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Consider this source:
===
struct base {
virtual void m() = 0;
};
struct derived : public base {
virtual void m() override;
virtual void method2() override
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77315
Tom Tromey changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77315
--- Comment #2 from Tom Tromey ---
Author: tromey
Date: Mon Oct 31 20:08:44 2016
New Revision: 241721
URL: https://gcc.gnu.org/viewcvs?rev=241721&root=gcc&view=rev
Log:
PR debug/77315:
* dwarf2out.c (mem_loc_descriptor): Use DW_O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77315
Tom Tromey changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tromey at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014
--- Comment #3 from Tom Tromey ---
(In reply to jos...@codesourcery.com from comment #2)
> Likewise an expression where the user did "typedef size_t my_size_t;" and
> then used my_size_t. And what about expressions resulting from arithmetic
>
1 - 100 of 315 matches
Mail list logo
