On 8/22/16, Mike Stump wrote:
> On Aug 22, 2016, at 5:02 AM, Eric Gallager wrote:
>>
>> As a rookie programmer considering possibly contributing to GCC in the
>> future once I'm more confident in my abilities, switching to C++11
>> would increase the barrier for me to contribute. I currently real
On Aug 22, 2016, at 5:02 AM, Eric Gallager wrote:
>
> As a rookie programmer considering possibly contributing to GCC in the
> future once I'm more confident in my abilities, switching to C++11
> would increase the barrier for me to contribute. I currently really
> only know C, and I still have t
On 22/08/16 13:02, Eric Gallager wrote:
As a rookie programmer considering possibly contributing to GCC in the
future once I'm more confident in my abilities, switching to C++11
would increase the barrier for me to contribute. I currently really
only know C, and I still have to learn C++ in gener
On 8/21/16, Pedro Alves wrote:
> On 08/20/2016 03:29 AM, Mike Stump wrote:
>> On Aug 10, 2016, at 10:03 AM, Oleg Endo wrote:
>>>
>>> Or just wait until people have agreed to switch to C++11 or C++14. I
>>> don't think in practice anybody uses an C++11-incapable GCC to build a
>>> newer GCC these
On Mon, Aug 22, 2016 at 9:18 AM, Trevor Saunders wrote:
> On Sun, Aug 21, 2016 at 09:00:26PM +0100, Pedro Alves wrote:
>> On 08/20/2016 03:29 AM, Mike Stump wrote:
>> > On Aug 10, 2016, at 10:03 AM, Oleg Endo wrote:
>> >>
>> >> Or just wait until people have agreed to switch to C++11 or C++14. I
On Sun, Aug 21, 2016 at 09:00:26PM +0100, Pedro Alves wrote:
> On 08/20/2016 03:29 AM, Mike Stump wrote:
> > On Aug 10, 2016, at 10:03 AM, Oleg Endo wrote:
> >>
> >> Or just wait until people have agreed to switch to C++11 or C++14. I
> >> don't think in practice anybody uses an C++11-incapable G
On 08/20/2016 03:29 AM, Mike Stump wrote:
> On Aug 10, 2016, at 10:03 AM, Oleg Endo wrote:
>>
>> Or just wait until people have agreed to switch to C++11 or C++14. I
>> don't think in practice anybody uses an C++11-incapable GCC to build a
>> newer GCC these days.
gdb will drop support for build
On Aug 10, 2016, at 10:03 AM, Oleg Endo wrote:
>
> Or just wait until people have agreed to switch to C++11 or C++14. I
> don't think in practice anybody uses an C++11-incapable GCC to build a
> newer GCC these days.
I use the system gcc 4.4.7 on RHEL to build a newer cross compiler... I could
On 08/17/2016 02:27 AM, Richard Biener wrote:
On Tue, Aug 16, 2016 at 7:54 PM, Martin Sebor wrote:
On 08/16/2016 10:47 AM, Jeff Law wrote:
On 08/16/2016 10:44 AM, Jakub Jelinek wrote:
On Tue, Aug 16, 2016 at 10:27:58AM -0600, Jeff Law wrote:
I think you're being rather short-sighed here.
On Tue, Aug 16, 2016 at 7:54 PM, Martin Sebor wrote:
> On 08/16/2016 10:47 AM, Jeff Law wrote:
>>
>> On 08/16/2016 10:44 AM, Jakub Jelinek wrote:
>>>
>>> On Tue, Aug 16, 2016 at 10:27:58AM -0600, Jeff Law wrote:
I think you're being rather short-sighed here. GCC is being used in
wa
On 08/16/2016 10:47 AM, Jeff Law wrote:
On 08/16/2016 10:44 AM, Jakub Jelinek wrote:
On Tue, Aug 16, 2016 at 10:27:58AM -0600, Jeff Law wrote:
I think you're being rather short-sighed here. GCC is being used in
ways we
can't necessarily predict -- which might include compile servers,
JITs, web
On 08/16/2016 10:44 AM, Jakub Jelinek wrote:
On Tue, Aug 16, 2016 at 10:27:58AM -0600, Jeff Law wrote:
I think you're being rather short-sighed here. GCC is being used in ways we
can't necessarily predict -- which might include compile servers, JITs, web
services, etc.
For compile server/web
On Tue, Aug 16, 2016 at 10:27:58AM -0600, Jeff Law wrote:
> I think you're being rather short-sighed here. GCC is being used in ways we
> can't necessarily predict -- which might include compile servers, JITs, web
> services, etc.
For compile server/web services one needs to add the protection ou
On 08/10/2016 12:33 PM, Richard Biener wrote:
Why would you want to get rid of the alloca here?
Do you know the range for LENGTH in the code above?
Yes, it's a set of tree code names.
Is it based on
something the user could potentially control (like a variable name,
typdef name, etc). If
On Thu, Aug 11, 2016 at 09:18:34PM +0900, Oleg Endo wrote:
> On Wed, 2016-08-10 at 21:31 -0400, Trevor Saunders wrote:
>
> >
> > Well, I'd say the compromises made in std::string make it pretty
> > terrible for general purpose use accept where perf and memory doesn't
> > matter at all.
> >
> > s
On Wed, 2016-08-10 at 21:31 -0400, Trevor Saunders wrote:
>
> Well, I'd say the compromises made in std::string make it pretty
> terrible for general purpose use accept where perf and memory doesn't
> matter at all.
>
> std::vector isn't very great size wise either, imho the size /
> capacity f
On Thu, Aug 11, 2016 at 02:03:29AM +0900, Oleg Endo wrote:
> On Tue, 2016-08-09 at 13:41 -0400, Trevor Saunders wrote:
>
> > If what you want is the ability to put the buffer on the stack
> > instead of the heap then I think a stack_string class that
> > interoperates with your string class is t
On August 10, 2016 8:00:20 PM GMT+02:00, Jeff Law wrote:
>On 08/10/2016 04:04 AM, Richard Biener wrote:
>> On Tue, Aug 9, 2016 at 3:17 PM, Aldy Hernandez
>wrote:
>>> On 08/05/2016 01:55 PM, Richard Biener wrote:
>>>
>>> Hi Richard.
>>>
Please don't use std::string. For string building you c
On 08/10/2016 04:04 AM, Richard Biener wrote:
On Tue, Aug 9, 2016 at 3:17 PM, Aldy Hernandez wrote:
On 08/05/2016 01:55 PM, Richard Biener wrote:
Hi Richard.
Please don't use std::string. For string building you can use obstacks.
Alright let's talk details then so I can write things up i
On Tue, 2016-08-09 at 13:41 -0400, Trevor Saunders wrote:
> If what you want is the ability to put the buffer on the stack
> instead of the heap then I think a stack_string class that
> interoperates with your string class is the thing you want.
I'd avoid a separate stack_string class. Instead
On Wed, Aug 10, 2016 at 12:12 PM, Aldy Hernandez wrote:
> On 08/10/2016 06:04 AM, Richard Biener wrote:
>>
>> On Tue, Aug 9, 2016 at 3:17 PM, Aldy Hernandez wrote:
>>>
>>> On 08/05/2016 01:55 PM, Richard Biener wrote:
>>>
>>> Hi Richard.
>>>
Please don't use std::string. For string building
On 08/10/2016 06:04 AM, Richard Biener wrote:
On Tue, Aug 9, 2016 at 3:17 PM, Aldy Hernandez wrote:
On 08/05/2016 01:55 PM, Richard Biener wrote:
Hi Richard.
Please don't use std::string. For string building you can use obstacks.
Alright let's talk details then so I can write things up i
On Tue, Aug 9, 2016 at 3:17 PM, Aldy Hernandez wrote:
> On 08/05/2016 01:55 PM, Richard Biener wrote:
>
> Hi Richard.
>
>> Please don't use std::string. For string building you can use obstacks.
>
>
> Alright let's talk details then so I can write things up in a way you
> approve of.
>
> Take for
On Tue, Aug 09, 2016 at 08:33:49PM +0900, Oleg Endo wrote:
> On Mon, 2016-08-08 at 13:39 -0400, Trevor Saunders wrote:
>
>
> > First sizeof std::string is 32 on x86_64, a char *, a size_t for the
> > length, and a 16 byte union of a size_t for allocated size and a 16
> > byte buffer for short st
On 08/09/2016 03:17 PM, Aldy Hernandez wrote:
On 08/05/2016 01:55 PM, Richard Biener wrote:
Hi Richard.
Please don't use std::string. For string building you can use obstacks.
Alright let's talk details then so I can write things up in a way you
approve of.
Take for instance simple uses
On 08/05/2016 01:55 PM, Richard Biener wrote:
Hi Richard.
Please don't use std::string. For string building you can use obstacks.
Alright let's talk details then so I can write things up in a way you
approve of.
Take for instance simple uses like all the tree_*check_failed routines,
whic
On Mon, 2016-08-08 at 13:39 -0400, Trevor Saunders wrote:
> First sizeof std::string is 32 on x86_64, a char *, a size_t for the
> length, and a 16 byte union of a size_t for allocated size and a 16
> byte buffer for short strings. I suppose some of this is required by
> the C++ standard,
I r
On August 8, 2016 7:39:39 PM GMT+02:00, Trevor Saunders
wrote:
>On Mon, Aug 08, 2016 at 11:00:28AM -0600, Jeff Law wrote:
>> On 08/06/2016 09:08 AM, Richard Biener wrote:
>> > On August 6, 2016 12:15:26 PM GMT+02:00, Aldy Hernandez
> wrote:
>> > > On 08/05/2016 04:07 PM, Richard Biener wrote:
>>
On Mon, Aug 08, 2016 at 11:00:28AM -0600, Jeff Law wrote:
> On 08/06/2016 09:08 AM, Richard Biener wrote:
> > On August 6, 2016 12:15:26 PM GMT+02:00, Aldy Hernandez
> > wrote:
> > > On 08/05/2016 04:07 PM, Richard Biener wrote:
> > > > On August 5, 2016 8:15:54 PM GMT+02:00, Oleg Endo
> > > wro
On 08/06/2016 09:08 AM, Richard Biener wrote:
On August 6, 2016 12:15:26 PM GMT+02:00, Aldy Hernandez
wrote:
On 08/05/2016 04:07 PM, Richard Biener wrote:
On August 5, 2016 8:15:54 PM GMT+02:00, Oleg Endo
wrote:
On Fri, 2016-08-05 at 19:55 +0200, Richard Biener wrote:
Please don't use s
On August 6, 2016 12:15:26 PM GMT+02:00, Aldy Hernandez
wrote:
>On 08/05/2016 04:07 PM, Richard Biener wrote:
>> On August 5, 2016 8:15:54 PM GMT+02:00, Oleg Endo
> wrote:
>>> On Fri, 2016-08-05 at 19:55 +0200, Richard Biener wrote:
>>>
Please don't use std::string. For string building
On 08/05/2016 04:07 PM, Richard Biener wrote:
On August 5, 2016 8:15:54 PM GMT+02:00, Oleg Endo wrote:
On Fri, 2016-08-05 at 19:55 +0200, Richard Biener wrote:
Please don't use std::string. For string building you can use
obstacks.
Just out of curiosity ... why? I remember there was som
On 08/05/2016 04:07 PM, Richard Biener wrote:
On August 5, 2016 8:15:54 PM GMT+02:00, Oleg Endo wrote:
On Fri, 2016-08-05 at 19:55 +0200, Richard Biener wrote:
Please don't use std::string. For string building you can use
obstacks.
Just out of curiosity ... why? I remember there was som
On August 5, 2016 8:15:54 PM GMT+02:00, Oleg Endo wrote:
>On Fri, 2016-08-05 at 19:55 +0200, Richard Biener wrote:
>
>>
>> Please don't use std::string. For string building you can use
>> obstacks.
>>
>
>Just out of curiosity ... why? I remember there was some discussion
>about it, what was th
On Fri, 2016-08-05 at 19:55 +0200, Richard Biener wrote:
>
> Please don't use std::string. For string building you can use
> obstacks.
>
Just out of curiosity ... why? I remember there was some discussion
about it, what was the conclusion? Is that now a general rule or does
it depend on the
On August 5, 2016 4:42:48 PM GMT+02:00, Aldy Hernandez wrote:
>
>> I was surprised by the always_inline trick. I suppose it makes
>> sense but I wouldn't have expected to be able to rely on it. Out
>> of curiosity I tested it with other compilers. It turns out that
>> it only works with some li
On August 5, 2016 6:23:27 PM GMT+02:00, Jeff Law wrote:
>On 08/05/2016 08:37 AM, Aldy Hernandez wrote:
>>
>> After looking at all this code, I realize no size will fit all if we
>> want something clean. So, I take my approach back. I think we're
>best
>> served by a couple different approaches,
On 08/05/2016 08:37 AM, Aldy Hernandez wrote:
After looking at all this code, I realize no size will fit all if we
want something clean. So, I take my approach back. I think we're best
served by a couple different approaches, depending on usage.
Yup.
My question is, how wed are we to an al
On 08/05/2016 03:37 PM, Aldy Hernandez wrote:
> My question is, how wed are we to an alloca based approach? Can we
> replace the non-critical uses by std::string (diagnostics,
> BLAH_check_failed(), building a string to manipulate the output of
> env("SOME_VAR"), etc?).
My suggestion too.
( I h
I was surprised by the always_inline trick. I suppose it makes
sense but I wouldn't have expected to be able to rely on it. Out
of curiosity I tested it with other compilers. It turns out that
it only works with some like GCC and IBM XLC++, but not others
like Clang or Sun CC. In recursive c
I think only thing you're missing is that we probably don't want to be
using alloca in new code anyway. And if we're going through the trouble
of fixing old code, we ought to just remove alloca. So building up this
kind of class is probably taking folks in the wrong direction.
After spending
On Thu, Aug 4, 2016 at 5:19 PM, Aldy Hernandez wrote:
> On 08/04/2016 08:57 AM, Richard Biener wrote:
>>
>> On Thu, Aug 4, 2016 at 1:30 PM, Aldy Hernandez wrote:
>>>
>>> Howdy!
>>>
>>> As part of my -Walloca-larger-than=life work, I've been running said pass
>>> over gcc, binutils, and gdb, and t
On 08/04/2016 05:30 AM, Aldy Hernandez wrote:
Howdy!
As part of my -Walloca-larger-than=life work, I've been running said
pass over gcc, binutils, and gdb, and trying to fix things along the way.
Particularly irritating and error prone is having to free malloc'd
pointers on every function exit
On 08/04/2016 08:26 PM, Jeff Law wrote:
> On 08/04/2016 01:21 PM, Pedro Alves wrote:
>> Most allocas I've seen in my life were written to simply build
>> strings at run time, while lazily avoiding to think about writing
>> a "free" call, rather than having been written for optimizing
>> some fast
On 08/04/2016 01:21 PM, Pedro Alves wrote:
On 08/04/2016 08:16 PM, Jeff Law wrote:
On 08/04/2016 01:06 PM, Pedro Alves wrote:
How wedded are we to alloca?
I would think only in the sense of existing codebase usage.
Based on how often alloca usage has resulted in a security vulnerability
it's
On 08/04/2016 09:19 AM, Aldy Hernandez wrote:
Particularly irritating and error prone is having to free malloc'd
pointers
on every function exit point. We end up with a lot of:
foo(size_t len)
{
void *p, *m_p = NULL;
if (len < HUGE)
p = alloca(len);
else
p = m_p = malloc(le
On 08/04/2016 08:16 PM, Jeff Law wrote:
> On 08/04/2016 01:06 PM, Pedro Alves wrote:
>> How wedded are we to alloca?
> I would think only in the sense of existing codebase usage.
>
> Based on how often alloca usage has resulted in a security vulnerability
> it's clear we as developers can't use it
On 08/04/2016 01:06 PM, Pedro Alves wrote:
How wedded are we to alloca?
I would think only in the sense of existing codebase usage.
Based on how often alloca usage has resulted in a security vulnerability
it's clear we as developers can't use it correctly on a consistent
basis, thus I'd like
How wedded are we to alloca?
On 08/04/2016 12:30 PM, Aldy Hernandez wrote:
> Is there a better blessed C++ way?
std::string
or if I'm reading gcc's vec.h correctly:
auto_vec
?
(or some typedef of the latter)
The latter would always allocate the stack space, but
my guess it that it would
On 08/04/2016 08:57 AM, Richard Biener wrote:
On Thu, Aug 4, 2016 at 1:30 PM, Aldy Hernandez wrote:
Howdy!
As part of my -Walloca-larger-than=life work, I've been running said pass
over gcc, binutils, and gdb, and trying to fix things along the way.
Particularly irritating and error prone is
On Thu, Aug 4, 2016 at 1:30 PM, Aldy Hernandez wrote:
> Howdy!
>
> As part of my -Walloca-larger-than=life work, I've been running said pass
> over gcc, binutils, and gdb, and trying to fix things along the way.
>
> Particularly irritating and error prone is having to free malloc'd pointers
> on e
Howdy!
As part of my -Walloca-larger-than=life work, I've been running said
pass over gcc, binutils, and gdb, and trying to fix things along the way.
Particularly irritating and error prone is having to free malloc'd
pointers on every function exit point. We end up with a lot of:
foo(size_
52 matches
Mail list logo
