Daniel Berlin wrote:
The problem that sizeof creates is different, in that you have no way
to tell where it's been used.
The point is that even if you *did* know, that wouldn't help you.
Nothing in the language says that "sizeof (X)" is any different from a
constant that has that ABI-specifi
On Tue, Jul 29, 2008 at 8:45 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
>
>> If you built an AST that included sizeof before doing template
>> instantiation (which may not even be possible), you could at least
>> determine whether sizeof was used on a given type other than
Daniel Berlin wrote:
If you built an AST that included sizeof before doing template
instantiation (which may not even be possible), you could at least
determine whether sizeof was used on a given type other than in a
malloc/new call (which we replace anyway).
Even if you did, I am allowed to k
On Tue, Jul 29, 2008 at 11:20 AM, Paolo Bonzini <[EMAIL PROTECTED]> wrote:
>
> For that matter, "print sizeof(X)" should print the same value when
> debugging optimized code as when debugging unoptimized code, even if the
> compiler has optimized X away to an empty structure!
For that matter, "print sizeof(X)" should print the same value when
debugging optimized code as when debugging unoptimized code, even if
the compiler has optimized X away to an empty structure!
I disagree. sizeof(X) in the code will return a value as small as
possible in that case (so that
On Jul 27, 2008, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> In that case, I'm not sure that *type* ought to be modified at all,
> from the debug perspective. To the extent there's still an object of
> type "struct X" around, it's type is still what it was. And other
> things you might do in a de
Kenneth Zadeck wrote:
Paolo Bonzini wrote:
Mark Mitchell wrote:
For that matter, "print sizeof(X)" should print the same value when
debugging optimized code as when debugging unoptimized code, even if
the compiler has optimized X away to an empty structure!
I disagree. sizeof(X) in the code
On Tue, 29 Jul 2008, Paolo Bonzini wrote:
> Mark Mitchell wrote:
> > For that matter, "print sizeof(X)" should print the same value when
> > debugging optimized code as when debugging unoptimized code, even if the
> > compiler has optimized X away to an empty structure!
>
> I disagree. sizeof(X)
Paolo Bonzini wrote:
Mark Mitchell wrote:
For that matter, "print sizeof(X)" should print the same value when
debugging optimized code as when debugging unoptimized code, even if
the compiler has optimized X away to an empty structure!
I disagree. sizeof(X) in the code will return a value as
Mark Mitchell wrote:
For that matter, "print sizeof(X)" should print the
same value when debugging optimized code as when debugging unoptimized
code, even if the compiler has optimized X away to an empty structure!
I disagree. sizeof(X) in the code will return a value as small as
possible in
Hi,
On Fri, 25 Jul 2008, Chris Lattner wrote:
> >But not all the trees implementing those types (and all the
> >cross-references between those, that are important for parsing but not
> >interesting at all for the middle-end). All you need is a tag (alias
> >set number) per type and a graph gi
On Sun, Jul 27, 2008 at 7:50 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
>
>> Then again, I also don't see what the big deal about adding a debug
>> info parser is.
>
> OK, yes, we may need to read debug info back in.
>
> I don't see it as a big deal, either -- and I also do
On Sun, Jul 27, 2008 at 7:48 PM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
>> you may of course be right and this is what we will end up doing, but the
> implications for whopr are not good. The parser is going to have to work
> in lockstep with the type merger
Why?
You d
On Sun, Jul 27, 2008 at 7:41 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
>> Daniel Berlin wrote:
>>
I agree that, at least in principle, it should be possible to emit the
debug
info (whether the format is DW
Daniel Berlin wrote:
Then again, I also don't see what the big deal about adding a debug
info parser is.
OK, yes, we may need to read debug info back in.
I don't see it as a big deal, either -- and I also don't see it as
locking us into DWARF2. We can presumably read in any formats we are
Daniel Berlin wrote:
On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
I agree that, at least in principle, it should be possible to emit the
debug
info (whether the format is DWARF, Stabs, etc.) once.
No, you can't.
You would at l
On Sun, Jul 27, 2008 at 3:10 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote:
>
>>> I agree that, at least in principle, it should be possible to emit the
>>> debug
>>> info (whether the format is DWARF, Stabs, etc.) once.
>>
>> No, you can't.
>> You would at least have to emit t
Daniel Berlin wrote:
I agree that, at least in principle, it should be possible to emit the debug
info (whether the format is DWARF, Stabs, etc.) once.
No, you can't.
You would at least have to emit the variables separate from the types
(IE emit debug info twice).
Yes, of course; that's what
Daniel Berlin wrote:
On Sun, Jul 27, 2008 at 1:18 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
David Edelsohn wrote:
I do not expect LTO (or WHOPR) to work on AIX -- at least not
without a lot of work on wrappers around the AIX linker. However, I do
not understand why enhancing
On Sun, Jul 27, 2008 at 1:18 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> David Edelsohn wrote:
>
>>I do not expect LTO (or WHOPR) to work on AIX -- at least not
>> without a lot of work on wrappers around the AIX linker. However, I do
>> not understand why enhancing GCC to support LTO -
Andrew Pinski wrote:
Actually there is a way to express this in Dwarf2, using DW_OP_piece.
See the thread at http://gcc.gnu.org/ml/gcc/2005-01/msg00080.html for
more information.
And if that's not sufficient, we can of course add extensions to DWARF
that do represent it -- and that would be b
On Sun, Jul 27, 2008 at 11:09 AM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> We generate variables with names like x$y for struct { int y; } x; - in theory
> the debugger could "magically" associate a print x.y with x$y. But of course
> there is no way to express this in the DWARF.
Actually t
On Sun, Jul 27, 2008 at 7:18 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> David Edelsohn wrote:
>
>>I do not expect LTO (or WHOPR) to work on AIX -- at least not
>> without a lot of work on wrappers around the AIX linker. However, I do
>> not understand why enhancing GCC to support LTO -
David Edelsohn wrote:
I do not expect LTO (or WHOPR) to work on AIX -- at least not
without a lot of work on wrappers around the AIX linker. However, I do
not understand why enhancing GCC to support LTO -- when GCC is run without
enabling LTO -- requires locking GCC completely into DWAR
On 7/26/08 3:48 PM, Richard Guenther wrote:
On Sat, Jul 26, 2008 at 8:42 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
So how do you plan to keep the debug info up to date in the presence
of structure reordering/etc transforms?
Provide no debug information for these types/decls.
That would b
On Sat, Jul 26, 2008 at 8:42 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 26, 2008 at 1:55 PM, Richard Guenther
> <[EMAIL PROTECTED]> wrote:
>> On Sat, Jul 26, 2008 at 7:48 PM, David Edelsohn <[EMAIL PROTECTED]> wrote:
>>> Kenny> 2) Generate the debugging for the types early, and then
On Sat, Jul 26, 2008 at 1:55 PM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> On Sat, Jul 26, 2008 at 7:48 PM, David Edelsohn <[EMAIL PROTECTED]> wrote:
>> Kenny> 2) Generate the debugging for the types early, and then add an
>> Kenny> interface that would parse and regenerate the debugging info w
On Sat, Jul 26, 2008 at 7:48 PM, David Edelsohn <[EMAIL PROTECTED]> wrote:
> Kenny> 2) Generate the debugging for the types early, and then add an
> Kenny> interface that would parse and regenerate the debugging info with
> Kenny> the changes. It is quite likely that this would lock gcc
> Kenny> c
Kenny> 2) Generate the debugging for the types early, and then add an
Kenny> interface that would parse and regenerate the debugging info with
Kenny> the changes. It is quite likely that this would lock gcc
Kenny> completely into dwarf, but that appears to only be a problem for
Kenny> AIX at this
On Jul 25, 2008, at 9:20 AM, Michael Matz wrote:
That is one example of extremely important information which requires
pulling in almost the entire source type system.
But not all the trees implementing those types (and all the
cross-references between those, that are important for parsing but
Mark Mitchell wrote:
Kenneth Zadeck wrote:
1) Screw the debugging. The motivation behind this option is that
not only is it easy, but the reality is that we have changed the
program so much that even if we did "fix up the types" so that the
matched the generated program, that the code
Kenneth Zadeck wrote:
1) Screw the debugging. The motivation behind this option is that
not only is it easy, but the reality is that we have changed the
program so much that even if we did "fix up the types" so that the
matched the generated program, that the code is so different from
Hi,
On Fri, 25 Jul 2008, Chris Lattner wrote:
> >the frontends, but can concentrate on what is useful and needed for the
> >middle-end right now.
>
> Sure, this makes plenty of sense to me (and sounds very *very*
> familiar). Do you intend to include things like TBAA in the initial
> type sy
On Jul 25, 2008, at 1:54 AM, Richard Guenther wrote:
Sure, typedefs in C/C++ seem clearly useless. I'm just curious how
you plan
to go about deciding whether things are useless in a more general
context.
How fine of a granularity do you intend to inspect bits? Trees
have lots
of random stu
Richard Guenther wrote:
On Fri, Jul 25, 2008 at 7:01 AM, Chris Lattner <[EMAIL PROTECTED]> wrote:
I dunno, this seems like a thing you could better figure out by trying
it and seeing where the problems are than by trying to anticipate
every single possible problem
(not that there should be no
Richard Guenther wrote:
On Fri, Jul 25, 2008 at 1:47 PM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
Arnaud Charlet wrote:
When danny and it wrote the ipa-type-escape pass, mark mitchell was all
over us because we assumed that the type system had some semantic meaning.
We ended up with a
On Fri, Jul 25, 2008 at 1:47 PM, Kenneth Zadeck
<[EMAIL PROTECTED]> wrote:
> Arnaud Charlet wrote:
>>>
>>> When danny and it wrote the ipa-type-escape pass, mark mitchell was all
>>> over us because we assumed that the type system had some semantic meaning.
>>> We ended up with a pass that general
Arnaud Charlet wrote:
When danny and it wrote the ipa-type-escape pass, mark mitchell was all
over us because we assumed that the type system had some semantic meaning.
We ended up with a pass that generally finds nothing useful. I would very
much like to redo that pass once we can mark a typ
On Fri, Jul 25, 2008 at 7:01 AM, Chris Lattner <[EMAIL PROTECTED]> wrote:
>>> I dunno, this seems like a thing you could better figure out by trying
>>> it and seeing where the problems are than by trying to anticipate
>>> every single possible problem
>>> (not that there should be no design, but t
> When danny and it wrote the ipa-type-escape pass, mark mitchell was all
> over us because we assumed that the type system had some semantic meaning.
> We ended up with a pass that generally finds nothing useful. I would very
> much like to redo that pass once we can mark a type as coming fro
I dunno, this seems like a thing you could better figure out by
trying
it and seeing where the problems are than by trying to anticipate
every single possible problem
(not that there should be no design, but that it would be better to
start with a design and iterate it than try to figure out per
Arnaud Charlet wrote:
I do not know Fortran but from the description above, this is similar in Ada:
you cannot freely mix different pointers, and you cannot make a pointer out
of any variable, unless variables are marked 'aliased'. This semantic is
already expressed today in GCC trees, so I'm not
Daniel Berlin wrote:
On Thu, Jul 24, 2008 at 2:13 PM, Chris Lattner <[EMAIL PROTECTED]> wrote:
On Jul 24, 2008, at 10:16 AM, Kenneth Zadeck wrote:
I thought the whole idea of the LTO project was to keep as much language
specific type information as late as possible. If you start stripp
>> I do not know Fortran but from the description above, this is similar in Ada:
>> you cannot freely mix different pointers, and you cannot make a pointer out
>> of any variable, unless variables are marked 'aliased'. This semantic is
>> already expressed today in GCC trees, so I'm not sure what m
On Thu, Jul 24, 2008 at 2:13 PM, Chris Lattner <[EMAIL PROTECTED]> wrote:
> On Jul 24, 2008, at 10:16 AM, Kenneth Zadeck wrote:
>>>
>>> I thought the whole idea of the LTO project was to keep as much language
>>> specific type information as late as possible. If you start stripping out
>>> useful
On Jul 24, 2008, at 10:16 AM, Kenneth Zadeck wrote:
I thought the whole idea of the LTO project was to keep as much
language specific type information as late as possible. If you
start stripping out useful information about types, it becomes
harder to do high level optimizations like devirt
Arnaud Charlet wrote:
In this same vein, I am very interested in using the gimple type
system as a way to start moving gcc from being a C compiler that
accommodates other languages to a compiler that handles different
languages on an equal footing. The freedom that C and C++ "enjoy" to
basically
Chris Lattner wrote:
On Jul 24, 2008, at 9:26 AM, Kenneth Zadeck wrote:
3) Generate the debugging for the types late. The problem here is
that we want the gimple type system to be stripped of the front end
specific information, so any front end specific info that is only
necessary for the
On Jul 24, 2008, at 9:26 AM, Kenneth Zadeck wrote:
3) Generate the debugging for the types late. The problem here is
that we want the gimple type system to be stripped of the front end
specific information, so any front end specific info that is only
necessary for the debugging, will both b
> In this same vein, I am very interested in using the gimple type
> system as a way to start moving gcc from being a C compiler that
> accommodates other languages to a compiler that handles different
> languages on an equal footing. The freedom that C and C++ "enjoy" to
> basically take a pointe
I have been working on a design for gimple types. The overall plan is
to gimplify the types, as we gimplify the executable code. Then we
can release the front end types and recover the space.
There are difficulties with this plan and most of them have to do with
the generation of debug informa
51 matches
Mail list logo
