June 2015 GNU Toolchain Update
Hi Guys,
In this month's news we have:
* GCC now supports a "noplt" function attribute. This specifies
that the annotated function should not be called via the PLT
mechanism.
* GCC now supports a "target ()" function attribute to
enable target specific options on individual functions. The ARM
port now uses this mechanism to allow programmers to individually
specify whether a function should use ARM or THUMB instructions.
For example:
int foo __attribute__((target("thumb")));
Any functions inlined into the attributed function will inherit
that function's attributes.
* GCC now supports attributes on enums values, although only one
such attribute is currently available:
enum E {
oldval __attribute__((deprecated)),
newval
};
The deprecated attribute results in a warning if the enumerator
value is used anywhere in the source file. This is useful when
identifying enumerators that are expected to be removed in a
future version of a program.
* GCC now supports a new warning option: -Wlto-type-mismatch
During the link-time optimization the compiler will issue warnings
about type mismatches between duplicate global declarations found
in different compilation units. This option is enabled by default
when LTO optimization is being performed.
* The ARM port of GCC now recognises the ARMv8,1 architecture
extensions including the Large System Extension instructions,
Privileged Access Never, Limited Ordering Regions and Advanced
SIMD instructions.
* In GDB support for process record-replay and reverse debugging on
AArch64 targets has been added.
* Also in GDB support for Sun's version of the "stabs" debug file
format has been removed.
* The linker has a new command line option: -print-memory-usage
This makes the linker print out the used size and total size of
each memory region specified by the link script and used by the
executable, which can be helpful to programmers trying to squeeze
every last byte out of a particularly small region. The output
has a fixed format which is human readable and machine parsable.
For example:
Memory region Used Size Region Size %age Used
ROM:256 KB 1 MB 25.00%
RAM: 32 B 2 GB 0.00%
* The assembler and linker now support the compact exception handler
sections as used by MIPS toolchains. The new gas pseudo ops:
.cfi_personality_id
.cfi_fde_data[ ,...]
.cfi_inline_lsda []
Are provided to help specify the contents of this new type of
section.
* The assembler has a new option to enable section name substitution:
--sectname-subst
If enabled then section names may include the "%S" sequence which
will be substituted for the name of the current section. For
example:
.macro gen_exceptions
.section %S.exception
[...]
.previous
.endm
.text
[...]
gen_exceptions
[...]
.section .init
[...]
gen_exceptions
[...]
This will create four sections: .text, .text.exception, .init and
.init.exception. In the future other substitution sequences in
addition to %S may be provided.
* Support for the ARMv8.1 architecture has been added to the AArch64
and ARM ports. This includes support for the Adv.SIMD, LOR and
PAN architecture extensions.
Cheers
Nick
RE: Possible range based 'for' bug
> -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf > Of Julian Klappenbach > Sent: 21 June 2015 16:56 > To: gcc@gcc.gnu.org > Subject: Re: Possible range based 'for' bug > > Version info: > > Configured with: > --prefix=/Applications/Xcode.app/Contents/Developer/usr > --with-gxx-include-dir=/usr/include/c++/4.2.1 > Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) > Target: x86_64-apple-darwin14.3.0 > Thread model: posix > Is this what gcc --version returns on your mac? Paulo Matos
Re: Possible range based 'for' bug
On 22 June 2015 at 10:18, Paulo Matos wrote: > > >> -Original Message- >> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf >> Of Julian Klappenbach >> Sent: 21 June 2015 16:56 >> To: gcc@gcc.gnu.org >> Subject: Re: Possible range based 'for' bug >> >> Version info: >> >> Configured with: >> --prefix=/Applications/Xcode.app/Contents/Developer/usr >> --with-gxx-include-dir=/usr/include/c++/4.2.1 >> Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) >> Target: x86_64-apple-darwin14.3.0 >> Thread model: posix >> > > Is this what gcc --version returns on your mac? Yes, because Apple's latest versions of Xcode are liars. It installs a binary called 'gcc' that is really clang. It's quite annoying.
GCC 5.1.1 Status Report (2015-06-22)
Status == I plan to release GCC 5.2.0 around July 10th which means a release candidate being done around July 3rd. Please check your open regression bugs for ones that eligible for backporting. Also please help getting the P1 bug count to zero (there is still the ARM aligned argument passing ABI issue). Quality Data Priority # Change from last report --- --- P12+ 2 P2 71- 3 P3 44+ 27 P4 82- 1 P5 32- 2 --- --- Total P1-P3 117+ 26 Total 231+ 23 Previous Report === https://gcc.gnu.org/ml/gcc/2015-04/msg00289.html The next report will be sent by me when announing a first GCC 5.2.0 release candidate.
Re: dwarf DW_AT_decl_name: system headers vs source files?
Hi, On Sat, 20 Jun 2015, DJ Delorie wrote: > Note that the DW_AT_decl_file refers to "dj.h" and not "dj.c". If you > remove the "3" from the '# 1 "dj.h" 1 3' line, the DW_AT_decl_file > instead refers to "dj.c". It's been this way for many releases. > > Is this intentional? I think it came in with r137873, aka https://gcc.gnu.org/ml/gcc-patches/2008-07/msg01061.html > If so, what is the rationalization for it? I can't really grok the situation Rafael wanted to improve. Ciao, Michael.
Version numbers question
I am wondering why it appears that GCC has started drastically raising its major version number for minor changes, instead of spending several years on version 3 and 4. 4.0.1, 4.1.1 and 4.12, 4.2.3, 4.3.2, 4.4.5, up through 4.7.0, 4.7.1, 4.7.2, the 4.8 and 4.9 releases, then version 5.1 and talking about version 6. Little changes should be reflected in minor version and bugfix numbers, not major version jumps. John Tellefson Kansas, where Brownback talks and the wind blows USA
Re: Version numbers question
> On Jun 22, 2015, at 6:55 AM, JohnT wrote: > > I am wondering why it appears that GCC has started drastically raising its > major version number for minor changes, instead of spending several years > on version 3 and 4. 4.0.1, 4.1.1 and 4.12, 4.2.3, 4.3.2, 4.4.5, up through > 4.7.0, 4.7.1, 4.7.2, the 4.8 and 4.9 releases, then version 5.1 and > talking about version 6. Little changes should be reflected in minor > version and bugfix numbers, not major version jumps. The simple answer is there is no justification to ever bump the major version any time soon so why not make the major version the one which gets bumped each year. So 5 is the version which is released this year, 6 next year, etc. this is no different from 4.9 last year and 4.8 the year before really. Just it was decided 4.10 does not make sense and is partly confusing to some users; does it come before or after 4.2. Anyways the decision was done to get rid of that confusion and also to avoid having to make a justification of when to bump the major version number. Thanks, Andrew Pinski > > John Tellefson > Kansas, where Brownback talks and the wind blows > > USA >
Re: Version numbers question
On Mon, Jun 22, 2015 at 08:55:03 -0500, JohnT wrote: > I am wondering why it appears that GCC has started drastically raising its > major version number for minor changes, instead of spending several years > on version 3 and 4. 4.0.1, 4.1.1 and 4.12, 4.2.3, 4.3.2, 4.4.5, up through > 4.7.0, 4.7.1, 4.7.2, the 4.8 and 4.9 releases, then version 5.1 and > talking about version 6. Little changes should be reflected in minor > version and bugfix numbers, not major version jumps. A part of the discussion (~80 mails) is here: https://gcc.gnu.org/ml/gcc/2014-07/msg00196.html -- Ilya
Re: Version numbers question
On 22 June 2015 at 14:55, JohnT wrote: > I am wondering why it appears that GCC has started drastically raising its > major version number for minor changes, instead of spending several years > on version 3 and 4. 4.0.1, 4.1.1 and 4.12, 4.2.3, 4.3.2, 4.4.5, up through > 4.7.0, 4.7.1, 4.7.2, the 4.8 and 4.9 releases, then version 5.1 and > talking about version 6. Little changes should be reflected in minor > version and bugfix numbers, not major version jumps. Define little.
Andreas Tobler appointed FreeBSD maintainer (was: FreeBSD users of gcc)
A while ago Loren James Rittle, who had been taking care of GCC on FreeBSD for many years and brought the port to modern standards, wrote the following on this list: >> I am the named maintainer of the freebsd port. I have been for >> approximately twelve years; although I haven't been very active >> the last four years. [...] I am looking for someone that both the >> GCC steering committee and I would be willing to hand over the >> reigns before I drop my officially-listed maintainership. Turns out that with Andreas Tobler we are in the lucky position to have someone like that. Andreas already contributed arm*-*-freebsd* support, PIE support for FreeBSD, did some PowerPC work, and more. So, today I am happy to announce that the steering committee has appointed Andreas maintainer of the FreeBSD ports of GCC. And I'd like to extend many thanks to Loren James for all his contributions to libstdc++ and GCC on FreeBSD over many years. Thanks a bunch, Loren, and happy hacking, Andreas! Gerald
Re: Andreas Tobler appointed FreeBSD maintainer
On 22.06.15 20:33, Gerald Pfeifer wrote: A while ago Loren James Rittle, who had been taking care of GCC on FreeBSD for many years and brought the port to modern standards, wrote the following on this list: >> I am the named maintainer of the freebsd port. I have been for >> approximately twelve years; although I haven't been very active >> the last four years. [...] I am looking for someone that both the >> GCC steering committee and I would be willing to hand over the >> reigns before I drop my officially-listed maintainership. Turns out that with Andreas Tobler we are in the lucky position to have someone like that. Andreas already contributed arm*-*-freebsd* support, PIE support for FreeBSD, did some PowerPC work, and more. So, today I am happy to announce that the steering committee has appointed Andreas maintainer of the FreeBSD ports of GCC. And I'd like to extend many thanks to Loren James for all his contributions to libstdc++ and GCC on FreeBSD over many years. Thanks a bunch, Loren, and happy hacking, Andreas! Thank you! I updated the MAINTAINERS file, see below. Andreas 2015-06-22 Andreas Tobler * MAINTAINERS (OS Port Maintainers): Add myself. (Various Maintainers): Remove myself from libffi testsuite. Index: MAINTAINERS === --- MAINTAINERS (revision 224759) +++ MAINTAINERS (working copy) @@ -125,7 +125,7 @@ darwin portMike Stump darwin portEric Christopher DJGPP DJ Delorie -freebsdLoren J. Rittle +freebsdAndreas Tobler GNU/Hurd Thomas Schwinge hpux John David Anglin hpux Steve Ellcey @@ -175,7 +175,6 @@ libiberty DJ Delorie libiberty Ian Lance Taylor libitm Torvald Riegel -libffi testsuite Andreas Tobler libmpx Ilya Enkovich libobjcNicola Pero libobjcAndrew Pinski
Re: Question about DRAP register and reserving hard registers
On Fri, 2015-06-19 at 09:09 -0400, Richard Henderson wrote: > On 06/16/2015 07:05 PM, Steve Ellcey wrote: > > > > I have a question about the DRAP register (used for dynamic stack alignment) > > and about reserving/using hard registers in general. I am trying to > > understand > > where, if a drap register is allocated, GCC is told not to use it during > > general register allocation. There must be some code somewhere for this > > but I cannot find it. > > There isn't. Because the vDRAP register is a pseudo. The DRAP register is > only live from somewhere in the middle of the prologue to the end of the > prologue. > > See ix86_get_drap_rtx, wherein we coordinate with the to-be-generated > prologue > (crtl->drap_reg), allocate the pseudo, and emit the hard-reg-to-pseudo copy > at > entry_of_function. > > > r~ OK, I think I have this part of the code working on MIPS but crtl->drap_reg is used in the epilogue as well as the prologue even if it is not 'live' in between. If I understand the code correctly the x86 prologue pushes the drap register on to the stack so that the epilogue can pop it off and use it to restore the stack pointer. Is my understanding correct? I also need the drap pointer in the MIPS epilogue but I would like to avoid having to get it from memory. Ideally I would like to restore it from the virtual register that the prologue code / get_drap_rtx code put it into. I tried just doing a move from the virtual drap register to the real one in expand_epilogue but that didn't work because it looks like you can't access virtual registers from expand_prologue or expand_epilogue. I guess that is why the code to copy the hard drap reg to the virtual drap_reg is done in get_drap_reg and not in expand_prologue. I thought about putting code in get_drap_reg to do this copying but I don't see how to access the end of a function. The hard drap reg to virtual drap reg copy is inserted into the beginning of a function with: insn = emit_insn_before (seq, NEXT_INSN (entry_of_function ())); Is there an equivalent method to insert code to the end of a function? I don't see an 'end_of_function ()' routine anywhere. Steve Ellcey sell...@imgtec.com
Re: Version numbers question
Thanks, Andrew, a reasonable reason. Time flies and GCC or its predecessor has been around for about 25 years. In another 25, hopefully GCC will still be a leading compiler and the larger numbers won't seem awkward. Regarding what's a small vs large change, I'd say that building with C++ and newly generated C++ library was worthy of a major version bump, but that's just my amateur opinion. John pins...@gmail.com wrote: > > > >> On Jun 22, 2015, at 6:55 AM, JohnT wrote: >> >> I am wondering why it appears that GCC has started drastically raising its >> major version number for minor changes, instead of spending several years >> on version 3 and 4. 4.0.1, 4.1.1 and 4.12, 4.2.3, 4.3.2, 4.4.5, up through >> 4.7.0, 4.7.1, 4.7.2, the 4.8 and 4.9 releases, then version 5.1 and >> talking about version 6. Little changes should be reflected in minor >> version and bugfix numbers, not major version jumps. > The simple answer is there is no justification to ever bump the major version > any time soon so why not make the major version the one which gets bumped > each year. So 5 is the version which is released this year, 6 next year, etc. > this is no different from 4.9 last year and 4.8 the year before really. Just > it was decided 4.10 does not make sense and is partly confusing to some > users; does it come before or after 4.2. Anyways the decision was done to get > rid of that confusion and also to avoid having to make a justification of > when to bump the major version number. >
