Hi,

On Fri, Aug 26, 2016 at 7:43 AM, Andre Vieira (lists)
<andre.simoesdiasvie...@arm.com> wrote:
> I am seeing failures on arm-none-eabi for Cortex-M0 for these two tests:
> .../gcc-final/arm-none-eabi/armv6-m/libstdc++-v3/include/variant: In
> member function 'std::__detail::__variant::_Variant_base<_Types>&
> std::__detail::__variant::_Variant_base<_Types>::operator=(const
> std::__detail::__variant::_Variant_base<_Types>&)':
> .../gcc-final/arm-none-eabi/armv6-m/libstdc++-v3/include/variant:442:
> error: '__try' was not declared in this scope
> .../gcc-final/arm-none-eabi/armv6-m/libstdc++-v3/include/variant:442:
> note: suggested alternative: '__try'
> .../gcc-final/arm-none-eabi/armv6-m/libstdc++-v3/include/variant:446:
> error: expected primary-expression before '...' token
> .../gcc-final/arm-none-eabi/armv6-m/libstdc++-v3/include/variant:446:
> error: there are no arguments to '__catch' that depend on a template
> parameter, so a declaration of '__catch' must be available [-fpermissive]^M
> .../gcc-final/arm-none-eabi/armv6-m/libstdc++-v3/include/variant:446:
> note: (if you use '-fpermissive', G++ will accept your code, but
> allowing the use of an undeclared name is deprecated)^M
> .../gcc-final/arm-none-eabi/armv6-m/libstdc++-v3/include/variant:447:
> error: expected ';' before '{' token^M
>
> (and more of the same ...)
>
> Adding '#include <bits/exception_defines.h>' to
> 'include/c++/7.0.0/variant' "fixes" that. Not sure its the right
> approach though.

Why not?

>
> For Cortex-M3 it builds but run.cc fails at execution time. I will look
> further into this.

Can you attach testsuite/libstdc++.log? I'll find an arm machine to
reproduce it.

> The reason it succeeds for Cortex-M3 is because
> '<utility>' includes '<exception>' and exception has the following code:
> #if (__cplusplus >= 201103L) && (ATOMIC_INT_LOCK_FREE > 1)
> #include <bits/exception_ptr.h>
> #include <bits/nested_exception.h>
> #endif
>
> Which includes bits/exception_ptr.h and thus bits/exception_defines.h
> for targets with ATOMIC_INT_LOCK_FREE which is the case for Cortex-M3
> but not Cortex-M0.



-- 
Regards,
Tim Shen

Reply via email to