This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
> > 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]