call of overloaded 'softdouble(int)' is ambiguous
R3volv360 opened this issue · comments
I'm seeing the following error on make that isn't referenced in the docs:
esp32-opencv/modules/core/src/softfloat.cpp:3537:107: error: call of overloaded 'softdouble(int)' is ambiguous
3537 | static const float64_t exp_prescale = float64_t::fromRaw(0x3ff71547652b82fe) * float64_t(1 << EXPTAB_SCALE);
| ^
In file included from esp32-opencv/modules/core/src/softfloat.cpp:68:
esp32-opencv/modules/core/include/opencv2/core/softfloat.hpp:257:14: note: candidate: 'cv::softdouble::softdouble(double)'
257 | explicit softdouble( const double a ) { Cv64suf s; s.f = a; v = s.u; }
| ^~~~~~~~~~
esp32-opencv/modules/core/src/softfloat.cpp:248:1: note: candidate: 'cv::softdouble::softdouble(int64_t)'
248 | softdouble::softdouble( const int64_t a ) { *this = i64_to_f64(a); }
| ^~~~~~~~~~
esp32-opencv/modules/core/src/softfloat.cpp:247:1: note: candidate: 'cv::softdouble::softdouble(int32_t)'
247 | softdouble::softdouble( const int32_t a ) { *this = i32_to_f64(a); }
| ^~~~~~~~~~
esp32-opencv/modules/core/src/softfloat.cpp:246:1: note: candidate: 'cv::softdouble::softdouble(uint64_t)'
246 | softdouble::softdouble( const uint64_t a ) { *this = ui64_to_f64(a); }
| ^~~~~~~~~~
esp32-opencv/modules/core/src/softfloat.cpp:245:1: note: candidate: 'cv::softdouble::softdouble(uint32_t)'
245 | softdouble::softdouble( const uint32_t a ) { *this = ui32_to_f64(a); }
| ^~~~~~~~~~
In file included from esp32-opencv/modules/core/src/softfloat.cpp:68:
esp32-opencv/modules/core/include/opencv2/core/softfloat.hpp:232:5: note: candidate: 'cv::softdouble::softdouble(const cv::softdouble&)'
232 | softdouble( const softdouble& c) { v = c.v; }
| ^~~~~~~~~~
Further up in the code it has: #define EXPTAB_SCALE 6 so the complaint seems to be about float64_t(1 << EXPTAB_SCALE) = float64_t(1 << 6) = float64_t(64)?
The definitions all refer to [u]int[size]_t and none for int. I am building this with the xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++ compiler. The docs show that it used xtensa-esp32-elf/esp-2019r2-8.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++ (the difference being esp-2022r1-11.2.0 vs esp-2019r2-8.2.0).
I don't have the C++ knowledge to formulate a good guess on why this isn't working with the ESP32 build setup vs compiling it for my 64bit Ubuntu machine. Why would the call not be ambiguous in the latter case, but with the ESP32 build it can't decide which method to use?
If I did have to guess I would think there is some difference in how integer types are being handled in the xtensa-esp32-elf/esp-2019r2-8.2.0 compiler vs the xtensa-esp32-elf/esp-2022r1-11.2.0, but I also have no idea how to check that.
Looks like there was a related change in the esp-2022r1-RC1 release:
GCC: Changed int32_t type in the Xtensa compiler to long instead of int before. Upstream GCC uses long for int32_t type on Xtensa, RISC-V, and other platforms.
I think that means that CV_INT32_T_IS_LONG_INT will need to be set as per this OpenCV code.
Will test this shortly
EDIT: this also seems relevant: ESP-IDF Programming Guide migration to 5.0
I'm getting new errors, so I guess that's progress :) I'm going to go and chip away at these to see if I can get it compiling with the latest toolchain
Hello, did you solve it or made more progress @R3volv360 ? It would really help me.
@jcandel01 unfortunately not. A combination of personal issues and my general lack of deep C++ understanding hindered me enough to put it down for now. I do have an ESP32 chip now just sitting around doing nothing, so maybe when I have more time I'll pick this up again, but no significant progress unfortunately.
Hey, I think I found a solution to this. Please create a file with the below content in it
/*
* Copyright (c) 2019 BayLibre SAS
*
* SPDX-License-Identifier: Apache-2.0
*/
#ifndef ZEPHYR_INCLUDE_TOOLCHAIN_STDINT_H_
#define ZEPHYR_INCLUDE_TOOLCHAIN_STDINT_H_
/*
* Some gcc versions and/or configurations as found in the Zephyr SDK
* (questionably) define __INT32_TYPE__ and derrivatives as a long int
* which makes the printf format checker to complain about long vs int
* mismatch when %u is given a uint32_t argument, and uint32_t pointers not
* being compatible with int pointers. Let's redefine them to follow
* common expectations and usage.
*/
#if __SIZEOF_INT__ != 4
#error "unexpected int width"
#endif
#undef __INT32_TYPE__
#undef __UINT32_TYPE__
#undef __INT_LEAST32_TYPE__
#undef __UINT_LEAST32_TYPE__
#undef __INT64_TYPE__
#undef __UINT64_TYPE__
#define __INT32_TYPE__ int
#define __UINT32_TYPE__ unsigned int
#define __INT_LEAST32_TYPE__ __INT32_TYPE__
#define __UINT_LEAST32_TYPE__ __UINT32_TYPE__
#define __INT64_TYPE__ long long int
#define __UINT64_TYPE__ unsigned long long int
/*
* The confusion also exists with __INTPTR_TYPE__ which is either an int
* (even when __INT32_TYPE__ is a long int) or a long int. Let's redefine
* it to a long int to get some uniformity. Doing so also makes it compatible
* with LP64 (64-bit) targets where a long is always 64-bit wide.
*/
#if __SIZEOF_POINTER__ != __SIZEOF_LONG__
#error "unexpected size difference between pointers and long ints"
#endif
#undef __INTPTR_TYPE__
#undef __UINTPTR_TYPE__
#define __INTPTR_TYPE__ long int
#define __UINTPTR_TYPE__ long unsigned int
#endif /* ZEPHYR_INCLUDE_TOOLCHAIN_STDINT_H_ */
and add the below flag to your compiler C++ flag variable
-imacros /home/kowshik/Desktop/opencv_porting/opencv/stdint.h
ultimately your CMAKE_CXX_FLAG command should look something like as shown below
set(CMAKE_CXX_FLAGS "${CMAKE_C_FLAGS} -w --std=c++11 -fpermissive -imacros /home/kowshik/Desktop/opencv_porting/opencv/stdint.h" CACHE INTERNAL "")
I downgraded the toolchain to esp-2021r2-patch3 . This eliminated the softdouble(int) issue, and the default esp32 build finished.