On Thu, 13 Aug 2020 17:38:41 +0400 Gleb Popov wrote:
> Still, I'm curious where I can get __atomic_load_n in an i386 case, if I
> don't want to pull in gcc?
There's an implementation in libcompiler_rt but we don't build it. It
doesn't look correct in this case because it seems to use FILDLL.
___
On Wed, Aug 12, 2020 at 3:42 PM Tijl Coosemans wrote:
> On Wed, 12 Aug 2020 09:44:25 +0400 Gleb Popov wrote:
> > On Wed, Aug 12, 2020 at 9:21 AM Gleb Popov wrote:
> >> Indeed, this looks like a culprit! When compiling using first command
> line
> >> (the long one) I get following warnings:
> >>
On Wed, 12 Aug 2020 17:35:17 +0300 Konstantin Belousov
wrote:
> On Wed, Aug 12, 2020 at 01:41:58PM +0200, Tijl Coosemans wrote:
>> StgWord64 is uint64_t which is unsigned long long which is 4 byte
>> aligned on i386. Clang wants 8 byte alignment to use the fildll
>> instruction.
> This all is ve
On Wed, Aug 12, 2020 at 01:41:58PM +0200, Tijl Coosemans wrote:
> On Wed, 12 Aug 2020 09:44:25 +0400 Gleb Popov wrote:
> > On Wed, Aug 12, 2020 at 9:21 AM Gleb Popov wrote:
> >> Indeed, this looks like a culprit! When compiling using first command line
> >> (the long one) I get following warnings:
On Wed, 12 Aug 2020 09:44:25 +0400 Gleb Popov wrote:
> On Wed, Aug 12, 2020 at 9:21 AM Gleb Popov wrote:
>> Indeed, this looks like a culprit! When compiling using first command line
>> (the long one) I get following warnings:
>>
>> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/c
On Wed, Aug 12, 2020 at 9:21 AM Gleb Popov wrote:
> Indeed, this looks like a culprit! When compiling using first command line
> (the long one) I get following warnings:
>
> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/cbits/atomic.c:369:10:
> warning: misaligned atomic operatio
On Wed, Aug 12, 2020 at 1:52 AM Tijl Coosemans wrote:
> On Tue, 11 Aug 2020 15:56:35 +0400 Gleb Popov wrote:
> > On Sun, Aug 9, 2020 at 7:43 PM Konstantin Belousov
> > wrote:
> >
> > > I do not believe there were any change in the toolchain between p2 and
> p7,
> > > this is more likely indicate
On Tue, 11 Aug 2020 15:56:35 +0400 Gleb Popov wrote:
> On Sun, Aug 9, 2020 at 7:43 PM Konstantin Belousov
> wrote:
>
> > I do not believe there were any change in the toolchain between p2 and p7,
> > this is more likely indicates some fluctuation in the build. The only
> > change that could be
On Tue, Aug 11, 2020 at 03:56:35PM +0400, Gleb Popov wrote:
> On Sun, Aug 9, 2020 at 7:43 PM Konstantin Belousov
> wrote:
>
> > I do not believe there were any change in the toolchain between p2 and p7,
> > this is more likely indicates some fluctuation in the build. The only
> > change that cou
On Sun, Aug 9, 2020 at 4:37 PM Tijl Coosemans wrote:
> On Sun, 9 Aug 2020 15:36:51 +0400 Gleb Popov wrote:
> > On Sat, Aug 8, 2020 at 5:30 PM Konstantin Belousov
> > wrote:
> >> For code generated by gcc or clang, yes.
> >> If the reference to the symbol was generated by ghc, then I do not know.
On Sun, Aug 9, 2020 at 7:43 PM Konstantin Belousov
wrote:
> I do not believe there were any change in the toolchain between p2 and p7,
> this is more likely indicates some fluctuation in the build. The only
> change that could be even remotely declared as possibly related is
> EN-20:10.build r36
On Sun, Aug 09, 2020 at 02:37:42PM +0200, Tijl Coosemans wrote:
> On Sun, 9 Aug 2020 15:36:51 +0400 Gleb Popov wrote:
> > On Sat, Aug 8, 2020 at 5:30 PM Konstantin Belousov
> > wrote:
> >> For code generated by gcc or clang, yes.
> >> If the reference to the symbol was generated by ghc, then I do
On Sun, 9 Aug 2020 15:36:51 +0400 Gleb Popov wrote:
> On Sat, Aug 8, 2020 at 5:30 PM Konstantin Belousov
> wrote:
>> For code generated by gcc or clang, yes.
>> If the reference to the symbol was generated by ghc, then I do not know.
>
> This doesn't seem to work.
>
> The code referencing __ato
On Sat, Aug 8, 2020 at 5:30 PM Konstantin Belousov
wrote:
> For code generated by gcc or clang, yes.
> If the reference to the symbol was generated by ghc, then I do not know.
>
This doesn't seem to work.
The code referencing __atomic_load_n() is C and GHC buildsystem already
passes -march=i686
l compiler) and it fails to link
>>> to i386 architectures with
>>>
>>> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.6.1-ghc8.10.1.so:
>>> undefined reference to `__atomic_store_8'
>>>
>>>
of GHC (Haskell compiler) and it fails to link
> > to
> > > i386 architectures with
> > >
> > >
> > /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-install/build/
> > > libHSghc-prim-0.6.1-ghc8.10.1.so: undefined reference to
>
t; >
> >
> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-install/build/
> > libHSghc-prim-0.6.1-ghc8.10.1.so: undefined reference to
> `__atomic_store_8'
> >
> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-in
/
> libHSghc-prim-0.6.1-ghc8.10.1.so: undefined reference to `__atomic_store_8'
> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-install/build/
> libHSghc-prim-0.6.1-ghc8.10.1.so: undefined reference to `__atomic_load_8'
>
> Any suggestions on how to fix
Hello toolchain@
I'm testing a new release of GHC (Haskell compiler) and it fails to link to
i386 architectures with
/wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.1/libraries/ghc-prim/dist-install/build/
libHSghc-prim-0.6.1-ghc8.10.1.so: undefined reference to `__atomic_store_8'
/wrkdirs
19 matches
Mail list logo
