This is the mail archive of the
mailing list for the GCC project.
Re: GCC 4.9.1 Status Report (2014-07-10)
- From: James Greenhalgh <james dot greenhalgh at arm dot com>
- To: "Franzi Edo." <edo dot franzi at ukos dot ch>
- 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 10:41:19 +0100
- 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>
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
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
> So, I am a bit without ideas
> On 11 Jul 2014, at 00:29, Joel Sherrill <email@example.com> wrote:
> > On 7/10/2014 5:14 PM, firstname.lastname@example.org wrote:
> >>> On Jul 10, 2014, at 3:13 PM, Ian Lance Taylor <email@example.com> wrote:
> >>>> On Thu, Jul 10, 2014 at 11:40 AM, Franzi Edo. <firstname.lastname@example.org> 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?
> > 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