On Thu, Mar 26, 2015 at 1:10 AM, Paolo Carlini wrote:
> Hi,
>
> sorry if I missed part of the discussion about the new numbering scheme and
> the answer to my question is already clear from that: why we do have 5.0 as
> Milestone in Bugzilla instead of 5.1?!?
Yeah, well ... details. We chose to
On Thu, Mar 26, 2015 at 09:36:30AM +0100, Richard Biener wrote:
> On Thu, Mar 26, 2015 at 1:10 AM, Paolo Carlini
> wrote:
> > sorry if I missed part of the discussion about the new numbering scheme and
> > the answer to my question is already clear from that: why we do have 5.0 as
> > Milestone i
Hi,
On 03/26/2015 09:52 AM, Jakub Jelinek wrote:
On Thu, Mar 26, 2015 at 09:36:30AM +0100, Richard Biener wrote:
On Thu, Mar 26, 2015 at 1:10 AM, Paolo Carlini wrote:
sorry if I missed part of the discussion about the new numbering scheme and
the answer to my question is already clear from th
Jakub Jelinek writes:
> Though, 5.0 milestone isn't completely meaningless, it means plan to fix it
> already before the release.
That's true for all 5.1 milestone bugs as well. :-)
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4
On Thu, Mar 26, 2015 at 10:15 AM, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
>> Though, 5.0 milestone isn't completely meaningless, it means plan to fix it
>> already before the release.
>
> That's true for all 5.1 milestone bugs as well. :-)
It would be "fix during development aka stage1-3
On Thu, Mar 26, 2015 at 10:19 AM, Richard Biener
wrote:
> On Thu, Mar 26, 2015 at 10:15 AM, Andreas Schwab wrote:
>> Jakub Jelinek writes:
>>
>>> Though, 5.0 milestone isn't completely meaningless, it means plan to fix it
>>> already before the release.
>>
>> That's true for all 5.1 milestone bu
On Thu, Mar 26, 2015 at 2:31 PM, xue yinsong wrote:
> I think the gimple front end project would be quite useful to gcc so I’d like
> to do work on it this summer.
>
> The problem is, it seems the GIMPLE front end project hasn’t been active for
> some time
> and Diego Novillo told me it may not
Hi all,
I've submitted my proposal to the GSoC website, it can be found here: [1]
After hearing some ideas from Oleg, I decided to go with working on
detecting and optimizing a few specific memory access patterns instead
of implementing a PBQP solver.
Any suggestions or comments are welcome.
I rea
Hi all,
I'd like to attempt to make GCC's usage of costs in the backends consistent.
We have a lot of different types: rtx costs, address costs, regmove costs,
vector costs etc. Some of them are use in different units, compared against
different types of costs and in general are a bit of a mess.
On 03/26/2015 08:32 AM, Erik Varga wrote:
Hi all,
I've submitted my proposal to the GSoC website, it can be found here: [1]
After hearing some ideas from Oleg, I decided to go with working on
detecting and optimizing a few specific memory access patterns instead
of implementing a PBQP solver.
An
On Tue, 24 Mar 2015 13:16:26 +0100
Martin Jambor wrote:
> Yes, I think that even just moving hopelessly outdated stuff to some
> "Archive" section, looking at what is left and then perhaps
> re-organizing the sections on the main page (and perhaps a few similar
> ones) would be great, if you have
The wiki page https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy says,
---
typedef char B3[3];
_Atomic B3 obj2;
An object will be promoted up to the next lock-free size in order to
enable lock free operations, as long as it isn't already a documented
lock free size. So obj2 will be prom
On 03/26/2015 04:02 PM, Jason Merrill wrote:
The wiki page https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy says,
---
typedef char B3[3];
_Atomic B3 obj2;
An object will be promoted up to the next lock-free size in order to
enable lock free operations, as long as it isn't already a do
(adding gcc@gcc.gnu.org)
On Thu, 2015-03-26 at 14:40 -0700, Andrew Morton wrote:
> On Thu, 26 Mar 2015 21:49:06 +0100 Mathias Krause
> wrote:
>
> > Andrew, what's your opinion on such a patch set? Do you too think it's
> > useful? Or do you share Ingo's fear about the additional maintenance
> >
On Thu, 26 Mar 2015 14:58:40 -0700 Joe Perches wrote:
> > I'd have thought that a function-wide
> > __attribute__((__string_section__(foo))
> > wouldn't be a ton of work to implement.
>
> Maybe not.
>
> Could some future version of gcc move string constants
> in a function to a specific sec
Snapshot gcc-4.8-20150326 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20150326/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, 2015-03-26 at 09:43 -0600, Jeff Law wrote:
> On 03/26/2015 08:32 AM, Erik Varga wrote:
> > Hi all,
> >
> > I've submitted my proposal to the GSoC website, it can be found here: [1]
> > After hearing some ideas from Oleg, I decided to go with working on
> > detecting and optimizing a few spe
On Thu, Mar 26, 2015 at 11:46 PM, Oleg Endo wrote:
> On Thu, 2015-03-26 at 09:43 -0600, Jeff Law wrote:
>> If you're looking at exploiting auto-inc addressing, others and myself
>> have speculated that something built around
>> straight-line-strength-reduction at the RTL level would be ideal for
>
On Thu, Mar 26, 2015 at 11:40 PM, Kyrill Tkachov wrote:
> Hi all,
>
> I'd like to attempt to make GCC's usage of costs in the backends consistent.
> We have a lot of different types: rtx costs, address costs, regmove costs,
> vector costs etc. Some of them are use in different units, compared agai
19 matches
Mail list logo
