On Wed, 2018-02-07 at 19:26 -0500, Paul Smith wrote:
> Thanks for the conversation. I'm moving forward with a real global
> operator new/delete and working out the magic needed to ensure those
> symbols are not global in our shared library.
I remember one annoying thing I ran into: through compil
On 02/08/2018 05:39 PM, Ian Lance Taylor wrote:
On Thu, Feb 8, 2018 at 3:24 PM, Martin Sebor wrote:
While testing what should be an innocuous patch to add LTO
to a bunch of middle-end warning options
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00381.html
I get Go errors during ordinary b
Never mind. I see the problem. I overlooked a few failures
in the preprocessor test suite. Turns out the patch accidentally
deletes the -d option from the .opt file. I didn't notice it in
the diff because the "-d" at the beginning of the line looks just
like the option is still there!
@@ -118
On Thu, Feb 8, 2018 at 3:24 PM, Martin Sebor wrote:
>
> While testing what should be an innocuous patch to add LTO
> to a bunch of middle-end warning options
>
> https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00381.html
>
> I get Go errors during ordinary bootstrap about undefined names
> for err
Hi Ian,
While testing what should be an innocuous patch to add LTO
to a bunch of middle-end warning options
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00381.html
I get Go errors during ordinary bootstrap about undefined names
for errno constants:
/opt/notnfs/msebor/src/gcc/84212/libgo/go/
Hi,
On 9 February 2018 at 09:08, Steve Ellcey wrote:
> I have a question about the poly_uint64 type and the TYPE_VECTOR_SUBPARTS
> macro. I am trying to copy some code from i386.c into my aarch64 build
> that is basically:
>
> int n;
> n = TYPE_VECTOR_SUBPARTS (type_out);
>
> And it is not compi
Snapshot gcc-7-20180208 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/7-20180208/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7
I have a question about the poly_uint64 type and the TYPE_VECTOR_SUBPARTS
macro. I am trying to copy some code from i386.c into my aarch64 build
that is basically:
int n;
n = TYPE_VECTOR_SUBPARTS (type_out);
And it is not compiling for me, I get:
/home/sellcey/gcc-vectmath/src/gcc/gcc/config/aa
On Mon, Feb 5, 2018 at 6:06 AM, Simon Marchi wrote:
> Hi Martin,
>
> Thanks for the reply.
>
> On 2018-02-04 02:17 PM, Martin Sebor wrote:
>> Printing the suffix is unhelpful because it leads to unnecessary
>> differences in diagnostics (even in non-template contexts). For
>> templates with non-t
On 8 February 2018 at 14:05, Paul Smith wrote:
> Isn't the problem with the mangled name, which otherwise would be just
> what we wanted since it's easy to match and is unique in just the way
> we want it to be, that mangling is not standardized?
No, because mangling is standardized:
http://itaniu
On Thu, 2018-02-08 at 11:26 +, Michael Matz wrote:
> As I said upthread, the mangled name of a type (sans _Z prefix) is what is
> stored as the type name for RTTI purposes (i.e. std::type_info::name()).
>
> It's just that the debug info currently doesn't have any reference to that
> definite
On Wed, Feb 7, 2018 at 5:37 AM, Alexandre Oliva wrote:
> Hi,
>
> In this round of GCC stabilization, I've noticed a larger than usual
> number of bugs that carried over from earlier cycles, with notes
> indicating it was too late to fix them during stabilization.
>
> I wish we had some means to ma
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
> 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
Am 08.02.2018 um 10:14 schrieb Rainer Emrich:
> Am 08.02.2018 um 10:00 schrieb Rainer Emrich:
>> Am 06.02.2018 um 19:18 schrieb Jonathan Wakely:
>>> On 6 February 2018 at 18:03, Rainer Emrich wrote:
>>>
At least 20 of the acats tests catch all memory until the host memory is
exhausted.
>
Am 08.02.2018 um 10:00 schrieb Rainer Emrich:
> Am 06.02.2018 um 19:18 schrieb Jonathan Wakely:
>> On 6 February 2018 at 18:03, Rainer Emrich wrote:
>>
>>> At least 20 of the acats tests catch all memory until the host memory is
>>> exhausted.
>>> Same holds for the two libstdc++ tests
>>> 23_cont
Am 06.02.2018 um 19:18 schrieb Jonathan Wakely:
> On 6 February 2018 at 18:03, Rainer Emrich wrote:
>
>> At least 20 of the acats tests catch all memory until the host memory is
>> exhausted.
>> Same holds for the two libstdc++ tests
>> 23_containers/unordered_set/requirements/exception/basic.cc
Am 08.02.2018 um 00:01 schrieb Eric Botcazou:
>> 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 cd
17 matches
Mail list logo
