gcc-ow...@gcc.gnu.org wrote on 30/05/2011 06:36:36 PM:
>
> Hi,
>
> I've been playing with the vectorizer for my port, and of course I use
> the testsuite to check the generated code. I fail to understand some
> of the FAILs I get. For example, in slp-3.c, the test contains:
>
> /* { dg-final { s
Matthias Kretz writes:
> Richard and Jonathan don't like it - or doubt its effectiveness.
>
> Ian supports the idea. Jakub and Nathan mentioned that they already do
> something like it, so can I count that as "like"? :)
>
> Should I write a patch or not? How are the chances that it gets accepted
On Mon, 30 May 2011 16:19:31 -0400
Diego Novillo wrote:
> On Mon, May 30, 2011 at 13:44, Basile Starynkevitch
> wrote:
>
> > Diego and other people interested in plugins, what do you think of such
> > a proposal?
>
> I don't think that would work. Plugins need to know at what level
> they are
On Mon, 30 May 2011 22:15:29 +0200
Richard Guenther wrote:
> On Mon, May 30, 2011 at 7:44 PM, Basile Starynkevitch
> wrote:
> > On Mon, 30 May 2011 17:58:48 +0200
> > Richard Guenther wrote:
> >
> >> You can't use language specific functions form a plugin that should be
> >> usable at link time
On Mon, May 30, 2011 at 13:44, Basile Starynkevitch
wrote:
> Diego and other people interested in plugins, what do you think of such
> a proposal?
I don't think that would work. Plugins need to know at what level
they are working. FE plugins would have access to functions and data
that gimple
On Mon, May 30, 2011 at 9:16 PM, Diego Novillo wrote:
> The new routines lto_output_int_in_range and lto_input_int_in_range do
> not seem to be working right. In the pph branch, we have an LTO_tags
> enum with a range [0 - 351]. This is causing two things:
>
> - The writer gets out of sync with
On Mon, May 30, 2011 at 7:44 PM, Basile Starynkevitch
wrote:
> On Mon, 30 May 2011 17:58:48 +0200
> Richard Guenther wrote:
>
>> On Mon, May 30, 2011 at 5:53 PM, Pierre Vittet wrote:
>> > Hello,
>> >
>> > I try to use the plugin pragma-plugin.c which is given in the testsuite
>> > (gcc/testsuite
On Mon, 30 May 2011 15:16:16 -0400
Diego Novillo wrote:
[...]
>
> lto_output_int_in_range(...)
> [ ... ]
> 1322 val -= min;
> 1323 lto_output_1_stream (obs, val & 255);
> 1324 if (range >= 0xff)
> 1325lto_output_1_stream (obs, (val << 8) & 255);
> 1326 if (range >= 0xf
The new routines lto_output_int_in_range and lto_input_int_in_range do
not seem to be working right. In the pph branch, we have an LTO_tags
enum with a range [0 - 351]. This is causing two things:
- The writer gets out of sync with the reader because, we emit
delimiters with output_zero. This w
On Mon, 30 May 2011 17:58:48 +0200
Richard Guenther wrote:
> On Mon, May 30, 2011 at 5:53 PM, Pierre Vittet wrote:
> > Hello,
> >
> > I try to use the plugin pragma-plugin.c which is given in the testsuite
> > (gcc/testsuite/g++.dg/plugin/pragma_plugin.c), I have compiled it as a
> > shared libr
Workshop on Essential Abstractions in GCC, 2011
(http://www.cse.iitb.ac.in/grc/gcc-workshop-11)
---
Organized by: GCC Resource Center (http://www.cse.iitb.ac.in/grc).
Venue:Department of Computer Science and Enginee
On Mon, May 30, 2011 at 5:53 PM, Pierre Vittet wrote:
> Hello,
>
> I try to use the plugin pragma-plugin.c which is given in the testsuite
> (gcc/testsuite/g++.dg/plugin/pragma_plugin.c), I have compiled it as a
> shared library.
>
> If I try it on a simple c file it works, however, if I use -flto
Hello,
I try to use the plugin pragma-plugin.c which is given in the testsuite
(gcc/testsuite/g++.dg/plugin/pragma_plugin.c), I have compiled it as a
shared library.
If I try it on a simple c file it works, however, if I use -flto it
causes an error:
gcc -fplugin=./pragma_plugin.so -flto t
Hi,
I've been playing with the vectorizer for my port, and of course I use
the testsuite to check the generated code. I fail to understand some
of the FAILs I get. For example, in slp-3.c, the test contains:
/* { dg-final { scan-tree-dump-times "vectorized 3 loops" 1 "vect" {
xfail vect_no_align
I noticed that gcc 4.7 implements the c++0x "final keyword" and jumped to
test it.
I'm hoping that eventually the keyword will be used to trigger
"devirtualization optimization"
for instance in this example I expect "geta" and "getb" to be compiled in th
every same object code
struct A {
vi
Hi,
On Thursday 26 May 2011 12:06:18 Matthias Kretz wrote:
> if you like the idea
Richard and Jonathan don't like it - or doubt its effectiveness.
Ian supports the idea. Jakub and Nathan mentioned that they already do
something like it, so can I count that as "like"? :)
Should I write a patch
On 05/30/2011 12:10 PM, Robert Beeporbop wrote:
I have some questions for the gcc developers:
Also, I had a couple other general development questions:
~ Has anyone been working on GPU support, automatically-utilized or
otherwise?
I have not used it - nor have I seen much documentation, bu
--- On Mon, 5/30/11, Richard Guenther wrote:
> On Mon, May 30, 2011 at 1:14 PM,
> Robert Beeporbop
> wrote:
> > Thank you for the information!
> >
> > So it sounds like right now, I could use 4.6.0
> (4.7.0?), and be architecture-independent between processors
> of the same type. Like, code coul
On Mon, May 30, 2011 at 1:14 PM, Robert Beeporbop wrote:
> Thank you for the information!
>
> So it sounds like right now, I could use 4.6.0 (4.7.0?), and be
> architecture-independent between processors of the same type. Like, code
> could be compiled to GIMPLE with no optimization for generic
Thank you for the information!
So it sounds like right now, I could use 4.6.0 (4.7.0?), and be
architecture-independent between processors of the same type. Like, code could
be compiled to GIMPLE with no optimization for generic x86, then optimized and
linked differently depending on the target
On Mon, May 30, 2011 at 12:10 PM, Robert Beeporbop wrote:
> Thanks to all the gcc developers!
>
> I am working on a Linux distribution which compiles all binaries statically
> at run-time with WHOPR. I hope to:
>
> = Have everything running insanely fast. I did some testing with a couple
> prog
Thanks to all the gcc developers!
I am working on a Linux distribution which compiles all binaries statically at
run-time with WHOPR. I hope to:
= Have everything running insanely fast. I did some testing with a couple
programs using gcc 4.5 with WHOPR and other new optimizations, and compare
22 matches
Mail list logo
