> 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 o
On Mon, May 30, 2011 at 10:50 PM, Basile Starynkevitch
wrote:
> 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 languag
On Mon, May 30, 2011 at 11:18 PM, Basile Starynkevitch
wrote:
> 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 do
Hi Ira,
thanks for your answer, however:
On 31 May 2011 08:06, Ira Rosen wrote:
>> This test fails for me because I get 4 vectorized loops instead of 3.
>> There are multiple other tests that generate more vectorization then
>> expected. I'd like to understand the reason for these failures, but
Frederic Riss wrote on 31/05/2011 12:34:35 PM:
> Hi Ira,
>
> thanks for your answer, however:
>
> On 31 May 2011 08:06, Ira Rosen wrote:
> >> This test fails for me because I get 4 vectorized loops instead of 3.
> >> There are multiple other tests that generate more vectorization then
> >> exp
--- On Mon, 5/30/11, Tobias Burnus wrote:
> From: Tobias Burnus
> Subject: Re: GCC on GPU - graphite OpenCL (was: WHOPR Linux distribution)
> To: "Robert Beeporbop"
> Cc: gcc@gcc.gnu.org, "Sebastian Pop"
> Date: Monday, May 30, 2011, 5:11 AM
> On 05/30/2011 12:10 PM, Robert
> Beeporbop wrote:
On Tue, 31 May 2011 10:52:39 +0200
Richard Guenther wrote:
> We could then,
> reasoning with the plugin use, add additional langhooks encapsulating
> functions such as c_register_pragma (possibly under a
> lang_hooks.plugin substructure).
Yes, that perhaps is a good way. But I never understood
Dear compiler gurus,
I wish to have executables with the library path
(-Wl,-rpath=$HOME/tools/lib) embedded.
This is intended to facilitate executables compiled with various
versions/release candidates/snapshots run without keeping track of
LD_LIBRARY_PATH. (modifying the specs file seems mo
(gcc-help ?)
On Tue, 31 May 2011, Thierry Moreau wrote:
But with the gcc (latest 4.6.1 snapshot), -rpath (requested through LDFLAGS
as indicated above) is effective only for executables built in stage 1 (and
fixincl), but not for the installed gcc executables.
Is it intentional that the LDFL
I've created a wiki page with the changes to codegen for the C++ memory
model that we're working on implementing.
http://gcc.gnu.org/wiki/Atomic/GCCMM/CodeGen
in a nutshell, it expands the set of __sync atomic builtin's to take
another parameter for memory model, and then allow machine descrip
On Tue, May 31, 2011 at 7:17 PM, Basile Starynkevitch
wrote:
> On Tue, 31 May 2011 10:52:39 +0200
> Richard Guenther wrote:
>
>> We could then,
>> reasoning with the plugin use, add additional langhooks encapsulating
>> functions such as c_register_pragma (possibly under a
>> lang_hooks.plugin s
Snapshot gcc-4.4-20110531 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110531/
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
On Tue, 31 May 2011 23:52:11 +0200
Richard Guenther wrote:
[...]
> I don't see a strong need for cross-language plugins with
> frontend function access - "meta plugins" such as MELT
> may be an exception, but they have to deal with that
> in a similar way we deal with frontends - have MELT++, MELT
13 matches
Mail list logo
