found the cause, sorry to disturb, please ignore this message.
--
Best Regards.
On Apr 5, 2010, Jeff Law wrote:
> On 04/05/10 14:32, Alexandre Oliva wrote:
>> 2. When renaming references from P to P' in a region, do take debug
>> insns in the region into account, renaming references in debug insns as
>> you would in any other insn.
> OK. So presumably the 2nd argument in
On Tue, 6 Apr 2010, Jack Howarth wrote:
> On Tue, Apr 06, 2010 at 03:45:27PM +0200, Richard Guenther wrote:
> >
> > A GCC 4.5.0 release candidate is available at:
> >
> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.0-RC-20100406/
> >
> > Please test the tarballs and report any problems to Bugzilla.
Hi,
Are there any known methodologies/tools/flows that enable operations
research on the compiler generated assembly?
The reasoning behind the question is that compiler heuristics
complexity are restricted by compilation time, while test environment
can run for a long time taking into account bot
On 07/04/2010 12:29, roy rosen wrote:
> Hi,
>
> Are there any known methodologies/tools/flows that enable operations
> research on the compiler generated assembly?
Something like MILEPOST+ICI? An automated machine learning version of gcc:
http://ctuning.org/wiki/index.php/CTools:MilepostGCC
h
Thanks Dave,
I'll have a look at these.
Roy.
2010/4/7, Dave Korn :
> On 07/04/2010 12:29, roy rosen wrote:
> > Hi,
> >
> > Are there any known methodologies/tools/flows that enable operations
> > research on the compiler generated assembly?
>
> Something like MILEPOST+ICI? An automated machine
Now that GCC 4.5 has been branched from the main line,
it seems that this is an appropriate time to consider
GUPC for inclusion into the GCC trunk.
GUPC was recently checked in as a GCC branch:
http://gcc.gnu.org/projects/gupc.html
What is the recommended process for having GUPC reviewed
(and hop
On Wed, Apr 7, 2010 at 11:05, Gary Funck wrote:
> What is the recommended process for having GUPC reviewed
> (and hopefully, subsequently approved) for being merged
> into the GCC mainline?
I would suggest splitting patches across reviewer domains. See
previous merges from big branches for exam
On 04/07/10 11:11:05, Diego Novillo wrote:
> I would suggest splitting patches across reviewer domains. See
> previous merges from big branches for examples. This makes it easier
> for maintainers and reviewers to review the relevant parts.
> Additionally, make sure that the branch bootstraps and
On Wed, 2010-04-07 15:05:09 +0800, Amker.Cheng wrote:
> found the cause, sorry to disturb, please ignore this message.
It would, however, be nice if you actually posted an answer to your
(now solved) question. That way, any casual reader may learn something
new.
MfG, JBG
--
Jan-Benedict
Hi Uros and Richard,
I was rewriting the Alpha sched_find_first_bit implementation for the
Linux Kernel, and in the process I think I've come across a gcc bug.
I rewrote the function using cmov instructions, and wrote a small
program to test its correctness and performance. I wrote the function
in
On 4/7/2010 9:17 AM, Gary Funck wrote:
On 04/07/10 11:11:05, Diego Novillo wrote:
Additionally, make sure that the branch bootstraps and tests on all
primary/secondary platforms with all languages enabled.
Diego, thanks for your prompt reply and suggestions. Regarding
the primary/sec
On Wed, 2010-04-07 at 09:17 -0700, Gary Funck wrote:
> On 04/07/10 11:11:05, Diego Novillo wrote:
> > I would suggest splitting patches across reviewer domains. See
> > previous merges from big branches for examples. This makes it easier
> > for maintainers and reviewers to review the relevant pa
Has anyone else seen this error from trunk?
$ svn status
svn: Error at entry 15 in entries file for 'gcc/testsuite/g++.dg/warn':
svn: Bogus date
Even if I delete the gcc/testsuite/g++.dg/warn tree, an update brings
the error back.
svn is 1.6.9.
--
Andrew :-)
Free Java Software Engineer
Red Hat
2010/4/6, Jim Wilson :
> On 04/06/2010 02:24 AM, roy rosen wrote:
> > (insn 33 32 34 7 a.c:25 (set (subreg:V2HI (reg:V4HI 114) 0)
> > (plus:V2HI (subreg:V2HI (reg:V4HI 112) 0)
> > (subreg:V2HI (reg:V4HI 113) 0))) 118 {addv2hi3} (nil))
> >
>
> Only subregs are decomposed. So use
On Wed, Apr 7, 2010 at 8:38 PM, Matt Turner wrote:
> I was rewriting the Alpha sched_find_first_bit implementation for the
> Linux Kernel, and in the process I think I've come across a gcc bug.
[...]
> Thanks. Let me know what I can do to help further.
Please fill a Bugzilla bugreport with you
16 matches
Mail list logo