Again, please don't do this.
As you can see (see Tom Tromey's email), others have a use to go between
vtable types and the types they are attached to.
We should be getting away from linkage names, not going further towards
them.
There are a bunch of gdb bugs this won't solve, but adding an extensio
>
>
> This avoids the problem of the demangler gdb is using getting a different
> name than the producer used. It also should always give you the right one.
> If the producer calls the type "vtable fo Foo<2u>" here and "Foo<2>"
> elsewhere, yes, that's a bug. It should be consistent.
>
>
This shoul
On Wed, Feb 7, 2018 at 5:44 AM, Simon Marchi
wrote:
> On 2018-02-07 02:21, Daniel Berlin wrote:
>
>> As the person who, eons ago, wrote a bunch of the the GDB code for this
>> C++
>> ABI support, and as someone who helped with DWARF support in both GDB and
>> GCC,
As the person who, eons ago, wrote a bunch of the the GDB code for this C++
ABI support, and as someone who helped with DWARF support in both GDB and
GCC, let me try to propose a useful path forward (in the hopes that someone
will say "that's horrible, do it this instead")
Here are the constraint
Sorry dude, I don't engage in substantive conversation with abusive trolls.
On Sat, Nov 24, 2012 at 2:43 PM, Ruben Safir wrote:
> On Sat, Nov 24, 2012 at 12:58:33PM -0500, Daniel Berlin wrote:
>> On Sat, Nov 24, 2012 at 12:13 PM, Ian Lance Taylor wrote:
>> >
On Sat, Nov 24, 2012 at 12:47 PM, Robert Dewar wrote:
>
>> 2) The fact that Android refuses to provide a non-HTML e-mail capability
>> is ridiculous but does not seem to me to be a reason for us to change
>> our policy.
>
>
> Surely there are altenrative email client for Android that have plain
>
On Sat, Nov 24, 2012 at 12:13 PM, Ian Lance Taylor wrote:
> Diego Novillo writes:
>
>> Sure. First I wanted to find out whether this requirement is just a
>> technical limitation with our mailing list software.
>
> It is not a technical limitation. We explicitly reject HTML e-mail. We
> could
On Thu, Sep 9, 2010 at 7:24 AM, Richard Guenther
wrote:
> On Thu, Sep 9, 2010 at 1:19 PM, Amker.Cheng wrote:
>> Hi,
>> I am studying gcc's points-to analysis right now and encountered a question.
>> In paper "Off-line Variable Substitution for Scaling Points-to
>> Analysis", section 3.2
>> It says
Your bug was not a real bug, AFAICT.
At least the debug info you have shown in
http://gcc.gnu.org/ml/gcc/2010-01/msg00054.html is not wrong.
Certainly, two DIES were unnecessary, but the way it did it was not broken.
Note that one of them is marked as DW_AT_declaration, specifying that
is where the
> In general it will be tricky for latter passes to clean up the messes.
> The fundamental problem is that the address computation is exposed to
> PRE prematurely (for a given target ) at GIMPLE level.
Yeah, i'm not sure PRE can really do anything different here.
I also think you would have a ve
On Sat, Dec 19, 2009 at 2:48 PM, Steven Bosscher wrote:
> On Mon, Nov 30, 2009 at 12:10 PM, Steven Bosscher
> wrote:
>> I'll see if I can make the intraprocedural version work again before
>> Christmass.
>
> Well, it works, but then again it really does not. For example, the
> original implement
On Sun, Nov 29, 2009 at 3:33 PM, Richard Guenther
wrote:
> On Sun, Nov 29, 2009 at 9:18 PM, Daniel Berlin wrote:
>>>
>>> Such a thing already existed a few years ago (IIRC Haifa had something
>>> that Dan picked up and passed on to me). But it never brought any
>
> Such a thing already existed a few years ago (IIRC Haifa had something
> that Dan picked up and passed on to me). But it never brought any
> benefits. I don't have the pass anymore, but perhaps Dan still has a
> copy of it somewhere.
It was actually posted and reviewed, you can find it in the
On Mon, Nov 23, 2009 at 10:17 AM, Ian Bolton wrote:
> David Edelsohn wrote:
>> On Fri, Nov 20, 2009 at 10:05 AM, Ian Bolton
>> wrote:
>> > From some simple experiments (see below), it appears as though GCC
>> aims
>> > to
>> > create a lop-sided tree when there are constants involved (func1
>> be
On Mon, Oct 12, 2009 at 5:20 PM, Jason Merrill wrote:
> On 10/12/2009 05:17 PM, Andrew Pinski wrote:
>>
>> That seems like a huge bug in git-svn because we already use multiple
>> directory levels under branches. Hint ibm and redhat and debain.
>
> Yep, that's why I said "expand". I've thought a
My guess, witjout seeing the testcase.
In ccp_initialize we have:
for (i = gsi_start_bb (bb); !gsi_end_p (i); gsi_next (&i))
{
gimple stmt = gsi_stmt (i);
bool is_varying = surely_varying_stmt_p (stmt);
if (is_varying)
{
tree d
On Fri, Aug 21, 2009 at 5:37 AM, Steven Bosscher wrote:
> On Fri, Aug 21, 2009 at 10:52 AM, Laurynas
> Biveinis wrote:
BTW, it does not deal with types that in some instances have variables
allocated in proper GC way (with a path from GC root) and in some
instances not. Fixing these
On Thu, Jul 16, 2009 at 5:00 AM, Li Feng wrote:
> Hi Richard,
> On 7/16/09, Richard Guenther wrote:
>> On Thu, Jul 16, 2009 at 1:15 AM, Tobias
>> Grosser wrote:
>>> On Wed, 2009-07-15 at 22:48 +0200, Richard Guenther wrote:
On Wed, Jul 15, 2009 at 10:46 PM, Richard
Guenther wrote:
>
You must be looking at old documentation or something.
Call's are represented by GIMPLE_CALL_STMT (or CALL_EXPR in older GCC'en).
There has been a callgraph for quite a long time (see cgraph*.c and cgraph*.h)
On Tue, Jul 7, 2009 at 7:26 AM, Nicolas
COLLIN wrote:
> Hello,
> I looked at the part of
>
> All that above said - do you expect us to carry both vec.h (for VEC in
> GC memory) and std::vector (for VECs in heap memory) (and vec.h
> for the alloca trick ...)? Or do you think we should try to make the GTY
> machinery C++ aware and annotate the standard library (ick...)?
Since the conta
On Mon, Jun 22, 2009 at 3:19 PM, Dave
Korn wrote:
> Joe Buck wrote:
>
>> As a general rule there is a performance cost for making iterators
>> on a data structure safe with respect to modifications of that data
>> structure. I'm not in a position to say what the right solution is
>> in this case,
On Sat, Jun 20, 2009 at 10:54 AM, Jeff Law wrote:
>
> Imagine a loop like this
>
> EXECUTE_IF_SET_IN_BITMAP (something, 0, i, bi)
> {
> bitmap_clear_bit (something, i)
> [ ... whatever code we want to process i, ... ]
> }
>
> This code is unsafe.
>
> If bit I happens to be the only bit set in
On Tue, Jun 16, 2009 at 10:17 AM, Jason Merrill wrote:
> On 06/15/2009 01:22 PM, Bernie Innocenti wrote:
>>
>> On 06/15/09 16:28, Rafael Espindola wrote:
>>>
>>> It fails with
>>>
>>> $ git config --add remote.origin.fetch
>>> '+refs/remotes/*:refs/remotes/origin/*'
>>> $ git fetch
>>> fatal: refs/
On Thu, Jun 11, 2009 at 3:07 AM, Bernie Innocenti wrote:
> On 06/10/09 02:43, Ian Lance Taylor wrote:
>> fche has already installed git 1.6.3.2 in /usr/local/bin on sourceware.
>> That is now the one you will get if you connect to port "git". Hope
>> nothing breaks.
>
> Thanks.
>
> I made a few ch
On Wed, Jun 10, 2009 at 9:38 PM, Jason Merrill wrote:
> Bernie Innocenti wrote:
>>
>> I won't re-create the repository from scratch, then.
>
> re-creating it from scratch should be fine as long as the metadata uses
> svn+ssh://gcc.gnu.org/svn/gcc. I'd think that
>
> git svn clone -s file://path/to
On Tue, Jun 9, 2009 at 8:51 PM, Joseph S. Myers wrote:
> On Tue, 9 Jun 2009, Ian Lance Taylor wrote:
>
>> I believe that the most useful immediate thing we could do to speed up
>> gcc development would be to move to a distributed version control
>> system.
>
> We haven't even finished the last vers
On Tue, Jun 9, 2009 at 3:16 PM, Bernie Innocenti wrote:
> On 06/09/09 16:17, Jason Merrill wrote:
>> Bernie Innocenti wrote:
>>> On 06/07/09 12:40, Ralf Wildenhues wrote:
Is this mirror an independent conversion from the infradead one (i.e., I
have to throw away the repo and re-download a
On Sun, Jun 7, 2009 at 8:08 AM, Bernie Innocenti wrote:
> On 06/07/09 13:38, Bernie Innocenti wrote:
>> On 06/07/09 12:40, Ralf Wildenhues wrote:
>>> Is this mirror an independent conversion from the infradead one (i.e., I
>>> have to throw away the repo and re-download a full repo? Or can I reuse
>
> We can measure some of these things now. Some can even be measured
> objectively ;-)
Do you have any of them handy (memory use, compile time with release
checking only, etc) so that we can start the public
argument^H^H^H^H^H^discussion?
;)
On Wed, May 27, 2009 at 10:33 PM, Mark Tall wrote:
> 2009/5/28 Andrew Pinski:
>>
>> GCC see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24314 .
>>
>
> hmm.. known since 2005. Is there some difficulty in fixing this ?
>
More likely it's pretty rare so nobody has gotten itchy enough to
scratch tha
On Sat, May 16, 2009 at 5:49 AM, Richard Guenther
wrote:
> On Sat, May 16, 2009 at 11:41 AM, VandeVondele Joost
> wrote:
>>
> I think it is useful to have a bugzilla here.
will do.
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
>>
>>>
>>> Btw, complete unrolling is also hi
On Wed, Apr 29, 2009 at 6:19 PM, Steven Bosscher wrote:
> On Thu, Apr 30, 2009 at 12:15 AM, Richard Guenther
> wrote:
>> Well, the challenge is to retain the per SSA name information across
>> Graphite. At some point we need to stop re-computing points-to
>> information because we cannot do so w
Errr, the format is not pre-1.5.0
It was svnadmin upgraded a while ago.
On Sat, Apr 25, 2009 at 5:06 AM, Laurynas Biveinis
wrote:
> Hi,
>
> Apparently the server is already running svn 1.5.5 but the repository
> format is pre-1.5.0. If the repository format was upgraded, we could
> start using p
On Sat, Apr 4, 2009 at 2:57 PM, Gerald Pfeifer wrote:
> On Tue, 24 Feb 2009, Joseph S. Myers wrote:
>> build.html was missing group write permission:
>>
>> -rw-r--r-- 1 gerald gcc 18920 Mar 30 2008 build.html
>>
>> This probably meant that the nightly onlinedocs update would fail to
>> update
On Wed, Apr 1, 2009 at 5:33 AM, Kirill Kononenko
wrote:
> Hello Dear GCC Developers,
>
>
>
> I would like to ask your opinion about possibility for integration of
> the libJIT Just-In-Time compilation library and GCC. For example, the
> same way as libffi is integrated within gcc source tree. It s
On Tue, Mar 31, 2009 at 3:01 PM, Gabriel Dos Reis wrote:
> On Tue, Mar 31, 2009 at 1:51 PM, Rainer Orth
> wrote:
>> Daniel Berlin writes:
>
>> Understood, but I wonder how other projects deal with this. I cannot
>> possibly be the only one in the world who wan
On Tue, Mar 31, 2009 at 2:51 PM, Rainer Orth
wrote:
> Daniel Berlin writes:
>
>> > I don't blame you at all, but find it highly
>> > unfortunate to be forced to use a browser for initial submission instead of
>> > being able to use a proper mailer/editor.
On Tue, Mar 31, 2009 at 2:46 PM, Rainer Orth
wrote:
> Daniel Berlin writes:
>
>> On Fri, Mar 27, 2009 at 6:34 PM, Joseph S. Myers
>> wrote:
>> > On Fri, 27 Mar 2009, Mark Mitchell wrote:
> [...]
>> > If we want to deprecate gccbug in 4.4 and remove i
On Sun, Mar 29, 2009 at 11:27 AM, Joseph S. Myers
wrote:
> On Fri, 27 Mar 2009, Mark Mitchell wrote:
>
>> The tasks that remain from branching.html are:
>
> I believe everything needed for starting the new release branch is now
> done apart from this:
>
>> 13. Asking Danny Berlin to adjust PRs.
>
On Fri, Mar 27, 2009 at 6:34 PM, Joseph S. Myers
wrote:
> On Fri, 27 Mar 2009, Mark Mitchell wrote:
>
>> 12. Updating the email parsing script. AFAICT, this hasn't been done in
>> a while, so I wasn't sure if it was considered obsolete.
>
> I have done this. I'll deal with the snapshot and .pot
On Sun, Mar 22, 2009 at 7:01 PM, Daniel Berlin wrote:
> On Sun, Mar 22, 2009 at 6:47 PM, Jeff Law wrote:
>> Richard Kenner wrote:
>>>>
>>>> Of course, just I (and others) don't see why they should do it in this
>>>> case. Delaying a *b
On Sun, Mar 22, 2009 at 6:47 PM, Jeff Law wrote:
> Richard Kenner wrote:
>>>
>>> Of course, just I (and others) don't see why they should do it in this
>>> case. Delaying a *branch* is different from, say, using a proprietary
>>> version control or bug tracking system.
>>>
>>
>> I don't either.
On Sun, Mar 22, 2009 at 10:47 AM, Paolo Bonzini wrote:
> On Sun, Mar 22, 2009 at 15:41, Richard Kenner
> wrote:
>>> I must admit that this interpretation is quite new to me.
>>> It certainly wasn't when EGCS reunited with gcc.
>>
>> I disagree. "reuniting with GCC" means "reuniting with the FSF"
On Sun, Mar 22, 2009 at 12:29 AM, Jerry Quinn wrote:
> Ian Lance Taylor wrote:
>>
>> Jerry Quinn writes:
>>
>>
>>>
>>> 2009-03-21 Jerry Quinn
>>>
>>> * config/i386/i386.c (ix86_function_specific_save): Don't check
>>> range of enum values.
>>>
>>
>> I still don't know why I don't see this,
On Sun, Mar 22, 2009 at 1:00 AM, Joe Buck wrote:
> On Sat, Mar 21, 2009 at 07:37:10PM -0700, Daniel Berlin wrote:
>> "The steering committee was founded in 1998 with the intent of
>> preventing any particular individual, group or organization from
>> getting control ove
On Sat, Mar 21, 2009 at 8:46 PM, Mark Mitchell wrote:
> David Edelsohn wrote:
>
>> I do not believe that Mark is asserting that he and the other release
>> managers have to follow the requests of the FSF. The question is not
>> what the GCC community or the release managers *can* do, the question
On Fri, Mar 20, 2009 at 7:18 PM, Mark Mitchell wrote:
> Richard Kenner wrote:
>
>> The matters to which we defer to the FSF are any matters that they *ask*
>> us to! They own the code. If RMS, for some reason, decides that he doesn't
>> like the phrasing of a comment somewhere, we have to either
On Fri, Mar 20, 2009 at 12:09 PM, David Edelsohn wrote:
> On Fri, Mar 20, 2009 at 11:42 AM, Daniel Berlin wrote:
>
>> Okay then, as the leadership body of the GCC community, part of your
>> responsibility is keeping your constituents (the rest of us!) informed
>>
On Fri, Mar 20, 2009 at 11:17 AM, David Edelsohn wrote:
> On Fri, Mar 20, 2009 at 9:34 AM, Daniel Berlin wrote:
>> On Fri, Mar 13, 2009 at 2:28 PM, Joe Buck wrote:
>>> On Fri, Mar 13, 2009 at 10:25:34AM -0700, Richard Guenther wrote:
>>>> The topmost sentence shoul
On Fri, Mar 13, 2009 at 2:28 PM, Joe Buck wrote:
> On Fri, Mar 13, 2009 at 10:25:34AM -0700, Richard Guenther wrote:
>> The topmost sentence should be unambiguous. Yes, the SC asked us not
>> to branch.
>
> The request came from RMS, the SC just passed it on.
>
There are two things here that both
On Mon, Mar 16, 2009 at 12:11 PM, Adam Nemet wrote:
> Ramana Radhakrishnan writes:
>> [Resent because of account funnies. Apologies to those who get this twice]
>>
>> Hi,
>>
>> > > This problem is reported every once in a while, all targets with
>> > small
>> > > load-immediate instructions suffer
On Thu, Mar 12, 2009 at 11:15 AM, Mark Mitchell wrote:
> Daniel Berlin wrote:
>
>> But if it was following this and removing const qualifiers, shouldn't
>> it have remove the const from const char * too?
>> Or am i missing something?
>
> No, that is not a
On Thu, Mar 12, 2009 at 9:32 AM, Paolo Carlini wrote:
> Hi,
>> Notice how the third argument is 'int' instead of 'const int'. Is
>> this the way C++ is supposed to behave or is this a bug in the FE?
>>
> Well, I would say this is a rather well known C++ feature not a bug. It
> took me a little ti
500, Daniel Berlin wrote:
>>If you want to help admin the wiki, I am more than happy to make you a
>>super user.
>>That goes for Steven, etc.
>
> Wait. Are we talking about giving people root access on sourceware
> just to clean up a wiki? Hopefully this is not the case.
>
> cgf
>
If you want to help admin the wiki, I am more than happy to make you a
super user.
That goes for Steven, etc.
On Thu, Feb 26, 2009 at 12:31 PM, Manuel López-Ibáñez
wrote:
> 2009/2/25 Gerald Pfeifer :
>> On Tue, 24 Feb 2009, Steven Bosscher wrote:
>>> Can someone *please* ban this nutcase from t
On Fri, Jan 30, 2009 at 7:44 AM, Bingfeng Mei wrote:
> Hello,
> I try to make modulo scheduling work more efficiently for our VLIW target. I
> found one serious issue that prevents current SMS algorithm from achieving
> high IPC is so-called "transitive closure" problem, where scheduling window
On Thu, Feb 5, 2009 at 5:59 AM, Ben Elliston wrote:
> On Tue, 2009-02-03 at 01:59 -0500, Sean Callanan wrote:
>
>> Our plugins do not break when switching compiler binaries. In fact, I
>> have had plug-in binaries that perform very simple tasks work fine
>> when switching (minor!) compiler releas
17,327,572 k
:)
On Wed, Jan 21, 2009 at 8:13 PM, Paolo Carlini wrote:
> Hi,
>
> for the record, today I started an rsync to get a local copy of the
> repository and, at variance with the information in:
>
> http://gcc.gnu.org/rsync.html
>
> the size I'm seeing is already > 17G, and counting...
On Fri, Nov 21, 2008 at 2:23 PM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Michael Matz <[EMAIL PROTECTED]> writes:
>
>>> This program appears to me to be invalid according to C99 6.7.3.1,
>>> which is the only definition of restrict that we have.
>>>
>>> If P is assigned the value of a poi
On Thu, Nov 20, 2008 at 9:28 PM, Alexey Salmin <[EMAIL PROTECTED]> wrote:
> 2008/11/20 Michael Matz <[EMAIL PROTECTED]>:
>> Hi,
>>
>> On Wed, 19 Nov 2008, H.J. Lu wrote:
>>
>>> On Wed, Nov 19, 2008 at 7:18 PM, Nicholas Nethercote
>>> <[EMAIL PROTECTED]> wrote:
>>> > On Tue, 18 Nov 2008, H.J. Lu wro
On Wed, Oct 29, 2008 at 11:42 AM, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> "Daniel Berlin" <[EMAIL PROTECTED]> writes:
>
>>> A bi-weekly status report of the patch tracker sent to gcc-patches
>>> would definitively make the list of unreviewed pat
On Wed, Oct 29, 2008 at 9:16 AM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/10/29 Daniel Berlin <[EMAIL PROTECTED]>:
>> The patch tracker was an experiment in trying to see if it would
>> improve the rate of patches falling through the cracks.
>> It ha
On Tue, Oct 28, 2008 at 8:02 PM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/10/25 Daniel Berlin <[EMAIL PROTECTED]>:
>> I have placed a continuous builder (IE it does one build per svn
>> change) for GCC for x86_64 on an 8 core machine (nicely provided by
>
On Mon, Oct 27, 2008 at 5:57 PM, Peter A. Felvegi
<[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I've run today into an infinite loop when compiled a test suite w/
> optimizations. The original tests were to do some loops with all the
> nonnegative values of some integral types. Instead of hardwiring
I have placed a continuous builder (IE it does one build per svn
change) for GCC for x86_64 on an 8 core machine (nicely provided by
Google), and it has results here:
http://home.dberlin.org:8010/waterfall
(I have not made it summarize the warnings yet, and these deliberately
do not run the tests
Sure, that's why they are there.
On Thu, Oct 23, 2008 at 10:00 AM,
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> Can i make use of functions defined in "tree-data-ref.h" for data dependency
> analysis on GIMPLE trees ?
>
> Thanks.
>
>
I am still looking into this, it's on my stack of PRE weirdness :)
On Thu, Oct 16, 2008 at 11:39 AM, Steve Ellcey <[EMAIL PROTECTED]> wrote:
>
> On Thu, 2008-10-16 at 11:29 +0200, Richard Guenther wrote:
>>
>> Do we have a bug for these FAILs? Maybe we should add the analysis that
>> happened so
>
> It's a field in the class$ structure. class$ is initialized by creating a
> CONSTRUCTOR tree and calling CONSTRUCTOR_APPEND_ELT for each field. The
> DECL_INITIAL of class$ points to the CONSTRUCTOR tree.
>
> _CD_pp is an array of void*. These are initialized by DECL_INITIAL too.
>
> InitCla
On Mon, Sep 29, 2008 at 10:37 AM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> You would not want a lawyer designing a compiler, so why...
>
Oh.
I guess i'll just hang up my hat then ...
On Mon, Sep 22, 2008 at 8:48 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Richard Guenther wrote:
>
>> char and signed char (if char is signed) are the same types for the
>> middle-end (but not for the Frontend).
>
> Is that desirable? Type-based alias analysis should be able to take
> advantage
Honestly?
You should use whatever gets a response.
If you are at the point you have to ping a patch, it obviously has
fallen through the cracks, and you should do whatever is necessary to
make sure it gets attention.
To that end, I would just use new threads, as they make it clear it is
not part o
Feel free to edit the hook scripts to do this.
On Sat, Sep 6, 2008 at 1:26 PM, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Sat, 6 Sep 2008, Manuel López-Ibáñez wrote:
>
>> Well, that is a property change and it is surprising that the log
>> shows the diff of the change. Normally logs only sho
I'll commit your patch.
On Fri, Sep 5, 2008 at 12:42 PM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/9/5 Christopher Faylor <[EMAIL PROTECTED]>:
>> On Sun, Aug 17, 2008 at 03:01:03PM -0500, John Freeman wrote:
>>> Daniel Berlin wrote:
>>>
&g
It's listed on the wiki that explains how to maintain branches :)
On Sun, Aug 17, 2008 at 2:32 PM, John Freeman <[EMAIL PROTECTED]> wrote:
> Christopher Faylor wrote:
>>
>> On Sat, Aug 16, 2008 at 02:35:08PM +0200, Manuel L?pez-Ib??ez wrote:
>>
>>>
>>> Dear GCC devs,
>>>
>>> Please do *not* use t
On Fri, Aug 15, 2008 at 11:31 AM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/8/15 Daniel Berlin <[EMAIL PROTECTED]>:
>> On Fri, Aug 15, 2008 at 10:58 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
>>> On Fri, Aug 15, 2008 at 8:06 AM, Manuel López-
On Fri, Aug 15, 2008 at 10:58 AM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Fri, Aug 15, 2008 at 8:06 AM, Manuel López-Ibáñez
> <[EMAIL PROTECTED]> wrote:
>> 2008/8/14 Daniel Berlin <[EMAIL PROTECTED]>:
>>> 1. You can't assume VUSE's are mus
On Fri, Aug 15, 2008 at 8:06 AM, Manuel López-Ibáñez
<[EMAIL PROTECTED]> wrote:
> 2008/8/14 Daniel Berlin <[EMAIL PROTECTED]>:
>> 1. You can't assume VUSE's are must-aliases. The fact that there is a
>> vuse for something does not imply it is must-used, it i
1. You can't assume VUSE's are must-aliases. The fact that there is a
vuse for something does not imply it is must-used, it implies it is
may-used.
We do not differentiate may-use from must-use in our alias system. You
can do some trivial must-use analysis if you like (by computing
cardinality of
Failure:
../../../libgfortran/intrinsics/cshift0.c: In function 'cshift0':
../../../libgfortran/intrinsics/cshift0.c:124: warning: passing
argument 1 of 'cshift0_i16' from incompatible pointer type
../../../libgfortran/intrinsics/cshift0.c:236: error: 'GFC_INTGER_16'
undeclared (first use in this
On Mon, Aug 4, 2008 at 6:19 AM, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Mon, 4 Aug 2008, Ralf Wildenhues wrote:
>
>> * Joseph S. Myers wrote on Sun, Aug 03, 2008 at 10:00:38PM CEST:
>> >
>> > (But the configure code also
>> > shouldn't allow configuring with a GPLv2 version of polylib.)
>>
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 u
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!
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
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 t
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
>
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.
>>
>>
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 -
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 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
The easiest way to not delete trunk is to not delete trunk.
On Thu, Jul 24, 2008 at 10:06 AM, Peter Bergner <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-07-24 at 18:48 +0200, Andreas Schwab wrote:
>> Definitely something fishy around that time. svn log says:
>>
>> --
Patches welcome :)
On Tue, Jul 22, 2008 at 3:55 AM, Andreas Schwab <[EMAIL PROTECTED]> wrote:
> "Dave Korn" <[EMAIL PROTECTED]> writes:
>
>> It's pretty obvious the moment you read the content of any of the posts
>> that it can't be cvs and has to be svn, even more so if you follow one of
>> the
On Mon, Jul 14, 2008 at 5:22 PM, Diego Novillo <[EMAIL PROTECTED]> wrote:
> We are failing to build libjava on PPC64 because of this:
>
> /home/dnovillo/perf/sbox/tuples/local.ppc64/bld/./gcc/xgcc -shared
> -libgcc -B/home/dnovillo/perf/sbox/tuples/local.ppc64/bld/./gcc
> -nostdinc++ -L/home/d
> no
On Sun, Jul 13, 2008 at 6:29 AM, Andi Kleen <[EMAIL PROTECTED]> wrote:
> Nils Pipenbrinck <[EMAIL PROTECTED]> writes:
>
>> Since the codebase is huge I have the feeling that I have overlooked
>> something. Does some kind of infrastructure to detect patterns within
>> a SSA tree already exists somew
Okay, i isolated the problem (we are folding based on the wrong type
for constants, so we have a case where 1 << 63 becomes 0 instead of a
very large value).
Working on a patch now.
On Fri, Jul 11, 2008 at 1:56 PM, Daniel Berlin <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 11, 2008 at
On Fri, Jul 11, 2008 at 1:17 PM, Paolo Carlini <[EMAIL PROTECTED]> wrote:
> Hi,
>>
>> This is likely to have been my patch.
>> I'm minimizing the check_construct_destroy failure right now.
>> If someone could give me some idea of what is causing the execution
>> failures while i do that, i may be a
This is likely to have been my patch.
I'm minimizing the check_construct_destroy failure right now.
If someone could give me some idea of what is causing the execution
failures while i do that, i may be able to fix them faster :)
On Wed, Jul 9, 2008 at 10:31 AM, Paolo Carlini <[EMAIL PROTECTED]> w
It's only "official" in that it lives on gcc.gnu.org.
It is maintained only by one person, not by the gcc project.
On Sun, Jul 6, 2008 at 2:31 PM, Nix <[EMAIL PROTECTED]> wrote:
> On 6 Jul 2008, Daniel Berlin spake thusly:
>
>> gcc.gnu.org/git/gcc.git tracks all
gcc.gnu.org/git/gcc.git tracks all branches.
Just remember to tell it to fetch all remote refs (since git-svn
branches are done as remotes)
On Sun, Jul 6, 2008 at 11:51 AM, Nix <[EMAIL PROTECTED]> wrote:
> [David, my fallible memory says that you operate this incredibly useful
> service: if not,
On Wed, Jul 2, 2008 at 2:30 PM, Hendrik Boom <[EMAIL PROTECTED]> wrote:
> On Wed, 25 Jun 2008 20:11:56 -0700, Ian Lance Taylor wrote:
>
>> Ivan Levashew <[EMAIL PROTECTED]> writes:
>>
Your comment makes little sense in context. Nobody could claim that
the existing gengtype code is simple
Maybe at some point then we should just stop using gengtype and just
hand-write the walkers once.
One of the reasons gengtype exists is because you can't easily have an
abstract interface with member functions that you can force people to
implement in C.
In C++, we can.
This is of course, a larg
1 - 100 of 1072 matches
Mail list logo
