Re: Build failure on macOS Sonoma 14.0 beta

[Hans Åberg]

> On 20 Sep 2023, at 22:45, Marc Culler  wrote:
> 
> I learned by reading the release notes for XCode 15 that Apple rewrote the 
> linker for XCode 15.  They also made the old linker available by using -ld64 
> as a linker option.

One should use -ld_classic as -ld64 is deprecated by a warning I got from the 
linker. 

Also, this is an issue for MacPorts gcc12; clang-16 works with new linker.


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Build failure on macOS Sonoma 14.0 beta

[Hans Åberg]

> On 22 Sep 2023, at 00:10, Marc Culler  wrote:
> 
> This appears to be a completely independent bug in Apple's new linker.  (You 
> are linking with libgmp, but presumably that library was built with a 
> different linker.  And the "error" is different.)

It may be because I use atomic code, in the reference counting.

> Once I knew what to look for I found lots of issues with the new linker 
> reported on the Apple development site.  Perhaps we can assume that the new 
> linker is still unstable and eventually will be working.

I reported it here because it may be if interest that there are bugs in 
connection with the new linker.

The release notes says it was rewritten to speed up static linking, but there 
is none such here, so they must have done some other, unspecified things, as 
well.

> In the meantime we can still use the old linker.  I guess that we can just 
> carry on and hope for the best.

That seems a good strategy. But the risk is that one forgets about the new 
linker and is left out in the cold when the old one is removed.

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Build failure on macOS Sonoma 14.0 beta

[Hans Åberg]

> On 20 Sep 2023, at 22:45, Marc Culler  wrote:
> 
> I learned by reading the release notes for XCode 15 that Apple rewrote the 
> linker for XCode 15.  They also made the old linker available by using -ld64 
> as a linker option.

When I use the new linker, using MacPorts gcc12 and gmp-6.2.1, I get the error 
[1] below. When adding '-ld64', I merely get a warning [2].

The file Relocations.cpp contains LLVM platform-independent functions to 
process relocations.

— 1 —
% make
/Applications/Xcode.app/Contents/Developer/usr/bin/make  all-am
/opt/local/bin/g++-mp-12 -std=c++20 -g  -L /usr/local/lib -o mli MLI.o gc.o 
main.o write-style.o basictype.o database.o database-lexer.o database-parser.o 
directive-lexer.o directive-parser.o definition.o inferenceengine.o 
metacondition.o precedence.o proposition.o substitution.o function.o 
hoare_logic.o  -lgmp
-macosx_version_min has been renamed to -macos_version_min
0  0x10dcfdf43  __assert_rtn + 64
1  0x10dbfff43  ld::AtomPlacement::findAtom(unsigned char, unsigned long long, 
ld::AtomPlacement::AtomLoc const*&, long long&) const + 1411
2  0x10dc1c431  ld::InputFiles::SliceParser::parseObjectFile(mach_o::Header 
const*) const + 19745
3  0x10dc2cb71  ld::InputFiles::parseAllFiles(void (ld::AtomFile const*) 
block_pointer)::$_7::operator()(unsigned long, ld::FileInfo const&) const + 657
4  0x7ff816142066  _dispatch_client_callout2 + 8
5  0x7ff816153e09  _dispatch_apply_invoke + 213
6  0x7ff816142033  _dispatch_client_callout + 8
7  0x7ff8161520f6  _dispatch_root_queue_drain + 683
8  0x7ff816152768  _dispatch_worker_thread2 + 170
9  0x7ff8162dfc0f  _pthread_wqthread + 257
ld: Assertion failed: (resultIndex < sectData.atoms.size()), function findAtom, 
file Relocations.cpp, line 1336.
collect2: error: ld returned 1 exit status
make[1]: *** [mli] Error 1
make: *** [all] Error 2

— 2 —

% /opt/local/bin/g++-mp-12 -std=c++20 -g  -L /usr/local/lib -o mli MLI.o gc.o 
main.o write-style.o basictype.o database.o database-lexer.o database-parser.o 
directive-lexer.o directive-parser.o definition.o inferenceengine.o 
metacondition.o precedence.o proposition.o substitution.o function.o 
hoare_logic.o  -lgmp -ld64
-macosx_version_min has been renamed to -macos_version_min
ld: warning: -ld64 is deprecated, use -ld_classic instead

— End —


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Build failure on macOS Sonoma 14.0 beta

[Hans Åberg]

> On 20 Sep 2023, at 16:36, Marc Culler  wrote:
> 
> …macOS Sonoma beta…
…
> …using: "Apple clang version 15.0.0
> (clang-1500.0.40.1)"

The same compiler version is now available on MacOS 13, together with Xcode 15.

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.2.1 core2 x86_64 assembler error "operands invalid for `movq'"

