On Fri, 21 Aug 2020 14:54:35 +0400 Gleb Popov wrote:
> On Thu, Aug 20, 2020 at 11:53 PM Dimitry Andric wrote:
>> On 20 Aug 2020, at 19:52, Gleb Popov wrote:
>>> On Wed, Aug 19, 2020 at 10:15 PM Gleb Popov wrote:
I'm building the latest GHC on 12.1-RELEASE i386 and having almost the
sa
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, 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
>> instruc
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 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 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, 8 Aug 2020 12:37:42 +0400 Gleb Popov wrote:
> On Sat, Aug 8, 2020 at 1:29 AM Konstantin Belousov
> wrote:
>> On Fri, Aug 07, 2020 at 08:42:12PM +0400, Gleb Popov wrote:
>>> Hello toolchain@
>>>
>>> I'm testing a new release of GHC (Haskell compiler) and it fails to link
>>> to i386 archi
oth
>>> ports, viz. his work on arm and powerpc, and upstream) and toolchain@!
>>>
>>> On Sun, 24 Feb 2019, Tijl Coosemans wrote:
>>>> GCC_4.3.0 instead of GCC_3.3.0. The gcc commit that changed this
>>>> doesn't explain why this was done,
On Mon, 8 Apr 2019 13:16:15 +0800 (WITA) Gerald Pfeifer
wrote:
> This patch make 3 the default for gfortran.
s/make/makes/ but otherwise the patch looks fine.
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/free
On Sun, 3 Mar 2019 15:21:56 +0100 Willem Jan Withagen
wrote:
> First success.
> I used this map, but also needed to fix a .symver:
>
> #define LIBRADOS_C_API_BASE_DEFAULT(fn) \
> - asm(".symver _" #fn ", " #fn "@@")
> + asm(".symver _" #fn ", " #fn "@")
>
> That last was more o
On Sun, 3 Mar 2019 12:50:03 +0100 Willem Jan Withagen
wrote:
> On 2-3-2019 18:35, Tijl Coosemans wrote:
> > On Sat, 2 Mar 2019 17:49:25 +0100 Willem Jan Withagen
> > wrote:
> >> On 2-3-2019 16:21, Tijl Coosemans wrote:
> >>> On Sat, 2 Mar 2019 14:21:57 +0
On Sat, 2 Mar 2019 17:49:25 +0100 Willem Jan Withagen
wrote:
> On 2-3-2019 16:21, Tijl Coosemans wrote:
>> On Sat, 2 Mar 2019 14:21:57 +0100 Willem Jan Withagen
>> wrote:
>>> Now if I look in librados.so for rados_create that gives:
>>>
>>&g
On Sat, 2 Mar 2019 14:21:57 +0100 Willem Jan Withagen
wrote:
> Now if I look in librados.so for rados_create that gives:
>
> > objdump -t librados.so.2.0.0 | grep rados_create
You want to look at dynamic symbols so "objdump -T".
___
freebsd-toolch
On Fri, 22 Feb 2019 16:09:09 +0100 Willem Jan Withagen
wrote:
> Hi Ed ea,
>
> In het ceph project, they started to use library versioning, so it seems.
>
> But compiling/linking that now with Clang and lld I run into trouble
> building the ceph-tools.
>
> This is what I get back of one of the
14 matches
Mail list logo
