hasdescriptor.c

[aoberoi]

Excellent work here! I'm fairly certain this issue is not yours, but most likely the version of clang I am using.

I ran ./checktests and got the one failure you mentioned, but I also got another failure for BlocksRuntime/tests/hasdescriptor.c. I am running clang 3.2 built from source on Ubuntu 12.10.

I just wanted to know if theres a better place to file this issue of if this might be something I screwed up while building.

Thanks.

[mackyle]

What is the output of clang --version?

If you uncomment the two printf lines (that are currently commented out) in hasdescriptor.c, what is the failure text for the hasdescriptor.c test?

Finally, if you change line 5 of checktests to:

CPPFLAGS='-O0 -Wno-unused -include testprefix.h -IBlocksRuntime'

(Changes optimization from default optimization to no optimization), does the hasdescriptor.c test still fail?

I have never seen the hasdescriptor.c test fail before and I've tested with clang 2.7 through clang 3.1, but I have not tested with clang 3.2 yet. Optimization settings can sometimes affect the test results (see issue #2), so try the -O0 setting.

Finally, bugs can be filed on the clang site at http://llvm.org/bugs/ (use the compiler-rt product to file a bug against the BlocksRuntime), but do try adjusting the optimization level in checktests first.

[ghost]

I'm encountering this issue on clang 4.0 on Alpine 3.6.2/edge (x86_64), which is musl-based. With and without optimizations, I get the following:

not ok 23 - hasdescriptor.c
# size of inner is 36
# size of outer is 40

[mackyle]

On Aug 8, 2017, at 00:53, Kiyoshi Aman wrote: I'm encountering this issue on clang 4.0 on Alpine 3.6.2/edge, which is musl-based. With and without optimizations, I get the following: not ok 23 - hasdescriptor.c # size of inner is 36 # size of outer is 40

Interesting. I will not be able to look at this for some time due to other time constraints. I also do not currently have access to a clang 4.0 build at the moment. However, if you look at the source code you see this: if (Block_size(inner) != Block_size(outer)) { printf("not the same size, using old compiler??\n"); return 1; } That suggests that indeed, it is compiler version related. Perhaps 4.0 went back to the same technique as the "old compiler" mentioned in the printf or that particular item is implemented in an architecture- specific fashion and Alpine 3.6.2/edge still uses the "old compiler" version. I do not know. The current version of that file can be found in this same repository in the "compiler-rt" branch (it always tracks the most current stuff) as the file (branch: compiler-rt) test/BlocksRuntime/ hasdescriptor.c, but if you check you will see it hasn't been updated in years, certainly not recently which brings me back to the possibility of it being specific to the Alpine 3.6.2/edge port of clang. It's also possible the clang folks haven't bothered to update the test file or you've found a (possibly architecture-specific) clang bug. If all the other tests pass though, blocks are clearly working for you (the sample does build and run just like described in the ReadMe.txt, right?) so I wouldn't worry too much about it -- just write it off as an Alpine 3.6.2/edge BlocksRuntime peculiarity. Kyle

[riyadshauk]

I'm getting the error too, running on Archlinux (kernel 4.18.16) with clang 7.0.0.

ok 22 - goto.c
not ok 23 - hasdescriptor.c
# In file included from <built-in>:1:
# In file included from ./testprefix.h:4:
# In file included from /usr/include/stdlib.h:25:
# In file included from /usr/include/bits/libc-header-start.h:33:
# /usr/include/features.h:184:3: warning: "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-W#warnings]
# # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE"
# ^
# 1 warning generated.
# not the same size, using old compiler??
ok 24 - josh.c

Everything else seemed fine.... so I just went ahead with the installation anyways... and ran the test command, seems fine for now... I needed this as a dependency to install Swift 4.2...

Do you think this should be a problem? Any updates on this issue?

Thanks for your help and for having this well-documented repo here; really helpful to newbies to compiler-related stuff.

