Questions, powerpc/powerpc64 clang 3.8.0/libc++ buildworld context: which _Unwind_RaiseException implementation(s)?

[Mark Millard]

Anyone know for clang 3.8.0 or devel/powerpc64-gcc based and WITH_LIBCPLUSPLUS= 
(use of libcxxrt and libc++ for the system) which _Unwind_RaiseException 
implementation is supposed to be used for TARGET_ARCH=powerpc? 
TARGET_ARCH=powerpc64? Alternatives around include:

/usr/src/contrib/llvm/projects/libunwind/src/Unwind-EHABI.cpp having:

> _Unwind_RaiseException(_Unwind_Exception *exception_object) {

/usr/src/contrib/llvm/projects/libunwind/src/UnwindLevel1.c having:

> _Unwind_RaiseException(_Unwind_Exception *exception_object) {

/usr/src/contrib/gcc/unwind.inc having:

> _Unwind_RaiseException(struct _Unwind_Exception *exc)

Should contrib/libcxxrt/exception.cc in a clang 3.8.0/libc++ or 
devel/powerpc64-gcc based buildworld context ever use contrib/gcc/unwind.inc's 
_Unwind_RaiseException implementation?

For both TARGET_ARCH=powerpc (clang 3.8.0 based buildworld) and 
TARGET_ARCH=powerpc64 (devel/powerpc64-gccb based buildworld) I currently get 
the contrib/gcc/unwind.inc binding.



But c++ exceptions fail to work for both contexts:

TARGET_ARCH=powerpc gets a SEGV in _Unwind_GetGR
(contrib/gcc/unwind-dw2.c:177).

TARGET_ARCH=powerpc64 loops without bound in _Unwind_RaiseException
(in contrib/gcc/unwind.inc).



For TARGET_ARCH=powerpc using a different compiler than clang 3.8.0:

> # g++5 -I /usr/include/c++/v1/ -L /usr/lib/ -g -Wall -pedantic 
> exception_test.cpp
> or
> # g++5 -g -Wall -pedantic exception_test.cpp
> or
> # g++49 -g -Wall -pedantic exception_test.cpp
> or
> # g++49 -I /usr/include/c++/v1/ -L /usr/lib/ -g -Wall -pedantic 
> exception_test.cpp

(Note the lack of -Wl,-rpath=/usr/local/lib/gcc49 or 
-Wl,-rpath=/usr/local/lib/gcc5 use.)

I get the same SEGV at the same place (return statement in _unwind_GetGR) 
despite the use of _Unwind_Resume_or_Rethrow being the caller of 
_Unwind_RaiseException (backtrace omitted here):

> # ./a.out
> terminate called after throwing an instance of 'std::exception'
> Segmentation fault (core dumped)


By contrast the following do not fail:

> # g++49 -Wl,-rpath=/usr/local/lib/gcc49 -g -Wall -pedantic exception_test.cpp
> # ./a.out
> # g++5 -Wl,-rpath=/usr/local/lib/gcc5 -g -Wall -pedantic exception_test.cpp
> # ./a.out
> # 



For TARGET_ARCH=powerpc64 (devel/powerpc64-gcc is already gcc5 based but has no 
/usr/local/lib/gcc5/ so just using lang/gcc49):

> # g++49 -I /usr/include/c++/v1/ -L /usr/lib/ -g -Wall -pedantic 
> exception_test.cpp

I get the same "loops without bound in _Unwind_RaiseException" as with clang++ 
and devel/powerpc64-gcc.

But for:

> # g++49 -Wl,-rpath=/usr/local/lib/gcc49 -g -Wall -pedantic exception_test.cpp


the ./a.out works fine for the powerpc64 context.



All this suggests problems in contrib/gcc/ for stack unwinding for powerpc and 
for powerpc64 for each of the g++49, g++5, and clang 3.8.0 compilers.

Some sort of exception-ABI difference(s) with gcc 4.2.1 for each of the 2 
TARGET_ARCH's and more modern compilers?

Note that for powerpc64 buildworld was done by devel/powerpc64-gcc, not by 
clang 3.8.0, vastly limiting clang's involvement. Yet a problem still exists.


The following 8 line program is enough to show the behavior:

> #include 
> 
> int main(void)
> {
> try { throw std::exception(); }
> catch (std::exception& e) {} // same result without &
> return 0;
> }

But the original problem was found and isolated in kyua and other programs 
before generating the simple example.

===
Mark Millard
markmi at dsl-only.net

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: Ceph compilation on inclusion of /usr/include/c++/v1/deque

[Willem Jan Withagen]

On 20-2-2016 16:50, Dimitry Andric wrote:
> On 20 Feb 2016, at 16:09, Willem Jan Withagen  wrote:
>>
>> I'm trying to build a port of Ceph for FreeBSD, which is sort of trying
>> to shoot at a tank with a watergun :)
> 
> This is very nice, it would be good to have Ceph on FreeBSD.  Note that
> if you have problems with porting, usually the freebsd-ports mailing
> list is a better audience.
> 
> 
>> I you want to reproduce it is rather labourious, but not all that complex:
>> git clone https://github.com/wjwithagen/ceph.git
>> cd ceph
>> git checkout wip-wjw-freebsd-tests
>> ./do_freebsd.sh
>>
>> And wait for the error to appear.
> ...
>> /usr/include/c++/v1/deque:912:49: error: invalid application of 'sizeof'
>> to an incomplete type 'value_type' (aka 'RGWPeriod')
>>static const difference_type __block_size = sizeof(value_type) < 256
>> ? 4096 / sizeof(value_type) : 16;
>>^~
>> /usr/include/c++/v1/deque:1159:15: note: in instantiation of template
>> class 'std::__1::__deque_base>  std::__1::allocator >' requested here
>>: private __deque_base<_Tp, _Allocator>
>>  ^
>> rgw/rgw_period_history.h:26:27: note: in instantiation of template class
>> 'std::__1::deque>> ' requested here
>>std::deque periods;
>>  ^
>> rgw/rgw_period_history.h:16:7: note: forward declaration of 'RGWPeriod'
>> class RGWPeriod;
>>  ^
> 
> Without having to build anything, I see the problem already. :) The
> error message is unfortunately rather confusing, but the gist of it is
> that the implementation of std::deque<> requires a complete type.
> 
> Which means that you cannot do this:
> 
> #include 
> class foo;
> std::deque bar;
> 
> Compiling this example with clang and libc++ will result in (not all
> errors shown, no need to):
> 
> In file included from deque-test.cpp:1:
> /usr/include/c++/v1/deque:912:49: error: invalid application of 'sizeof' 
> to an incomplete type 'value_type' (aka 'foo')
> static const difference_type __block_size = sizeof(value_type) < 256 
> ? 4096 / sizeof(value_type) : 16;
> ^~
> /usr/include/c++/v1/deque:1159:15: note: in instantiation of template 
> class 'std::__1::__deque_base' requested here
> : private __deque_base<_Tp, _Allocator>
>   ^
> deque-test.cpp:3:17: note: in instantiation of template class 
> 'std::__1::deque' requested here
> std::deque bar;
> ^
> deque-test.cpp:2:7: note: forward declaration of 'foo'
> class foo;
>   ^
> 
> Similarly, compiling the example with g++ and libstdc++ (6.0.0 from
> ports) results in:
> 
> In file included from /usr/local/lib/gcc6/include/c++/deque:64:0,
>  from deque-test.cpp:1:
> /usr/local/lib/gcc6/include/c++/bits/stl_deque.h: In instantiation of 
> 'void std::_Deque_base<_Tp, _Alloc>::_M_initialize_map(std::size_t) [with _Tp 
> = foo; _Alloc = std::allocator; std::size_t = unsigned int]':
> /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:490:26:   required from 
> 'std::_Deque_base<_Tp, _Alloc>::_Deque_base() [with _Tp = foo; _Alloc = 
> std::allocator]'
> /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:884:23:   required from 
> 'std::deque<_Tp, _Alloc>::deque() [with _Tp = foo; _Alloc = 
> std::allocator]'
> deque-test.cpp:3:17:   required from here
> /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:682:74: error: invalid 
> application of 'sizeof' to incomplete type 'foo'
>const size_t __num_nodes = (__num_elements/ 
> __deque_buf_size(sizeof(_Tp))
>   
> ^
> /usr/local/lib/gcc6/include/c++/bits/stl_deque.h:713:31: error: invalid 
> application of 'sizeof' to incomplete type 'foo'
>   % __deque_buf_size(sizeof(_Tp)));
>^
> 
> Looking at rgw_period_history.h, it is indeed using an incomplete type:
> 
> #include 
> #include 
> #include 
> #include 
> #include "include/assert.h"
> #include "include/types.h"
> 
> namespace bi = boost::intrusive;
> 
> class RGWPeriod;
> 
> /**
>  * RGWPeriodHistory tracks the relative history of all inserted periods,
>  * coordinates the pulling of missing intermediate periods, and provides a
>  * Cursor object for traversing through the connected history.
>  */
> class RGWPeriodHistory final {
>   /// an ordered history of consecutive periods
>   struct History : public bi::avl_set_base_hook<> {
> std::deque periods;
> 
> E.g at this point, all the compiler has is a forward declaration of
> RGWPeriod.  If this even compiles on Linux, I am unsure how it manages
> to do 

Re: Ceph compilation on inclusion of /usr/include/c++/v1/deque

[Dimitry Andric]

On 20 Feb 2016, at 16:09, Willem Jan Withagen  wrote:
> 
> I'm trying to build a port of Ceph for FreeBSD, which is sort of trying
> to shoot at a tank with a watergun :)

This is very nice, it would be good to have Ceph on FreeBSD.  Note that
if you have problems with porting, usually the freebsd-ports mailing
list is a better audience.


> I you want to reproduce it is rather labourious, but not all that complex:
> git clone https://github.com/wjwithagen/ceph.git
> cd ceph
> git checkout wip-wjw-freebsd-tests
> ./do_freebsd.sh
> 
> And wait for the error to appear.
...
> /usr/include/c++/v1/deque:912:49: error: invalid application of 'sizeof'
> to an incomplete type 'value_type' (aka 'RGWPeriod')
>static const difference_type __block_size = sizeof(value_type) < 256
> ? 4096 / sizeof(value_type) : 16;
>^~
> /usr/include/c++/v1/deque:1159:15: note: in instantiation of template
> class 'std::__1::__deque_base  std::__1::allocator >' requested here
>: private __deque_base<_Tp, _Allocator>
>  ^
> rgw/rgw_period_history.h:26:27: note: in instantiation of template class
> 'std::__1::deque> ' requested here
>std::deque periods;
>  ^
> rgw/rgw_period_history.h:16:7: note: forward declaration of 'RGWPeriod'
> class RGWPeriod;
>  ^

Without having to build anything, I see the problem already. :) The
error message is unfortunately rather confusing, but the gist of it is
that the implementation of std::deque<> requires a complete type.

