On 16.09.2014 10:53, Andrey Chernov wrote:
>
> Probably it have sense to track down and look at first post-4.7 gcc/tree.c
> change which cause fail (gcc47 works with BOOTSTRAP=off).
>
>> Anybody have an idea what kind of magic in gcc is changed, when this
>> DEV-PHASE file is altered? Some debu
On 15.09.2014 22:00, Dimitry Andric wrote:
> On 14 Sep 2014, at 19:27, Dimitry Andric wrote:
> ...
>> In any case, I have now narrowed it down to gcc/tree.c, which is not a
>> very small file, and which is changed very often upstream, sometimes
>> almost daily.
>>
>> So I will see if I can reprodu
On 14 Sep 2014, at 19:27, Dimitry Andric wrote:
...
> In any case, I have now narrowed it down to gcc/tree.c, which is not a
> very small file, and which is changed very often upstream, sometimes
> almost daily.
>
> So I will see if I can reproduce it with gcc trunk first, and if that
> turns out
On 13 Sep 2014, at 20:52, Andrey Chernov wrote:
> On 13.09.2014 22:30, Dimitry Andric wrote:
>>> By first glance I see a lots of things. It is known that
>>> in edge cases gcc preserves more "unused" values than clang. It can be
>>> the possible case. I'll try to lower -O level preserving -march=
On 13.09.2014 22:30, Dimitry Andric wrote:
>> By first glance I see a lots of things. It is known that
>> in edge cases gcc preserves more "unused" values than clang. It can be
>> the possible case. I'll try to lower -O level preserving -march=core2
>> and see.
>
> It seems to work for me with -O
On 13 Sep 2014, at 20:00, Andrey Chernov wrote:
> On 13.09.2014 20:45, Dimitry Andric wrote:
>> After some massaging of gcc's source to disable its built-in segfault
>> handlers, I get this backtrace:
>
> Do you get this with my core or finally able to reproduce it by yourself?
I was able to rep
On 13.09.2014 20:45, Dimitry Andric wrote:
> After some massaging of gcc's source to disable its built-in segfault
> handlers, I get this backtrace:
Do you get this with my core or finally able to reproduce it by yourself?
> I think it's most likely this is some type of undefined behavior in gcc,
On 12 Sep 2014, at 22:52, Andrey Chernov wrote:
> On 13.09.2014 0:44, Andrey Chernov wrote:
>> On 12.09.2014 22:40, Andrey Chernov wrote:
>>> I don't have -current & i386 combination, but I can try -current & x64
>>> later (with different -march).
>>
>> It works on -current, amd64, -march=core2.
On 13.09.2014 0:44, Andrey Chernov wrote:
> On 12.09.2014 22:40, Andrey Chernov wrote:
>> I don't have -current & i386 combination, but I can try -current & x64 later
>> (with different -march).
>
> It works on -current, amd64, -march=core2. So it either -stable or
> i386-specific clang bug.
>
On 12.09.2014 22:40, Andrey Chernov wrote:
> I don't have -current & i386 combination, but I can try -current & x64 later
> (with different -march).
It works on -current, amd64, -march=core2. So it either -stable or
i386-specific clang bug.
--
http://ache.vniz.net/
signature.asc
Description:
On 12.09.2014 21:20, Dimitry Andric wrote:
> Do you also have a coredump of the crashed process?
Core file bzipped:
http://rghost.ru/57982669
--
http://ache.vniz.net/
signature.asc
Description: OpenPGP digital signature
On 12.09.2014 22:40, Andrey Chernov wrote:
> As you see, last meaningful info say something about "locale". If system
> locale assumed here, I use ru_RU.KOI8-R. I try to check this thing with
> LANG=C later.
Does not help. The same fault with LANG=C too.
--
http://ache.vniz.net/
signature.a
On 12.09.2014 21:20, Dimitry Andric wrote:
> On 12 Sep 2014, at 17:01, Andrey Chernov wrote:
>>
>> Please look at this thread. At the end the bug trigger found, since
>> removing -march=core2 fix the thing. tijl@ suspects that clang produce
>> 64bit instruction on i386 in that case.
>>
>> https://
On 12 Sep 2014, at 17:01, Andrey Chernov wrote:
>
> Please look at this thread. At the end the bug trigger found, since
> removing -march=core2 fix the thing. tijl@ suspects that clang produce
> 64bit instruction on i386 in that case.
>
> https://lists.freebsd.org/pipermail/freebsd-ports/2014-Se
Hi.
Please look at this thread. At the end the bug trigger found, since
removing -march=core2 fix the thing. tijl@ suspects that clang produce
64bit instruction on i386 in that case.
https://lists.freebsd.org/pipermail/freebsd-ports/2014-September/095466.html
--
http://ache.vniz.net/
___
15 matches
Mail list logo
