Hi James (all), Thank you for all of your suggestions. I tried everything unsuccessfully. Unfortunately, the
make CFLAGS="-g -O2 -fbracket-depth=1024” and the make BUILD_CFLAGS="-g -O2 -fbracket-depth=1024” do not solve the problem. Well, at this point, I have to admit that I am a bit lost. So, if you have other suggestions, I will check them with pleasure. Thanks Edo On 12 Jul 2014, at 11:41, James Greenhalgh <james.greenha...@arm.com> wrote: > On Fri, Jul 11, 2014 at 07:52:06PM +0100, Franzi Edo. wrote: >> Hi All, >> Thank you for your suggestions. >> Unfortunately, no way! >> >> 4. I can generate my cross compiler based on the "gcc 4.8.3” without problem >> (using both the apple-gcc4.2 or the XCode llvm) So, what has changed of >> fundamental between the 4.8.3 and the 4.9 versions? > (Sorry for any duplicate mails, my mailer is having difficulty with > certain symbols in the body of the mail). > > The fundamental change was a patch I put in to 4.9 in October of 2013 [1]. > > In this patch, we use a large define_attr to group together all of the Neon > types used for (set_attr "type") expressions in the ARM backend in the > "is_neon_type" attribute, which we use later to decide if an instruction is > predicable. We end up with a define_attr with around 290 elements for the > "yes" case. > > As you can see in the preprocessed source on the LLVM bug [2], each element > in the define_attr is expanded as > > ((cached_type == TYPE_NEON_FOO) || ... ) > > So after three elements we have 3 levels of nesting. After six, we have 6. > After around 290 we have 290 levels of bracket nesting, and Clang errors. > > If there is a better way for me to write the "is_neon_type" attribute, I'll > happily spin a patch for it. Certainly, I don't like the size of that > generated "if" statement. > > Alternatively, perhaps the code which generates the if statement could be > rewritten to build a switch rather than the large "||" expression. I don't > know anything about the gen* programs and how define_attr can be used in > the general case to say how feasible that change would be. > > None of this solves your problem in the interim, for that I think your best > bet is to set -fbracket-depth=1024 in your BUILD_CFLAGS, as suggested by > Chris. > > Thanks, > James > > [1] > https://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_9-branch/gcc/config/arm/arm.md?r1=203059&r2=203613 > [2] http://llvm.org/bugs/show_bug.cgi?id=19650 > >> >> So, I am a bit without ideas >> Cheers, >> Edo >> >> >> On 11 Jul 2014, at 00:29, Joel Sherrill <joel.sherr...@oarcorp.com> wrote: >> >>> >>> On 7/10/2014 5:14 PM, pins...@gmail.com wrote: >>>> >>>>> On Jul 10, 2014, at 3:13 PM, Ian Lance Taylor <i...@google.com> wrote: >>>>> >>>>>> On Thu, Jul 10, 2014 at 11:40 AM, Franzi Edo. <edo.fra...@ukos.ch> wrote: >>>>>> >>>>>> As for the version 4.9.0, on OSX stil remain a problem. >>>>>> I cannot build an ARM a cross compiler! >>>>>> Here is the message (same as for the 4.9.0) > <snipped> >>>>> You did not include enough context to be sure, but I don't think that >>>>> error message is coming from GCC. At least, I don't see that error >>>>> message in the GCC sources. >>>>> >>>>> I think that error message is coming from the host compiler you are >>>>> using, in which case, based on the error message, the solution would >>>>> seem to be > <snipped> >>>> Also i thought we did not support cross building with anything besides >>>> gcc. >>> The RTEMS community sees this when using clang/llvm on FreeBSD. >>> >>> Franzi.. did the suggestion from Chris Johns to increase the limit >>> to 1024, not work? >>> >>> https://gcc.gnu.org/ml/gcc/2014-05/msg00018.html >>> >>> This ended up being reported at http://llvm.org/bugs/show_bug.cgi?id=19650 >>> >>> --joel >>>> Thanks, >>>> Andrew >>>> >>>>> Ian >>> >
