Re: gcc 4.9.0 do not build on OSX
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
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
Re: gcc 4.9.0 do not build on OSX
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.
I have generated a preprocessed source file as asked by clang and it is
attached to the PR I raised there. The file shows 288 brackets at line
51623 in the file.
So this sounds like a bug in clang. Please report it to them.
The PR is http://llvm.org/bugs/show_bug.cgi?id=19650.
Chris
Re: GCC 4.9.1 Status Report (2014-07-10)
On 12/07/2014 4:52 am, Franzi Edo. wrote: make CFLAGS="-g -O2 -fbracket-depth=512” (512, 1024, 2048 … no way)! For a cross-compiler I think this should be BUILD_CFLAGS and I suggest 1024 rather than 512 ? Chris
Re: GCC 4.9.1 Status Report (2014-07-10)
On 13/07/2014 3:38 am, Franzi Edo. wrote: 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. Please add 'BUILD_CFLAGS="-g -O2 -fbracket-depth=1024”' to the configure command line before the configure script is referenced, ie: $ BUILD_CFLAGS="-g -O2 -fbracket-depth=1024” ../gcc-4.9.0/configure ... Chris
Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
On 20/02/2015 8:23 am, Joel Sherrill wrote: On 2/19/2015 2:56 PM, Sandra Loosemore wrote: Jakub Jelinek wrote: On Wed, Feb 18, 2015 at 11:21:56AM -0800, Jeff Prothero wrote: Starting with gcc 4.9, -O2 implicitly invokes -fisolate-erroneous-paths-dereference: which https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html documents as Detect paths that trigger erroneous or undefined behavior due to dereferencing a null pointer. Isolate those paths from the main control flow and turn the statement with erroneous or undefined behavior into a trap. This flag is enabled by default at -O2 and higher. This results in a sizable number of previously working embedded programs mysteriously crashing when recompiled under gcc 4.9. The problem is that embedded programs will often have ram starting at address zero (think hardware-defined interrupt vectors, say) which gets initialized by code which the -fisolate-erroneous-paths-deference logic can recognize as reading and/or writing address zero. If you have some pages mapped at address 0, you really should compile your code with -fno-delete-null-pointer-checks, otherwise you can run into tons of other issues. H, Passing the additional option in user code would be one thing, but what about library code? E.g., using memcpy (either explicitly or implicitly for a structure copy)? It looks to me like cr16 and avr are currently the only architectures that disable flag_delete_null_pointer_checks entirely, but I am sure that this issue affects other embedded targets besides nios2, too. E.g. scanning Mentor's ARM board support library, I see a whole pile of devices that have memory mapped at address zero (TI Stellaris/Tiva, Energy Micro EFM32Gxxx, Atmel AT91SAMxxx, ). Plus our simulator BSPs assume a flat address space starting at address 0. I forwarded this to the RTEMS list and was promptly pointed to a patch on a Coldfire BSP where someone worked around this behavior. We are discussing how to deal with this. It is likely OK in user code but horrible in BSP and driver code. We don't have a solution ourselves. We just recognize it impacts a number of targets. My main concern is not knowing the trap has been added to the code. If I could build an application and audit it somehow then I can manage it. We have a similar issue with the possible use of FP registers being used in general code (ISR save/restore trade off). Can the ELF be annotated in some GCC specific way that makes it to the final executable to flag this is happening ? We can then create tools to audit the executables. Chris
Re: Obscure crashes due to gcc 4.9 -O2 => -fisolate-erroneous-paths-dereference
On 28/02/2015 9:12 am, Manuel López-Ibáñez wrote: On 02/19/15 14:56, Chris Johns wrote: My main concern is not knowing the trap has been added to the code. If I could build an application and audit it somehow then I can manage it. We have a similar issue with the possible use of FP registers being used in general code (ISR save/restore trade off). Can the ELF be annotated in some GCC specific way that makes it to the final executable to flag this is happening ? We can then create tools to audit the executables. Simply ignore me if I'm misunderstanding the issue: Couldn't GCC generate, instead of a trap, a call to a noinline noreturn cold weak function __gcc_is_a_trap that by default calls the trap? Then, audit tools can inspect the code and see if such a function call appears and even override it with something else. Yes it could and this is a nice idea. Chris, wouldn't that be enough for your purposes? I think it does because we can scan an executable for the call locations and audit them. Chris
Building gcc 12 cross-compiler with --enable-lto on FreeBSD fails
Hi, I am trying to build a cross-compiler on FreeBSD with --enable-lto because a chip vendor is using it when building controller software that is part of a system. The build I am using symlinks gmp, mpfr etc as source so they are built as part of the gcc build. The mpfr package is reporting ... build/mpfr/config.log:configure:17408: error: Link Time Optimisation is not supported (see config.log for details). Should the enable option be passed to these packages? I have assumed the enable option for LTO is for the cross compiler and not the host gcc? Thanks Chris
Re: Building gcc 12 cross-compiler with --enable-lto on FreeBSD fails
On 15/6/22 7:56 pm, Richard Biener wrote: > On Wed, Jun 15, 2022 at 11:27 AM Chris Johns > wrote: >> >> Hi, >> >> I am trying to build a cross-compiler on FreeBSD with --enable-lto because a >> chip vendor is using it when building controller software that is part of a >> system. >> >> The build I am using symlinks gmp, mpfr etc as source so they are built as >> part >> of the gcc build. >> >> The mpfr package is reporting ... >> >> build/mpfr/config.log:configure:17408: error: Link Time Optimisation is not >> supported (see config.log for details). >> >> Should the enable option be passed to these packages? > > You shouldn't need --enable-lto, it's effect (adding lto to the set of > compiled > languages) is already the default. You can use --enable-languages=default,lto > to achieve the same effect without getting the mpfr side-effect. Oh that is great and I had no idea this is how it is controlled. I have rebuilt my compiler and it is now building. Nice. >> I have assumed the enable option for LTO is for the cross compiler and not >> the >> host gcc? > > it's for the built GCC, enabling LTO support (but not for enabling > building GCC itself > with LTO). It now makes sense. I will also update the RTEMS tools builds. Thanks Chris
Building gcc-12 on MacOS Ventura (aarch64)
Hi, I am sorting out some issues building RTEMS on MacOS including the M processors. The building gcc-12.2.1 for the few architectures I tested fail with sig faults in xgcc when building the runtime. I tried arm, aarch64 and sparc. As a result I wondered about bootstrapping gcc and using that to build the tools rather than clang from Xcode. Is aarch64-apple-darwin supported? I am seeing: *** Configuration aarch64-apple-darwin22.3.0 not supported Thanks Chris
Re: Building gcc-12 on MacOS Ventura (aarch64)
On 25/3/2023 10:07 am, Jonathan Wakely wrote: > On Fri, 24 Mar 2023, 23:07 Jonathan Wakely, <mailto:jwakely@gmail.com>> wrote: > On Fri, 24 Mar 2023, 23:03 Chris Johns, <mailto:ch...@contemporary.net.au>> wrote: > > Hi, > > I am sorting out some issues building RTEMS on MacOS including the M > processors. > The building gcc-12.2.1 for the few architectures I tested fail with > sig > faults > in xgcc when building the runtime. I tried arm, aarch64 and sparc. As > a > result I > wondered about bootstrapping gcc and using that to build the tools > rather than > clang from Xcode. > > Is aarch64-apple-darwin supported? > > No. Iain Sandoe has some personal branches with changes to support it, but > the changes are not in the official gcc repo yet. If you search the > gcc-h...@gcc.gnu.org <mailto:gcc-h...@gcc.gnu.org> list you'll find links > to > his code. I think Homebrew is his patches too. > > *uses his patches too. > I tried Iain's repo and it fails in the same way. I have been building the tools on MacOS for over a decade with just the Apple base to make sure we have a clean platform without any issues. To do that I avoid MacPorts and Homebrew. I am fine with our users making use of those packages however knowing a build works with just the Apple support makes our support simpler. Chris
Re: Building gcc-12 on MacOS Ventura (aarch64)
On 25/3/2023 11:08 am, Stuff Received wrote: > On 2023-03-24 19:51, Chris Johns wrote: >> On 25/3/2023 10:07 am, Jonathan Wakely wrote: >>> On Fri, 24 Mar 2023, 23:07 Jonathan Wakely, >> <mailto:jwakely@gmail.com>> wrote: >>> On Fri, 24 Mar 2023, 23:03 Chris Johns, >> <mailto:ch...@contemporary.net.au>> wrote: >>> >>> Hi, >>> >>> I am sorting out some issues building RTEMS on MacOS including the >>> M >>> processors. >>> The building gcc-12.2.1 for the few architectures I tested fail >>> with >>> sig >>> faults >>> in xgcc when building the runtime. I tried arm, aarch64 and sparc. >>> As a >>> result I >>> wondered about bootstrapping gcc and using that to build the tools >>> rather than >>> clang from Xcode. >>> >>> Is aarch64-apple-darwin supported? >>> >>> No. Iain Sandoe has some personal branches with changes to support it, >>> but >>> the changes are not in the official gcc repo yet. If you search the >>> gcc-h...@gcc.gnu.org <mailto:gcc-h...@gcc.gnu.org> list you'll find >>> links to >>> his code. I think Homebrew is his patches too. >>> >>> *uses his patches too. >>> >> >> I tried Iain's repo and it fails in the same way. >> >> I have been building the tools on MacOS for over a decade with just the Apple >> base to make sure we have a clean platform without any issues. To do that I >> avoid MacPorts and Homebrew. I am fine with our users making use of those >> packages however knowing a build works with just the Apple support makes our >> support simpler. >> >> Chris > > I am able to build gcc from Iain's repo gcc-darwin-arm64 on an M1 Mini, > running > macos 11.3.1, using the following configuration. (Change your language > preferences accordingly.) I used make -j4. > > CC=/opt/homebrew/bin/gcc-12 \ > CXX=/opt/homebrew/bin/g++-12 \ > ../../src/gcc-darwin-arm64/configure \ > --prefix=$HOME/gm2/arm64 \ > --exec-prefix=$HOME/gm2/arm64 \ > --enable-languages=c,c++,m2 \ > --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk \ > --with-mpc=/opt/homebrew \ > --with-gmp=/opt/homebrew \ > --with-mpfr=/opt/homebrew \ > --disable-bootstrap \ > --enable-threads=posix > > However, you must first define HAVE_FCNTL_H to 1 in libiberty/config.h (that > is > missed somehow by configure). Thanks for this. It was helpful. I installed homebrew and the `gcc` package and updated the RTEMS RSB to use homebrew if installed. I can build RTEMS tools: % /Users/chris/development/rtems/6/bin/sparc-rtems6-gcc --version sparc-rtems6-gcc (GCC) 12.2.1 20230224 (RTEMS 6, RSB f0e34eab8bf33b833a7d9d0b2bddd3b89f6d83cb-modified, Newlib 17ac400) Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. % file /Users/chris/development/rtems/6/bin/sparc-rtems6-gcc /Users/chris/development/rtems/6/bin/sparc-rtems6-gcc: Mach-O 64-bit executable arm64 This will work for us. Thanks to those who responded. Chris
