On Thu, Dec 17, 2020 at 10:22 AM Nikhil Benesch
wrote:
>
> On 12/17/20 1:05 PM, Ian Lance Taylor wrote:
> > Thanks for looking into this. I've gotten confused now, though.
> > Which patch fixes the problem on Solaris? Thanks.
> >
> > Ian
>
> The patch I submitted upstream is all that is needed
On 12/17/20 1:05 PM, Ian Lance Taylor wrote:
Thanks for looking into this. I've gotten confused now, though.
Which patch fixes the problem on Solaris? Thanks.
Ian
The patch I submitted upstream is all that is needed to fix the
compilation failures on Solaris:
On Thu, Dec 17, 2020 at 8:31 AM Nikhil Benesch via Gcc-patches
wrote:
>
> On 12/17/20 7:28 AM, Rainer Orth wrote:
> > I first tried with the new version included, but that broke badly:
> >
> > cc1 -fpreprocessed sysinfo.i -quiet -O -std=gnu99
> > -fdump-go-spec=tmp-gen-sysinfo.go -o sysinfo.s
>
On 12/17/20 7:28 AM, Rainer Orth wrote:
I first tried with the new version included, but that broke badly:
cc1 -fpreprocessed sysinfo.i -quiet -O -std=gnu99
-fdump-go-spec=tmp-gen-sysinfo.go -o sysinfo.s
now SEGVs with either infinite or very deep recursion:
Thread 2 received signal SIGSEGV,
Hi Nikhil,
>> I suspect what is happening here is that godump sees "typedef ucontext_t
>> struct
>> ucontext" and outputs the typedef immediately. Only later does it observe
>> that
>> "struct ucontext" is invalid. At that point it is too late to comment out the
>> typedef for _ucontext_t.
>
>
On 12/16/20 3:13 PM, Nikhil Benesch wrote:
On 12/16/20 2:20 PM, Rainer Orth wrote:
Hi Nikhil,
On 12/15/20 3:00 AM, Nikhil Benesch wrote:
If this patch looks good, I'll submit it upstream tomorrow.
Assuming no news is good news, I sent
On 12/16/20 2:20 PM, Rainer Orth wrote:
Hi Nikhil,
On 12/15/20 3:00 AM, Nikhil Benesch wrote:
If this patch looks good, I'll submit it upstream tomorrow.
Assuming no news is good news, I sent
https://go-review.googlesource.com/c/gofrontend/+/278672.
sorry for the delay, but unfortunately
Hi Nikhil,
> On 12/15/20 3:00 AM, Nikhil Benesch wrote:
>> If this patch looks good, I'll submit it upstream tomorrow.
>
> Assuming no news is good news, I sent
> https://go-review.googlesource.com/c/gofrontend/+/278672.
sorry for the delay, but unfortunately news is not so good: I get
On 12/15/20 3:00 AM, Nikhil Benesch wrote:
If this patch looks good, I'll submit it upstream tomorrow.
Assuming no news is good news, I sent
https://go-review.googlesource.com/c/gofrontend/+/278672.
On 12/14/20 10:48 PM, Nikhil Benesch wrote:
On 12/14/20 10:34 PM, Ian Lance Taylor wrote:
On Mon, Dec 14, 2020 at 7:14 PM Nikhil Benesch wrote:
Also godump now emits a dummy `type _u?pad128_t struct {}` entry,
so we just suppress that and conditionally add it back.
I don't understand this
On 12/14/20 10:34 PM, Ian Lance Taylor wrote:
On Mon, Dec 14, 2020 at 7:14 PM Nikhil Benesch wrote:
Also godump now emits a dummy `type _u?pad128_t struct {}` entry,
so we just suppress that and conditionally add it back.
I don't understand this bit. Why are we seeing an empty struct
On Mon, Dec 14, 2020 at 7:14 PM Nikhil Benesch wrote:
>
> On 12/14/20 5:30 AM, Rainer Orth wrote:
> > with the revised godump.c patch and this one for mk*sysinfo.sh, I still
> > get failures on all of Solaris 11.3/x86, 11.4/x86, and 11.4/SPARC
> > (didn't try 11.3/SPARC):
> >
> > * Solaris
On 12/14/20 5:30 AM, Rainer Orth wrote:
with the revised godump.c patch and this one for mk*sysinfo.sh, I still
get failures on all of Solaris 11.3/x86, 11.4/x86, and 11.4/SPARC
(didn't try 11.3/SPARC):
* Solaris 11.3/x86 and 11.4/x86:
runtime_sysinfo.go:5995:6: error: redefinition of
Hi Nikhil,
> On 12/10/20 4:44 PM, Rainer Orth wrote:
>> I'm attaching the -save-temps output, so you can work on the real data
>> rather than trying to figure things out from the Illumos repos.
>
> Thanks, that was helpful. I also have successfully acquired access to
> gcc211, so I should be self
Thanks very much, Ian. I'll submit the second half of the patch (the
changes to mk[r]sysinfo.sh) tomorrow.
On Mon, Dec 14, 2020 at 2:39 AM Ian Lance Taylor wrote:
>
> On Sun, Dec 13, 2020 at 3:30 PM Nikhil Benesch
> wrote:
> >
> > On 12/13/20 4:55 PM, Nikhil Benesch wrote:
> > > There are a
On Sun, Dec 13, 2020 at 3:30 PM Nikhil Benesch wrote:
>
> On 12/13/20 4:55 PM, Nikhil Benesch wrote:
> > There are a few more hurdles before this patch is ready for commit. The
> > changes to godump.c deserve new test cases. [...]
>
> Updated patch attached, as promised, and is ready for review.
On 12/13/20 4:55 PM, Nikhil Benesch wrote:
There are a few more hurdles before this patch is ready for commit. The
changes to godump.c deserve new test cases. [...]
Updated patch attached, as promised, and is ready for review.
gcc/:
* godump.c (go_output_typedef): Suppress typedefs
On 12/10/20 4:44 PM, Rainer Orth wrote:
I'm attaching the -save-temps output, so you can work on the real data
rather than trying to figure things out from the Illumos repos.
Thanks, that was helpful. I also have successfully acquired access to
gcc211, so I should be self sufficient moving
Hi Nikhil,
> On 12/10/20 2:34 PM, Rainer Orth wrote:
>> I've just checked: is effectively unchanged since
>> Solaris 10.
>>
>> Besides, there's gcc211 in the GCC compile farm, running Solaris 11.3/SPARC.
>
> Ah, thanks, I wasn't aware there was a compile farm available to GCC
> developers. I've
On 12/10/20 2:34 PM, Rainer Orth wrote:
I've just checked: is effectively unchanged since
Solaris 10.
Besides, there's gcc211 in the GCC compile farm, running Solaris 11.3/SPARC.
Ah, thanks, I wasn't aware there was a compile farm available to GCC
developers. I've applied for an account, but
Hi Nikhil,
> Sorry about this, Rainer. I think I see the issue, though it's hard to
> be certain without access to a Solaris machine. Assuming the icmp6.h
> header hasn't changed since the last time Solaris code was open source
> [0], I think the issue is likely to be typedefs that define a named
Sorry about this, Rainer. I think I see the issue, though it's hard to
be certain without access to a Solaris machine. Assuming the icmp6.h
header hasn't changed since the last time Solaris code was open source
[0], I think the issue is likely to be typedefs that define a named
struct and an alias
Hi Ian,
> On Tue, Dec 8, 2020 at 2:57 PM Nikhil Benesch
> wrote:
>>
>> This patch corrects -fdump-go-spec's handling of incomplete types.
>> To my knowledge the issue fixed here has not been previously
>> reported. It was exposed by an in-progress port of gccgo to FreeBSD.
>>
>> Given the
On Tue, Dec 8, 2020 at 2:57 PM Nikhil Benesch wrote:
>
> This patch corrects -fdump-go-spec's handling of incomplete types.
> To my knowledge the issue fixed here has not been previously
> reported. It was exposed by an in-progress port of gccgo to FreeBSD.
>
> Given the following C code
>
>
This patch corrects -fdump-go-spec's handling of incomplete types.
To my knowledge the issue fixed here has not been previously
reported. It was exposed by an in-progress port of gccgo to FreeBSD.
Given the following C code
struct s_fwd v_fwd;
struct s_fwd { };
-fdump-go-spec
25 matches
Mail list logo
