On 12/17/2016 05:24 PM, Jakub Jelinek wrote:
> On Sat, Dec 17, 2016 at 11:17:25AM -0500, Frank Ch. Eigler wrote:
>> Pedro Alves writes:
>>
>>> [...]
>>> malloc will fail, new will throw bad_alloc, and GCC will abort and
>>> maybe generate a core dump, instead of gracefully printing
>>> something l
On Sat, Dec 17, 2016 at 11:17:25AM -0500, Frank Ch. Eigler wrote:
> Pedro Alves writes:
>
> > [...]
> > malloc will fail, new will throw bad_alloc, and GCC will abort and
> > maybe generate a core dump, instead of gracefully printing
> > something like:
> >cc1: out of memory allocating NN
Pedro Alves writes:
> [...]
> malloc will fail, new will throw bad_alloc, and GCC will abort and
> maybe generate a core dump, instead of gracefully printing
> something like:
>cc1: out of memory allocating bytes ...
> and existing with error status.
Consider having the main() funct
On 12/17/2016 01:07 PM, Jonathan Wakely wrote:
> On 17 December 2016 at 12:28, Pedro Alves wrote:
>> On 12/17/2016 12:23 PM, Jonathan Wakely wrote:
>>> Instead of replacing the global new operator we could write a custom
>>> allocator that uses xmalloc, and we can have e.g. gcc::string as a
>>> typ
On 17 December 2016 at 12:28, Pedro Alves wrote:
> On 12/17/2016 12:23 PM, Jonathan Wakely wrote:
>> Instead of replacing the global new operator we could write a custom
>> allocator that uses xmalloc, and we can have e.g. gcc::string as a
>> typedef for std::basic_string,
>> gcc::xmallocator>
>>
>
On 12/17/2016 12:23 PM, Jonathan Wakely wrote:
> Instead of replacing the global new operator we could write a custom
> allocator that uses xmalloc, and we can have e.g. gcc::string as a
> typedef for std::basic_string,
> gcc::xmallocator>
>
That doesn't make sense to me, as it leaves the problem
Instead of replacing the global new operator we could write a custom
allocator that uses xmalloc, and we can have e.g. gcc::string as a
typedef for std::basic_string,
gcc::xmallocator>
On 12/17/2016 10:58 AM, Janus Weil wrote:
> 2016-12-16 19:46 GMT+01:00 Pedro Alves :
> So, it seems like it would be a good idea to follow your suggestion
> from PR 78822:
>
>
>> You can replace the global operator new/new[] to call xmalloc instead of
>> malloc.
>> Then memory allocation by std:
2016-12-16 19:46 GMT+01:00 Pedro Alves :
And in particular: How do the current uses of
std::string in GCC deal with this problem? (Do they?)
>>>
>>> Doesn't look like they do.
>>
>> Huh, that's a problem then, isn't it?
>
> Right. The easiest way to trigger it I think is if something
> c
On 12/16/2016 06:56 PM, Jakub Jelinek wrote:
> On Fri, Dec 16, 2016 at 06:52:03PM +, Pedro Alves wrote:
>> GDB has a string_printf function that prints into a std::string, for
>> example. Like:
>>
>> std::string hello = string_printf ("%s", "hello world");
>>
>> That's a function that many C
On Fri, Dec 16, 2016 at 06:52:03PM +, Pedro Alves wrote:
> GDB has a string_printf function that prints into a std::string, for
> example. Like:
>
> std::string hello = string_printf ("%s", "hello world");
>
> That's a function that many C++ projects reinvent.
If you then want to work wit
On 12/16/2016 06:04 PM, Jakub Jelinek wrote:
> On Fri, Dec 16, 2016 at 06:55:12PM +0100, Janus Weil wrote:
>> To get to more specific questions ...
>>
>>> Basically the only STL construct used in the Fortran FE right now
>>> seems to be std::swap, and a single instance of std::map in
>>> trans-comm
On 12/16/2016 06:31 PM, Janus Weil wrote:
> 2016-12-16 18:53 GMT+01:00 Pedro Alves :
>> On 12/16/2016 05:33 PM, Janus Weil wrote:
>>> And in particular: How do the current uses of
>>> std::string in GCC deal with this problem? (Do they?)
>>
>> Doesn't look like they do.
>
> Huh, that's a problem
2016-12-16 18:53 GMT+01:00 Pedro Alves :
> On 12/16/2016 05:33 PM, Janus Weil wrote:
>
>> "You would need to make sure it uses a xmalloc based allocator first
>> or at least calls xmalloc_failed upon allocation failure, otherwise it
>> will be a serious regression."
>>
>> I'm really not an expert o
On Dec 16 2016, Janus Weil wrote:
thanks for this lengthy comment, but that's really not the kind of
discussion I wanna get into here. (And I don't actually agree to all
of your points, but that doesn't matter.)
Sorry - I misunderstood.
Regards,
Nick Maclaren.
On Fri, Dec 16, 2016 at 06:55:12PM +0100, Janus Weil wrote:
> To get to more specific questions ...
>
> > Basically the only STL construct used in the Fortran FE right now
> > seems to be std::swap, and a single instance of std::map in
> > trans-common.c.
>
> I see that fortran/trans-common.c has
To get to more specific questions ...
> Basically the only STL construct used in the Fortran FE right now
> seems to be std::swap, and a single instance of std::map in
> trans-common.c.
I see that fortran/trans-common.c has:
#define INCLUDE_MAP
and apparently there is also a INCLUDE_STRING macr
On 12/16/2016 05:33 PM, Janus Weil wrote:
> "You would need to make sure it uses a xmalloc based allocator first
> or at least calls xmalloc_failed upon allocation failure, otherwise it
> will be a serious regression."
>
> I'm really not an expert on GCC's memory management principles and how
> i
Hi Nick,
2016-12-16 18:16 GMT+01:00 N.M. Maclaren :
> On Dec 16 2016, Janus Weil wrote:
>>
>> What I'd like to know is: In the current state of things in GCC, is it
>> possible/reasonable to use any of the STL containers (like
>> std::vector, std::string, whatever) in GCC and its front ends (in
>>
On Dec 16 2016, Janus Weil wrote:
What I'd like to know is: In the current state of things in GCC, is it
possible/reasonable to use any of the STL containers (like
std::vector, std::string, whatever) in GCC and its front ends (in
particular gfortran)?
That question has two parts:
1) Is it techn
Hi all,
I recently ran into some discussion with Jakub about using std::string
in gfortran (see PR 78822), which got me curious about some general
points ...
What I'd like to know is: In the current state of things in GCC, is it
possible/reasonable to use any of the STL containers (like
std::vect
21 matches
Mail list logo
