Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues
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 cd2b11a cd2b15c >> ce2102l ce2102m ce2103a ce2103b ce3102d ce3107a ce3115a cxa4005 cxa4008 >> cxa4016 cxa4019 cxac003 cxb3012 cxf3a01 cxf3a02 >> /opt/devel/gnu/src/gcc-mingw-w64/gcc-8.0.0/gcc/testsuite/ada/acats/run_all.s >> h completed at Wed Feb 7 12:28:36 CET 2018 > > Please open a PR for the ACATS regressions on mainline. > PR84277, done. signature.asc Description: OpenPGP digital signature
Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues
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
>> and
>> 23_containers/unordered_set/requirements/exception/propagation_consistent.cc
>
> Are these new failures? What changed? Where does it get stuck?
>
Some of my observations, I don't know whats expected:
In the function populate p(container_control)
"make_container_n made(n);" is called with n=82.
This allocates nearly 16GByte on memory. Is this expected?
Before the call to run_steps_to_limit(container_control, f) the
container_control structure has:
_M_bucket_count = 2019773507
_M_element_count = 82
_M_rehash_policy = {static _S_growth_factor = 2, _M_max_load_factor = 1,
_M_next_resize = 2019773507}
To answer my own question, that's not expected. So at this state it's
already wrong.
signature.asc
Description: OpenPGP digital signature
Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues
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_containers/unordered_set/requirements/exception/basic.cc
>>> and
>>> 23_containers/unordered_set/requirements/exception/propagation_consistent.cc
>>
>> Are these new failures? What changed? Where does it get stuck?
>>
>
> Some of my observations, I don't know whats expected:
>
> In the function populate p(container_control)
> "make_container_n made(n);" is called with n=82.
> This allocates nearly 16GByte on memory. Is this expected?
>
> Before the call to run_steps_to_limit(container_control, f) the
> container_control structure has:
> _M_bucket_count = 2019773507
> _M_element_count = 82
> _M_rehash_policy = {static _S_growth_factor = 2, _M_max_load_factor = 1,
> _M_next_resize = 2019773507}
>
> To answer my own question, that's not expected. So at this state it's
> already wrong.
>
Forgot to mention that's for
23_containers/unordered_set/requirements/exception/propagation_consistent.cc.
signature.asc
Description: OpenPGP digital signature
Re: GCC 8.0.0 status on x86_64-w64-mingw32, some issues
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.
Same holds for the two libstdc++ tests
23_containers/unordered_set/requirements/exception/basic.cc
and
23_containers/unordered_set/requirements/exception/propagation_consistent.cc
>>>
>>> Are these new failures? What changed? Where does it get stuck?
>>>
>>
>> Some of my observations, I don't know whats expected:
>>
>> In the function populate p(container_control)
>> "make_container_n made(n);" is called with n=82.
>> This allocates nearly 16GByte on memory. Is this expected?
>>
>> Before the call to run_steps_to_limit(container_control, f) the
>> container_control structure has:
>> _M_bucket_count = 2019773507
>> _M_element_count = 82
>> _M_rehash_policy = {static _S_growth_factor = 2, _M_max_load_factor = 1,
>> _M_next_resize = 2019773507}
>>
>> To answer my own question, that's not expected. So at this state it's
>> already wrong.
>>
> Forgot to mention that's for
> 23_containers/unordered_set/requirements/exception/propagation_consistent.cc.
>
For 23_containers/unordered_set/requirements/exception/basic.cc the
situation is a little bit different. During the fifth invocation of
run_steps_to_limit(i, container, f) about 32 GByte are allocated.
Interesstingly the output seems right:
N10__gnu_test12functor_base12insert_pointISt13unordered_setIN9__gnu_cxx17throw_value_limitESt4hashIS4_ESt8equal_toIS4_ENS3_21throw_allocator_limitIS4_EEELb1ELb0EEE
end count 7
But the container structure is nonesense after the call:
_M_bucket_count = 4294967291
_M_element_count = 77
_M_rehash_policy = {static _S_growth_factor = 2, _M_max_load_factor = 1,
_M_next_resize = 18446744073709551615}
I hope that helps.
signature.asc
Description: OpenPGP digital signature
Re: gdb 8.x - g++ 7.x compatibility
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 class name (e.g. "Foo<10>"). That wouldn't make sense, since > >> there's no symbol for the class itself. > > > > echo _Z3FooILi10EE | c++filt > > Ok, thanks for the precision! 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 definitely-unique string, only to the "human-friendly" name, which somewhat resembles the demangled name (and that's exactly the crux, it really isn't the demangled one right now, as you found out the painful way). Ciao, Michael.
Re: finding bugs deferred from previous releases
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 mark such bugs clearly, so that they could > be found easily earlier in the development cycles, instead of lingering > on until we find it's too late again. > > Just targeting it to a future release might be enough during > stabilization, but later on, it will be hard to tell these cases apart > from other bugs for which we didn't make such assessment, and that could > in theory still be addressed during the next round of stabilization. > > What I wish for is some means to find these bugs easily, while we're > earlier in a development cycle. We could mark them as we go through the > current regressions list, so that others wouldn't look at them again in > this cycle, but could find them at any point in the next. > > Just bumping the target milestone would address part of the problem: it > would help exclude it from bug lists that need fixing in this cycle. > However, it wouldn't help locate these bugs during the next cycle, since > at some point GCC8 will be out and the target milestone for all unfixed > bugs will be bumped. Also, when we get to GCC9 stabilization, it would > be nice to have some means to defer again any bugs that, during the > earlier stabilization cycles, were deemed unfixable in the stabilization > phase, so as to defer them again. > > Any thoughts on how to mark such bugs in bugzilla? Add a 'defered' keyword? Richard. > -- > Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ > You must be the change you wish to see in the world. -- Gandhi > Be Free! -- http://FSFLA.org/ FSF Latin America board member > Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
Re: gdb 8.x - g++ 7.x compatibility
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 > definitely-unique string, only to the "human-friendly" name, which > somewhat resembles the demangled name (and that's exactly the crux, it > really isn't the demangled one right now, as you found out the painful > way). 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? If GDB relied on the mangled name it would need to incorporate demanglers for any compiler that it wanted to be able to debug and figure out which demangler to use when it was trying to debug a program. This goes against the concept of a common debug format like DWARF I would expect.
Re: gdb 8.x - g++ 7.x compatibility
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://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling The *demangled* name doesn't have a fixed, canonical form.
Re: gdb 8.x - g++ 7.x compatibility
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-type template parameters there is no difference
>> between, say A<1>, A<1U>, A<(unsigned) 1>, or even A when
>> Green is an enumerator that evaluates to 1, so including the suffix
>> serves no useful purpose.
>
> This is the part I don't understand. In Roman's example, spelling
> foo<10> and foo<10u> resulted in two different instantiations of the
> template, with different code. So that means it can make a difference,
> can't it?
>
>> In the GCC test suite, it would tend to
>> cause failures due to differences between the underlying type of
>> common typedefs like size_t and ptrdiff_t. Avoiding these
>> unnecessary differences was the main motivation for the change.
>> Not necessarily just in the GCC test suite but in all setups that
>> process GCC messages.
>
> Ok, I understand.
>
>> I didn't consider the use of auto as a template parameter but
>> I don't think it changes anything. There, just like in other
>> contexts, what's important is the deduced types and the values
>> of constants, not the minute details of how they are spelled.
>
> Well, it seems like using decltype on a template constant value is
> a way to make the type of constants important, in addition to their
> value. I know the standard seems to say otherwise (what Manfred
> quoted), but the reality seems different. I'm not a language expert
> so I can't tell if this is a deficiency in the language or not.
>
>> That said, it wasn't my intention to make things difficult for
>> the debugger.
>
> I hope so :).
>
>> But changing GCC back to include the suffix,
>> even just in the debug info, isn't a solution. There are other
>> compilers besides GCC that don't emit the suffixes, and there
>> even are some that prepend a cast to the number, so if GDB is
>> to be usable with all these kinds of producers it needs to be
>> able to handle all of these forms.
>
> As I said earlier, there are probably ways to make GDB cope with it.
> The only solution I saw (I'd like to hear about other ones) was to make
> GDB ignore the template part in DW_AT_name and re-build it from the
> DW_TAG_template_* DIEs in the format it expects. It can already do
> that somewhat, because, as you said, some compilers don't emit
> the template part in DW_AT_name.
>
> Doing so would cause major slowdowns in symbol reading, I've tried it
> for the sake of experimentation/discussion. I have a patch available
> on the "users/simark/template-suffix" branch in the binutils-gdb
> repo [1]. It works for Roman's example, but running the GDB testsuite
> shows that, of course, the devil is in the details.
>
> Consider something like this:
>
> template
> struct foo { virtual ~foo() {} };
>
> int n;
>
> int main ()
> {
> foo<&n> f;
> }
>
>
> The demangled name that GDB will be looking up is "foo<&n>". The
> debug info about the template parameter only contains the resulting
> address of n (the value of &n):
>
> <2>: Abbrev Number: 11 (DW_TAG_template_value_param)
>DW_AT_name: P
>DW_AT_type: <0x1ac>
>DW_AT_location: 10 byte block: 3 34 10 60 0 0 0 0 0 9f
> (DW_OP_addr: 601034; DW_OP_stack_value)
>
> I don't see how GDB could reconstruct the "&n" in the template, so
> that's where my idea falls short.
For other reasons I've always wanted sth like
DW_OP_addr; DW_OP_name: n; DW_OP_stack_value
thus put symbolical expressions in locations and have the consumer look them up
(in context obviously). That way gdb can also choose to print foo instead of
foo<1> or foo<>.
Of course that needs DWARF extensions.
Richard.
> Simon
>
> [1]
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=shortlog;h=refs/heads/users/simark/template-suffix
poly_uint64 / TYPE_VECTOR_SUBPARTS question
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/aarch64/aarch64-builtins.c:1504:37:
error: cannot convert ‘poly_uint64’ {aka ‘poly_int<2, long unsigned int>’} to
‘int’ in assignment
n = TYPE_VECTOR_SUBPARTS (type_out);
My first thought was that I was missing a header file but I put
all the header includes that are in i386.c into aarch64-builtins.c
and it still does not compile. It works on the i386 side. It looks
like poly-int.h and poly-int-types.h are included by coretypes.h
and I include that header file so I don't understand why this isn't
compiling and what I am missing. Any help?
Steve Ellcey
sell...@cavium.com
gcc-7-20180208 is now available
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-branch revision 257505 You'll find: gcc-7-20180208.tar.xzComplete GCC SHA256=0339d55f00b24ab9ea597acefdd1fe02c1ae7701b1770a38cd64d1ec941fbe9c SHA1=a34ec4841b50c9e09c4d9603004e042bc00c819c Diffs from 7-20180201 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: poly_uint64 / TYPE_VECTOR_SUBPARTS question
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 compiling for me, I get:
>
> /home/sellcey/gcc-vectmath/src/gcc/gcc/config/aarch64/aarch64-builtins.c:1504:37:
> error: cannot convert ‘poly_uint64’ {aka ‘poly_int<2, long unsigned int>’}
> to ‘int’ in assignment
>n = TYPE_VECTOR_SUBPARTS (type_out);
AFIK, you could use to_constant () if known to be a compile time constant.
Thanks,
Kugan
>
> My first thought was that I was missing a header file but I put
> all the header includes that are in i386.c into aarch64-builtins.c
> and it still does not compile. It works on the i386 side. It looks
> like poly-int.h and poly-int-types.h are included by coretypes.h
> and I include that header file so I don't understand why this isn't
> compiling and what I am missing. Any help?
>
> Steve Ellcey
> sell...@cavium.com
how to debug go build errors
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/syscall/env_unix.go:96:10: error: reference to undefined name ‘EINVAL’ Bootstrapping all other front ends (including Ada and Brig), succeeds and there are no regressions in the test suite. I have no experience with Go. Does anything about the patch jump out at you that could be causing this? If not, can you suggest how to debug it? Thanks Martin
Re: how to debug go build errors
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 errno constants: > > /opt/notnfs/msebor/src/gcc/84212/libgo/go/syscall/env_unix.go:96:10: error: > reference to undefined name ‘EINVAL’ > > Bootstrapping all other front ends (including Ada and Brig), > succeeds and there are no regressions in the test suite. > > I have no experience with Go. Does anything about the patch > jump out at you that could be causing this? If not, can you > suggest how to debug it? No, I don't see why your patch would cause this problem. EINVAL should be defined in the generated file TARGET/libgo/sysinfo.go. You should see, among many others, the lines const _EINVAL = 22 and const EINVAL = Errno(_EINVAL) That file is built by the shell script libgo/mksysinfo.sh, which looks at the generated file TARGET/libgo/gen-sysinfo.go. The gen-sysinfo.go file is built by running the C compiler with the -fdump-go-spec option on the file libgo/sysinfo.c (essentially GCC_FOR_TARGET -fdump-go-spec=gen-sysinfo.go -std=gnu99 -S sysinfo.c). I guess something along that chain has broken, but I don't know what. Ian
Re: how to debug go build errors
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! @@ -1186,7 +1186,6 @@ ansi C ObjC C++ ObjC++ A synonym for -std=c89 (for C) or -std=c++98 (for C++). -d C ObjC C++ ObjC++ Joined ; Documented in common.opt. FIXME - what about -dI, -dD, -dN and -dD? Sorry for the noise! On 02/08/2018 04:24 PM, Martin Sebor wrote: 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/syscall/env_unix.go:96:10: error: reference to undefined name ‘EINVAL’ Bootstrapping all other front ends (including Ada and Brig), succeeds and there are no regressions in the test suite. I have no experience with Go. Does anything about the patch jump out at you that could be causing this? If not, can you suggest how to debug it? Thanks Martin
Re: how to debug go build errors
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 bootstrap about undefined names for errno constants: /opt/notnfs/msebor/src/gcc/84212/libgo/go/syscall/env_unix.go:96:10: error: reference to undefined name ‘EINVAL’ Bootstrapping all other front ends (including Ada and Brig), succeeds and there are no regressions in the test suite. I have no experience with Go. Does anything about the patch jump out at you that could be causing this? If not, can you suggest how to debug it? No, I don't see why your patch would cause this problem. EINVAL should be defined in the generated file TARGET/libgo/sysinfo.go. You should see, among many others, the lines const _EINVAL = 22 and const EINVAL = Errno(_EINVAL) That file is built by the shell script libgo/mksysinfo.sh, which looks at the generated file TARGET/libgo/gen-sysinfo.go. The gen-sysinfo.go file is built by running the C compiler with the -fdump-go-spec option on the file libgo/sysinfo.c (essentially GCC_FOR_TARGET -fdump-go-spec=gen-sysinfo.go -std=gnu99 -S sysinfo.c). I guess something along that chain has broken, but I don't know what. I've figured out what was causing it -- a silly typo. (Our emails must have crossed by barely a couple of minutes). Thanks for the quick reply though! Martin
Re: gcc 7.3: Replacing global operator new/delete in shared libraries
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 compiler "magic" the
-fvisibility=hidden compile-time attribute is ignored when it comes to
global operator new/delete. Similarly, it's a compiler error to force
visibility("hidden") in the declaration via __attribute__.
The only way to get operator new/delete to be hidden inside a shared
library is to really force it using a linker script that declares them
"local:" specifically.
