> On Feb. 21, 2015, 7:24 p.m., Corey Farrell wrote:
> > /branches/11/configure.ac, line 1065
> > <https://reviewboard.asterisk.org/r/4370/diff/3/?file=71557#file71557line1065>
> >
> >     I missed this before / thought Josh pointed it out.  This one should be 
> > AC_MSG_ERROR as well.
> 
> Matt Jordan wrote:
>     Replacing this with:
>                       AC_MSG_ERROR("nested-functions is required for gcc")
>     
>     Caused configure to fail:
>     
>     checking for -Wshadow... yes
>     checking for -march=native support... yes
>     checking for gcc -fnested-functions... configure: error: 
> "nested-functions is required for gcc"
>     
>     Even though I did have nested functions....
>     
>     
>     So that's weird.
>
> 
> Matt Jordan wrote:
>     I'm actually not sure what -fnested-functions would even do. My 
> google-foo is failing me on its use with GCC (which appears to not understand 
> it), and since we only set that on the "false" path (that is, we failed to 
> compile a program with a nested function), I'm not sure how it would help.
>     
>     As it is, I think I will put an AC_MSG_ERROR in the 'false' path of the 
> compilation.
> 
> Corey Farrell wrote:
>     So this finding can be dropped, I was wrong.  This line (and the next 
> line with [AST_NESTED_FUNCTIONS=]) is the block that is run if 
> AC_COMPILE_IFELSE succeeds without the -fnested-functions gcc flag.  So we're 
> not checking for nested functions, we're checking if nested functions fail 
> without the flag.
>     
>     Now if AC_COMPILE_IFELSE does fail we assume that it would succeed with 
> the GCC flag.  In theory we should verify that it would work with 
> -fnested-functions.  But that is a separate issue.
> 
> Matt Jordan wrote:
>     I'm not even sure '-fnested-functions' does anything...

See: https://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html

GCC Nested functions are actually used inside the gcc version of the RAII_VAR 
macro on the second line, to declare block local function which is called by 
the cleanup function to execute the desctuctor. This function gets embedded 
locally in the function where the RAII_VAR macro is called, creating a nested 
function in the process, ie:

void _dtor_ ## varname (vartype * v) {
  dtor(*v); 
}

called by:
vartype varname __attribute__((cleanup(_dtor_ ## varname))) = (initval)

Nested functions are somewhat similar to the clang blocks extension (though 
clang's version is much more powerfull in most, respects, except for using them 
by cleanup directly, which is were this whole patch is coming in).

In all this also means that if -fnested-functions is not supported in gcc, then 
RAII_VAR on gcc will fail and should be checked and cause a configure error, in 
my opinion. Gcc's nested-functions have been around since version 3.0.4 i 
think, by default enabled in gcc, but disabled (requiring -fnested-functions) 
when using llvm-gcc.


- Diederik


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4370/#review14519
-----------------------------------------------------------


On Feb. 21, 2015, 3:35 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4370/
> -----------------------------------------------------------
> 
> (Updated Feb. 21, 2015, 3:35 a.m.)
> 
> 
> Review request for Asterisk Developers and Diederik de Groot.
> 
> 
> Bugs: ASTERISK-20850
>     https://issues.asterisk.org/jira/browse/ASTERISK-20850
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This is a continuation of the patch put up for review on r3488. It addresses 
> the issues found on that review.
> 
> This patch *should* make Asterisk compile under clang. Note that compiling 
> with --enable-dev-mode will cause Asterisk to fail to compile under clang, as 
> it detects a number of warnings that aren't fixed under this patch.
> 
> 
> Diffs
> -----
> 
>   /branches/11/makeopts.in 432053 
>   /branches/11/main/Makefile 432053 
>   /branches/11/include/asterisk/utils.h 432053 
>   /branches/11/include/asterisk/inline_api.h 432053 
>   /branches/11/configure.ac 432053 
>   /branches/11/configure UNKNOWN 
>   /branches/11/Makefile 432053 
> 
> Diff: https://reviewboard.asterisk.org/r/4370/diff/
> 
> 
> Testing
> -------
> 
> * Compiled Asterisk with and without --enable-dev-mode using gcc. Asterisk 
> compiles correctly.
> * Compiled Asterisk without --enable-dev-mode using clang. Asterisk compiles, 
> links, and executes.
> 
> Note that you will need the BlocksRuntime to run Asterisk when it is compiled 
> with clang.
> 
> 
> Thanks,
> 
> Matt Jordan
> 
>

-- 
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Reply via email to