Re: Modern C failures in Haskell stack

2024-02-16 Thread David Abdurachmanov
On Fri, Feb 16, 2024 at 9:38 AM Jens-Ulrik Petersen  wrote:
>
> Thanks Richard for the PR and Florian for the patch
>
> On Thu, Feb 15, 2024 at 11:28 PM Richard W.M. Jones  wrote:
>>
>> On Thu, Feb 15, 2024 at 12:57:21PM +0100, Florian Weimer wrote:
>> > For the first issue, please try this GHC patch
>
>
>>
>> I submitted it to GHC here:
>> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12079
>
>
> The patch was approved upstream.
>
> It should now be in the Rawhide buildroot as ghc-9.4.5-140.fc41
> (Richard: hopefully also serves as a rebuild bump for riscv64)

I started building this NVR a couple of hours ago in Fedora/RISCV Koji.

http://fedora.riscv.rocks/koji/taskinfo?taskID=1602528

Should take ~24 hours.

Cheers,
david

>
> Cheers, Jens
>
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Modern C failures in Haskell stack

2024-02-15 Thread Jens-Ulrik Petersen
Thanks Richard for the PR and Florian for the patch

On Thu, Feb 15, 2024 at 11:28 PM Richard W.M. Jones 
wrote:

> On Thu, Feb 15, 2024 at 12:57:21PM +0100, Florian Weimer wrote:
> > For the first issue, please try this GHC patch
>


> I submitted it to GHC here:
> https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12079


The patch was approved upstream.

It should now be in the Rawhide buildroot as ghc-9.4.5-140.fc41
(Richard: hopefully also serves as a rebuild bump for riscv64)

Cheers, Jens
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Modern C failures in Haskell stack

2024-02-15 Thread Jens-Ulrik Petersen
Thank you for looking into this, much appreciated,
since I hadn't found proper time yet.

It might be helpful to have a downstream ghc bug to track this too.

Jens
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Modern C failures in Haskell stack

2024-02-15 Thread Richard W.M. Jones
On Thu, Feb 15, 2024 at 12:57:21PM +0100, Florian Weimer wrote:
> For the first issue, please try this GHC patch (only compile-tested with
> the stage 0 compiler build this point):
> 
> diff --git a/compiler/GHC/HsToCore/Foreign/C.hs 
> b/compiler/GHC/HsToCore/Foreign/C.hs
> index 2164ded112..8beaa8986e 100644
> --- a/compiler/GHC/HsToCore/Foreign/C.hs
> +++ b/compiler/GHC/HsToCore/Foreign/C.hs
> @@ -560,7 +560,7 @@ mkFExportCBits dflags c_nm maybe_target arg_htys res_hty 
> is_IO_res_ty cc
>   ,   ppUnless res_hty_is_unit $
>   if libffi
>then char '*' <> parens (ffi_cResType <> char '*') <>
> -   text "resp = cret;"
> +   text "resp = " <> parens ffi_cResType <> text "cret;"
>else text "return cret;"
>   , rbrace
>   ]

Thanks, I tested this and it works.

I submitted it to GHC here:
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12079

(Unfortunately to modify this you'll have to sign up to their gitlab
instance, which is very timeconsuming.)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Modern C failures in Haskell stack

