On Tue, Oct 25, 2016 at 7:06 PM, Jakub Jelinek wrote:
>
> I think this patch should fix it, will bootstrap/regtest it now:
>
Yes, the fails in gdb.cp/member-ptr.exp go away with the patched g++.
I run gdb.cp/member-ptr.exp with three different c++ variations,
Schedule of variations:
unix/-st
On Tue, Oct 25, 2016 at 04:05:30PM +0100, Andre Vieira (lists) wrote:
> I built gcc for the following:
> 1) revision r241135
> 2) revision r241135 + cherry-picked your patch in revision r241137
> (skipped the patch in revision r241136 because that gives a build failure).
> 3) trunk + patch in http
On 21/10/16 16:14, Jakub Jelinek wrote:
> On Fri, Oct 21, 2016 at 03:57:34PM +0100, Yao Qi wrote:
>> Hi Jakub,
>>
>> On Thu, Oct 20, 2016 at 5:21 PM, Andre Vieira (lists)
>> wrote:
>>> <2><8f5>: Abbrev Number: 38 (DW_TAG_member)
>>> <8f6> DW_AT_specification: <0x8be>
>>> <8fa> DW_AT_l
On Fri, Oct 21, 2016 at 03:57:34PM +0100, Yao Qi wrote:
> Hi Jakub,
>
> On Thu, Oct 20, 2016 at 5:21 PM, Andre Vieira (lists)
> wrote:
> > <2><8f5>: Abbrev Number: 38 (DW_TAG_member)
> > <8f6> DW_AT_specification: <0x8be>
> > <8fa> DW_AT_linkage_name: (indirect string, offset: 0x4a0)
Hi Jakub,
On Thu, Oct 20, 2016 at 5:21 PM, Andre Vieira (lists)
wrote:
> <2><8f5>: Abbrev Number: 38 (DW_TAG_member)
> <8f6> DW_AT_specification: <0x8be>
> <8fa> DW_AT_linkage_name: (indirect string, offset: 0x4a0):
> _ZN6BANANA1sE
> <8fe> DW_AT_location: 5 byte block: 3 64
> Does this fix it? It still works on Linux:
>
> 2016-10-20 Jakub Jelinek
>
> * g++.dg/cpp1z/inline-var1.C (w): Initialize to 64 + 2.
Yes, it does, thanks!
--
Eric Botcazou
On 13/10/16 20:34, Jason Merrill wrote:
> On Tue, Oct 11, 2016 at 9:39 AM, Jakub Jelinek wrote:
>
>> And, as mentioned in the DWARF mailing list, I think we should emit
>> DW_AT_inline on the inline vars (both explicit and implicit - static
>> constexpr data members in C++17 mode). I hope that
On Thu, Oct 20, 2016 at 01:22:16PM +0200, Eric Botcazou wrote:
> If fails because x == 16 and w == 0 on the first invocation to bar but, given
> that w is not modified anywhere else, this seems to be expected.
Does this fix it? It still works on Linux:
2016-10-20 Jakub Jelinek
* g++
> The test wants to ensure:
> 1) the foo calls in the ctors are invoked in increasing order (this is used
>for inline vars defined in both CUs)
> 2) ensure that the first bar call in the ctors is invoked after foo (5)
> 3) that bar used in ctors (it is used for inline vars defined in one or the
On Thu, Oct 20, 2016 at 12:50:56PM +0200, Eric Botcazou wrote:
> > testsuite/
> > * g++.dg/cpp1z/inline-var1.C: New test.
> > * g++.dg/cpp1z/inline-var1a.C: New test.
> > * g++.dg/cpp1z/inline-var1.h: New file.
>
> This one fails on SPARC/Solaris:
>
> 0xfefcaa58 in _lwp_kill () from /
> testsuite/
> * g++.dg/cpp1z/inline-var1.C: New test.
> * g++.dg/cpp1z/inline-var1a.C: New test.
> * g++.dg/cpp1z/inline-var1.h: New file.
This one fails on SPARC/Solaris:
0xfefcaa58 in _lwp_kill () from /lib/libc.so.1
(gdb) bt
#0 0xfefcaa58 in _lwp_kill () from /lib/libc.so.1
On Tue, Oct 11, 2016 at 9:39 AM, Jakub Jelinek wrote:
> Here is an attempt to implement C++17 inline variables.
> Bootstrapped/regtested on x86_64-linux and i686-linux.
>
> The main question is if the inline variables, which are vague linkage,
> should be !DECL_EXTERNAL or DECL_EXTERNAL DECL_NOT_R
Hi!
Here is an attempt to implement C++17 inline variables.
Bootstrapped/regtested on x86_64-linux and i686-linux.
The main question is if the inline variables, which are vague linkage,
should be !DECL_EXTERNAL or DECL_EXTERNAL DECL_NOT_REALLY_EXTERN while
in the FE. In the patch, they are !DECL
13 matches
Mail list logo