Which means that you cannot do this:

#include 
class foo;
std::deque bar;

Compiling this example with clang and libc++ will result in (not all
errors shown, no need to):

In file included from deque-test.cpp:1:
/usr/include/c++/v1/deque:912:49: error: invalid application of 'sizeof' to 
an incomplete type 'value_type' (aka 'foo')
static const difference_type __block_size = sizeof(value_type) < 256 ? 
4096 / sizeof(value_type) : 16;
^~
/usr/include/c++/v1/deque:1159:15: note: in instantiation of template class 
'std::__1::__deque_base' requested here
: private __deque_base<_Tp, _Allocator>
  ^
deque-test.cpp:3:17: note: in instantiation of template class 
'std::__1::deque' requested here
std::deque bar;
^
deque-test.cpp:2:7: note: forward declaration of 'foo'
class foo;
  ^

Similarly, compiling the example with g++ and libstdc++ (6.0.0 from
ports) results in:

In file included from /usr/local/lib/gcc6/include/c++/deque:64:0,
 from deque-test.cpp:1:
/usr/local/lib/gcc6/include/c++/bits/stl_deque.h: In instantiation of 'void 
std::_Deque_base<_Tp, _Alloc>::_M_initialize_map(std::size_t) [with _Tp = foo; 
_Alloc = std::allocator; std::size_t = unsigned int]':
/usr/local/lib/gcc6/include/c++/bits/stl_deque.h:490:26:   required from 
'std::_Deque_base<_Tp, _Alloc>::_Deque_base() [with _Tp = foo; _Alloc = 
std::allocator]'
/usr/local/lib/gcc6/include/c++/bits/stl_deque.h:884:23:   required from 
'std::deque<_Tp, _Alloc>::deque() [with _Tp = foo; _Alloc = 
std::allocator]'
deque-test.cpp:3:17:   required from here
/usr/local/lib/gcc6/include/c++/bits/stl_deque.h:682:74: error: invalid 
application of 'sizeof' to incomplete type 'foo'
   const size_t __num_nodes = (__num_elements/ 
__deque_buf_size(sizeof(_Tp))
  ^
/usr/local/lib/gcc6/include/c++/bits/stl_deque.h:713:31: error: invalid 
application of 'sizeof' to incomplete type 'foo'
  % __deque_buf_size(sizeof(_Tp)));
   ^

