Skip to content

Trigger rewriting to propagate itypes from one declaration to another of the same function #678

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
kyleheadley opened this issue Aug 16, 2021 · 3 comments
Labels
benchmark failure A bug causing a failure in our nightly benchmark tests rewriter

Comments

@kyleheadley
Copy link
Member

In this example, we'd like to save some work by having the itypes rewritten to the definition:

static int compare (int* a : itype(_Ptr<int>), int* b : itype(_Ptr<int>));

static int compare (int* a, int* b)
{
  a = 1;
  b = 1;
  return 1;
}

Internally, a and b are itypes in both prototypes, because clang merges them. The problem is that 3C avoids rewriting prototypes that don't change, and there's nothing to trigger the change. Make one of them safe, and you'll see that the other itype shows up as well.

It's possible that, because of clang's merge, 3C can't tell that there's a needed rewrite without reading the source during the rewrite phase.

@kyleheadley
Copy link
Member Author

I added a temp fix for the generic case in DeclRewriter.cpp(search "#678"). This can be removed when a more general fix is finished.

@mattmccutchen-cci mattmccutchen-cci changed the title Trigger rewriting to propagate itypes Trigger rewriting to propagate itypes from one declaration to another of the same function Sep 10, 2021
@mattmccutchen-cci
Copy link
Member

Another example, reduced from an error Kyle reported in the Olden mst benchmark:

foo.c:

#include <stdlib.h>

bar.c:

extern int atoi(const char *);

void bar(const char *arg) {
  atoi(arg);
}

After 3c -alltypes -output-dir=out.checked bar.c foo.c --, we have the following in out.checked/bar.c:

extern int atoi(const char *);

void bar(_Nt_array_ptr<const char> arg) {
  atoi(arg);
}

which of course is a compile error because the itype for atoi isn't available in that translation unit:

bar.c:4:8: error: passing '_Nt_array_ptr<const char>' to parameter of incompatible type 'const char *'
  atoi(arg);
       ^~~
bar.c:1:29: note: passing argument to parameter here
extern int atoi(const char *);
                            ^

Of course, it's bad practice to hard-code declarations of system functions like this, but it did occur in Olden. If we decide not to handle system functions as part of this issue, we can transfer this example to #507.

@mattmccutchen-cci mattmccutchen-cci added the benchmark failure A bug causing a failure in our nightly benchmark tests label Oct 7, 2021
@mattmccutchen-cci
Copy link
Member

A similar problem with environ came up in #725. In principle, we can include that case in this issue, although it's going to be harder to fix until 3C has real support for itypes on global variables.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
benchmark failure A bug causing a failure in our nightly benchmark tests rewriter
Projects
None yet
Development

No branches or pull requests

2 participants