If the else code fails with this compiler, using the if code seems to be a simple solution. We just need to extend the if condition to include this special compiler. Perhaps you can do that yourself and send a pull request?

Removing the const attributes would not be a good solution because they help the compilers to produce faster code and allow to calculate the table at compile time.

If 2 compilers (clang, icc) does not accept that code, maybe it's wrong?

I'm no C++ guru, and the information I've found online on this topic is about as clear as mud. This is the closest I've got:

https://stackoverflow.com/questions/27744079/is-it-a-conforming-compiler-extension-to-treat-non-constexpr-standard-library-fu

However, it does appear that there can be cases where a constexpr function is ill-formed, yet the standard requires no diagnostic, so the fact that the code compiles doesn't necessarily mean it is completely correct. (Which may have implications for the optimization it is intended to bring about.)

Another one from stackoverflow:
https://stackoverflow.com/questions/36497632/constexpr-function-cannot-be-used-in-a-constant-expression

https://lists.gnu.org/archive/html/lmi/2017-04/msg00030.html

#if __cplusplus < 201402 || defined(__clang__) // C++11

#if __cplusplus < 201402 || defined(__clang__) || defined(__INTEL_COMPILER) // C++11

Thank you. Fixed in commit ca87b06.

I don't understand. Is the code correct, and both the Clang and Intel compilers are erroring out spuriously? (I can submit an issue to Intel, if need be.)

It's not clear that this C++ usage is correct, and the Stack Overflow link that @amitdo posted implies that G++ accepts it only due to a non-conforming extension. If the desire is to take advantage of a GNU extension, then the code at issue should be enclosed in a #ifdef __GNUG__ or similar conditional, rather than enumerating all compilers which do not support it. However, I doubt that this should be necessary; do C++14/C++17 really not allow an acceptable form of this initialization?

I'd welcome code which works with any modern compiler and which does the same.

The goal is to calculate two lookup tables at compile time instead of wasting time during execution.

This works perfectly with the GNU compiler:

    $ size functions.o
       text	   data	    bss	    dec	    hex	filename
      65536	      0	      0	  65536	  10000	lstm/functions.o

Here the result with clang which needs code to fill the tables at runtime:

    $ size functions.o
      text	   data	    bss	    dec	    hex	filename
       200	      8	  65537	  65745	  100d1	lstm/functions.o

I completely agree that such an optimization is desirable. The problem is, the current implementation is not valid C++14/C++17 code, and only works with G++ due to a GNU extension---yet this is conditionalized in the code as though it were a limitation of the Clang and Intel compilers. If and when someone tries to build Tesseract using some other modern/conforming C++ compiler, they're going to encounter the same issue, and by this pattern yet another || defined(__BLAH__) will end up getting added. Eventually, you could well have every modern C++ compiler other than G++ listed here.

I don't know C++ well enough to suggest the Right Way(tm) of doing this initialization (after some more reading, it's not clear to me that such a way even exists at this point in time), but I would say, if you're going to rely on a GNU extension, then own up to it---conditionalize that code so that only __GNUG__ sees it, and everything else gets the less-optimal (but conformant) version. If and when other compilers are willing to break the standard like the GNU folks have, then those can be added to the conditional. It'll surely be a smaller set than where the current one is headed.

In the last hour I have read a bit more on this topic. The code is valid C++14 code for all compilers which handle the functions exp and tanh with a known argument as constexpr. The GNU compiler does this while other compilers don't. I think it is legitimate to say this is a limitation of such compilers.

The current implementation with the growing list of cases which don't use the optimal code is the result of a software evolution. We want the optimal code. If we'd change the implementation to restrict the optimal code to g++, we might miss other compilers which support it. And we would miss the fact that some compilers don't use the optimal code.

To solve this dilemma, we could add a feature check to the configure script. Or we could generate the source code for constant lookup tables, either by a small Python script or by a simple C program. Such generated source code would even work with any ANSI C compiler.

Have you looked at that first Stack Overflow link I posted ("Is it a conforming compiler extension to treat non-constexpr standard library functions as constexpr?")? Not only does it appear that the standard math-library functions are explicitly not allowed to be constexpr, it seems there is some possibility that G++'s non-conformance on this point may be dialed back in the future (though that discussion dates from 2014, so perhaps it has been superseded).

Given that at present, G++ builds are the only known beneficiaries of this optimization, I believe taking the "classic" approach of generating the table via an external script (and sidestepping the whole C++ standards-conformance issue) would be a good way to go. In my experience, it's certainly possible for code to be too modern for its own good...

The code for the classic approach is much shorter than the whole discussion here, even shorter than your comment. I'll send a pull request for it tomorrow.

I'm not surprised that the discussion outweighs the code :-]

Thank you Stefan, I appreciate this solution which will allow all modern C++ compilers to benefit from the optimization.

FYI, Intel C/C++ compilers complete adoption of LLVM

I know It does not matter for this issue because the code in #2740 is compiler independent.