https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
Jonathan Wakely changed:
What|Removed |Added
Attachment #55070|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #32 from Janez Zemva ---
I resolved this issue by porting openlibm over to djgpp (some hacks and typedef
float float_t;, ... were necessary). The fix on the side of gcc might have been
a more thorough analysis of what is available in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #30 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:49f59826c66bcaa3531429381b4aed944c332e5b
commit r14-1454-g49f59826c66bcaa3531429381b4aed944c332e5b
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #29 from Jonathan Wakely ---
(In reply to Janez Zemva from comment #27)
> forcing glibcxx_cv_c99_math_tr1=yes solved this issue for me. The C99
> compliance test is really strict, even openlibm fails the test (it fails to
> define fl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #28 from Jonathan Wakely ---
(In reply to Janez Zemva from comment #26)
> I am a c++ user, so I don't like using c header files if at all possible.
is a C++ header file, if you doubt that, you can check the path where
it's included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #27 from Janez Zemva ---
forcing glibcxx_cv_c99_math_tr1=yes solved this issue for me. The C99
compliance test is really strict, even openlibm fails the test (it fails to
define float_t and double_t, but this can be hacked around).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #26 from Janez Zemva ---
I am a c++ user, so I don't like using c header files if at all possible. I am
pleased with how things are: I now compile/link a replacement libm and replace
the sloppy djgpp header files, but I haven't teste
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #25 from Jonathan Wakely ---
I think the simplest solution for this bug is just use and call trunc
instead of trying to use std::trunc. If you use the functions in the
global namespace then you get exactly the set that is supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #24 from Janez Zemva ---
I'll go libm shopping them, I know just the thing to try out first:
https://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/libm/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #23 from Jonathan Wakely ---
No, the built-in functions just call the functions defined in libm. GCC doesn't
implement them.
Look at the code for a call to __builtin_acosh:
https://godbolt.org/z/dPf46sKxx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #22 from Janez Zemva ---
They are very sloppy, so I doubt even what they provide is working 100%. This
is why I suggested the generative approach. gcc has many built-in functions,
surely a rudimentary could be cobbled out of them.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #21 from Jonathan Wakely ---
Oh, checking FLT_EVAL_METHOD doesn't work, because that's defined in
not . So another djgpp-specific "NO_FLOAT_TYPES" macro will be needed.
Sigh.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #20 from Jonathan Wakely ---
Created attachment 55070
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55070&action=edit
Patch to make cmath configure tests more granular
Something like this might work, but it's horrible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #19 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #15)
> A proper fix would be to split up the configure test for USE_C99_MATH_TR1 to
> be more fine-grained, so that we use the subset of functions that are
> supp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #18 from Jonathan Wakely ---
No, the functionality belongs in the C library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #17 from Janez Zemva ---
Perhaps missing functionality could also be auto-generated? I am a big fan of
generative programming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
Jonathan Wakely changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #16 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #15 from Jonathan Wakely ---
The reason that std::trunc is not provided is because (In reply to Jonathan
Wakely from comment #11)
> The problem is more likely to be that this macro is not defined for djgpp:
>
> #ifdef _GLIBCXX_USE_C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #14 from Janez Zemva ---
Certainly, but users will still be able to make use of the kludge.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #13 from Jonathan Wakely ---
The workaround is wrong and will not be accepted upstream.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #12 from Janez Zemva ---
I doubt DJGPP will change their C library, at least this workaround exists now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #10 from Jonathan Wakely ---
(In reply to Janez Zemva from comment #8)
> I took a look and I believe the c_global is already being selected and I
> believe the hack I presented should perhaps be applied to
> libstdc++-v3/include/c_gl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #9 from Janez Zemva ---
I'd also like to mention, that the hack is already present in the c_global
cmath file, but is perhaps in a wrong section of the file, i.e. it is in the
section protected by:
#if defined(__STDCPP_FLOAT64_T__)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #8 from Janez Zemva ---
I took a look and I believe the c_global is already being selected and I
believe the hack I presented should perhaps be applied to
libstdc++-v3/include/c_global/cmath - the hack template is in there. As for th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #7 from Jonathan Wakely ---
Some of the libstdc++ changes in
https://aur.archlinux.org/cgit/aur.git/tree/gcc-djgpp.diff?h=dosbox-gcc would
be great to upstream.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #6 from Janez Zemva ---
There are a lot of patches and I never went over all of them. I'll take another
look and update my bug report, if necessary (I think you're probably right).
But, should anyone else want to, the build script is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #5 from Jonathan Wakely ---
And the $build-dir/$target/libstdc++-v3/config.log file should show the output
from this:
AC_MSG_NOTICE("C" header strategy set to $enable_cheaders)
That would confirm if it's being set to c_std
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #4 from Jonathan Wakely ---
Hmm, I don't see anything in the configure scripts that would cause c_std to be
used implicitly for djgpp (or any other target). Maybe there's a local patch
applied to the djgpp copy of GCC sources?
It mi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #3 from Janez Zemva ---
I am the "maintainer" of this dosbox-gcc aur (mostly I just borrow from other
builds). I have told the DJGPP community about this issue 2 times and they
shrugged it off, since they mostly compile .c source fil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #2 from Jonathan Wakely ---
Also:
if test $enable_cheaders = c_std ; then
AC_MSG_WARN([the --enable-cheaders=c_std configuration is obsolete,
c_global should be used instead])
AC_MSG_WARN([if you are unable to use c_global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109818
--- Comment #1 from Jonathan Wakely ---
This means djgpp is doing this:
dnl To use the obsolete 'c_std' headers use --enable-cheaders-obsolete as
dnl well as --enable-cheaders=c_std, otherwise configure will fail.
Any idea why?
As it says, th
33 matches
Mail list logo
