Hello All,
Let's imagine someone is writing a plugin (or a MELT extension...) which
computes some complex information around gimple in a pass before LTO
serialization and re-uses that information in a later pass after LTO
serialization. A possible way to associate data inside a plugin to some g
On Fri, Mar 25, 2011 at 8:37 AM, Basile Starynkevitch
wrote:
> Hello All,
>
> Let's imagine someone is writing a plugin (or a MELT extension...) which
> computes some complex information around gimple in a pass before LTO
> serialization and re-uses that information in a later pass after LTO
>
On Wed, Mar 23, 2011 at 5:46 PM, Jason Merrill wrote:
> Yep. Here is the wording that we approved today:
[snip]
Nice. Thank you.
But now I'm a bit concerned about the complexity of this issue. Mind
me, I think that this solution is nice, but maybe it is a burden for
library implementors.
Let's
On 25 March 2011 10:13, Rodrigo Rivas wrote:
>
> But now I'm a bit concerned about the complexity of this issue. Mind
> me, I think that this solution is nice, but maybe it is a burden for
> library implementors.
>
> Let's say that I want to imitate 'exactly' the behavior of the
> range-for, but wi
On Fri, Mar 25, 2011 at 11:13 AM, Rodrigo Rivas
wrote:
> On Wed, Mar 23, 2011 at 5:46 PM, Jason Merrill wrote:
>> Yep. Here is the wording that we approved today:
> [snip]
>
> Nice. Thank you.
> But now I'm a bit concerned about the complexity of this issue. Mind
> me, I think that this solution
On Fri, Mar 25, 2011 at 5:13 AM, Rodrigo Rivas
wrote:
> On Wed, Mar 23, 2011 at 5:46 PM, Jason Merrill wrote:
>> Yep. Here is the wording that we approved today:
> [snip]
>
> Nice. Thank you.
> But now I'm a bit concerned about the complexity of this issue. Mind
> me, I think that this solution
Richard Sandiford schrieb:
> Georg-Johann Lay writes:
>> 1) The internals just mention TARGET_SECONDARY_RELOAD for REG-MEM and
>> for REG-REG moves, no word about REG-CONST moves. So is using
>> secondary reloads for CONST_INT (or other consts) like outlined
>> above a defined use case
On 03/25/2011 11:13 AM, Rodrigo Rivas wrote:
Let's say that I want to imitate 'exactly' the behavior of the
range-for, but with a plain old for (there are plenty of reasons for
that):
Note that there was already a special case for arrays.
Jason
On Fri, Mar 25, 2011 at 11:52 AM, James Dennett wrote:
> I'd be interested to know those reasons.
Well, maybe not *plenty*, but *some*... Let's say that I have a function:
template void Dump(S &s, const T &t)
{
for (auto i : t)
s.dump(i);
}
Cool!
Now I want to do the following:
templ
> On 03/25/2011 11:13 AM, Rodrigo Rivas wrote:
> Note that there was already a special case for arrays.
Yes, but std::begin/std::end are overloaded for arrays also, so the
library implementor would get the right behavior for free.
They are still vulnerable to the ADL issue, though.
--
Rodrigo
On Fri, Mar 25, 2011 at 06:06, Richard Guenther
wrote:
> You are not allowed to piggy-back on statements but only global things
> like cgraph and varpool. There is no way to transition data from before
> LTO to after associated with statements. And there never will be.
But one could write out
On Fri, Mar 25, 2011 at 12:52 PM, Diego Novillo wrote:
> On Fri, Mar 25, 2011 at 06:06, Richard Guenther
> wrote:
>
>> You are not allowed to piggy-back on statements but only global things
>> like cgraph and varpool. There is no way to transition data from before
>> LTO to after associated with
N.B. I'm going to use the term "good old for" instead of "plain old for" ;-)
On 25 March 2011 11:43, Rodrigo Rivas wrote:
> On Fri, Mar 25, 2011 at 11:52 AM, James Dennett
> wrote:
>> I'd be interested to know those reasons.
> Well, maybe not *plenty*, but *some*... Let's say that I have a fun
On Fri, Mar 25, 2011 at 11:27 AM, Jonathan Wakely wrote:
> Or just don't use range-for, it's not essential (given the trouble
> it's caused I'd quite happily have lived without it in C++0x!)
IMO, this goes beyond the syntactic sugar that the range-for provides.
It is about specifying a unified 'r
Hello,
Is it possible to support multiple pointer sizes (e.g. 16bit, 32bit)
which can co-exist in single compilation unit?
I want to add this support in backend code of a target architecture
for C and C++ languages.
I referred an old discussion about same topic on following URL:
http://gcc.gnu.
On 25 March 2011 12:27, Rodrigo Rivas wrote:
>
> IMO, this goes beyond the syntactic sugar that the range-for provides.
> It is about specifying a unified 'range' concept. The range-for is
> just the first, highly visible, user of this implicit specification.
Yes but it's too late to specify it in
On Fri, Mar 25, 2011 at 7:27 AM, Rodrigo Rivas
wrote:
> On Fri, Mar 25, 2011 at 11:27 AM, Jonathan Wakely
> wrote:
>> Or just don't use range-for, it's not essential (given the trouble
>> it's caused I'd quite happily have lived without it in C++0x!)
>
> IMO, this goes beyond the syntactic sugar
On Fri, Mar 25, 2011 at 1:34 PM, Gabriel Dos Reis
wrote:
> But what is that `unified range concept'? And why do we need it?
See Boost.Range for the concept and possibly uses. There has been some
discussion to accept it in the standard, IIRC.
> Exactly. Which for me means, it must be simple. Si
On Fri, Mar 25, 2011 at 1:33 PM, Jonathan Wakely wrote:
> Yes but it's too late to specify it in C++0x.
>
> Boost.Range is the best place to work on that idea at present.
> If/when it's fully baked I hope we'll see something like that in a
> future TR or standard.
Agreed.
But just now, how would
Merhaba,
Yeni sezon ürünlerimizi incelemenizi rica ederim.
Teslimatta ödeme seçeneği başlamıştır.
Bilginize.
www.eliticgiyim.com
ELİT İÇ GİYİM
Pazaar Ltd Şti
Tarlabaşı Bulvarı No: 117 Daire: 1
Beyoğlu / İstanbul - TÜRKİYE
Tel: 0212 2528577 Fax: 0212 2525668
Gsm: 0530 7733170
Powered by Do
Hi Michael,
Thanks for running these. I spent some time this morning looking
through the results, they largely look ok though I don't have much
perspective on the
the objc/ obj-c++ failures.
These failures here
For v7-a , A9 and Neon - these failures below:
> Running target unix
> FAIL: gfortra
On 25 March 2011 14:22, Rodrigo Rivas wrote:
> On Fri, Mar 25, 2011 at 1:33 PM, Jonathan Wakely
> wrote:
>> Yes but it's too late to specify it in C++0x.
>>
>> Boost.Range is the best place to work on that idea at present.
>> If/when it's fully baked I hope we'll see something like that in a
>> f
Georg-Johann Lay writes:
>>> 2) The secondary reload hook is always called with
>>> regclass = GENERAL_REGS, even in cases where the class
>>> is known to be NO_LD_REGS like, e.g. when preparing arguments
>>> for a function call. Why this? I would expect to get the smallest
>>> ava
On Mon, Mar 21, 2011 at 03:12:14PM -0700, Jakub Jelinek wrote:
> A second GCC 4.6.0 release candidate is available at:
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.0-RC-20110321/
>
> Please test the tarballs and report any problems to Bugzilla.
> CC me on the bugs if you believe they are regressio
"Jayant R. Sonar" writes:
> Is it possible to support multiple pointer sizes (e.g. 16bit, 32bit)
> which can co-exist in single compilation unit?
> Whether it is supported in GCC now?
> Is there any other architecture which has this feature already
> implemented?
Yes, there are three that I kno
On Fri, Mar 25, 2011 at 10:28:33AM -0700, Joe Buck wrote:
> On Mon, Mar 21, 2011 at 03:12:14PM -0700, Jakub Jelinek wrote:
> > A second GCC 4.6.0 release candidate is available at:
> >
> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.0-RC-20110321/
> >
> > Please test the tarballs and report any probl
On Mar 25, 2011, at 1:37 PM, DJ Delorie wrote:
>
> "Jayant R. Sonar" writes:
>> Is it possible to support multiple pointer sizes (e.g. 16bit, 32bit)
>> which can co-exist in single compilation unit?
>> Whether it is supported in GCC now?
>> Is there any other architecture which has this feature
> Hi Michael,
>
> Thanks for running these. I spent some time this morning looking
> through the results, they largely look ok though I don't have much
> perspective on the the objc/ obj-c++ failures.
I had a quick look at the test results for 4.6.0 under Michael's
name on the mailing list.
The
Richard Sandiford schrieb:
Georg-Johann Lay writes:
2) The secondary reload hook is always called with
regclass = GENERAL_REGS, even in cases where the class
is known to be NO_LD_REGS like, e.g. when preparing arguments
for a function call. Why this? I would expect to get the smallest
> ? MIPS has two pointer sizes, but a given compilation (gcc
> invocation) uses only one of them, it comes from the chosen ABI.
You can still override it with __attribute__((mode(SI))) or
__attribute__((mode(DI))) for some configurations.
On Fri, Mar 25, 2011 at 8:56 AM, Rodrigo Rivas
wrote:
> On Fri, Mar 25, 2011 at 1:34 PM, Gabriel Dos Reis
> wrote:
>> But what is that `unified range concept'? And why do we need it?
> See Boost.Range for the concept and possibly uses.
Boost.Range is a library component.
> There has been some
On Fri, Mar 25, 2011 at 9:22 AM, Rodrigo Rivas
wrote:
> On Fri, Mar 25, 2011 at 1:33 PM, Jonathan Wakely
> wrote:
>> Yes but it's too late to specify it in C++0x.
>>
>> Boost.Range is the best place to work on that idea at present.
>> If/when it's fully baked I hope we'll see something like that
On Fri, Mar 25, 2011 at 7:50 PM, Gabriel Dos Reis
wrote:
> Boost.Range is a library component.
True, but should it ever make its way to the standard library, it
would be good if it is consistent with the 'range' used by the
range-for. If not, we will have two subtly different definitions of
'range
On Fri, Mar 25, 2011 at 2:51 PM, Rodrigo Rivas
wrote:
> On Fri, Mar 25, 2011 at 7:50 PM, Gabriel Dos Reis
> wrote:
>> Boost.Range is a library component.
> True, but should it ever make its way to the standard library, it
You were earlier talking about some "unified concept"; weren't you?
Now, i
On Fri, Mar 25, 2011 at 9:35 PM, Gabriel Dos Reis
wrote:
> You were earlier talking about some "unified concept"; weren't you?
> Now, it is shifting to library component.
With "unified" I meant that the same concept (range) is present both
in the core language and the standard library. And that i
Snapshot gcc-4.6-20110325 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110325/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Fri, Mar 25, 2011 at 5:01 PM, Rodrigo Rivas
wrote:
> On Fri, Mar 25, 2011 at 9:35 PM, Gabriel Dos Reis
> wrote:
>> You were earlier talking about some "unified concept"; weren't you?
>> Now, it is shifting to library component.
>
> With "unified" I meant that the same concept (range) is presen
Status
==
GCC 4.6.0 release tarballs have been uploaded to gcc.gnu.org
and ftp.gnu.org, the 4.6 branch is open again for commits under
the usual release branch rules.
I'll announce the release once mirrors had some time to download it.
GCC 4.6.1 is planned for roughly late May, unless some u
38 matches
Mail list logo