Looking at rgw_period_history.h, it is indeed using an incomplete type:

#include 
#include 
#include 
#include 
#include "include/assert.h"
#include "include/types.h"

namespace bi = boost::intrusive;

class RGWPeriod;

/**
 * RGWPeriodHistory tracks the relative history of all inserted periods,
 * coordinates the pulling of missing intermediate periods, and provides a
 * Cursor object for traversing through the connected history.
 */
class RGWPeriodHistory final {
  /// an ordered history of consecutive periods
  struct History : public bi::avl_set_base_hook<> {
std::deque periods;

E.g at this point, all the compiler has is a forward declaration of
RGWPeriod.  If this even compiles on Linux, I am unsure how it manages
to do so. :-)  Maybe the Linux build pulls in some other header first,
getting the full definition of RGWPeriod somehow?

In any case, the easiest fix is probably to switch around the inclusions
of the headers in rgw_period_history.cc, e.g. changing:

Ceph compilation on inclusion of /usr/include/c++/v1/deque

[Willem Jan Withagen]

I'm trying to build a port of Ceph for FreeBSD, which is sort of trying
to shoot at a tank with a watergun :)

There are 2 things to porting burdens:
Linux <> FreeBSD
GCC <> Clang

So I'm not sure whether to error below is due a GCC-ism that is not
suppoted by the 3.7.1 Clang we are running on CURRENT.

