This is the mail archive of the
mailing list for the GCC project.
Re: GCC 4.9.1 Status Report (2014-07-10)
- From: "Franzi Edo." <edo dot franzi at ukos dot ch>
- To: James Greenhalgh <james dot greenhalgh at arm dot com>
- Cc: Joel Sherrill <joel dot sherrill at oarcorp dot com>, "pinskia at gmail dot com" <pinskia at gmail dot com>, Ian Lance Taylor <iant at google dot com>, Jakub Jelinek <jakub at redhat dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Sat, 12 Jul 2014 19:38:51 +0200
- Subject: Re: GCC 4.9.1 Status Report (2014-07-10)
- Authentication-results: sourceware.org; auth=none
- References: <20140710103011 dot GE31640 at tucnak dot redhat dot com> <4E484367-BB51-4E47-A5C6-7A71C9A5FC83 at ukos dot ch> <CAKOQZ8yFgUf092b9-F+Hf_ZTZhiNdxQGJJ8znLPxVCw9MhFshg at mail dot gmail dot com> <24B0C232-909F-40BD-BD3A-32DA133E4035 at gmail dot com> <53BF13CB dot 7080001 at oarcorp dot com> <08A99D9D-6C8B-496A-9470-FC259BF95EE5 at ukos dot ch> <20140712094119 dot GA31278 at arm dot com>
Hi James (all),
Thank you for all of your suggestions.
I tried everything unsuccessfully. Unfortunately, the
make CFLAGS="-g -O2 -fbracket-depth=1024”
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.
On 12 Jul 2014, at 11:41, James Greenhalgh <email@example.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 .
> 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 , 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
>  https://gcc.gnu.org/viewcvs/gcc/branches/gcc-4_9-branch/gcc/config/arm/arm.md?r1=203059&r2=203613
>  http://llvm.org/bugs/show_bug.cgi?id=19650
>> So, I am a bit without ideas
>> On 11 Jul 2014, at 00:29, Joel Sherrill <firstname.lastname@example.org> wrote:
>>> On 7/10/2014 5:14 PM, email@example.com wrote:
>>>>> On Jul 10, 2014, at 3:13 PM, Ian Lance Taylor <firstname.lastname@example.org> wrote:
>>>>>> On Thu, Jul 10, 2014 at 11:40 AM, Franzi Edo. <email@example.com> 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)
>>>>> 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
>>>> 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?
>>> This ended up being reported at http://llvm.org/bugs/show_bug.cgi?id=19650