Similar to 1467a5c and PR 98412. Bootstrapping on FreeBSD 12.2 with the
default compiler (Clang 10.0.1) fails if the and
headers are included after abort is redefined to fancy_abort.
Appears to be missing defines in the new C++ module code. The following
patch is sufficient.
gcc/cp/ChangeLog:
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 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,
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
https://go-review.googlesource.com/c/gofrontend
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
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
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 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
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,
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
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
for that struct in one shot. I'll start pulling on
that thread.
[0]:
https://github.com/kofemann/opensolaris/blob/80192cd83/usr/src/uts/common/netinet/icmp6.h#L71-L74
On Thu, Dec 10, 2020 at 2:18 PM Rainer Orth
wrote:
>
> Hi Ian,
>
> > On Tue, Dec 8, 2020 at 2:57 PM Nikhil Bene
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
On 11/6/20 12:09 PM, Jeff Law wrote:
So I think the best path forward is to let you and Eduard-Mihai make the
technical decisions about what bits are ready for the trunk. When y'all
think something is ready, let's go ahead and get it installed and
iterate on things that aren't quite ready yet.
On 11/1/20 6:57 AM, Eduard-Mihai Burtescu wrote:
Reading the diff patch, the v0 changes look great. I wouldn't be too worried
about the "printable character" aspect, there are similar Unicode-related
issues elsewhere, e.g. the "non-control ASCII" comment in decode_legacy_escape
(I suppose we
On 10/29/20 12:16 AM, Nikhil Benesch wrote:
On Wed, Oct 28, 2020 at 7:53 PM Eduard-Mihai Burtescu wrote:
I agree that landing the extra changes later on top should be fine anyway,
though when I make the sprintf -> snprintf change, I could provide the extra
changes as well (eit
On Wed, Oct 28, 2020 at 7:53 PM Eduard-Mihai Burtescu wrote:
> I agree that landing the extra changes later on top should be fine anyway,
> though when I make the sprintf -> snprintf change, I could provide the extra
> changes as well (either as a combined patch, or as a second tiny patch).
>
>
plates with value parameters, enabling e.g. types like
> `CustomArray`), which supports a few different kinds of primitive
> values, whereas the original patch only handled unsigned integers.
>
> Thanks,
> - Eddy B.
>
> On Wed, Oct 28, 2020, at 23:25, Nikhil Benesch wrote:
> &g
On 10/28/20 5:22 PM, Nikhil Benesch wrote:
Ian, are you able to review this? I saw that you reviewed many of the
prior changes to the Rust demangler.
If not, can you suggest someone who can?
Thanks very much.
Nikhil
I seem to have failed to convince my email client to set the appropriate
Ian, are you able to review this? I saw that you reviewed many of the
prior changes to the Rust demangler.
If not, can you suggest someone who can?
Thanks very much.
Nikhil
Ian—is there anything preventing this from getting merged? (I don't have
write access.)
On Thu, Jan 24, 2019 at 11:31 AM Nikhil Benesch
wrote:
> On Thu, Jan 24, 2019 at 10:15 AM Richard Biener
> wrote:
> >
> > Ah, I missed that pt is probably a pointer type as well, then t
to work for all the
build/host/target combination possibilities.)
On Fri, Jan 25, 2019 at 12:18 PM Joseph Myers wrote:
>
> On Fri, 25 Jan 2019, Nikhil Benesch wrote:
>
> > I am attempting to convince GCC to build target libraries with link-time
> > optimizations enabled. I am
I am attempting to convince GCC to build target libraries with link-time
optimizations enabled. I am primarily interested in libgo, but this discussion
seems like it would be applicable to libstdc++, libgfortran, etc. The
benchmarking I've done suggests that LTOing libgo yields a 5-20% speedup on
On Thu, Jan 24, 2019 at 10:15 AM Richard Biener
wrote:
>
> Ah, I missed that pt is probably a pointer type as well, then the code
> simply aligns the pointed-to type (note dependent on how pt was built
> this seems prone to wreck the TYPE_POINTER_TO/TYPE_NEXT_PTR_TO
> chains which link pointer
On Thu, Jan 24, 2019 at 6:01 AM Richard Biener
wrote:
>
> On Thu, Jan 24, 2019 at 2:18 AM Nikhil Benesch
> wrote:
> >
> > diff --git a/gcc/go/go-gcc.cc b/gcc/go/go-gcc.cc
> > index 7fbdd074119..4e9e0e3026a 100644
> > --- a/gcc/go/go-gcc.cc
> > +++ b/
test coverage by adding
a subtest to the Go torture test suite that compiles with -flto.
Bootstrapped and ran Go test suite on x86_64-pc-linux-gnu.
2018-01-23 Nikhil Benesch
PR go/89019
* go-gcc.cc (Gcc_backend::placeholder_struct_type): Mark
placeholder structs
that is currently mishandled by -fdump-go-spec. This
results in the build getting stuck in libgo/mksysinfo.sh.
2018-11-22 Nikhil Benesch
* gcc/godump.c (go_output_typedef): When outputting a typedef, use
the refer to the underlying type by its name and not its structure
29 matches
Mail list logo