[Hans Åberg]

> On 1 Nov 2022, at 22:55, Torbjörn Granlund  wrote:
> 
> Is this on a recent version of macos with current versions gcc+binutils
> installed?  Or is either old variants?

Darwin 11.4.2 is OS X 10.7.5 Lion from September 19, 2012.

https://en.wikipedia.org/wiki/OS_X_Lion


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Build error using pre-packaged GMP

[Hans Åberg]

> On 26 May 2021, at 10:31, Marc Glisse  wrote:
> 
> My first guess would be some misguided
> 
> extern "C" {
> #include 
> }

Indeed it is, testing with g++ 11. The errors that the OP posted arrive at the 
end, the first, not posted, error is:
/opt/local/include/gcc11/c++/bits/memoryfwd.h:63:3: error: template with C 
linkage
   63 |   template
  |   ^~~~

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: small patch to suppress a warning

[Hans Åberg]

> On 10 Feb 2021, at 23:55, Stephan Pleines  wrote:
> 
> Can you please elaborate why it is a compiler bug?

It is a legal C feature, so there should not be issued a warning.

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: small patch to suppress a warning

[Hans Åberg]

You do not say which compiler it is, but it looks like a clang bug.


> On 10 Feb 2021, at 17:26, Stephan Pleines  wrote:
> 
> Hi,
> 
> This is a tiny patch to suppress a warning about operator precedence.
> 
> Thank you,
> Stephan
> 
> diff -r 925753a1f950 mpz/pprime_p.c
> --- a/mpz/pprime_p.cMon Dec 21 00:48:03 2020 +0100
> +++ b/mpz/pprime_p.cWed Feb 10 08:21:36 2021 -0800
> @@ -60,7 +60,7 @@
>  int is_prime;
>  unsigned long n0;
>  n0 = mpz_get_ui (n);
> - is_prime = n0 & (n0 > 1) ? isprime (n0) : n0 == 2;
> + is_prime = (n0 & (n0 > 1)) ? isprime (n0) : n0 == 2;
>  return is_prime ? 2 : 0;
>}
>   /* Negative number.  Negate and fall out.  */
> ___
> gmp-bugs mailing list
> gmp-bugs@gmplib.org
> https://gmplib.org/mailman/listinfo/gmp-bugs

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: uint_least32_t is in stdint.h not in inttypes.h

[Hans Åberg]

> On 16 Nov 2020, at 10:53, Torbjörn Granlund  wrote:
> 
> Vincent Lefevre  writes:
> 
>  So, including  if present should be sufficient, and
>  this is what the above code does.
> 
>  That said, for C99 implementations, the #if tests would be useless,
>  so that the above code is also designed for non-C99 implementations,
>  which may have  and  with a behavior different
>  from C99, i.e.  will not necessarily include 
>  (but this also means that  will not necessarily have
>  uint_least32_t).
> 
> The mainline gmp repository and the next major GMP release (7.0) will
> require a C99 compiler.  I believe we have not fully determined which
> C++ standard we will require (or, Marc, did we come to a conclusion?).
> We will use C99 constructs and will gradually clean up code which
> handles older environments.

GCC has as default C++14, skipping over C++11 as the implementation was 
complicated, the latter which in turn first defined the corresponding headers.

https://en.cppreference.com/w/cpp/types/integer
https://en.cppreference.com/w/c/types/integer


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bootstrap fails with Autoconf 2.69d

[Hans Åberg]

> On 16 Nov 2020, at 11:41, Vincent Lefevre  wrote:
> 
> On 2020-11-16 10:29:13 +0100, Hans Åberg wrote:
>>> On 16 Nov 2020, at 01:18, Vincent Lefevre  wrote:
>>> If I understand correctly, the goal is to have the Reporting-Bugs.html
>>> URL together with the e-mail address.
>> 
>> Yes, and such a feature is not supported.
>> 
>> https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Initializing-configure.html
> 
> I can read:
> 
>  AC_PACKAGE_BUGREPORT, PACKAGE_BUGREPORT
>Exactly bug-report, if one was provided. Typically an email
>address, or URL to a bug management web page.
> 
> So I think that GMP is correct here.
> 
> Earlier it is said "The optional argument bug-report should be the
> email to which users should send bug reports." but that's a "should"
> so that one can expect thinks to work, in particular with the
> AC_PACKAGE_BUGREPORT / PACKAGE_BUGREPORT description.
> 
> Note that URLs can contain commas (this occurs in practice, but
> perhaps not for BTS URLs), so that if commas or other characters
> are forbidden, this should be documented so that the URL is
> written with such characters encoded.
> 
> Note for GMP: if the URL is accepted, wouldn't it be better to just
> put the URL in order to make sure users read this page?

That seems better.


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bootstrap fails with Autoconf 2.69d