2024-02-15 Thread Richard W.M. Jones
I did a more thorough review of all the failed ghc-* packages by
submitting scratch builds for every one of them (starting from this
list: https://kojipkgs.fedoraproject.org/mass-rebuild/f40-failures.html).

It turns out that there is only one "class" of modern C failure,
of this form:

  /tmp/ghc167_0/ghc_8.c: In function 
‘zdreadlinezm1zi0zi3zi0zm5rmDmTTeacP6ZZL2WI5OaFEzdSystemziConsoleziReadlinezdreadlinezzm1zzi0zzi3zzi0zzm5rmDmTTeacP6L2WI5OaFEzuSystemzziConsolezziReadlinezuexportDequoter’:
  /tmp/ghc167_0/ghc_8.c:68:17: error:
   error: assignment to ‘ffi_arg’ {aka ‘long unsigned int’} from ‘HsPtr’ 
{aka ‘void *’} makes integer from pointer without a cast [-Wint-conversion]
 68 | *(ffi_arg*)resp = cret;
| ^
 |
  68 | *(ffi_arg*)resp = cret;
 | ^

I'll try Florian's suggested patch for ghc in a few minutes.

The other errors were not really related (except maybe OpenSSL ones).
They were:

* ghc-libxml-sax has non-generated code with missing headers

* ghc-th-orphans crashes ("Killed") during the build

* ghc-gi-gtk, ghc-gi-ostree seems to have a haskell code bug

* ghc-HsOpenSSL errors are significantly complex and need
  further investigation:
  https://koji.fedoraproject.org/koji/taskinfo?taskID=113537596

Several packages actually built fine so I have submitted proper builds
for those.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Modern C failures in Haskell stack

2024-02-15 Thread Jakub Jelinek
On Thu, Feb 15, 2024 at 12:57:21PM +0100, Florian Weimer wrote:
> For the first issue, please try this GHC patch (only compile-tested with
> the stage 0 compiler build this point):
> 
> diff --git a/compiler/GHC/HsToCore/Foreign/C.hs 
> b/compiler/GHC/HsToCore/Foreign/C.hs
> index 2164ded112..8beaa8986e 100644
> --- a/compiler/GHC/HsToCore/Foreign/C.hs
> +++ b/compiler/GHC/HsToCore/Foreign/C.hs
> @@ -560,7 +560,7 @@ mkFExportCBits dflags c_nm maybe_target arg_htys res_hty 
> is_IO_res_ty cc
>   ,   ppUnless res_hty_is_unit $
>   if libffi
>then char '*' <> parens (ffi_cResType <> char '*') <>
> -   text "resp = cret;"
> +   text "resp = " <> parens ffi_cResType <> text "cret;"
>else text "return cret;"
>   , rbrace
>   ]
> 
> I'm not even sure if there is a better fix for this.  Perhaps emitting a
> memcpy call to avoid the aliasing violation?

I thought it isn't an aliasing violation (though I only looked at the
diagnostics, nothing else), I thought the problem is that cret has some
pointer type and ffi_arg has integer type.  The above will work
if cret has non-pointer type (changes implicit conversion to explicit) but
with pointers still will emit a warning if say ffi_arg is 64-bit and pointers
are 32-bit or ffi_arg is 32-bit and pointers are 64-bit.
For that (ffi_arg) (uintptr_t) cret;
casts would be desirable, but one would need to find out if cret is a
pointer or not.

Jakub
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Modern C failures in Haskell stack

2024-02-15 Thread Florian Weimer
* Richard W. M. Jones:

> We noticed that some ghc-* packages FTBFS with Modern C failures eg
> these two picked at random:
>
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534568
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534602
>
> I think what's happening here is that ghc is generating C FFI code
> which is fed to GCC 14.  The code being generated is buggy.
>
> So probably the fix for this is just in ghc itself.  I looked at
> upstream ghc and wasn't able to identify any commits which fix this
> (except maybe
> https://github.com/ghc/ghc/commit/b3a3534b6f75b34dc4db76e904e071485da6d5cc).
> But I didn't look especially hard and the code is very complicated.
>
> An alternative to fixing this in the compiler is to throw up our hands
> and add:
>
>   %global build_type_safety_c 0
>
> to every affected ghc-* package.

Please don't do this, it's unnecessary busy-work.

> eg This fixes ghc-readline:
>
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113535426
>
> Any thoughts on this?

If GHC cannot be fixed properly, it should be trivial to teach it to
emit #pragma directives near the start of the generated files.  This is
what we currently do for Vala:



(The upstream submission has a Clang variant as well.)

Hopefully, GHC has a better understanding of the types and the control
flow of the code it generates than the Vala compiler, so this shouldn't
be necessary.

For the first issue, please try this GHC patch (only compile-tested with
the stage 0 compiler build this point):

diff --git a/compiler/GHC/HsToCore/Foreign/C.hs 
b/compiler/GHC/HsToCore/Foreign/C.hs
index 2164ded112..8beaa8986e 100644
--- a/compiler/GHC/HsToCore/Foreign/C.hs
+++ b/compiler/GHC/HsToCore/Foreign/C.hs
@@ -560,7 +560,7 @@ mkFExportCBits dflags c_nm maybe_target arg_htys res_hty 
is_IO_res_ty cc
  ,   ppUnless res_hty_is_unit $
  if libffi
   then char '*' <> parens (ffi_cResType <> char '*') <>
-   text "resp = cret;"
+   text "resp = " <> parens ffi_cResType <> text "cret;"
   else text "return cret;"
  , rbrace
  ]

I'm not even sure if there is a better fix for this.  Perhaps emitting a
memcpy call to avoid the aliasing violation?

For the second build failure, GCC reports *genuine* bugs in the C code
in that package, leading to run-time crashes:

