On Wed, Oct 19, 2016 at 6:23 AM, Richard Biener
<richard.guent...@gmail.com> wrote:
> On Wed, Oct 19, 2016 at 3:17 PM, Ian Lance Taylor <i...@golang.org> wrote:
>> On Wed, Oct 19, 2016 at 4:30 AM, Richard Biener
>> <richard.guent...@gmail.com> wrote:
>>> On Mon, Oct 17, 2016 at 6:54 PM, Ian Lance Taylor <i...@golang.org> wrote:
>>>> This patch to libgo copies the rdebug code from the Go 1.7 runtime to 
>>>> libgo.
>>>>
>>>> While we're at it, this updates the runtime/debug package, and starts
>>>> running its testsuite by default.  I'm not sure why runtime/debug was
>>>> not previously updated to 1.7.  Doing that led me to fix some minor
>>>> aspects of runtime.Stack and the C function runtime/debug.readGCStats.
>>>>
>>>> Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.  Committed
>>>> to mainline.
>>>
>>> Not sure which of the merges broke it but I get
>>>
>>> ...
>>> rc/svn/trunk2/libgo/go/runtime/time.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/trace.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/traceback_gccgo.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/type.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/typekind.go
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/write_err.go
>>> runtime_sysinfo.go  -fPIC -o .libs/runtime-go.o
>>> /space/rguenther/src/svn/trunk2/libgo/go/runtime/netpoll_epoll.go:52:49:
>>> error:integer constant overflow
>>>   ev.events = _EPOLLIN | _EPOLLOUT | _EPOLLRDHUP | _EPOLLET
>>>                                                  ^
>>> make[4]: *** [runtime-go.lo] Error 1
>>>
>>> now and bootstrap is broken for me.  This is on x86_64-linux, SLES 11
>>> SP4 which uses glibc 2.11.3.
>>
>> Is this the 32-bit or 64-bit build?
>
> Hum, don't remember ...
>
>> What is the output of
>>
>> find x86_64-pc-linux-gnu -name runtime_sysinfo.go | xargs grep EPOLLET
>>
>> in your build directory?
>
> x86_64-pc-linux-gnu/32/libgo/runtime_sysinfo.go:const _EPOLLET = -2147483648
> x86_64-pc-linux-gnu/libgo/runtime_sysinfo.go:const _EPOLLET = -2147483648
>
> looks like the culprit.  All other _EPOLL* constants are positive

I have not been able to recreate the problem.  Perhaps the definition
of EPOLLET in your <sys/epoll.h> file is different; on my system the
definition is

    EPOLLET = 1u << 31

In any case, I have committed this patch which I believe will fix the
problem.  Bootstrapped and tested on x86_64-pc-linux-gnu on a system
that does not show the problem anyhow.

Ian

Reply via email to