Is importC ready? (page 3)

On 11/11/2021 9:06 AM, bachmeier wrote: > It would really help if the compiler would automatically add lines like `#define __restrict restrict`. Iain and I discussed that a few months ago. The original plan was to make them keywords. But there's a blizzard of them, and it's a different list for every compiler. We eventually decided it might be simpler to have the compiler automatically apply a set of its own #defines, like you say, but that will only work if the compiler itself is executing the preprocessor.

On Friday, 12 November 2021 at 04:13:44 UTC, Steven Schveighoffer wrote:

On 11/11/21 10:29 PM, Walter Bright wrote:

On 11/11/2021 8:58 AM, bachmeier wrote:

[...]

Was the file/line number given for the error incorrect?

While you are thinking about this, one thing I brought up in another thread, is that the preprocessor automatically adds file/line information to the preprocessed file. That is important so you can trace the error back to the original file.

But for this purpose, you do have a preprocessed file, which may have code that either ImportC cannot deal with or where the preprocessed file seemingly has been badly formed. Having to find the real line to diagnose in the real file is not that easy when the error messages are all based on the file/line rewrite tokens.

It would be nice for the compiler to at least have an option to show "true" file/line numbers. Maybe a directive to ignore all file/line rewrite tokens.

-Steve

Invoke gcc (or clang) with the -P flag. It will disable linemarker output, which means you’ll get error messages corresponding to the preprocessed line instead of the original line.

On 11/11/2021 8:13 PM, Steven Schveighoffer wrote: > While you are thinking about this, one thing I brought up in [another thread](https://forum.dlang.org/post/smdtv6$1rjc$1@digitalmars.com), is that the preprocessor automatically adds file/line information to the preprocessed file. That is important so you can trace the error back to the original file. > > But for this purpose, you do have a preprocessed file, which may have code that either ImportC cannot deal with or where the preprocessed file seemingly has been badly formed. Having to find the real line to diagnose in the real file is not that easy when the error messages are all based on the file/line rewrite tokens. > > It would be nice for the compiler to at least have an option to show "true" file/line numbers. Maybe a directive to ignore all file/line rewrite tokens. If you really need it, running a script to delete the file/line directives would do it.

On Friday, 12 November 2021 at 03:29:07 UTC, Walter Bright wrote: > On 11/11/2021 8:58 AM, bachmeier wrote: >> - The error messages tell you nothing. The only solution is to go through the entire (large) preprocessed C file and identify every problem, with no help from the compiler. The error message that caused me to file the bug was `illegal combination of type specifiers`. After more than an hour of working on it, I had finally commented out enough lines to make the error messages go away. > > Was the file/line number given for the error incorrect? > > I agree, though, that the error messages are inadequate. This first iteration of ImportC has a priority of getting correct code to compile correctly. Error messages are admittedly mostly placeholders. The important thing is the file/line being correct. The error messages are of this form: ``` /usr/include/x86_64-linux-gnu/bits/mathcalls.h(316): Error: illegal combination of type specifiers /usr/include/string.h(43): Error: found `__dest` when expecting `,` ``` I was only able to identify the offending lines by repeatedly commenting and uncommenting code.

November 15, 2021

[Solved] Re: Is importC ready?

Posted by bachmeier
in reply to bachmeier

Permalink

bachmeier

Posted in reply to bachmeier

Permalink

On Tuesday, 9 November 2021 at 16:41:04 UTC, bachmeier wrote:

I tried to compile a simple C file this morning, containing

#include "nmath.h"

double fsign(double x, double y)
{
#ifdef IEEE_754
    if (ISNAN(x) || ISNAN(y))
	return x + y;
#endif
    return ((y >= 0) ? fabs(x) : -fabs(x));
}

I assumed this would be straightforward since it doesn't have a bunch of dependencies and it's only a few lines of code. Instead, I got a stream of errors. After running the file through the preprocessor, I had to comment out anything with

__extension__
Restricted pointers *__restrict
_Float128
__asm__

And in the source, anything with ISNAN, or in the preprocessed file,

__builtin_isnan

I filed a bug. After this experience, it's not obvious to me that importC is ready to be part of a stable compiler release. Maybe I just had bad luck with the choice of file.

There's a solution for this. Buried in a recent post on This Week in D, there's a link to a list of fixes. That plus #define __builtin_isnan isnan allows my C file and many others to compile with LDC. Some files that compile with LDC do not compile with DMD. I'm still having trouble with __builtin_isfinite errors. I thought #define __builtin_isfinite isfinite would work, but it doesn't.

Once I understand this better, I will update the issue I created.

Forums