Building gcc-4.9.0 for the arm target using clang on OSX and FreeBSD 10 fails with an error. The error message for OSX can be seen in the post to the gcc mailing list here http://gcc.gnu.org/ml/gcc/2014-05/msg00014.html. The thread contains a comment from a gcc developer the file does not have this level of nesting brackets.
Please attach the preprocessed source of the file in question
Created attachment 12477 [details] ARM md preprocessed output The file shows gcc is generating source with over 288 nested brackets. I have decided to add the file here because I need to upload it somewhere. I will let gcc know the file is here. It is line 51623 that has (I think) 288 brackets. The name of the bug is wrong because it is not false and can be changed if required.
(In reply to comment #0) > The thread contains a comment from a gcc developer the file does not have > this level of nesting brackets. So... this gcc developer was not correct; as you observed, the preprocessed source contains this on line 51623: )))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) This exceeds the suggested implementation limit of 256 for "nesting levels of parenthesized expressions within a full-expression" given in Annex B of the C++ standard. That said, we should probably increase our default limit here. I expect we can set it a lot higher and still be safe from stack overflow on typical systems.
(In reply to comment #3) > This exceeds the suggested implementation limit of 256 for "nesting levels > of parenthesized expressions within a full-expression" given in Annex B of > the C++ standard. I will raise a bug on gcc and reference this comment. Thanks. I think they are willing to look into the issue and alter the way they generate this code and this is a nice reason to do so. > That said, we should probably increase our default limit here. I expect we > can set it a lot higher and still be safe from stack overflow on typical > systems. There is a way to override the default and that is what we are doing.