gcc 4.9.0 do not build on OSX

2014-05-03 Thread Franzi Edo.
Hi,
I am trying to build a gcc-4.9.0 ARM cross compiler on OSX Mavericks 
unsuccessfully.
My toolchain works fine with the previous version 4.8.2 but on the 4.9.0 I have 
this error during the gcc building pass 1.

/opt/uKOS/Packages/gcc-4.9.0/gcc/config/arm/neon.md:3486:10917: fatal error:
 bracket nesting level exceeded maximum of 256
/opt/uKOS/Packages/gcc-4.9.0/gcc/config/arm/neon.md:3486:10917: note: use
 -fbracket-depth=N to increase maximum nesting level
32 warnings and 1 error generated.
make[1]: *** [insn-attrtab.o] Error 1
make: *** [all-gcc] Error 2
Error building gcc pass 1

So, I tried to increase the number of nesting level as indicated 
(-fbracket-depth=1024) but I get the same error.
I use these packages:

GMP_VER=6.0.0
MPFR_VER=3.1.2
MPC_VER=1.0.2
BIN_VER=2.24
GCC_VER=4.9.0
NLB_VER=2.1.0
GDB_VER=7.7

The configure for the pass 1 is:

export GCC1_CONFIG=" \
--enable-interwork \
--enable-languages=c,c++ \
--with-newlib \

--with-headers=${PATH_TOOLS_GCC}/Packages/newlib-${NLB_VER}/newlib/libc/include 
\
--with-mpfr=${PATH_TOOLS_GCC}/cross/mpfr-${MPFR_VER} \
--with-gmp=${PATH_TOOLS_GCC}/cross/gmp-${GMP_VER} \
--with-mpc=${PATH_TOOLS_GCC}/cross/mpc-${MPC_VER}"

Any idea? 
Regards,
 Edo

Re: INSN_CODE used on jump_table_data

2014-05-03 Thread Denis Chertykov
2014-04-30 1:29 GMT+04:00 Tom de Vries :
> Denis,
>
> when building gcc for avr with --enable-checking=yes,rtl , I run into the
> following error:
> ...
> /home/vries/gcc_versions/devel/src/libgcc/unwind-c.c: In function
> ‘__gcc_personality_sj0’:
> /home/vries/gcc_versions/devel/src/libgcc/unwind-c.c:234:1: internal
> compiler error: RTL check: expected elt 6 type 'i' or 'n', have '0' (rtx
> jump_table_data) in recog_memoized, at recog.h:154
>  }
>  ^
> 0xbcb709 rtl_check_failed_type2(rtx_def const*, int, int, int, char const*,
> int, char const*)
> /home/vries/gcc_versions/devel/src/gcc/rtl.c:764
> 0xf85f36 recog_memoized
> /home/vries/gcc_versions/devel/src/gcc/recog.h:154
> 0xf9ccaa avr_adjust_insn_length(rtx_def*, int)
> /home/vries/gcc_versions/devel/src/gcc/config/avr/avr.c:7780
> 0x84c2a9 shorten_branches(rtx_def*)
> /home/vries/gcc_versions/devel/src/gcc/final.c:1198
> 0x85cbc2 rest_of_handle_shorten_branches
> /home/vries/gcc_versions/devel/src/gcc/final.c:4519
> 0x85cc10 execute
> /home/vries/gcc_versions/devel/src/gcc/final.c:4549
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> ...
>
> AFAIU, the problem is that avr_adjust_insn_length uses recog_memoized, which
> uses INSN_CODE on a jump_table_data.

Thank you for report.
Fix committed.

Denis.


Re: RFA: speeding up dg-extract-results.sh

2014-05-03 Thread Mike Stump
On Feb 13, 2014, at 1:18 AM, Richard Sandiford  
wrote:
> This patch tries to reduce that by providing an alternative single-script
> version.

> Python isn't yet required and I'm pretty sure this script needs 2.6
> or later.