cbits/hslibxml-shim.c:44:21: error:
 warning: incompatible implicit declaration of built-in function ‘calloc’ 
[-Wbuiltin-declaration-mismatch]
   44 | user_data = calloc(1, sizeof(UserData));
  | ^~

That hasn't been valid C since 1986 or thereabouts.

As Jakub said, you really need to include the appropriate header files
to make this work.

Thanks,
Florian
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Modern C failures in Haskell stack

2024-02-15 Thread Richard W.M. Jones
On Thu, Feb 15, 2024 at 12:24:22PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 15, 2024 at 11:13:08AM +, Richard W.M. Jones wrote:
> > We noticed that some ghc-* packages FTBFS with Modern C failures eg
> > these two picked at random:
> > 
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534568
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534602
> > 
> > I think what's happening here is that ghc is generating C FFI code
> > which is fed to GCC 14.  The code being generated is buggy.
> > 
> > So probably the fix for this is just in ghc itself.  I looked at
> > upstream ghc and wasn't able to identify any commits which fix this
> > (except maybe
> > https://github.com/ghc/ghc/commit/b3a3534b6f75b34dc4db76e904e071485da6d5cc).
> > But I didn't look especially hard and the code is very complicated.
> > 
> > An alternative to fixing this in the compiler is to throw up our hands
> > and add:
> > 
> >   %global build_type_safety_c 0
> 
> Please don't if at all possible.
> 
> > to every affected ghc-* package.  eg This fixes ghc-readline:
> > 
> >   https://koji.fedoraproject.org/koji/taskinfo?taskID=113535426
> > 
> > Any thoughts on this?
> 
> The diagnostics is quite clear what needs to be done, in some cases
> #include , in others (uintptr_t) cast added when you want to
> assign a pointer to ffi_arg which is integral type.  Perhaps stdint.h
> include for that.

The problem isn't that we don't know how to change the code,
the problem is we need to work out where in the depths of GHC
to make the change.  Take a look for yourself:

https://github.com/ghc/ghc/blob/master/compiler/GHC/HsToCore/Foreign/C.hs

Rich.



>   Jakub
> --
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct: 
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam, report it: 
> https://pagure.io/fedora-infrastructure/new_issue

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Re: Modern C failures in Haskell stack

2024-02-15 Thread Jakub Jelinek
On Thu, Feb 15, 2024 at 11:13:08AM +, Richard W.M. Jones wrote:
> We noticed that some ghc-* packages FTBFS with Modern C failures eg
> these two picked at random:
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534568
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113534602
> 
> I think what's happening here is that ghc is generating C FFI code
> which is fed to GCC 14.  The code being generated is buggy.
> 
> So probably the fix for this is just in ghc itself.  I looked at
> upstream ghc and wasn't able to identify any commits which fix this
> (except maybe
> https://github.com/ghc/ghc/commit/b3a3534b6f75b34dc4db76e904e071485da6d5cc).
> But I didn't look especially hard and the code is very complicated.
> 
> An alternative to fixing this in the compiler is to throw up our hands
> and add:
> 
>   %global build_type_safety_c 0

Please don't if at all possible.

> to every affected ghc-* package.  eg This fixes ghc-readline:
> 
>   https://koji.fedoraproject.org/koji/taskinfo?taskID=113535426
> 
> Any thoughts on this?

The diagnostics is quite clear what needs to be done, in some cases
#include , in others (uintptr_t) cast added when you want to
assign a pointer to ffi_arg which is integral type.  Perhaps stdint.h
include for that.

Jakub
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


Modern C failures in Haskell stack

2024-02-15 Thread Richard W.M. Jones
We noticed that some ghc-* packages FTBFS with Modern C failures eg
these two picked at random:

  https://koji.fedoraproject.org/koji/taskinfo?taskID=113534568
  https://koji.fedoraproject.org/koji/taskinfo?taskID=113534602

I think what's happening here is that ghc is generating C FFI code
which is fed to GCC 14.  The code being generated is buggy.

So probably the fix for this is just in ghc itself.  I looked at
upstream ghc and wasn't able to identify any commits which fix this
(except maybe
https://github.com/ghc/ghc/commit/b3a3534b6f75b34dc4db76e904e071485da6d5cc).
But I didn't look especially hard and the code is very complicated.

An alternative to fixing this in the compiler is to throw up our hands
and add:

  %global build_type_safety_c 0

to every affected ghc-* package.  eg This fixes ghc-readline:

  https://koji.fedoraproject.org/koji/taskinfo?taskID=113535426

Any thoughts on this?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue