On Dienstag, 6. Februar 2018 01:01:29 CET Jan Hubicka wrote:
> Dne 2018-02-05 18:44, Richard Biener napsal:
> > On February 5, 2018 12:26:58 PM GMT+01:00, Allan Sandfeld Jensen
> >
> > wrote:
> >> Hello GCC
> >>
> >> In trying to make it possible to use LTO for distro-builds of Qt, I
> >> have a
On Tue, 6 Feb 2018, Paul Smith wrote:
My environment has been using GCC 6.2 (locally compiled) on GNU/Linux
systems. We use a separate heap management library (jemalloc) rather
than the libc allocator. The way we did this in the past was to
declare operator new/delete (all forms) as inline fun
Am 06.02.2018 um 22:50 schrieb Eric Botcazou:
>> Here's a short status report for trunk on x86_64-w64-mingw32 host.
>>
>> I know this is only a secondary platform, but there are some serius issues.
>>
>> Especially the ada part is in a bad shape compared to 7.3.0, see
>> https://gcc.gnu.org/ml/gcc-
On 05/02/18 22:01 +0100, Tim van Deurzen wrote:
Hi,
I've written to this list previously to mention I'm working on
implementing p0515 (the spaceship operator) for C++. Although I'm still
far from finished I'd like to make sure that when I am, I will be able
to contribute my changes to GCC. Pleas
On 07/02/18 12:16 +, Jonathan Wakely wrote:
On 05/02/18 22:01 +0100, Tim van Deurzen wrote:
Hi,
I've written to this list previously to mention I'm working on
implementing p0515 (the spaceship operator) for C++. Although I'm still
far from finished I'd like to make sure that when I am, I wi
On 2018-02-07 02:21, Daniel Berlin wrote:
As the person who, eons ago, wrote a bunch of the the GDB code for this
C++
ABI support, and as someone who helped with DWARF support in both GDB
and
GCC, let me try to propose a useful path forward (in the hopes that
someone
will say "that's horrible,
On Wed, 2018-02-07 at 11:32 +0100, Marc Glisse wrote:
> On Tue, 6 Feb 2018, Paul Smith wrote:
>
> > My environment has been using GCC 6.2 (locally compiled) on
> > GNU/Linux systems. We use a separate heap management library
> > (jemalloc) rather than the libc allocator. The way we did this in
>
On 02/07/2018 02:44 PM, Simon Marchi wrote:
On 2018-02-07 02:21, Daniel Berlin wrote:
As the person who, eons ago, wrote a bunch of the the GDB code for
this C++
ABI support, and as someone who helped with DWARF support in both GDB and
GCC, let me try to propose a useful path forward (in the
On 7 February 2018 at 15:07, Manfred wrote:
>
>
> On 02/07/2018 02:44 PM, Simon Marchi wrote:
>>
>> On 2018-02-07 02:21, Daniel Berlin wrote:
>>>
>>> As the person who, eons ago, wrote a bunch of the the GDB code for this
>>> C++
>>> ABI support, and as someone who helped with DWARF support in bot
On 4 February 2018 at 05:01, Simon Marchi wrote:
> On 2018-02-03 13:35, Manfred wrote:
>> n4659 17.4 (Type equivalence) p1.3:
>>
>> Two template-ids refer to the same class, function, or variable if
>> ...
>> their corresponding non-type template arguments of integral or
>> enumeration type have id
Hi Eric,
Thank you very much. Your advise is exact right. :)
The function bit_position and byte_position is what I want to implement
offsetof.
Regards
At 2018-02-07 00:58:17, "Eric Botcazou" wrote:
>> I am writing a gcc plugin for parsing the structure fields. But I have the
>> problem how to
On 2/7/2018 4:15 PM, Jonathan Wakely wrote:
On 7 February 2018 at 15:07, Manfred wrote:
On 02/07/2018 02:44 PM, Simon Marchi wrote:
[...]
This addresses the issue of how to do good software design in GDB to
support different producers cleanly, but I think we have some issues even
befor
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
> This addresses the issue of how to do good software design in GDB to
> support different producers cleanly, but I think we have some issues
> even before that, like how to support g++ 7.3 and up. I'll try to
> summarize the issue quickly. It's now
On 2018-02-07 11:26, Michael Matz wrote:
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
This addresses the issue of how to do good software design in GDB to
support different producers cleanly, but I think we have some issues
even before that, like how to support g++ 7.3 and up. I'll try to
summ
On 7 February 2018 at 16:36, Simon Marchi wrote:
> On 2018-02-07 11:26, Michael Matz wrote:
>>
>> Hi,
>>
>> On Wed, 7 Feb 2018, Simon Marchi wrote:
>>
>>> This addresses the issue of how to do good software design in GDB to
>>> support different producers cleanly, but I think we have some issues
>>
On Wed, Feb 7, 2018 at 5:44 AM, Simon Marchi
wrote:
> On 2018-02-07 02:21, Daniel Berlin wrote:
>
>> As the person who, eons ago, wrote a bunch of the the GDB code for this
>> C++
>> ABI support, and as someone who helped with DWARF support in both GDB and
>> GCC, let me try to propose a useful p
On 7 February 2018 at 17:03, Simon Marchi wrote:
> On 2018-02-07 11:50, Jonathan Wakely wrote:
>>
>> On 7 February 2018 at 16:36, Simon Marchi wrote:
>>>
>>> On 2018-02-07 11:26, Michael Matz wrote:
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
> This addresses the
>
>
> This avoids the problem of the demangler gdb is using getting a different
> name than the producer used. It also should always give you the right one.
> If the producer calls the type "vtable fo Foo<2u>" here and "Foo<2>"
> elsewhere, yes, that's a bug. It should be consistent.
>
>
This shoul
GNU MPFR 4.0.1 ("dinde aux marrons", patch level 1), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:
http://www.mpfr.org/mpfr-4.0.1/
from InriaForge:
https://gforge.inria.fr/projects/mpfr/
and from t
On 2018-02-07 11:50, Jonathan Wakely wrote:
On 7 February 2018 at 16:36, Simon Marchi wrote:
On 2018-02-07 11:26, Michael Matz wrote:
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
This addresses the issue of how to do good software design in GDB to
support different producers cleanly, but I t
On 2018-02-07 12:08, Jonathan Wakely wrote:
Why would they not have a mangled name?
Interesting. What do they look like, and in what context do they
appear?
Anywhere you need a name for linkage purposes, such as in a function
signature, or as a template argument of another type, or in the
st
On 7 February 2018 at 17:20, Simon Marchi wrote:
> On 2018-02-07 12:08, Jonathan Wakely wrote:
>>
>> Why would they not have a mangled name?
>>
>>> Interesting. What do they look like, and in what context do they appear?
>>
>>
>> Anywhere you need a name for linkage purposes, such as in a functio
On Wed, 7 Feb 2018, Simon Marchi wrote:
On 2018-02-07 12:08, Jonathan Wakely wrote:
Why would they not have a mangled name?
Interesting. What do they look like, and in what context do they appear?
Anywhere you need a name for linkage purposes, such as in a function
signature, or as a templ
On 2018-02-07 12:30, Jonathan Wakely wrote:
Ah ok, the class name appears mangled in other entities' mangled name.
But
from what I understand there's no mangled name for the class such that
echo | c++filt
outputs the class name (e.g. "Foo<10>"). That wouldn't make sense,
since
there's n
> "Dan" == Daniel Berlin writes:
Dan> If there are multiple types named Foo<2u>, DWARF needs to be extended to
Dan> allow a pointer from the vtable debug info to the class type debug info
Dan> (unless they already added one).
This is what we did for Rust.
Rust doesn't have a stable ABI yet,
On 02/07/2018 12:11 PM, Daniel Berlin wrote:
Note that the ABI is explicitly designed so that type identity can be done
by address comparison.
correct, but be aware that lots of dynamic objects seem to step outside
the ABI by building shared objects with -Bsymbolic[1], or the equivalent
vis
Snapshot gcc-6-20180207 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180207/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6
> Indeed, this solves most of the new failures. Here is the acats test
> summary:
> === acats Summary ===
> # of expected passes 2298
> # of unexpected failures 22
> *** FAILURES: c23003b c23003g c23003i c250002 c380004 cd2b11a cd2b15c
> ce2102l ce2102m ce2103a ce2103b c
On 02/06/2018 03:56 PM, Paul Smith wrote:
Hi all.
Hopefully this isn't too annoying a question :).
My environment has been using GCC 6.2 (locally compiled) on GNU/Linux
systems. We use a separate heap management library (jemalloc) rather
than the libc allocator. The way we did this in the pas
On 7 February 2018 at 23:38, Martin Sebor wrote:
> On 02/06/2018 03:56 PM, Paul Smith wrote:
>>
>> Hi all.
>>
>> Hopefully this isn't too annoying a question :).
>>
>> My environment has been using GCC 6.2 (locally compiled) on GNU/Linux
>> systems. We use a separate heap management library (jemal
On Wed, 7 Feb 2018, Paul Smith wrote:
My question is, what do I need to do to ensure this behavior
persists if I create a global operator new/delete?
Is it sufficient to ensure that the symbol for our shared library
global new/delete symbols are hidden and not global, using a linker
map or -fvi
On Wed, 2018-02-07 at 16:38 -0700, Martin Sebor wrote:
> I'm not sure I see how defining operator new inline can work
> unless you recompile the world (i.e., all the DSOs used by
> the program, including libstdc++). As Marc already hinted,
> if libstdc++ dynamically allocates an object using the de
On Thu, 2018-02-08 at 01:17 +0100, Marc Glisse wrote:
> On Wed, 7 Feb 2018, Paul Smith wrote:
> > > > My question is, what do I need to do to ensure this behavior
> > > > persists if I create a global operator new/delete?
> > > >
> > > > Is it sufficient to ensure that the symbol for our shared
>
33 matches
Mail list logo
