GNU bug report logs - #46495
28.0.50; [native-comp] Build fails for 32bit --with-wide-int

Previous Next

Full log

Message #56 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, andrewjmoreton <at> gmail.com,
 46495 <at> debbugs.gnu.org
Subject: Re: bug#46495: 28.0.50; [native-comp] Build fails for 32bit
 --with-wide-int
Date: Tue, 16 Feb 2021 19:49:15 +0000

Andrea Corallo via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Andrea Corallo <akrl <at> sdf.org>
>>> Cc: andrewjmoreton <at> gmail.com, 46495 <at> debbugs.gnu.org
>>> Date: Tue, 16 Feb 2021 16:30:46 +0000
>>> 
>>> I did some GCC debugging (the crash is there) using my reduced
>>> reproducer and clearly look (for my case at least) this is a libgccjit
>>> bug that we trigger only generating code for 32bit wide-int.
>>
>> So GCC 10 has a bug when it generates code which manipulates 64-bit
>> integers, is that what you are saying?
>
> It's not strictly related to the integer size.  On 32bit wide-int we
> indeed we generate significantly different code respect to 64bit.  For
> one case of this GCC manage to prove that a piece of code will deference
> a null pointer (this code in reality is unreachable) and tries to add a
> call to __builtin_trap () in place.  Unfortunately the libgccjit
> front-end is not initializing this built-in declaration.  This is as far
> as I've analyzed the problem for now.
>
>>> GCC trunk is broken but as you've anticipated 9 is working (just
>>> finished an Emacs bootstrap).
>>
>> Thanks, this is good to know.  I think we should add an entry to
>> etc/PROBLEMS about this.
>
> Will do, still wants to try 10 to be sure.
>
>> Does the buggy behavior of GCC 10 happen regardless of optimization
>> level?
>
> I think -O0 should spot this as copy-prop is not running.  We might have
> a better (more narrowed) ways to work around this but I need to
> investigate more.  Will follow-up.
>
>>> This evening I'll open a bug on the GCC bugzilla and link it here.
>>> Would be nice to fix it before the end of stage4... :/
>>
>> Thanks.
>
> Welcome
>
>   Andrea

Here the bugzilla bug with some description more:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99126

I think a good work-around might be to try to switch off the
'isolate-paths' pass.

  Andrea

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.