EDIT:
I commented out the libblocksruntime dependency in the PKGBUILD file from the AUR for swift-language anyways, and went along with the installation... The installation failed in the building process. Here's the last screen of errors, for those interested:

In file included from /home/build/swift-language/src/swift/tools/swift-reflection-dump/swift-reflection-dump.cpp:23:
In file included from /home/build/swift-language/src/swift/include/swift/Reflection/ReflectionContext.h:29:
/home/build/swift-language/src/swift/include/swift/Reflection/TypeRef.h:517:5: error: 'GenericTypeParameterTypeRefs' following the 'template' keyword does not refer to a template
    FIND_OR_CREATE_TYPEREF(A, GenericTypeParameterTypeRef, Depth, Index);
    ^
/home/build/swift-language/src/swift/include/swift/Reflection/TypeRef.h:56:32: note: expanded from macro 'FIND_OR_CREATE_TYPEREF'
  Allocator.DEPENDENT_TEMPLATE TypeRefTy##s.insert({ID, TR});                  \
                               ^
<scratch space>:22:1: note: expanded from here
GenericTypeParameterTypeRefs
^
/home/build/swift-language/src/swift/include/swift/Reflection/TypeRefs.def:27:1: note: declared as a non-template here
TYPEREF(GenericTypeParameter, TypeRef)
^
/home/build/swift-language/src/swift/include/swift/Reflection/TypeRefBuilder.h:191:57: note: expanded from macro 'TYPEREF'
                     TypeRefID::Hash, TypeRefID::Equal> Id##TypeRefs;
                                                        ^
<scratch space>:151:1: note: expanded from here
GenericTypeParameterTypeRefs
^
In file included from /home/build/swift-language/src/swift/tools/swift-reflection-dump/swift-reflection-dump.cpp:23:
In file included from /home/build/swift-language/src/swift/include/swift/Reflection/ReflectionContext.h:29:
/home/build/swift-language/src/swift/include/swift/Reflection/TypeRef.h:558:5: error: 'DependentMemberTypeRefs' following the 'template' keyword does not refer to a template
    FIND_OR_CREATE_TYPEREF(A, DependentMemberTypeRef, Member, Base, Protocol);
    ^
/home/build/swift-language/src/swift/include/swift/Reflection/TypeRef.h:51:51: note: expanded from macro 'FIND_OR_CREATE_TYPEREF'
  const auto Entry = Allocator.DEPENDENT_TEMPLATE TypeRefTy##s.find(ID);       \
                                                  ^
<scratch space>:23:1: note: expanded from here
DependentMemberTypeRefs
^
/home/build/swift-language/src/swift/include/swift/Reflection/TypeRefBuilder.h:296:36: note: in instantiation of function template specialization 'swift::reflection::DependentMemberTypeRef::create<swift::reflection::TypeRefBuilder>' requested here
    return DependentMemberTypeRef::create(*this, member, base, *protocol);
                                   ^
/home/build/swift-language/src/swift/include/swift/Reflection/TypeRefs.def:28:1: note: declared as a non-template here
TYPEREF(DependentMember, TypeRef)
^
/home/build/swift-language/src/swift/include/swift/Reflection/TypeRefBuilder.h:191:57: note: expanded from macro 'TYPEREF'
                     TypeRefID::Hash, TypeRefID::Equal> Id##TypeRefs;
                                                        ^
<scratch space>:153:1: note: expanded from here
DependentMemberTypeRefs
^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
20 errors generated.
[807/813] Building CXX object tools/sw...-digester.dir/swift-api-digester.cpp.o
/home/build/swift-language/src/swift/tools/swift-api-digester/swift-api-digester.cpp:892:15: warning: unused variable 'Usr' [-Wunused-variable]
    StringRef Usr;
              ^
1 warning generated.
ninja: build stopped: subcommand failed.
./utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting
==> ERROR: A failure occurred in build().
    Aborting...
#