[Hans Åberg]

> On 16 Nov 2020, at 01:18, Vincent Lefevre  wrote:
> 
> On 2020-11-15 23:49:10 +0100, Hans Åberg wrote:
>> One can also have an additional URL argument, which defines a variable 
>> PACKAGE_URL:
>> 
>> AC_INIT(GNU MP, GMP_VERSION, [gmp-bugs@gmplib.org (see 
>> https://gmplib.org/manual/Reporting-Bugs.html)], gmp, [https://gmplib.org/])
> 
> If I understand correctly, the goal is to have the Reporting-Bugs.html
> URL together with the e-mail address.

Yes, and such a feature is not supported.

https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Initializing-configure.html


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: possible miscompilation on macOS Catalina 10.15.6

[Hans Åberg]

> On 28 Oct 2020, at 12:24, Trevor Spiteri  wrote:
> 
> Sorry for not being clearer: I was only concerned that there was a
> chance the combination
> 
> configure --enable-fat --disable-shared --with-pic
> 
> might cause issues with Catalina's default compiler, if there even is
> such a thing, and since I don't have such a system I couldn't test it
> myself. If that's not the case, then the rest is of course useless
> information.

It worked for me with latest MacOS & Xcode, using CC=/usr/bin/clang.


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP bug (?) - unable to build for ARM64 with assembly enabled

[Hans Åberg]

> On 14 Oct 2020, at 12:59, Andreas Buff  wrote:
> 
> We are cross building GMP for use on ARM64 iOS devices using this command:
> …

This link suggests using the -target option for makefiles outside Xcode.

https://developer.apple.com/documentation/xcode/building_a_universal_macos_binary


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: gmp 6.2.0 documentation bug

[Hans Åberg]

> On 29 Sep 2020, at 19:17, Marco Bodrato  wrote:
> 
> Il 2020-09-29 16:09 TonyMcC ha scritto:
>> I think there is a word (a function name?) missing from the
>> documentation for gmp 6.2.0.  In gmp.texi, at line 2541 it reads:
>> "it's probably best to call to get a starting point and iterate from there."
>> Should there be a function name after "call"?
> 
> The complete sentence is:
> 
> Functions like @code{mpz_fac_ui}, @code{mpz_fib_ui} and @code{mpz_bin_uiui}
> are designed for calculating isolated values.  If a range of values is wanted
> it's probably best to call to get a starting point and iterate from there.
> 
> Maybe we can simply remove "to call".
> 
> The documentation of mpz_fib_ui correctly suggests the function to call: 
> mpz_fib2_ui.
> 
> Speaking about mpz_fac_ui and mpz_bin_uiui, it shouldn't be necessary to 
> suggest how to get the starting point.

It might say:
  If a range of values is wanted, see the definition respective function.
Since it is properly described for first two. For the binomials, it would be 
most efficient to compute the trapezoid above the values in Pascal's triangle, 
I would think, and the function does not provide an efficient way to get that.


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Linking failure on aarch64

[Hans Åberg]

> On 2 Jul 2020, at 21:23, Torbjörn Granlund  wrote:
> 
> Hans Åberg  writes:
> 
>  So here it should be
>xcode-select --switch /Applications/Xcode-beta.app/Contents/Developer
> 
> Sorry, I must have been unclear.  I lacked installation instructions for
> how to get /Applications/Xcode-beta.app installed.  My problem was not
> adding features to the beta compiler.  My probles was getting from .xip
> file to the /Applications/Xcode-beta.app.

I double-clicked on it, the Universal Apps beta, taking several minutes to 
verify and unpack, and then dragged it to /Applications/. There is also an 
article here [1].
https://osxdaily.com/2018/11/02/open-extract-xip-file-mac/


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Linking failure on aarch64

[Hans Åberg]

> On 2 Jul 2020, at 20:53, Torbjörn Granlund  wrote:
> 
> Hans Åberg  writes:
> 
>  One must run 'xcode-select install' from the Terminal.
> 
> I came that far (except it is --install) before giving up.

Right.

> But --install is not for installing a new Xcode, but for installing
> command line tools.

Yes, but if you have something run by a Makefile, then that would be needed, 
also when running in the GUI. I had a problem with that when switching Xcode 
version: Some things would work, others not.

> What version?  It does not say.  

If one does not indicate which one by an argument, then it is probably 
/Applications/Xcode, or the one set by --switch:

One can set version by the --switch argument; see --help. It should be (as root)
  xcode-select --switch /Applications/Xcode.app/Contents/Developer

> The opened
> "dialogue" is not much of a dialogue as OK and Cancel was the only
> options IIRC.  The command takes no argument (such as an Xcode release
> image) at least not as per its lackluster manual, nor in any way my
> experimentation could find out.
> 
> How to install the (in the manual) mentioned
> /Applications/Xcode-beta.app remains undocumented.

So here it should be
  xcode-select --switch /Applications/Xcode-beta.app/Contents/Developer

>  I may not try the Xcode betas for other reasons, they may corrupt some other 
> installations.
> 
> Perhaps you also failed with your installation, overwriting the existing
> Xcode?

It was not I, but one on the LilyPond list that was not being able to run the 
lilypond program. I suggested to make a new volume with a new MacOS 
installation, and he found it worked, and that it was not due to MacPorts. A 
suggestion on the net suggested that some versions of Xcode 11 beta could cause 
such issues. See:

https://lists.gnu.org/archive/html/lilypond-user/2020-03/msg00368.html


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Linking failure on aarch64

[Hans Åberg]

> On 2 Jul 2020, at 16:15, Torbjörn Granlund  wrote:
> 
> Hans Åberg  writes:
> 
>> On 2 Jul 2020, at 00:49, Torbjörn Granlund  wrote:
>> 
>> (I actually attempted installing Apple's compiler bundle "Xcode" with
>> support for arm64, in order to work out some of these issues.
>> Unfortunately, Apple's documentaton was too lacking for a successful
>> install.)
> 
>  Exactly what did not work?
> 
> It did not behave as a normal release.  It did not install in a place
> where its commands finds its own subcommands.  The download pages and
> associated documentation did not mention anything about how to install
> it properly.

One must run 'xcode-select install' from the Terminal.

> I.e., a complete waste of time.  I will not try again.

I may not try the Xcode betas for other reasons, they may corrupt some other 
installations.


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Linking failure on aarch64

[Hans Åberg]

> On 2 Jul 2020, at 00:49, Torbjörn Granlund  wrote:
> 
> (I actually attempted installing Apple's compiler bundle "Xcode" with
> support for arm64, in order to work out some of these issues.
> Unfortunately, Apple's documentaton was too lacking for a successful
> install.)

Exactly what did not work?


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Constructor taking 64-bit integer missing on (some) Windows C++ compilers

[Hans Åberg]

> On 6 Jun 2020, at 06:28, Mihai Preda  wrote:
> 
> At this point the C++ compiler on windows (where long is 32-bit)
> reports errors, see at the end. The problem is that the set of
> constructors does not include one taking a 64-bit integer:
> 
> #define __GMPXX_DEFINE_ARITHMETIC_CONSTRUCTORS\
>  __gmp_expr(signed char c) { init_si(c); }\
>  __gmp_expr(unsigned char c) { init_ui(c); }\
>  __gmp_expr(signed int i) { init_si(i); }\
>  __gmp_expr(unsigned int i) { init_ui(i); }\
>  __gmp_expr(signed short int s) { init_si(s); }\
>  __gmp_expr(unsigned short int s) { init_ui(s); }\
>  __gmp_expr(signed long int l) { init_si(l); }\
>  __gmp_expr(unsigned long int l) { init_ui(l); }\
>  __gmp_expr(float f) { init_d(f); }\
>  __gmp_expr(double d) { init_d(d); }
> 
> Among all in the list above, none takes a uint64_t or int64_t.

Those types are just typedefs to the appropriate C types [1], and with those 
compilers one would have to use [unsigned/signed] long long [2], which is not 
on the list. So it would suffice adding those, it would seem.

1. https://en.cppreference.com/w/cpp/types/integer
2. https://en.cppreference.com/w/cpp/language/types


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP and Macos Catalina

[Hans Åberg]

> On 15 Dec 2019, at 00:45, Torbjörn Granlund  wrote:
> 
> Hans Åberg  writes:
> 
>> On 14 Dec 2019, at 23:49, Torbjörn Granlund  wrote:
>> 
>> Many people have reported problems with GMP on Macos Catalina.
>> 
>> The problem now seems to have been fixed with the Xcode 11.3 release.
> 
>  At least the tests pass: One error with clang 9.0.0 of MacPorts (using
>  gmp-6.1.2), which should be more recent.
> 
>  FAIL: t-sqrlo
> 
> You're so terse and vague that it is hard to infer anything from your
> messages.
> 
> Are you saying that there are still GMP-related issues with Catalina's
> compiler?
> 
> Or are you saying that some clang version is still buggy?  (sic)

It used to be the case that the Apple clang was at least one year or so older 
than the real clang, but they successively hid away all the variables that 
allowed one to tell.

The one I tried was the latest official clang. So it could be that it is a 
coincidence that Apple clang passed, or perhaps they took down it down from the 
repository so it would be later, but that seems unlikely because they want to 
have very stable versions.

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP and Macos Catalina

[Hans Åberg]

> On 14 Dec 2019, at 23:49, Torbjörn Granlund  wrote:
> 
> Many people have reported problems with GMP on Macos Catalina.
> 
> The problem now seems to have been fixed with the Xcode 11.3 release.

At least the tests pass: One error with clang 9.0.0 of MacPorts (using 
gmp-6.1.2), which should be more recent.

FAIL: t-sqrlo

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: macOS Catalina: FAIL: t-powm

[Hans Åberg]

> On 16 Nov 2019, at 10:14, Torbjörn Granlund  wrote:
> 
> There is a non-zero probability that these GMP test suite failures are
> caused by bugs in GMP.  We cannot tell for sure, as we have not isolated
> the failures. 

Or maybe just the test suite, as suggested som other post?!

> And as gdb no longer
> works on Macos, I would feel like a beginner programmer again.

There is “native” lldb, which should work with GCC, too, I think.

I also found a way to use make style programs in the Xcode visual debugger [1], 
which works for clang; for gcc there is some variable it complains over. If 
somebody figures out how to set it, please let me know. :-)

1. https://lists.gnu.org/archive/html/help-bison/2018-10/msg4.html


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: macOS Catalina: FAIL: t-powm

[Hans Åberg]

> On 16 Nov 2019, at 14:21, Jack Howarth  
> wrote:
> 
>> > And as gdb no longer
>> > works on Macos, I would feel like a beginner programmer again.
>> 
>> There is “native” lldb, which should work with GCC, too, I think.
> 
> Just to be clear, the 'gcc' on recent macOS has always been stub binary that 
> points to Apple's clang compiler and not gcc. Apple hasn't shipped an actual 
> gcc based compiler since before Xcode 5.0.

Right, GCC from MacPorts or something (building it yourself is ambitious). BTW, 
MacPorts also has gdb, so hopefully it is working. :-)

> ps The gmp package in MacPorts relies on always building with the core2 
> architecture in order ship uniform packaging of gmp for all Intel based Macs. 
> That is why everyone sees the same glitch in Xcode 11 who is using MacPorts.

The 'make check' with MacPorts gcc9 passed though.


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: macOS Catalina: FAIL: t-powm

[Hans Åberg]

> On 16 Nov 2019, at 14:21, Jack Howarth  
> wrote:
> 
> The gmp package in MacPorts relies on always building with the core2 
> architecture in order ship uniform packaging of gmp for all Intel based Macs. 
> That is why everyone sees the same glitch in Xcode 11 who is using MacPorts.

The make check passed with clang when turning off optimization, but it seems 
not known how much performance loss, if any, that results. Also, one might 
check if the tests fail when turning off optimization only when compiling the 
library or the test.


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: macOS Catalina: FAIL: t-powm

[Hans Åberg]

> On 15 Nov 2019, at 12:42, Torbjörn Granlund  wrote:
> 
> Apple has released a new version of Xcode.  It is said to fix some issue
> with UITextView, and as the update size is 8 GiB UITextView must be a
> very large function.
> 
> But hopefully they also managed to fix the C compiler to miscompile many
> of our functions.

No Xcode release will fix anything here, as I tried the official latest public 
clang, and Apple is using a much older one where they have carefully erased all 
version references to original clang so that users shall not know how old it in 
reality is.


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Report: gmp-6.1.2 on MacOS 10.15 using GCC and two Clang

[Hans Åberg]

> On 8 Nov 2019, at 18:26, Marco Bodrato  wrote:
> 
> Il Ven, 8 Novembre 2019 4:59 pm, Niels Möller ha scritto:
>> Hans Åberg  writes:
>> 
>>> How about memory allocations? — There is info here, suggesting
>>> uninitialized memory access in the test suite:
> 
> Our priority is to avoid bugs in the library. So that we usually pay more
> attention to the library code than to the code "in the test suite". ;-D

Yes, of course. But those that are encouraged to make check get a scare. :-)


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Report: gmp-6.1.2 on MacOS 10.15 using GCC and two Clang