> I'm also worried that the seek/tell stuff might not work on
> Windows.

> OK to install?

So, my intent is to approve this, but, I do want to give people a chance to 
argue against python if they care to.  I think python is at least as fine as 
tcl, or better, and this script is only used during test suite running, so the 
impact on the minimum requirements is only for those that run the test suite.  
Additionally, falling back I think is nice in the short term (a year or two), 
if someone finds something disastrous, they can just flip it back to the old 
way.  If the new way is maintained and works well, I’d like to remove the old 
version.  This gives people a bit of time try it on windows and other platforms 
and get it working.  Seems like that should be sufficient.  If all goes well, 
after that, I’d like to remove the old way entirely.

Let’s give people 4 or 5 days to weigh in.  Absent objections, Ok.  If there 
are some, we’ll consider all the points raised and then approve or not.  Thanks 
for the work.

gcc-4.7-20140503 is now available

2014-05-03 Thread gccadmin
Snapshot gcc-4.7-20140503 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20140503/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch 
revision 210042

You'll find:

 gcc-4.7-20140503.tar.bz2 Complete GCC

  MD5=bf00c4294b3718e29261f1f61af21040
  SHA1=34faa8d8b1e473dd739d1dc2f8103116ee4ff7b5

Diffs from 4.7-20140426 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.


Re: gcc 4.9.0 do not build on OSX

2014-05-03 Thread Chris Johns

On 3/05/2014 10:57 pm, Franzi Edo. wrote:

Hi,
I am trying to build a gcc-4.9.0 ARM cross compiler on OSX Mavericks 
unsuccessfully.
My toolchain works fine with the previous version 4.8.2 but on the 4.9.0 I have 
this error during the gcc building pass 1.

/opt/uKOS/Packages/gcc-4.9.0/gcc/config/arm/neon.md:3486:10917: fatal error:
  bracket nesting level exceeded maximum of 256
/opt/uKOS/Packages/gcc-4.9.0/gcc/config/arm/neon.md:3486:10917: note: use
  -fbracket-depth=N to increase maximum nesting level
32 warnings and 1 error generated.
make[1]: *** [insn-attrtab.o] Error 1
make: *** [all-gcc] Error 2
Error building gcc pass 1

So, I tried to increase the number of nesting level as indicated 
(-fbracket-depth=1024) but I get the same error.


This failure can also be seen on FreeBSD 10 when building with the 
default c and c++ compilers. Adding the option to the build cflags does 
fix it on FreeBSD. I have not tried OSX yet but will at some point.


I am not sure if this is something the gcc build system should manage or 
the limit is to low in clang and the issue raised there. It is an 
interesting limit to have.



I use these packages:

GMP_VER=6.0.0
MPFR_VER=3.1.2
MPC_VER=1.0.2
BIN_VER=2.24
GCC_VER=4.9.0
NLB_VER=2.1.0
GDB_VER=7.7

The configure for the pass 1 is:

export GCC1_CONFIG=" \
--enable-interwork \
--enable-languages=c,c++ \
--with-newlib \

--with-headers=${PATH_TOOLS_GCC}/Packages/newlib-${NLB_VER}/newlib/libc/include 
\
--with-mpfr=${PATH_TOOLS_GCC}/cross/mpfr-${MPFR_VER} \
--with-gmp=${PATH_TOOLS_GCC}/cross/gmp-${GMP_VER} \
--with-mpc=${PATH_TOOLS_GCC}/cross/mpc-${MPC_VER}"

Any idea?


Add CFLAGS="-O2 -fbracket-depth=1024" to the command line before configure.

Chris


Regards,
  Edo



Re: gcc 4.9.0 do not build on OSX

