Re: GCC 4.9.1 Status Report (2014-07-10)

["Franzi Edo." <edo dot franzi at ukos dot ch>]

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.greenhalgh@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.sherrill@oarcorp.com> wrote:
>> 
>>> 
>>> On 7/10/2014 5:14 PM, pinskia@gmail.com wrote:
>>>> 
>>>>> On Jul 10, 2014, at 3:13 PM, Ian Lance Taylor <iant@google.com> wrote:
>>>>> 
>>>>>> On Thu, Jul 10, 2014 at 11:40 AM, Franzi Edo. <edo.franzi@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
>>> 
>