[Hans Åberg]

> On 8 Nov 2019, at 15:48, Torbjörn Granlund  wrote:
> 
> There is info here, suggesting
>  uninitialized memory access in the test suite:
>  https://lists.llvm.org/pipermail/cfe-users/2019-November/001640.html
> 
> What are you trying to contribute to the discussion in the Subject line?
> 
> Apple suggests that the stack pointer is not properly aligned.
> 
> The quoted text does not seem to have anything to do with the issue at
> hand.

It is the same issue, but discussed on another list. I leave it up to you to 
interpret it: I was interested in another issue.


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Report: gmp-6.1.2 on MacOS 10.15 using GCC and two Clang

[Hans Åberg]

> On 20 Oct 2019, at 22:14, Torbjörn Granlund  wrote:
> 
> Believe it or not, but the GMP devs are pretty good at computer
> arithmetic.

How about memory allocations? — There is info here, suggesting uninitialized 
memory access in the test suite:
https://lists.llvm.org/pipermail/cfe-users/2019-November/001640.html

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Report: gmp-6.1.2 on MacOS 10.15 using GCC and two Clang

[Hans Åberg]

> On 20 Oct 2019, at 22:14, Torbjörn Granlund  wrote:
> 
> Hans Åberg  writes:
> 
>> I believe we assume signed integers are in two's complement.
> 
>  Strictly, it is for signed overflows one cannot assume modulo 2^n, n =
>  number of bits. For the unsigned integer types it is required,
>  though.
> 
> Believe it or not, but the GMP devs are pretty good at computer
> arithmetic.

