Re: Enable -Wreturn-type by default ?
Hello, On 17/11/2013 17:47, Jonathan Wakely wrote: > On 17 November 2013 15:40, Sylvestre Ledru wrote: >> For "control reaches end of non-void function", I haven't activated by >> default and I called the option -Wfalloff-nonvoid-function >> Of course, that is just a proposal! :) Better names are welcome. > It was nearly called -Wmissing-return a decade ago, but got bundled > with -Wreturn-type, see > http://gcc.gnu.org/ml/gcc-patches/2002-02/msg02002.html As discussed on this mailing list, I proposed a patch on the gcc-patches mailing list. http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00820.html Any chance one of you could review it? Thanks, Sylvestre
Re: Enable -Wreturn-type by default ?
On 16 January 2014 11:11, Sylvestre Ledru wrote: > Hello, > > On 17/11/2013 17:47, Jonathan Wakely wrote: >> On 17 November 2013 15:40, Sylvestre Ledru wrote: >>> For "control reaches end of non-void function", I haven't activated by >>> default and I called the option -Wfalloff-nonvoid-function >>> Of course, that is just a proposal! :) Better names are welcome. >> It was nearly called -Wmissing-return a decade ago, but got bundled >> with -Wreturn-type, see >> http://gcc.gnu.org/ml/gcc-patches/2002-02/msg02002.html > As discussed on this mailing list, I proposed a patch on the gcc-patches > mailing list. > http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00820.html > > Any chance one of you could review it? I like the change in principle, but it's not up to me, I can't approve front-end patches. I can comment on the docs and ChangeLog but I'm not subscribed to gcc-patches so didn't get the mail. I'll send some comments, could you please reply to your gcc-patches mail and include my comments? Thanks.
libatomic Makefile unconditionally sets -march=armv7-a when configuring with ifunc support
Hi Richard, I noticed that Makefile.in in libatomic sets -march=armv7-a when compiling for arm linux targets with ifunc support: @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=armv7-a -DHAVE_KERNEL64 Is there any particular reason why it must do that? It seems that if we're trying to build a multilib for armv8-a, for example, this would override any architecture options, and even conflict with any -mcpu options that we might specify elsewhere. Would there be any fallout I'm not seeing from removing -march=armv7-a from there? Thanks, Kyrill
Re: Infinite number of iterations in loop [v850, mep]
Hi, My name is Chris Gallimore and I am a headhunter. I am currently recruiting for a compiler design engineer with knowledge of GCC to join Ericsson in the UK. I was hoping that somebody here might be interested or might know somebody. If so, please drop me an email at chris.gallim...@wenhamcarter.com Best regards, Chris -- View this message in context: http://gcc.1065356.n5.nabble.com/Infinite-number-of-iterations-in-loop-v850-mep-tp984790p1003192.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: Enable -Wreturn-type by default ?
On 01/16/14 04:45, Jonathan Wakely wrote: On 16 January 2014 11:11, Sylvestre Ledru wrote: Hello, On 17/11/2013 17:47, Jonathan Wakely wrote: On 17 November 2013 15:40, Sylvestre Ledru wrote: For "control reaches end of non-void function", I haven't activated by default and I called the option -Wfalloff-nonvoid-function Of course, that is just a proposal! :) Better names are welcome. It was nearly called -Wmissing-return a decade ago, but got bundled with -Wreturn-type, see http://gcc.gnu.org/ml/gcc-patches/2002-02/msg02002.html As discussed on this mailing list, I proposed a patch on the gcc-patches mailing list. http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00820.html Any chance one of you could review it? I like the change in principle, but it's not up to me, I can't approve front-end patches. I can comment on the docs and ChangeLog but I'm not subscribed to gcc-patches so didn't get the mail. I'll send some comments, could you please reply to your gcc-patches mail and include my comments? Thanks. Note that your opinion is still quite important in this space though. My gut tells me for C++ this is a no-brainer. For C it's less clear, but I think we still want it. Ultimately I suspect we're going to catch more real bugs than false positives once we start looking at real code rather than the regression suite. As long as folks writing code like Geoff K pointed out in the 2002 thread can turn the warning off, I think we'll be OK. So Sylvestre, the big part of the work is doing a bootstrap and regression test and it looks like you're well into that. Hopefully you can wrap up soon. jeff
gnattools cannot be built for freestanding/bare metal environment without hacking up the build machinery
Hi,
I've been over this before and have got nowhere with it. As I've just
retried building the latest sources after a long break I'd thought I'd
add some further comment in the hope that someone somewhere cares enough
to fix this issue; this is over my head at this time.
Say you want to build an Ada compiler for embedded work, small
SBC/micro's/osdev/whatever, you will want to set target to -elf or
similar. You can do this, to a point. You can configure the build as:
../../../source/gcc-git-ro/configure --prefix=/home/laguest/opt/tinyada
--target=arm-none-eabi --enable-interwork --enable-multilib
--without-headers --disable-nls --disable-shared --disable-threads
--disable-lto --with-gnu-as --with-gnu-ld --enable-languages=c,ada
--disable-libssp --disable-cloog-version-check
--disable-isl-version-check --with-gmp=/home/laguest/opt/tinyada
--with-mpfr=/home/laguest/opt/tinyada
--with-mpc=/home/laguest/opt/tinyada
--with-isl=/home/laguest/opt/tinyada
--with-cloog=/home/laguest/opt/tinyada
You can build it with "make all-gcc" and install with "make install-gcc"
and you get a gnat1 and -gnatbind, this is fine, you can use the
system tools, gnatmake, etc. along with these tools - I have done this
before.
But what about the gnattools? Not buildable. A message in the ml
archives states to build them with "make -C gcc gnattools," but this
fails:
make: Entering directory
`/home/laguest/src/mine/tinyada-new/build/arm-none-eabi/gcc2-built-with-git-ro/gcc'
make -C ada CC="gcc" CXX="g++" "ADA_CFLAGS=" "BISON=bison" "BISONFLAGS="
"CFLAGS=-g " "LDFLAGS=-static-libstdc++ -static-libgcc " "FLEX=flex"
"FLEXFLAGS=" "LN=ln" "LN_S=ln -s" "MAKEINFO=makeinfo
--split-size=500" "MAKEINFOFLAGS=--no-split" "MAKEOVERRIDES="
"SHELL=/bin/sh" "exeext=" "build_exeext=" "objext=.o"
"exec_prefix=/home/laguest/opt/tinyada"
"prefix=/home/laguest/opt/tinyada" "local_prefix=/usr/local"
"gxx_include_dir=/home/laguest/opt/tinyada/lib/gcc/arm-none-eabi/4.9.0/../../../../arm-none-eabi/include/c++/4.9.0"
"build_tooldir=/home/laguest/opt/tinyada/arm-none-eabi"
"gcc_tooldir=/home/laguest/opt/tinyada/lib/gcc/arm-none-eabi/4.9.0/../../../../arm-none-eabi"
"bindir=/home/laguest/opt/tinyada/bin"
"libexecsubdir=/home/laguest/opt/tinyada/libexec/gcc/arm-none-eabi/4.9.0"
"datarootdir=/home/laguest/opt/tinyada/share"
"datadir=/home/laguest/opt/tinyada/share"
"localedir=/home/laguest/opt/tinyada/share/locale" "ADA_FOR_BUILD="
"ADA_INCLUDE_DIR=/home/laguest/opt/tinyada/lib/gcc/arm-none-eabi/4.9.0/adainclude"
"ADA_RTL_OBJ_DIR=/home/laguest/opt/tinyada/lib/gcc/arm-none-eabi/4.9.0/adalib"
"ADAFLAGS=-gnatpg -gnatwns -W -Wall" "ADA_FOR_TARGET="
"INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644"
"INSTALL_PROGRAM=/usr/bin/install -c"
ADA_INCLUDES="-I/home/laguest/opt/tinyada/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/adalib/../adainclude
-I/home/laguest/opt/tinyada/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/adalib/"
GNATMAKE="gnatmake" GNATBIND="gnatbind" GNATLINK="gnatlink" LIBGNAT=""
gnattools1
make[1]: Entering directory
`/home/laguest/src/mine/tinyada-new/build/arm-none-eabi/gcc2-built-with-git-ro/gcc/ada'
touch ../stamp-tools
You must first build the GNAT library: make gnatlib
make[1]: *** [../stamp-gnatlib-rts] Error 1
make[1]: Leaving directory
`/home/laguest/src/mine/tinyada-new/build/arm-none-eabi/gcc2-built-with-git-ro/gcc/ada'
make: *** [gnattools] Error 2
make: Leaving directory
`/home/laguest/src/mine/tinyada-new/build/arm-none-eabi/gcc2-built-with-git-ro/gcc'
You can't disable libada using the command line as that also disables
gnattools - I don't know the reason for requiring this behaviour.
So there are 3 ways to get this work:
1) Do what AVR-Ada (and MSP430 as they use the same patch) to knock out
the dependency of libada on gnattools, from configure:
if test "${ENABLE_LIBADA}" != "yes" ; then
noconfigdirs="$noconfigdirs"
fi
This then breaks normal builds, i.e. hosted, so you can use the same
sources reliably to build a new host compiler and the cross compiler(s).
2) Do as shown above to get gnat1 and -gnatbind and use these
through the host's system tools.
3) Patch the source up to build a custom and pointless RTS that will
just take up disk space and never get used as the user will be
implementing their own. Currently, I'm getting a bug box on my patches
for arm-none-eabi.
Given that the C compiler can be build for a freestanding environment,
as can the C++ compiler and I'm betting some of the others can too, I
can't see why the Ada compiler can't as it is supported, at least in the
source, just not in the build infrastructure.
The following (or similar) will need to be added to gnattools/configure
to enable this kind of build (under the "Per-target case statement"):
*-*-elf* | *-*-eabi*)
TOOLS_TARGET_PAIRS="\
mlib-tgt-specific.adb
Re: gnattools cannot be built for freestanding/bare metal environment without hacking up the build machinery
Am 16.01.2014 18:17, schrieb Luke A. Guest: But what about the gnattools? Not buildable. A message in the ml archives states to build them with "make -C gcc gnattools," but this fails: This is PR19959, see comment #13. IMHO, this PR was incorrectly closed. That's why we use the mentioned build kludge in AVR-Ada. Rolf
Re: libatomic Makefile unconditionally sets -march=armv7-a when configuring with ifunc support
On 01/16/2014 05:51 AM, Kyrill Tkachov wrote: > Hi Richard, > > I noticed that Makefile.in in libatomic sets -march=armv7-a when compiling for > arm linux targets with ifunc support: > > @ARCH_ARM_LINUX_TRUE@@HAVE_IFUNC_TRUE@IFUNC_OPTIONS = -march=armv7-a > -DHAVE_KERNEL64 > > Is there any particular reason why it must do that? Because armv7-a is required to enable the strexb, strexh, and strexd insns. Then the ifunc selects between the kernel, armv6 and armv7 versions. > Would there be any fallout I'm not seeing from removing -march=armv7-a from > there? You'd break the build for any configuration where strex[bhd] aren't enabled. There are extensions to libatomic that could be made for armv8 support, what with the new load-acquire etc insns. But merely using -march=armv8 doesn't achieve that. I.e. it doesn't do you any good to just remove the flag. r~
Re: gnattools cannot be built for freestanding/bare metal environment without hacking up the build machinery
On Thu, 2014-01-16 at 18:53 +0100, Rolf Ebert wrote: > Am 16.01.2014 18:17, schrieb Luke A. Guest: > > > But what about the gnattools? Not buildable. A message in the ml > > archives states to build them with "make -C gcc gnattools," but this > > fails: > > This is PR19959, see comment #13. IMHO, this PR was incorrectly closed. > That's why we use the mentioned build kludge in AVR-Ada. I never liked this method, but it does work, to a point. But it is a hack. Ah, I tried looking but didn't find this, FYI http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19959 As usual, there is a comment stating, see RTEMS on how to do it, which never answers the question or fixes the issue. Also, comment 14, is the apparent howto which fails as I mentioned in my first post and I really don't understand Arnaud's comment at all there. I just don't get the reasoning. But this is not AVR specific, as he states in #16 and the following does not work either, as he states: make -C gcc gnattools-cross or make gnattools-cross as the rules don't exist, even tried -C gcc/ada. Thanks, Luke.
Re: gnattools cannot be built for freestanding/bare metal environment without hacking up the build machinery
And to clarify: $ make -C gnattools/ gnattools-cross make: Entering directory `/home/laguest/src/mine/tinyada-new/build/arm-none-eabi/gcc2-built-with-git-ro/gnattools' # gnattools1-re make -C ../gcc/ada/tools -f ../Makefile \ "CC=cc" "CXX=g++" "CFLAGS=-g -W -Wall" "LDFLAGS=" "ADAFLAGS=-gnatpg -gnata" "ADA_CFLAGS=" "INCLUDES=-I. -I.. -I../.. -I/home/laguest/src/mine/tinyada-new/source/gcc-git-ro/gcc/ada -I/home/laguest/src/mine/tinyada-new/source/gcc-git-ro/gcc/config -I/home/laguest/src/mine/tinyada-new/source/gcc-git-ro/gcc/../include -I/home/laguest/src/mine/tinyada-new/source/gcc-git-ro/gcc" "ADA_INCLUDES=-I/home/laguest/opt/tinyada/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/adalib/../adainclude -I/home/laguest/opt/tinyada/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/adalib/ -I. -I/home/laguest/src/mine/tinyada-new/source/gcc-git-ro/gcc/ada" "exeext=" "fsrcdir=/home/laguest/src/mine/tinyada-new/source/gcc-git-ro/gcc" "srcdir=/home/laguest/src/mine/tinyada-new/source/gcc-git-ro/gcc" "GNATMAKE=gnatmake" "GNATLINK=gnatlink" "GNATBIND=gnatbind" "TOOLSCASE=cross" "LIBGNAT=" INCLUDES="" \ gnatmake-re gnatlink-re make: Entering an unknown directory make: *** ../gcc/ada/tools: No such file or directory. Stop. make: Leaving an unknown directory make: *** [gnattools-cross] Error 2 make: Leaving directory `/home/laguest/src/mine/tinyada-new/build/arm-none-eabi/gcc2-built-with-git-ro/gnattools' Also fails. Luke.
gcc-4.8-20140116 is now available
Snapshot gcc-4.8-20140116 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140116/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 206688 You'll find: gcc-4.8-20140116.tar.bz2 Complete GCC MD5=0a330159aaae89a60c3f642da132f8e1 SHA1=763713c6524feb07025a7b83651e90007276c3d0 Diffs from 4.8-20140109 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 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.