2014-05-03 Thread Andrew Pinski
On Sat, May 3, 2014 at 5:48 PM, Chris Johns  wrote:
> On 3/05/2014 10:57 pm, Franzi Edo. wrote:
>>
>> Hi,
>> I am trying to build a gcc-4.9.0 ARM cross compiler on OSX Mavericks
>> unsuccessfully.
>> My toolchain works fine with the previous version 4.8.2 but on the 4.9.0 I
>> have this error during the gcc building pass 1.
>>
>> /opt/uKOS/Packages/gcc-4.9.0/gcc/config/arm/neon.md:3486:10917: fatal
>> error:
>>   bracket nesting level exceeded maximum of 256
>> /opt/uKOS/Packages/gcc-4.9.0/gcc/config/arm/neon.md:3486:10917: note: use
>>   -fbracket-depth=N to increase maximum nesting level
>> 32 warnings and 1 error generated.
>> make[1]: *** [insn-attrtab.o] Error 1
>> make: *** [all-gcc] Error 2
>> Error building gcc pass 1

There is some large conditionals inside insn-attrtab.c but I don't see
any which have more than 30 depth of parenthesis.  The max level of {}
is 4 in that file too.
So this sounds like a bug in clang.  Please report it to them.

Thanks,
Andrew Pinski

>>
>> So, I tried to increase the number of nesting level as indicated
>> (-fbracket-depth=1024) but I get the same error.
>
>
> This failure can also be seen on FreeBSD 10 when building with the default c
> and c++ compilers. Adding the option to the build cflags does fix it on
> FreeBSD. I have not tried OSX yet but will at some point.
>
> I am not sure if this is something the gcc build system should manage or the
> limit is to low in clang and the issue raised there. It is an interesting
> limit to have.
>
>
>> I use these packages:
>>
>> GMP_VER=6.0.0
>> MPFR_VER=3.1.2
>> MPC_VER=1.0.2
>> BIN_VER=2.24
>> GCC_VER=4.9.0
>> NLB_VER=2.1.0
>> GDB_VER=7.7
>>
>> The configure for the pass 1 is:
>>
>> export GCC1_CONFIG=" \
>> --enable-interwork \
>> --enable-languages=c,c++ \
>> --with-newlib \
>>
>> --with-headers=${PATH_TOOLS_GCC}/Packages/newlib-${NLB_VER}/newlib/libc/include
>> \
>> --with-mpfr=${PATH_TOOLS_GCC}/cross/mpfr-${MPFR_VER} \
>> --with-gmp=${PATH_TOOLS_GCC}/cross/gmp-${GMP_VER} \
>> --with-mpc=${PATH_TOOLS_GCC}/cross/mpc-${MPC_VER}"
>>
>> Any idea?
>
>
> Add CFLAGS="-O2 -fbracket-depth=1024" to the command line before configure.
>
> Chris
>
>> Regards,
>>   Edo
>>
>


Re: gcc 4.9.0 do not build on OSX

2014-05-03 Thread Chris Johns

On 4/05/2014 12:34 pm, Andrew Pinski wrote:

On Sat, May 3, 2014 at 5:48 PM, Chris Johns  wrote:

On 3/05/2014 10:57 pm, Franzi Edo. wrote:


Hi,
I am trying to build a gcc-4.9.0 ARM cross compiler on OSX Mavericks
unsuccessfully.
My toolchain works fine with the previous version 4.8.2 but on the 4.9.0 I
have this error during the gcc building pass 1.

/opt/uKOS/Packages/gcc-4.9.0/gcc/config/arm/neon.md:3486:10917: fatal
error:
   bracket nesting level exceeded maximum of 256
/opt/uKOS/Packages/gcc-4.9.0/gcc/config/arm/neon.md:3486:10917: note: use
   -fbracket-depth=N to increase maximum nesting level
32 warnings and 1 error generated.
make[1]: *** [insn-attrtab.o] Error 1
make: *** [all-gcc] Error 2
Error building gcc pass 1


There is some large conditionals inside insn-attrtab.c but I don't see
any which have more than 30 depth of parenthesis.  The max level of {}
is 4 in that file too.
So this sounds like a bug in clang.  Please report it to them.



Thanks for looking into this. I will report the issue.

Chris