Sorry for offending you: My response was to the part you snipped, which you did 
not detail. And on the Bison list a very savvy C programmer suggested the rule 
was one’s complement legacy, apparently not realizing modern optimization use.

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Report: gmp-6.1.2 on MacOS 10.15 using GCC and two Clang

[Hans Åberg]

> On 20 Oct 2019, at 21:44, Torbjörn Granlund  wrote:
> 
> Hans Åberg  writes:
> 
>  A common programming error is assuming that signed integer types are
>  two’s complement, because even though all current CPUs are that,
>  overflows are undefined in C/C++, and an optimizer can take advantage
>  of that. One example from [1]: checking overflows with x > x + 1 may
>  work as intended with optimization turned off, but when on, the
>  optimizer can assume that it is always false since x + 1 is undefined
>  when overflowed.
> 
> I believe we assume signed integers are in two's complement.
> 
> We don't do a lot of arithmetic on signed integers, though.

Strictly, it is for signed overflows one cannot assume modulo 2^n, n = number 
of bits. For the unsigned integer types it is required, though. Here is a list 
for various languages:

https://en.wikipedia.org/wiki/Integer_overflow


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Report: gmp-6.1.2 on MacOS 10.15 using GCC and two Clang

[Hans Åberg]

> On 20 Oct 2019, at 13:24, Torbjörn Granlund  wrote:
> 
> Hans Åberg  writes:
> 
>  I have compiled gmp-6.1.2 on MacOS 10.15 using the inhouse Apple clang
>  and the MacPorts gcc9 and clang9, with ‘make check’. All tests passed
>  on gcc9, but the two clang had one error each.
> 
> Several people seem to have trouble with using clang.  When clang first
> appeared, I isolated several of the GMP failures only to determine that
> they were clang codegen bugs.  I don't have time to debug clang for
> Apple or the other clang devs, and this new GMP failure is with very
> high probability yet another clang codegen bug.

