Qun-Ying | 19 Dec 19:59 2014

GCC document link broken and some document questions


I found that links for the "GNAT User's Guide"  are broken for version
4.8.4 and 4.9.2.

The links are
https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gnat_ugn_unw/ and

There are links to the guide at


But the documents there have some texinfo left over (HTML only, PDF seems OK)

And all the rest of the links to the PDF/PostSCript or HTML  tarball
have the same problem, need to remove "_unw" from the filename

Also for GCC 4.9.2:

It mention the flag "-fdump-xref", but it does not work:
cc1: error: unrecognized command line option ‘-fdump-xref’
Seems a mismatch in document.

For the generated PDF and PS files, I am not sure why it puts the
table of content at the end of the file. It defects its purpose.

(Continue reading)

Jakub Jelinek | 19 Dec 14:57 2014

GCC 4.8.5 Status Report (2014-12-19)


GCC 4.8.4 has been released, the branch is again open for regression
bugfixes and documentation fixes.  GCC 4.8.5 could be tentatively released
in April next year.

Quality Data

Priority          #   Change from Last Report
--------        ---   -----------------------
P1                0   +- 0
P2              123   +- 0
P3                6   +- 0
--------        ---   -----------------------
Total           129   +- 0

Previous Report


Jakub Jelinek | 19 Dec 14:31 2014

GCC 4.8.4 Released

The GNU Compiler Collection version 4.8.4 has been released.

GCC 4.8.4 is the fourth bug-fix release containing important fixes for
regressions and serious bugs in GCC 4.8.3 with over 80 bugs fixed since
the previous release.

This release is available from the FTP servers listed at:


Please do not contact me directly regarding questions or comments about
this release.  Instead, use the resources available from

As always, a vast number of people contributed to this GCC release -- far
too many to thank them individually!

Roger Ferrer Ibáñez | 19 Dec 10:13 2014

Issue with __int128 in powerpc64le


I'm observing a weird behaviour in PowerPC64 Little Endian that does
not seem to occur on other architectures supporting __int128. The
following code, when compiled with -O1 generates wrong output.

-- test.c
#include <stdio.h>

typedef unsigned __int128 uint128_t;

#define PRINT(value) \
    { union u { uint128_t i; unsigned long long l[2]; } _t = { .i = value }; \
        fprintf(stderr, "%s => <%016llx, %016llx>\n", #value, _t.l[1],
_t.l[0]); }

uint128_t get_int(uint128_t value, unsigned int num_bytes)
    uint128_t mask = ~(uint128_t)0;
    mask <<= (uint128_t)(8 * num_bytes); /* assuming 1 byte = 8 bits */
    mask = ~mask;
    value &= mask;

    return value;

int main(int argc, char* argv[])
    uint128_t x = 0;
(Continue reading)

gccadmin | 18 Dec 23:37 2014

gcc-4.8-20141218 is now available

Snapshot gcc-4.8-20141218 is now available on
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 218877

You'll find:

 gcc-4.8-20141218.tar.bz2             Complete GCC


Diffs from 4.8-20141211 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.

S.K. | 18 Dec 04:45 2014


This is to request your assistance for a lucrative project in Asia. Kindly respond for specifics.

Sebastian Huber | 18 Dec 10:05 2014

Localized write permission for OS maintainers


I have a question regarding the localized write permission for OS 
maintainers.  In


we have

"Localized write permission.

    This is for people who have primary responsibility for ports, front
    ends, or other specific aspects of the compiler. These folks are
    allowed to make changes to areas they maintain and related
    documentation, web pages, and test cases without approval from
    anyone else, and approve other people's changes in those areas. They
    must get approval for changes elsewhere in the compiler.

    Maintainers of a port maintain the relevant files in |gcc/config|,
    documentation, web pages, and test cases and aspects of these
    relevant to that port. Port maintainers do not have approval rights
    beyond this."

Does this cover OS specific areas in the gcc/config.gcc file?  For example:



Sebastian Huber, embedded brains GmbH

(Continue reading)

gccadmin | 17 Dec 23:45 2014

gcc-4.9-20141217 is now available

Snapshot gcc-4.9-20141217 is now available on
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

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

You'll find:

 gcc-4.9-20141217.tar.bz2             Complete GCC


Diffs from 4.9-20141210 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
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.

Lewis Hyatt | 17 Dec 19:12 2014

Extending -flto parallel feature to the rest of the build


I recently started using -flto in my builds, it's a very impressive
feature, thanks very much for adding it. One thing that occurred to me
while switching over to using it: In an LTO world, the object files,
it seems to me, are becoming increasingly less relevant, at least for
some applications. Since you are already committing to the build
taking a long time, in return for the run-time performance benefit, it
makes sense in a lot of cases to go whole-hog and just compile
everything every time anyway. This comes with a lot of advantages,
besides fewer large files laying around, it simplifies things a lot,
say I don't need to worry about accidentally linking in an object file
compiled differently vs the rest (different -march, different
compiler, etc.), since I am just rebuilding from scratch every time.
In my use case, I do such things a lot, and find it very freeing to
know I don't need to worry about any state from a previous build.

In any case, the above was some justification for why I think the
following feature would be appreciated and used by others as well.
It's perhaps a little surprising, or at least disappointing, that

g++ -flto=jobserver *.o

will be parallelized, but this:

g++ -flto=jobserver *.cpp

will effectively not be; each .cpp is compiled serially, then the LTO
runs in parallel, but in many cases the first step dominates the build
(Continue reading)

Mark Farnell | 16 Dec 20:54 2014

Re: trying out openacc 2.0

That's good news.  Does it mean that if I want to try out openACC with
KNL and PTX support, then all I need to do is to compile the
gomp-4_0-branch *without* any extra parameters into ./configure ?

Also, are other GPUs such as the AMD ATI and the built-in GPUs such as
the Intel GPU and AMD fusion supported?  If so, are they already
supported in the trunk, or only specific branch?

Finally, when will support of Knights Corner (knc) be added to the
trunk and/or one of the branches?



On Tue, Dec 16, 2014 at 9:22 PM, Tobias Burnus
<tobias.burnus <at> physik.fu-berlin.de> wrote:
> Mark Farnell wrote:
>> Has OpenACC 2.0 support been merged into the trunk yet?  If not, then
>> is it contained in gomp-4_0-branch?
>> If so, what parameters should I pass to ./configure to enable OpenACC
>> 2.0, and relevant backends such as CUDA, MIC and other GPGPU/manycore
>> architecture?
>> Also, I have a feeling that OpenACC 2.0 did NOT make it to gcc 5.0, am
>> I correct?  If I am correct, then will it be included in gcc 5.1?  If
>> I am wrong and it is already included into gcc 5.0, then I would
>> really really like to use it.
(Continue reading)

BELBACHIR Selim | 16 Dec 15:53 2014

bug in lra-constraints.c (simple_move_p register_move_cost)


I may have found a bug when I was trying to port my private backend to new LRA pass (using gcc 4.9.2+patches).

In lra-constraints.c, in function simple_move_p, the target hook targetm.register_move_cost is
called with two badly swapped parameters :

        targetm.register_move_cost (GET_MODE (src), sclass, dclass) 

should be :

        targetm.register_move_cost (GET_MODE (src), dclass, sclass)

In my port of GCC it leads to an error when checking constrain_operands at the end of LRA pass


Selim Belbachir