On Sun, 2006-01-15 at 18:35 -0500, Daniel Berlin wrote:
> On Mon, 2006-01-16 at 00:24 +0100, Richard Guenther wrote:
> > On Sun, 15 Jan 2006, Daniel Berlin wrote:
> >
> > > On Sun, 2006-01-15 at 22:24 +0100, Tobias Schlüter wrote:
> > > > Richard Guenther wro
> I see that. I'm testing the following fix to address the fortran
> regressions. The observation is that the fortran FE uses structures
> to pass (lots of) arguments to I/O functions, and uses array descriptors
> for passing arrays, which are handled similarly. Now those structures
> are only _
Just so you guys know, a change in 1.3 will make large commits take a
longer than they used to.
We background the task that sends out the mail, and in 1.2, this used to
cause the post-commit hook that runs to return immediately.
However, 1.3, in order to catch output from the post-commit hooks, n
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
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,
>
>
> 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
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
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:
>
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
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 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
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
>
> 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 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
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
> 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
>
> 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
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
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 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
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
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 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 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 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 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
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 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
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
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
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
>
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
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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
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 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
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, 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
>
> 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 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
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 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 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 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 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 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 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,
>
> 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
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
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
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
On Fri, 2006-01-20 at 10:53 +0530, Ranjit Mathew wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> Mainline fails to bootstrap for me (revision 110017)
> on i686-pc-linux-gnu.
>
> Configured as:
>
> $GCC_SRC_DIR/configure --prefix=$HOME/gcc --enable-languages=c,c++,java \
>
On Fri, 2006-01-20 at 12:34 +0100, Andreas Jaeger wrote:
> The tree is still broken for me. Daniel, did you commit your patch?
No, because i realized last night that you will just hit the rest of the
problem during bootstrap, without fail.
>
> Andreas
On Fri, 2006-01-20 at 16:06 +0100, Zdenek Dvorak wrote:
> Hello,
>
> > >>>The attached fixes *that*, but this just causes a crash deeper in trying
> > >>>to free some chains.
> > >>>
> > >>[...]
> > >>Sorry for the problems and thanks for looking into them.
> > >>
> > >
> > >Ken, please
On Sat, 2006-01-21 at 15:33 +0100, Jan Hubicka wrote:
> > One way to avoid this restriction would be to extend RTL alias
> > analysis to not be strictly type based. In particular, we could
> > extend it to know that a particular stack slot has a range of alias
> > sets. And we would then have to
On Thu, 2006-01-26 at 11:20 +0100, Bernd Schmidt wrote:
> Joern RENNECKE wrote:
> > For easier reviewing, I have attached the diff to the cfgcleanup version
> > previous to the patch backout.
>
> Thanks. Let me see if I understood the problem - please correct me if I
> describe anything incorre
H. J. Lu wrote:
> I got
>
> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c: In function
> `df_record_entry_block_defs':
> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c:1753: error:
> `INCOMING_RETURN_ADDR_RTX' undeclared (first use in this function)
> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df
H. J. Lu wrote:
> On Fri, Jan 27, 2006 at 06:20:41PM -0500, Daniel Berlin wrote:
>> H. J. Lu wrote:
>>> I got
>>>
>>> /net/gnu-13/export/gnu/src/gcc/gcc/gcc/df-scan.c: In function
>>> `df_record_entry_block_defs':
>>> /
I have fixed the svn-mailer bug that would cause large diffs of
configure, et al to be sent to both gcc-cvs, and bug reports, when a
property changed.
Sorry bout that.
(I also fixed the bug that caused it to send these things to a large
number of bug reports. Regexp was a little too loose).
I was staring at the comment database, and noticed
mysql> select COUNT(*) from longdescs where length(thetext) > 10;
+--+
| COUNT(*) |
+--+
| 271 |
+--+
1 row in set (0.48 sec)
mysql> select COUNT(*) from longdescs where length(thetext) > 50;
+--+
| CO
Dave Korn wrote:
> On 01 February 2006 05:43, Daniel Berlin wrote:
>
>> I was staring at the comment database, and noticed
>
>> I can't imagine *any* of these comments are useful to human beings to
>> read.
>
> Did you browse a few? I'm curious, my
So it looks like the addition of reading ldblspecs causes crashes
because it's reading from unallocated memory.
(i found this because bootstrap on dataflow branch fails on ppc64 with
this crash).
I can't trigger it with -save-temps, sadly.
According to valgrind on ppc (3.1.0 from developer.valgr
Mike Stump wrote:
> When bulk merging trunk to local release branch, svn reports whole file
> conflicts as 'A'. :-(
>
If you can give me a way to reproduce it, i can fix it.
I've never seen such behavior. AFAIK, all conflicts should be flagged as
C, whole file or not.
On Wed, 2006-02-08 at 12:28 -0500, Andrew Pinski wrote:
> >
> > I've build in a unified (symlink) tree, with sourceware stuff checked
> > out via cvs from date/time D2006.02.07.17.00.00
>
> I am reducing this failure and will file a bug report.
>
This failure is actually a latent bug elsewhere
> ssh to access the GCC tree. Is that correct? So how does he or she do
> > a checkout if the above method doesn't work due to a firewall? Are they
> > just out of luck?
>
> I'm in the same situation at work, which is why gcc-testresults no
> longer gets d
On Thu, 2006-02-09 at 15:55 -0800, Joe Buck wrote:
> On Thu, Feb 09, 2006 at 06:48:40PM -0500, Daniel Berlin wrote:
> > Errr, I emailed you privately a few months ago saying i had set up http
> > access :)
>
> I recall that you mailed me saying that you were *going* to do
On Thu, 2006-02-09 at 15:58 -0800, Steve Ellcey wrote:
> svn co http://gcc.gnu.org/svn/gcc/trunk
You must have a transparent proxy or something that doesn't proxy webdav
requests properly (i tried this from all the hosts i have access to, and
it works fine)
On Mon, 2006-02-13 at 11:48 +0900, Arquimedes Canedo wrote:
> Dear developers,
>
> I am trying to get all global declarations in GIMPLE level just
> before RTL expansion. I have tried to copy the scope instead of
> pop_scope() to catch the global declarations in the way
> c_write_global_decl
On Sun, 2006-02-19 at 09:56 -0500, Kenneth Zadeck wrote:
> Steven, Zdenek
>
> 1) single_set is built on top of single_set2.
Yes
> 2) single_set_2 uses REG_UNUSED notes.
Only if there are multiple sets.
> 3) tree-ssa-loop-ivops.c:seq_cost uses single_set.
This is because Zdenek builds RTL to dete
(steven, you spent a fair amount of time in gcse.c, which is why i've
copied you to see if you knew what was up)
In record_mem_last_set_info, we have
if (CALL_P (insn))
{
/* Note that traversals of this loop (other than for free-ing)
will break after encountering a CALL_INSN.
On Fri, 2006-02-24 at 15:48 +0100, Sebastian Pop wrote:
> Jeffrey A Law wrote:
> >
> > Note how the conversions have been lost.
> >
>
> This is a bug in chrec_convert_aggressive.
>
> The following patch fixes the problem in a quite drastic way,
> disabling the analysis of ivs that contain casts
On Wed, 2006-03-01 at 05:31 +0100, Zdenek Dvorak wrote:
> Hello,
>
> during a recent discussion, it was pointed to my attention that
> update_stmt is performance critical. I wondered why; this is the number
> of update_stmt calls for combine.i (all the other passes have less then
> 1000 calls):
>
On Wed, 2006-03-08 at 15:05 -0500, Andrew Pinski wrote:
> I notice in your PDF, you have:
> Since alias analysis results are often conservative, may-alias sets my
> contain tens
> and enve hundreds of symbols.
>
> Is there a reason why not tune the aliasing anaysis to return more liberal
> resul
> > * Maybe it would be possible to perform further development on a vendor
> > branch in the GCC svn repository? I'm not sure if this would require SC
> > buy-in, though. Perhaps the changes might become acceptible for FSF GCC
> > at some point in time; there have been discussions over at
On Fri, 2006-03-10 at 14:06 -0800, Alexey Starovoytov wrote:
> On Fri, 10 Mar 2006, Andrew Pinski wrote:
>
> >
> > On Mar 10, 2006, at 3:34 PM, Alexey Starovoytov wrote:
> >
> > > Few major infrastructure features needs to be done first.
> >
> > Like? Please give examples. If link time optimizat
On Fri, 2006-03-10 at 12:34 -0800, Alexey Starovoytov wrote:
> On Fri, 10 Mar 2006, David Edelsohn wrote:
>
> > > Alexey Starovoytov writes:
> >
> > > If Sun starts improving GCC backend now it will never be able to catch up
> > > with Sun's own backend.
> >
> > This is a completely ridicu
On Mon, 2006-03-13 at 16:25 -0700, Tom Tromey wrote:
> > "Mike" == Mike Mattie <[EMAIL PROTECTED]> writes:
>
> Mike> Has anyone ever tried to build a scripting interface into the guts of
> Mike> GCC with something like SWIG ?
>
> I've heard of a couple efforts along these lines -- once with S
On Tue, 2006-03-21 at 17:30 -0500, Andrew MacLeod wrote:
> On Tue, 2006-03-21 at 10:10 +0100, Richard Guenther wrote:
> > On 3/21/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > > On Mon, 2006-03-20 at 18:55 -0500, Andrew Pinski wrote:
> > > > On Mar 20, 2006, at 5:18 PM, Andrew MacLeod wrote:
>
> Maybe someone can have a look at the attribute((pointer_no_escape))
> patch I posted a while ago. With some IPA machinery we could possibly
> trim down the clobber lists quite a bit.
>
Well, let me confirm first that he is right. This requires a cpgram.ii
that compiles (none of the attachmen
On Tue, 2006-03-21 at 22:16 -0500, Andrew MacLeod wrote:
> On Tue, 2006-03-21 at 17:42 -0500, Daniel Berlin wrote:
> > On Tue, 2006-03-21 at 17:30 -0500, Andrew MacLeod wrote:
> > > On T
> > > I seem to have narrowed it down to this patch:
> > >
> > &
On Tue, 2006-03-21 at 22:13 -0500, Andrew MacLeod wrote:
> On Tue, 2006-03-21 at 18:00 -0500, Daniel Berlin wrote:
> > > Maybe someone can have a look at the attribute((pointer_no_escape))
> > > patch I posted a while ago. With some IPA machinery we could possibly
> &
> >
> > I used the attached one with -fpermissive
>
>
> Thanks, i'm looking into it now.
>
So the alias analysis time increase *is* the result of moving the
is_global_var check out of is_call_clobbered. This is easy to fix, i'll
have a patch in a few hours.
However, there is worse news, AFAI
On Mon, 2006-03-27 at 03:32 +0200, Gabriel Dos Reis wrote:
> "cvs-commit at developer dot classpath dot org" <[EMAIL PROTECTED]> writes:
>
> | --- Comment #7 from cvs-commit at developer dot classpath dot org
> 2006-03-20 20:03 ---
> | Subject: Bug 11070
> |
> | CVSROOT:/cvsroot
601 - 700 of 1072 matches
Mail list logo