Then I will have to do it for you: :-)

It is an optimization issue. When turning it off, both clang pass.

A common programming error is assuming that signed integer types are two’s 
complement, because even though all current CPUs are that, overflows are 
undefined in C/C++, and an optimizer can take advantage of that. One example 
from [1]: checking overflows with x > x + 1 may work as intended with 
optimization turned off, but when on, the optimizer can assume that it is 
always false since x + 1 is undefined when overflowed.

I do not know if anything like that is done in GMP.


1. http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Report: gmp-6.1.2 on MacOS 10.15 using GCC and two Clang

[Hans Åberg]

I have compiled gmp-6.1.2 on MacOS 10.15 using the inhouse Apple clang and the 
MacPorts gcc9 and clang9, with ‘make check’. All tests passed on gcc9, but the 
two clang had one error each.

% uname -a
Darwin Kernel Version 19.0.0: Wed Sep 25 20:18:50 PDT 2019; 
root:xnu-6153.11.26~2/RELEASE_X86_64 x86_64 


—— 

% /opt/local/bin/gcc-mp-9 --version
gcc-mp-9 (MacPorts gcc9 9.2.0_1) 9.2.0

Compiler warnings:

../../gmp-6.1.2/printf/obprintf.c:59: warning: ISO C forbids an empty 
translation unit [-Wpedantic]
   59 | #endif /* HAVE_OBSTACK_VPRINTF */

../../gmp-6.1.2/printf/obvprintf.c:52: warning: ISO C forbids an empty 
translation unit [-Wpedantic]
   52 | #endif /* HAVE_OBSTACK_VPRINTF */

../../gmp-6.1.2/printf/obprntffuns.c:72: warning: ISO C forbids an empty 
translation unit [-Wpedantic]
   72 | #endif /* HAVE_OBSTACK_VPRINTF */


% make check passed without errors

——

% /usr/bin/clang --version
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: 
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Compiler warnings:

