https://bugs.kde.org/show_bug.cgi?id=431436
--- Comment #2 from Wolfgang Bauer <wba...@tmo.at> ---
PS: changing the type to float_t in the callers instead doesn't help, I get a
different error then:
/home/abuild/rpmbuild/BUILD/kseexpr-4.0.1.0/src/KSeExprUI/Utils.cpp:37:6:
error: redefinition of 'bool KSeExpr::Utils::parseRangeComment(const string&,
float_t&, float_t&)'
37 | bool KSeExpr::Utils::parseRangeComment(const std::string &comment,
float_t &from, float_t &to)
| ^~~~~~~
/home/abuild/rpmbuild/BUILD/kseexpr-4.0.1.0/src/KSeExprUI/Utils.cpp:7:6: note:
'bool KSeExpr::Utils::parseRangeComment(const string&, double_t&, double_t&)'
previously defined here
7 | bool KSeExpr::Utils::parseRangeComment(const std::string &comment,
double_t &from, double_t &to)
| ^~~~~~~
So it seems that float_t is actually the same as double_t on i586 (apparently
both are long double), and therefore the compiler can't decide which one to
use...
FTR, this is how the types are defined in /usr/include/math.h here:
# if __GLIBC_FLT_EVAL_METHOD == 0 || __GLIBC_FLT_EVAL_METHOD == 16
typedef float float_t;
typedef double double_t;
# elif __GLIBC_FLT_EVAL_METHOD == 1
typedef double float_t;
typedef double double_t;
# elif __GLIBC_FLT_EVAL_METHOD == 2
typedef long double float_t;
typedef long double double_t;
# elif __GLIBC_FLT_EVAL_METHOD == 32
typedef _Float32 float_t;
typedef double double_t;
# elif __GLIBC_FLT_EVAL_METHOD == 33
typedef _Float32x float_t;
typedef _Float32x double_t;
# elif __GLIBC_FLT_EVAL_METHOD == 64
typedef _Float64 float_t;
typedef _Float64 double_t;
# elif __GLIBC_FLT_EVAL_METHOD == 65
typedef _Float64x float_t;
typedef _Float64x double_t;
# elif __GLIBC_FLT_EVAL_METHOD == 128
typedef _Float128 float_t;
typedef _Float128 double_t;
# elif __GLIBC_FLT_EVAL_METHOD == 129
typedef _Float128x float_t;
typedef _Float128x double_t;
# else
# error "Unknown __GLIBC_FLT_EVAL_METHOD"
# endif
#endif
and from /usr/include/bits/flt-eval-method.h:
#ifdef __FLT_EVAL_METHOD__
# if __FLT_EVAL_METHOD__ == -1
# define __GLIBC_FLT_EVAL_METHOD 2
# else
# define __GLIBC_FLT_EVAL_METHOD __FLT_EVAL_METHOD__
# endif
#elif defined __x86_64__
# define __GLIBC_FLT_EVAL_METHOD 0
#else
# define __GLIBC_FLT_EVAL_METHOD 2
#endif
=> __GLIBC_FLT_EVAL_METHOD is 2 on i586, leading to both float_t and double_t
being long double.
The same problem might occur on certain other architectures or compilers as
well, I suppose.
Quoting from https://en.cppreference.com/w/c/numeric/math/float_t:
> The types float_t and double_t are floating types at least as wide as float
> and
> double, respectively, and such that double_t is at least as wide as float_t.
> The value of FLT_EVAL_METHOD determines the types of float_t and double_t.
> FLT_EVAL_METHOD Explanation
> 0 float_t and double_t are equivalent to float and double, respectively
> 1 both float_t and double_t are equivalent to double
> 2 both float_t and double_t are equivalent to long double
> other both float_t and double_t are implementation defined
--
You are receiving this mail because:
You are watching all bug changes.
