On Wed, Nov 01, 2017 at 10:30:29AM -0600, Jeff Law wrote:
> On 10/31/2017 08:47 PM, Trevor Saunders wrote:
> > On Tue, Oct 31, 2017 at 11:38:48AM -0600, Jeff Law wrote:
> > > On 10/31/2017 11:22 AM, Eric Botcazou wrote:
> > > > > I don't see a reason not to other than a pretty small amount of work
On 10/31/2017 08:47 PM, Trevor Saunders wrote:
On Tue, Oct 31, 2017 at 11:38:48AM -0600, Jeff Law wrote:
On 10/31/2017 11:22 AM, Eric Botcazou wrote:
I don't see a reason not to other than a pretty small amount of work
each time we make a release.
I'm not sure it would be so small an amount o
On Tue, Oct 31, 2017 at 11:38:48AM -0600, Jeff Law wrote:
> On 10/31/2017 11:22 AM, Eric Botcazou wrote:
> >> I don't see a reason not to other than a pretty small amount of work
> >> each time we make a release.
> >
> > I'm not sure it would be so small an amount of work, especially on
> > non-L
On 10/31/2017 11:22 AM, Eric Botcazou wrote:
>> I don't see a reason not to other than a pretty small amount of work
>> each time we make a release.
>
> I'm not sure it would be so small an amount of work, especially on non-Linux
> platforms, so this would IMO divert our resources for little bene
> I don't see a reason not to other than a pretty small amount of work
> each time we make a release.
I'm not sure it would be so small an amount of work, especially on non-Linux
platforms, so this would IMO divert our resources for little benefit.
> Well first this would only matter to the 0.01
On Mon, Oct 30, 2017 at 11:11:12AM +0100, Eric Botcazou wrote:
> > It sounds like people are mostly concerned about sun studio and xlc? It
> > doesn't seem that hard to provide precompiled binaries for those two
> > platforms, and maybe 4.8 binaries for people who want to compile theire
> > own gcc
> It sounds like people are mostly concerned about sun studio and xlc? It
> doesn't seem that hard to provide precompiled binaries for those two
> platforms, and maybe 4.8 binaries for people who want to compile theire
> own gcc from source.
I'm not sure that we want to enter the business of preco
Trevor Saunders writes:
> On Thu, Oct 26, 2017 at 09:37:31PM +0200, Eric Botcazou wrote:
>> > Can you figure what oldest GCC release supports the C++11/14 POD handling
>> > that would be required?
>>
>> GCC needs to be buildable by other compilers than itself though.
>
> It sounds like people are
On Thu, Oct 26, 2017 at 09:37:31PM +0200, Eric Botcazou wrote:
> > Can you figure what oldest GCC release supports the C++11/14 POD handling
> > that would be required?
>
> GCC needs to be buildable by other compilers than itself though.
It sounds like people are mostly concerned about sun studio
On 10/27/2017 02:35 AM, Richard Biener wrote:
> On Thu, Oct 26, 2017 at 9:43 PM, Jakub Jelinek wrote:
>> On Thu, Oct 26, 2017 at 02:43:55PM +0200, Richard Biener wrote:
>>> On Thu, Oct 26, 2017 at 2:18 PM, Richard Sandiford
>>> wrote:
Richard Biener writes:
> On Mon, Oct 23, 2017 at 1:2
On 10/27/2017 09:35 AM, Richard Biener wrote:
> On Thu, Oct 26, 2017 at 9:43 PM, Jakub Jelinek wrote:
>> On Thu, Oct 26, 2017 at 02:43:55PM +0200, Richard Biener wrote:
>>> Can you figure what oldest GCC release supports the C++11/14 POD handling
>>> that would be required?
>>
>> I think it is to
> There's always the possibility of building GCC 4.8 with the other compiler
> and then GCC 9+ (?) with GCC 4.8.
What an user-friendly solution...
> What's the list of other compilers people routinely use? I see various
> comments on other compilers in install.texi but those are already saying
>
On Fri, Oct 27, 2017 at 10:35:56AM +0200, Richard Biener wrote:
> > I think it is too early for that, we aren't LLVM or Rust that don't really
> > care about what build requirements they impose on users.
>
> That's true, which is why I asked. For me requiring sth newer than GCC 4.8
> would be a b
On Thu, Oct 26, 2017 at 9:43 PM, Jakub Jelinek wrote:
> On Thu, Oct 26, 2017 at 02:43:55PM +0200, Richard Biener wrote:
>> On Thu, Oct 26, 2017 at 2:18 PM, Richard Sandiford
>> wrote:
>> > Richard Biener writes:
>> >> On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford
>> >> wrote:
>> >>> This p
On Thu, Oct 26, 2017 at 9:37 PM, Eric Botcazou wrote:
>> Can you figure what oldest GCC release supports the C++11/14 POD handling
>> that would be required?
>
> GCC needs to be buildable by other compilers than itself though.
There's always the possibility of building GCC 4.8 with the other comp
On Thu, Oct 26, 2017 at 02:43:55PM +0200, Richard Biener wrote:
> On Thu, Oct 26, 2017 at 2:18 PM, Richard Sandiford
> wrote:
> > Richard Biener writes:
> >> On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford
> >> wrote:
> >>> This patch adds a POD version of fixed_size_mode. The only current u
Richard Biener writes:
> On Thu, Oct 26, 2017 at 2:18 PM, Richard Sandiford
> wrote:
>> Richard Biener writes:
>>> On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford
>>> wrote:
This patch adds a POD version of fixed_size_mode. The only current use
is for storing the __builtin_apply a
> Can you figure what oldest GCC release supports the C++11/14 POD handling
> that would be required?
GCC needs to be buildable by other compilers than itself though.
--
Eric Botcazou
On Thu, Oct 26, 2017 at 2:18 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford
>> wrote:
>>> This patch adds a POD version of fixed_size_mode. The only current use
>>> is for storing the __builtin_apply and __builtin_result register mode
Richard Biener writes:
> On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford
> wrote:
>> This patch adds a POD version of fixed_size_mode. The only current use
>> is for storing the __builtin_apply and __builtin_result register modes,
>> which were made fixed_size_modes by the previous patch.
>
>
On Mon, Oct 23, 2017 at 1:22 PM, Richard Sandiford
wrote:
> This patch adds a POD version of fixed_size_mode. The only current use
> is for storing the __builtin_apply and __builtin_result register modes,
> which were made fixed_size_modes by the previous patch.
Bah - can we update our host comp
This patch adds a POD version of fixed_size_mode. The only current use
is for storing the __builtin_apply and __builtin_result register modes,
which were made fixed_size_modes by the previous patch.
2017-10-23 Richard Sandiford
Alan Hayward
David Sherwood
gcc/
22 matches
Mail list logo