libtool: compile:  /usr/bin/clang -DHAVE_CONFIG_H -I. -I../../gmp-6.1.2/mpn 
-I.. -D__GMP_WITHIN_GMP -I../../gmp-6.1.2 -DOPERATION_toom_interpolate_5pts -O2 
-pedantic -fomit-frame-pointer -m64 -mtune=skylake -march=broadwell -c 
toom_interpolate_5pts.c  -fno-common -DPIC -o .libs/toom_interpolate_5pts.o
toom_interpolate_5pts.c:71:19: warning: expression result unused 
[-Wunused-value]
  ASSERT_NOCARRY (mpn_divexact_by3 (v2, v2, kk1));/* v2 <- v2 / 3 */
  ^~~
../../gmp-6.1.2/gmp-impl.h:1621:6: note: expanded from macro 'mpn_divexact_by3'
  (3 & mpn_bdiv_dbm1 (dst, src, size, __GMP_CAST (mp_limb_t, GMP_NUMB_MASK / 
3)))
   ~ ^
../../gmp-6.1.2/gmp-impl.h:2412:33: note: expanded from macro 'ASSERT_NOCARRY'
#define ASSERT_NOCARRY(expr)   (expr)
^~~~
1 warning generated.


toom_interpolate_8pts.c:164:18: warning: expression result unused 
[-Wunused-value]
  ASSERT_NOCARRY(mpn_divexact_by3 (r5, r5, 3 * n + 1));
  ~~~^
../../gmp-6.1.2/gmp-impl.h:1621:6: note: expanded from macro 'mpn_divexact_by3'
  (3 & mpn_bdiv_dbm1 (dst, src, size, __GMP_CAST (mp_limb_t, GMP_NUMB_MASK / 
3)))
   ~ ^
../../gmp-6.1.2/gmp-impl.h:2412:33: note: expanded from macro 'ASSERT_NOCARRY'
#define ASSERT_NOCARRY(expr)   (expr)
^~~~

../../gmp-6.1.2/printf/obprintf.c:59:34: warning: ISO C requires a translation 
unit to contain at least one declaration [-Wempty-translation-unit]
#endif /* HAVE_OBSTACK_VPRINTF */
 ^

../../gmp-6.1.2/printf/obvprintf.c:52:34: warning: ISO C requires a translation 
unit to contain at least one declaration [-Wempty-translation-unit]
#endif /* HAVE_OBSTACK_VPRINTF */
 ^

../../gmp-6.1.2/printf/repl-vsnprintf.c:396:30: warning: ISO C requires a 
translation unit to contain at least one declaration [-Wempty-translation-unit]
#endif /* ! HAVE_VSNPRINTF */
 ^


% make check errors

../../../gmp-6.1.2/test-driver: line 107: 30266 Segmentation fault: 11  "$@" > 
$log_file 2>&1
FAIL: t-toom53

——

% /opt/local/bin/clang-mp-9.0 --version
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-9.0/bin

Compiler warnings:

toom_interpolate_5pts.c:71:19: warning: expression result unused 
[-Wunused-value]
  ASSERT_NOCARRY (mpn_divexact_by3 (v2, v2, kk1));/* v2 <- v2 / 3 */
  ^~~
../../gmp-6.1.2/gmp-impl.h:1621:6: note: expanded from macro 'mpn_divexact_by3'
  (3 & mpn_bdiv_dbm1 (dst, src, size, __GMP_CAST (mp_limb_t, GMP_NUMB_MASK / 
3)))
   ~ ^
../../gmp-6.1.2/gmp-impl.h:2412:33: note: expanded from macro 'ASSERT_NOCARRY'
#define ASSERT_NOCARRY(expr)   (expr)
^~~~


toom_interpolate_8pts.c:164:18: warning: expression result unused 
[-Wunused-value]
  ASSERT_NOCARRY(mpn_divexact_by3 (r5, r5, 3 * n + 1));
  ~~~^
../../gmp-6.1.2/gmp-impl.h:1621:6: note: expanded from macro 'mpn_divexact_by3'
  (3 & mpn_bdiv_dbm1 (dst, src, size, __GMP_CAST (mp_limb_t, GMP_NUMB_MASK / 
3)))
   ~ ^
../../gmp-6.1.2/gmp-impl.h:2412:33: note: expanded from macro 'ASSERT_NOCARRY'
#define ASSERT_NOCARRY(expr)   (expr)
^~~~


../../gmp-6.1.2/printf/obprintf.c:59:34: warning: ISO C requires a translation 
unit to contain at least one declaration [-Wempty-translation-unit]
#endif /* HAVE_OBSTACK_VPRINTF */
 ^


../../gmp-6.1.2/printf/obvprintf.c:52:34: warning: ISO C requires a translation 
unit to contain at least one declaration [-Wempty-translation-unit]
#endif /* HAVE_OBSTACK_VPRINTF */
 

Re: segmentation fault in t-toom53 test with MAC OS X Catalina (Clang 11.0)