I you want to reproduce it is rather labourious, but not all that complex:
git clone https://github.com/wjwithagen/ceph.git
cd ceph
git checkout wip-wjw-freebsd-tests
./do_freebsd.sh

And wait for the error to appear.

--WjW



libtool: compile:  clang++ -DHAVE_CONFIG_H -I. -D__CEPH__
-D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D__STDC_FORMAT_MACROS
-D_GNU_SOURCE -DCEPH_LIBDIR=\"/usr/local/lib\"
-DCEPH_PKGLIBDIR=\"/usr/local/lib/ceph\" -DGTEST_USE_OWN_TR1_TUPLE=0
-D_REENTRANT -Woverloaded-virtual -fPIC -I./xxHash -Wall -Wtype-limits
-Wignored-qualifiers -Winit-self -Wpointer-arith -Werror=format-security
-fno-strict-aliasing -fsigned-char -ftemplate-depth-1024
-Wnon-virtual-dtor -Wno-invalid-offsetof -g -DGTEST_USE_OWN_TR1_TUPLE=1
-I/usr/local/include -Wno-unused-local-typedef -Wno-mismatched-tags
-Wno-macro-redefined -Wno-unused-function -Wno-unused-label
-Wno-undefined-bool-conversion -Wno-unused-private-field
-Wno-unused-local-typedef -Wno-uninitialized -Wno-gnu-designator
-Wno-inconsistent-missing-override -Wno-deprecated-declarations
-std=gnu++11 -MT rgw/librgw_la-rgw_basic_types.lo -MD -MP -MF
rgw/.deps/librgw_la-rgw_basic_types.Tpo -c rgw/rgw_basic_types.cc -o
rgw/librgw_la-rgw_basic_types.o >/dev/null 2>&1
In file included from rgw/rgw_client_io.cc:8:
In file included from rgw/rgw_client_io.h:13:
In file included from rgw/rgw_common.h:37:
In file included from rgw/rgw_website.h:18:
rgw/rgw_xml.h:168:12: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
  while (o = iter.get_next()) {
 ~~^
rgw/rgw_xml.h:168:12: note: place parentheses around the assignment to
silence this warning
  while (o = iter.get_next()) {
   ^
 (  )
rgw/rgw_xml.h:168:12: note: use '==' to turn this assignment into an
equality comparison
  while (o = iter.get_next()) {
   ^
   ==
In file included from rgw/rgw_cache.cc:4:
In file included from rgw/rgw_cache.h:7:
In file included from rgw/rgw_rados.h:11:
In file included from rgw/rgw_common.h:37:
In file included from rgw/rgw_website.h:18:
rgw/rgw_xml.h:168:12: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
  while (o = iter.get_next()) {
 ~~^
rgw/rgw_xml.h:168:12: note: place parentheses around the assignment to
silence this warning
  while (o = iter.get_next()) {
   ^
 (  )
rgw/rgw_xml.h:168:12: note: use '==' to turn this assignment into an
equality comparison
  while (o = iter.get_next()) {
   ^
   ==
In file included from rgw/rgw_cr_rados.cc:1:
In file included from rgw/rgw_rados.h:11:
In file included from rgw/rgw_common.h:37:
In file included from rgw/rgw_website.h:18:
rgw/rgw_xml.h:168:12: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
  while (o = iter.get_next()) {
 ~~^
rgw/rgw_xml.h:168:12: note: place parentheses around the assignment to
silence this warning
  while (o = iter.get_next()) {
   ^
 (  )
rgw/rgw_xml.h:168:12: note: use '==' to turn this assignment into an
equality comparison
  while (o = iter.get_next()) {
   ^
   ==
In file included from rgw/rgw_tools.cc:11:
In file included from rgw/rgw_common.h:37:
In file included from rgw/rgw_website.h:18:
rgw/rgw_xml.h:168:12: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
  while (o = iter.get_next()) {
 ~~^
rgw/rgw_xml.h:168:12: note: place parentheses around the assignment to
silence this warning
  while (o = iter.get_next()) {
   ^
 (  )
rgw/rgw_xml.h:168:12: note: use '==' to turn this assignment into an
equality comparison
  while (o = iter.get_next()) {
   ^
   ==
In file included from rgw/rgw_bucket.cc:11:
In file included from rgw/rgw_rados.h:11:
In file included from rgw/rgw_common.h:37:
In file included from rgw/rgw_website.h:18:
rgw/rgw_xml.h:168:12: warning: using the result of an assignment as a
condition without parentheses [-Wparentheses]
  while (o = iter.get_next()) {
 ~~^
rgw/rgw_xml.h:168:12: note: place parentheses around the assignment to
silence this warning
  while (o = iter.get_next()) {
   ^
 (  )
rgw/rgw_xml.h:168:12: note: use '==' to turn this assignment into an
equality comparison
  while (o = iter.get_next()) {
   ^
   ==
In file included from rgw/rgw_cache.cc:4:
In file included from rgw/rgw_cache.h:7:
In file included from 

Re: Questions about problems/errors with the include files

[Willem Jan Withagen]

On 20-2-2016 15:37, Dimitry Andric wrote:
> On 20 Feb 2016, at 15:31, Willem Jan Withagen  wrote:
>>
>> Before I actually dump the problem here.
>> Would this be the place to ask about include files that give errors for
>> code compiling under GCC but not under Clang 3.7??
>>
>> gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)
>>
>> FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225
>> Target: x86_64-unknown-freebsd11.0
>> Thread model: posix
> 
> Well, posting the actual error message(s) would help. :-)

I know, but Don't want the burden the list with a lot of cr.p if
it is not appriciated
Will send a next post.

--WjW


___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: confusing messages from clang

[Dimitry Andric]

On 20 Feb 2016, at 08:33, Alex Denisov <1101.deb...@gmail.com> wrote:
>> On 20 Feb 2016, at 01:57, Steve Kargl  
>> wrote:
>> 
>> If anyone is interesting fixing FreeBSD's C compiler, it
>> would be appreciated.
...
>> foo.c:21:1: error: use of undeclared identifier 'corrupt'; did you mean 
>> 'crypt'?
>> corrupt:
>> ^~~
>> crypt
>> /usr/include/unistd.h:450:7: note: 'crypt' declared here
>> char*crypt(const char *, const char *);
>>^
>> foo.c:21:8: error: expected ';' after return statement
>> corrupt:
>>  ^
>>  ;
>> foo.c:14:12: error: use of undeclared label 'corrupt'
>> goto corrupt;
>>  ^
...
> I’ve submitted the bug to LLVM’s bugzilla: 
> https://llvm.org/bugs/show_bug.cgi?id=26678
> 
> Also, it looks like OS agnostic. At least I see the same behaviour on OSX as 
> well.

Yes, the messages could definitely be improved.  But for a compiler, it
is sometimes hard to guess the 'intent' of the code, though. :)

Note that gcc (I used 6.0 from ports) gives similarly confused messages:

foo.c: In function 'foo':
foo.c:21:1: error: 'corrupt' undeclared (first use in this function)
 corrupt:
 ^~~
foo.c:21:1: note: each undeclared identifier is reported only once for each 
function it appears in
foo.c:21:1: warning: 'return' with a value, in function returning void
foo.c:5:1: note: declared here
 foo(int i)
 ^~~
foo.c:21:8: error: expected ';' before ':' token
 corrupt:
^
foo.c:14:6: error: label 'corrupt' used but not defined
  goto corrupt;
  ^~~~

In gcc's case, it appears to read the statement as "return corrupt:",
causing it to first complain about the undeclared identifier, and then
about a missing semicolon.  Later, the label is of course still not
defined, so it complains again.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Questions about problems/errors with the include files

[Dimitry Andric]

On 20 Feb 2016, at 15:31, Willem Jan Withagen  wrote:
> 
> Before I actually dump the problem here.
> Would this be the place to ask about include files that give errors for
> code compiling under GCC but not under Clang 3.7??
> 
> gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)
> 
> FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225
> Target: x86_64-unknown-freebsd11.0
> Thread model: posix

Well, posting the actual error message(s) would help. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Questions about problems/errors with the include files

[Willem Jan Withagen]

Hi,

Before I actually dump the problem here.
Would this be the place to ask about include files that give errors for
code compiling under GCC but not under Clang 3.7??

gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)

FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225
Target: x86_64-unknown-freebsd11.0
Thread model: posix

--WjW
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc [fpr use also tested]

[Dimitry Andric]

On 20 Feb 2016, at 09:34, Roman Divacky  wrote:
> Fwiw, I've just committed the patch to clang in r261422. You might want
> to keep using a local modification or ask dim@ to import that patch
> to our copy of 3.8.

I've asked the LLVM release manager to consider merging this into the
3.8 branch.  The fix looks trivial enough. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: confusing messages from clang

[David Chisnall]

C compilers are always doing best effort attempts to report when you feed them 
code that is not valid C.

For example, in this case:

On 20 Feb 2016, at 00:57, Steve Kargl  wrote:
>   if (i > 0)
>  goto corrupt;

This is valid, as long as you have a label called corrupt to look for.  You do 
not, however, because:

>   return;
> 
> whoops:
>   printf("whoops\n");
>   return
> 
> corrupt:
>   printf("corrupt\n”);

The statement:

> return corrupt: printf("corrupt\n");


is just confusing.  It appears to be trying to return the value in corrupt 
(which is not an identifier that corresponds to any valid variable) and then 
has some trailing characters after the end of the statement.  Fortunately, the 
compiler tells you exactly what is wrong:

First it says:

> foo.c:21:1: error: use of undeclared identifier 'corrupt'; did you mean 
> 'crypt'?
> corrupt:
> ^~~

Here, it is telling you that the value passed to your return statement is an 
undeclared identifier.  Then it tells you that you have more tokens after the 
end of your return statement:

> foo.c:21:8: error: expected ';' after return statement
> corrupt:
>   ^
>   ;

I am slightly surprised that there’s no warning that a return statement with a 
value is invalid in a function that returns void, but perhaps that’s because 
after finding two things wrong with one statement it gives up.

The correct fix, of course, is to insert the missing semicolon after the return 
at the end of line 19.  If you had tried compiling the same thing with gcc 5, 
then you would have noticed that you get very similar error messages (though 
gcc doesn’t attempt to provide a fixit hint and does warn that you have a 
return statement returning a value from a function that returns void).

David

___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"

Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc [fpr use also tested]

[Mark Millard]

Thanks!

llvm bugzilla's 26605 did not having anything yet for this so I've copied over 
your note. But I've left the status alone.


The next thing that I ran into looks nastier: c++'s exception handling is 
broken.

#include 

int main(void)
{
try { throw std::exception(); }
catch (std::exception& e) {} // same result without &
return 0;
}


does not work on powerpc (SEGV) or powerpc64 (unbounded loop, never returning 
from _Unwind_RaiseException). (The powerpc64 context is using 
devel/powerpc64-gcc or g++49 as the compiler with the system's headers and 
libraries. powerpc64-gcc was used for buildworld/buildkernel as well for this 
context.)

[g++49 using its own headers and libraries works fine for the above program.]


===
Mark Millard
markmi at dsl-only.net

On 2016-Feb-20, at 12:34 AM, Roman Divacky  wrote:

Fwiw, I've just committed the patch to clang in r261422. You might want
to keep using a local modification or ask dim@ to import that patch
to our copy of 3.8.

Thanks for your diagnosis and testing!

Roman

On Thu, Feb 18, 2016 at 02:29:29PM -0800, Mark Millard wrote:
> On 2016-Feb-17, at 9:23 PM, Mark Millard  wrote:
>> 
>> My fpr related notes/worries about the fix were wrong.
>> 
>> I finally got some time to look at this again and I see that I somehow 
>> missed the following code when I looked before:
>> 
>> // The calling convention either uses 1-2 GPRs or 1 FPR.
>> Address NumRegsAddr = Address::invalid();
>> if (isInt || IsSoftFloatABI) {
>>   NumRegsAddr = Builder.CreateStructGEP(VAList, 0, CharUnits::Zero(), "gpr");
>> } else {
>>   NumRegsAddr = Builder.CreateStructGEP(VAList, 1, CharUnits::One(), "fpr");
>> }
>> 
>> So the
>> 
>>   Builder.CreateStore(Builder.getInt8(8), NumRegsAddr);
>> 
>> in Case 2 is tracking gpr vs. fpr usage contexts as it should. Also:
>> 
>> llvm::Value *NumRegs = Builder.CreateLoad(NumRegsAddr, "numUsedRegs");
>> 
>> // "Align" the register count when TY is i64.
>> if (isI64 || (isF64 && IsSoftFloatABI)) {
>>   NumRegs = Builder.CreateAdd(NumRegs, Builder.getInt8(1));
>>   NumRegs = Builder.CreateAnd(NumRegs, Builder.getInt8((uint8_t) ~1U));
>> }
>> 
>> llvm::Value *CC =
>> Builder.CreateICmpULT(NumRegs, Builder.getInt8(8), "cond");
>> 
>> is using the same bounds check figure (8) for gpr and fpr.
>> 
>> Apparently that common bound is one reason that the clang numbering is not 
>> the same as the ABI document's numbering: clang's numbering allows using the 
>> same figure for both contexts. (Given the prior alignment for isI64 (or 
>> isF64 with IsSoftFloatABI).)
>> 
>> Sorry for the prior noise about fpr.
>> 
>> It is still true that DOUBLE_OR_FLOAT is untested so far.
>> 
>> ===
>> Mark Millard
>> markmi at dsl-only.net
> 
> I finally got some time to apply to some basic testing involving double as 
> well (for involving fpr use). . .
> 
> No problems with exceptions. Looking at the memory contents at various stages 
> in gdb looks good. va_list's gpr, fpr, overflow_arg_area changes as its 
> va_args use progresses look good. Values extracted by va_args use looks good. 
> Both default and -O2.
> 
> The added
> 
>> Builder.CreateStore(Builder.getInt8(8), NumRegsAddr);
> 
> 
> passes my checks. I've not observed any problems from buildworld materials, 
> unlike when that line is missing.
> 
> [Note: I run with the signal delivery modified to have a "red zone" to deal 
> with other aspects of clang 3.8.0 code generation that are not ABI compliant 
> for when the stack pointer is moved. Having a "red zone" is still 
> operationally correct for an ABI compliant code generation, it just 
> temporarily wastes more bytes. Also: the kernel was built with gcc 4.2.1 but 
> world was built with clang 3.8.0.]
> 
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> . . . [bad fpr related material omitted] . . .
> 
> On 2016-Feb-16, at 2:45 AM, Mark Millard  wrote:
> 
> I used:
> 
>> Index: /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp
>> ===
>> --- /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp 
>> (revision 295601)
>> +++ /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp 
>> (working copy)
>> @@ -3569,6 +3569,8 @@
>> {
>>  CGF.EmitBlock(UsingOverflow);
>> 
>> +Builder.CreateStore(Builder.getInt8(8), NumRegsAddr);
>> +
>>  // Everything in the overflow area is rounded up to a size of at least 4.
>>  CharUnits OverflowAreaAlign = CharUnits::fromQuantity(4);
> 
> as my test change. (Get evidence of operation before potential cleanup of the 
> duplicated 8's.)
> 
> After a full buildworld/installworld based on the updated compiler. . .
> 
> My simple example of the problem no longer fails.
> 
> "ls -l -n /" now works.
> 
> "svnlite update -r295601 /usr/src" now works.
> 
> So whatever you want to do for the details of any submitted code, the basics 
> of the change do avoid the