On 07/11/2011 07:56 PM, David Malcolm wrote:
Hope this is fun/helpful (and that I'm correctly interpreting the data!)
You are, and it shows some bugs even. gimple_lcx is obviously destroyed
by expand, and I find it unlikely that no pass ever introduces a
critical edge...
Paolo
On 07/12/2011 08:54 AM, Arnaud Charlet wrote:
>> I'm not sure because I don't think we want to compile the C files of the Ada
>> > runtime with the C++ compiler. We want to do that only for the compiler.
>
> Right, we definitely don't want to use the C++ compiler for building the
> Ada run-time.
I have a test program written in UPC that takes a long time to compile
on Mac OS X. This is caused by the var_tracking code that I think is
getting erroneously enabled for no-optimization case - only "-g" option
is used on a command line.
When process_options (in toplevel.c) is called, flag_va
> Right, we definitely don't want to use the C++ compiler for building the
> Ada run-time.
OK, so the only needed Makefile change is to gcc-interface/Make-lang.in:
Index: ada/gcc-interface/Make-lang.in
===
--- ada/gcc-interface/Make-
> Perhaps it is better to always build those files with cc, perhaps not.
> Since there are two versions of the Ada RTL, the one in the compiler and
> the one in libada, my questions are:
>
> 1) Do they share any object files when not cross-compiling?
>
> 2) If not, is using C++ for the former okay?
> But apparently they already are (when building the compiler), otherwise
That's different: some parts of the run-time is used with a native compiler to
bootstrap GNAT.
The GNAT run-time is built separately using the target compiler (potentially
different from the native compiler), so bootstrappi
On 07/12/2011 10:00 AM, Eric Botcazou wrote:
But your patch isn't necessary to do that, the C files are already compiled
with the C++ compiler as of today; the only issue is at the linking stage.
The problem is that the patches links gnattools unconditionally with
g++. It should depend on --e
> The problem is that the patches links gnattools unconditionally with
> g++. It should depend on --enable-build-with-cxx instead.
Yes, that part was wrong, it will be dropped, we don't want to use g++ here.
--
Eric Botcazou
On 12/07/11 08:22, Paolo Bonzini wrote:
On 07/11/2011 07:56 PM, David Malcolm wrote:
Hope this is fun/helpful (and that I'm correctly interpreting the data!)
You are, and it shows some bugs even. gimple_lcx is obviously destroyed
by expand, and I find it unlikely that no pass ever introduces a
On Jul 12, 2011, at 2:54 AM, Arnaud Charlet wrote:
>> I'm not sure because I don't think we want to compile the C files of the Ada
>> runtime with the C++ compiler. We want to do that only for the compiler.
>
> Right, we definitely don't want to use the C++ compiler for building the
> Ada run-t
> Why not? If extern "C" is used correctly, the result will work just the same,
> and the improved type checking etc. would be an asset here just as it is
> elsewhere.
We don't use much C code, so the extra benefits wouldn't really be useful
to us (we already get much more benefits by having most
On Jul 12, 2011, at 6:56 AM, Arnaud Charlet wrote:
>> Why not? If extern "C" is used correctly, the result will work just the
>> same,
>> and the improved type checking etc. would be an asset here just as it is
>> elsewhere.
>
> We don't use much C code, so the extra benefits wouldn't really b
Not familiar with combine inerts, I'd like to know if
it's low hanging fruit to teach insn combine to perform
optimizations like the following.
Suppose following C code, int = HI
int y15;
int x15;
void qmul8_xy (char c, int x, int y)
{
y15 = y * c;
x15 = x * c;
}
and that the target has
On 07/12/11 13:11, Georg-Johann Lay wrote:
> Not familiar with combine inerts, I'd like to know if
> it's low hanging fruit to teach insn combine to perform
> optimizations like the following.
>
> Suppose following C code, int = HI
>
> int y15;
> int x15;
>
> void qmul8_xy (char c, int x, int y)
Bernd Schmidt wrote:
> On 07/12/11 13:11, Georg-Johann Lay wrote:
>> Not familiar with combine inerts, I'd like to know if
>> it's low hanging fruit to teach insn combine to perform
>> optimizations like the following.
>>
>> Suppose following C code, int = HI
>>
>> int y15;
>> int x15;
>>
>> void q
On 07/12/2011 02:22 AM, Paolo Bonzini wrote:
On 07/11/2011 07:56 PM, David Malcolm wrote:
Hope this is fun/helpful (and that I'm correctly interpreting the data!)
You are, and it shows some bugs even. gimple_lcx is obviously destroyed
by expand, and I find it unlikely that no pass ever introdu
We discussed this briefly at the recent London meetings. If anyone is
interested in participating, please contact me.
Diego.
Original Message
Subject:Google Summer of Code 2011 Doc Camp 17 October - 21 October
Date: Mon, 11 Jul 2011 17:41:02 -0700
From: Carol S
On 07/12/2011 10:43 AM, Paulo J. Matos wrote:
Hope this is fun/helpful (and that I'm correctly interpreting the data!)
You are, and it shows some bugs even. gimple_lcx is obviously destroyed
by expand, and I find it unlikely that no pass ever introduces a
critical edge...
But the diagram s
On 12/07/11 17:04, Paolo Bonzini wrote:
It shows bugs in GCC's pass description, to be clear.
Paolo
That makes sense.
--
PMatos
On Tue, 2011-07-12 at 09:43 +0100, Paulo J. Matos wrote:
> On 12/07/11 08:22, Paolo Bonzini wrote:
> > On 07/11/2011 07:56 PM, David Malcolm wrote:
> >> Hope this is fun/helpful (and that I'm correctly interpreting the data!)
> >
> > You are, and it shows some bugs even. gimple_lcx is obviously des
FYI. If you just want text dump of gcc passes and their on|off
settings, option -fdump-passes can be used. This can be enhanced to
dump properties and TODOs.
David
On Tue, Jul 12, 2011 at 9:07 AM, David Malcolm wrote:
> On Tue, 2011-07-12 at 09:43 +0100, Paulo J. Matos wrote:
>> On 12/07/11 08:2
On Tue, 2011-07-12 at 11:43 +0800, Mingjie Xing wrote:
> 2011/7/12 David Malcolm :
> > For fun over the weekend I wrote a python script (using my
> > gcc-python-plugin[1]) to render an SVG diagram of GCC's optimization
> > passes (or, at least, based on my understanding of them).
> >
> > This diagr
On 12 July 2011 16:07, Diego Novillo wrote:
>
> We discussed this briefly at the recent London meetings. If anyone is
> interested in participating, please contact me.
>
>
> Diego.
>
> Original Message
> Subject: Google Summer of Code 2011 Doc Camp 17 October - 21 October
On 10 July 2011 22:42, ismail kuru wrote:
> Hi all,
> I am one of GSOC students. We have started the project with doing some
> experiments for checking the compatibility of
> OpenMP threads with [trans-mem] branch of GCC.
> We made a presentation
> (http://www.gsd.inesc-id.pt/~mcouceiro/eurotm/1s
On 11-07-12 12:52 , Philip Herron wrote:
Would Gcc internals documentation count or is it more for a whole
project documentation work? I probably missed the thing about this in
London since i had to leave on the Sunday morning.
I am kind of interested but i am unsure what kind of documentation
On Tue, 2011-07-12 at 09:15 -0700, Xinliang David Li wrote:
> FYI. If you just want text dump of gcc passes and their on|off
> settings, option -fdump-passes can be used. This can be enhanced to
> dump properties and TODOs.
Thanks!
I got a bit mystified by:
$ gcc -fdump-passes test.c
cc1: e
On Tue, Jul 12, 2011 at 10:55 AM, David Malcolm wrote:
> On Tue, 2011-07-12 at 09:15 -0700, Xinliang David Li wrote:
>> FYI. If you just want text dump of gcc passes and their on|off
>> settings, option -fdump-passes can be used. This can be enhanced to
>> dump properties and TODOs.
>
> Thanks!
>
On Tue, 2011-07-12 at 08:34 -0500, Joel Sherrill wrote:
> On 07/12/2011 02:22 AM, Paolo Bonzini wrote:
> > On 07/11/2011 07:56 PM, David Malcolm wrote:
> >> Hope this is fun/helpful (and that I'm correctly interpreting the data!)
> > You are, and it shows some bugs even. gimple_lcx is obviously de
> "David" == David Malcolm writes:
David> This would be good. However, looking at, say,
David> http://gcc.gnu.org/onlinedocs/gccint/Tree-SSA-passes.html#Tree-SSA-passes
David> I don't see meaningful per-pass anchors there. I'm not familiar with
David> gcc's documentation toolchain; is ther
On Mon, Jul 11, 2011 at 12:38:34PM +0200, Georg-Johann Lay wrote:
> How do I write a pre-reload combine + pre-reload split correctly?
> I'd like to avoid clobber reg.
>
> Thanks much for any hint.
The move patterns are always kind of funny, particularly during register
allocation.
Lets see given
Snapshot gcc-4.4-20110712 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110712/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
31 matches
Mail list logo