[Hans Åberg]

> On 8 Oct 2019, at 23:59, Torbjörn Granlund  wrote:
> 
> Juergen Reuter  writes:
> 
>  Please let me know any further information you need.
> 
> This is almost surely a compiler bug.  We have encountered countless of
> bugs in clang since it showed up.  We have up-to-date apple systems for
> running GMP tests, but your clang seems to be newer than what we have.

One can take down a Clang 8 binary which might be newer than the inhouse one.

> I suggest that you install gcc on your system.  It might be a pain to
> compile if you only have a buggy clang on your system, but I believe
> there are precompiled gcc ready to download.

One suggestion is MacPorts which has not yet been updated for this MacOS 10.15.

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: segmentation fault in t-toom53 test with MAC OS X Catalina (Clang 11.0)

[Hans Åberg]

One might take down MacPorts GCC on MacOS 10.14 and then update to MacOS 10.15, 
but then it cannot be updated unless MacPorts has done so.


> On 9 Oct 2019, at 00:52, JRR  wrote:
> 
> I see, I haven't updated my newer Macbook Pro from 2015 (which is Haswell)
> to 10.15, but updated the XCode. There compilation and running the tests do
> work.
> 
> 
> Am 09.10.19 um 00:44 schrieb Hans Åberg:
>>> On 8 Oct 2019, at 23:59, Torbjörn Granlund  wrote:
>>> 
>>> Juergen Reuter  writes:
>>> 
>>>  Please let me know any further information you need.
>>> 
>>> This is almost surely a compiler bug.  We have encountered countless of
>>> bugs in clang since it showed up.  We have up-to-date apple systems for
>>> running GMP tests, but your clang seems to be newer than what we have.
>> One can take down a Clang 8 binary which might be newer than the inhouse one.
>> 
>>> I suggest that you install gcc on your system.  It might be a pain to
>>> compile if you only have a buggy clang on your system, but I believe
>>> there are precompiled gcc ready to download.
>> One suggestion is MacPorts which has not yet been updated for this MacOS 
>> 10.15.
>> 
> 
> -- 
> --
> -
> Juergen Reuter
> DESY Theory Group, Bldg. 2a
> Notkestr. 85
> 22607 Hamburg, GERMANY
> Tel +49 (0)40 8998 3895
> Fax +49 (0)40 8998 2777
> skype: jr_reuter
> -
> 

___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: Latest commit introduces undefined behavior in hgcd2.c

[Hans Åberg]

> On 18 Sep 2019, at 21:37, Niels Möller  wrote:
> 
> …a problem, at least in theory, if it is "undefined behavior". I'm afraid I
> don't know these fine details of the C spec by heart.

It is undefined behavior according to the section “Shift operators” in
  https://en.cppreference.com/w/c/language/operator_arithmetic


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: repl-vsnprintf.c:396:0: error: ISO C forbids an empty translation unit

[Hans Åberg]

> On 13 Feb 2018, at 12:24, Torbjörn Granlund  wrote:
> 
> Dennis Clarke  writes:
> 
>  As a minor annoyance it does cause gcc ( recent versions 7.x ) to fail.
>  Oddly enough ye Oracle Studio 12.6 cc running in strict c99 mode is fine
>  and happy with everything. That is a new experience for me. However the
>  performance on sparc is miserable.  We all know this and we know why.
> 
> I like Vincent's proposal; I had thought we needed to add something
> which leaves garbage in the object files.

There is a discussion here [1]: The translation unit is the input source, it 
seems, which must be non-empty, but not the resulting object file; however, a 
conforming compiler can complain about whatever.

1. https://bytes.com/topic/c/answers/222053-empty-translation-unit-valid


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs

Re: GMP 6.1.2: 32-bit ARM build failure on 64-bit hardware with CFLAGS=-g

[Hans Åberg]

> On 24 Jan 2018, at 18:09, Torbjörn Granlund  wrote:
> 
> If you override flags for choosing the architecture level and/or ABI,
> you cannot expect things to work.
> 
>  If so, is there another easy with debug info, without knowing in
>  advance what compiler flags configure would have autodetected?
> 
> Cut and paste?

Automake adds the CXXFLAGS after the AM_CXXFLAGS. So if one in the Makefile.am 
sets
  AM_CXXFLAGS = -std=c++14
then
  ..//configure CXXFLAGS=-std=c++17
gives "-std=c++14 -std=c++17" to the compiler. Then GCC chooses the last one in 
the sequence, so in this case, it is "-std=c++17" that is used, and the compile 
is for C++17.

This way, one can make different builds in parallel directories. It depends 
though on the compiler, and what is does for each setting.


___
gmp-bugs mailing list
gmp-bugs@gmplib.org
https://gmplib.org/mailman/listinfo/gmp-bugs