gccadmin | 26 Mar 23:35 2015

gcc-4.8-20150326 is now available

Snapshot gcc-4.8-20150326 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 221712

You'll find:

 gcc-4.8-20150326.tar.bz2             Complete GCC


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

Jason Merrill | 26 Mar 21:02 2015

Atomic operations and unaligned memory

The wiki page https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy says,

   typedef char B3[3];
   _Atomic B3 obj2;

An object will be promoted up to the next lock-free size in order to 
enable lock free operations, as long as it isn't already a documented 
lock free size. So obj2 will be promoted to a 4 byte object with 
whatever alignment is required in order to enable lock-free operations.

But the implementation doesn't follow this.  First, the above is 
rejected due to applying _Atomic to an array type.  If we wrap the array 
in a struct, the resulting atomic object still has size 3 and alignment 1.

Did the design change, or is this a bug?


Kyrill Tkachov | 26 Mar 16:40 2015

Fixing inconsistent uses of address costs

Hi all,

I'd like to attempt to make GCC's usage of costs in the backends consistent.
We have a lot of different types: rtx costs, address costs, regmove costs,
vector costs etc. Some of them are use in different units, compared against
different types of costs and in general are a bit of a mess. For now I'd 
to clean up address costs since they are actually not used as much as some
other costs and seem to me to be a slightly simpler task.

 From what I can see, address costs i.e. the TARGET_ADDRESS_COST hook 
are used
in 5 places overall:
* fwprop.c: forward propagation tries to propagate an rtx into an address
and compare the address cost of the old address and the one it wants to
propagate into it and picks the most profitable.

* postreload.c: Again, tries to replace an address with a new one and 
the two address costs and picks the most profitable.

* tree-ssa-loop-ivopts.c: A bit more involved here. From what I can tell 
it is
used to assign a cost to various addressing modes, but ends up comparing but
in the computation_cost function adds/mixes the address cost with rtx costs.

* Some targets use address costs as part of their calculation of rtx costs
for, say, a memory access instruction.

* The final and worst part is in loop-invariant.c in the 
(Continue reading)

Richard Biener | 26 Mar 15:15 2015

Re: Question about Gimple FE

On Thu, Mar 26, 2015 at 2:31 PM, xue yinsong <xyshh94225 <at> hotmail.com> wrote:
> I think the gimple front end project would be quite useful to gcc so I’d like to do work on it this summer.
> The problem is, it seems the GIMPLE front end project hasn’t been active for some time
> and Diego Novillo told me it may not even make sense to use the same codebase, but start from scratch.
> I’m not sure if I should pick it up where it left off or write another one from scratch
> Could you give me some advice?

I don't know the current codebase at all (unfortunately).  I think it
is useful to get yourself familiarized
with it even if you start from scratch as it will get you to learn
something about GIMPLE and about
writing a frontend.

Note that LTO support already is able to output everything needed to
re-create GIMPLE thus from
there you can also learn what is required to populate a GIMPLE
representation.  And LTO support
might be used to create output that can be read by the GIMPLE frontend
- the whole project
feels like finding a textual form of the LTO bytecode (in some way).

Note that it's always useful to ask such questions on the mailing list
as there may be other people
who can give useful input.  Thus, CCed.


(Continue reading)

Paolo Carlini | 26 Mar 01:10 2015

Bugzilla vs 5.0 milestone


sorry if I missed part of the discussion about the new numbering scheme 
and the answer to my question is already clear from that: why we do have 
5.0 as Milestone in Bugzilla instead of 5.1?!?


gccadmin | 25 Mar 23:36 2015

gcc-4.9-20150325 is now available

Snapshot gcc-4.9-20150325 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 221674

You'll find:

 gcc-4.9-20150325.tar.bz2             Complete GCC


Diffs from 4.9-20150318 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.

Jack Howarth | 25 Mar 17:16 2015

-Wno-c++11-extensions addition

Does anyone remember which FSF gcc release first added the
-Wno-c++11-extensions option for g++? I know it exists in 4.6.3 but am
not having much luck Googling for the original submission in the
gcc-patches archives. According to
https://gcc.gnu.org/projects/cxx0x.html, the initial c++-11 support
goes back to 4.3 but this specific warning isn't mentioned in the
documentation for 4.6.3 which supports -Wno-c++11-extensions

Rainer Emrich | 25 Mar 16:54 2015

Bootstrap broken on trunk, stage 2 gengtype: Internal error: abort in error_at_line, at gengtype.c:112

This is on x86_64-w64-mingw32.

build/gengtype.exe  \
                    -S ../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc -I gtyp-input.list -w tmp-gtype.state
gtyp-input.list:101: file
specified more than once for language (all)
gengtype: cp/cp-tree.h is in language directory 'cp' but is not tagged for that language
../../../../../../../opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/cp/cp-tree.h:524: type
`abstract_class_use' previously defined
previously defined here
duplicate definition of 'struct (null)'
gengtype: Internal error: abort in error_at_line, at gengtype.c:112
Makefile:2401: recipe for target 's-gtype' failed
make[3]: *** [s-gtype] Error 1
make[3]: Leaving directory '/opt/devel/SCRATCH/tmp.wvqDtH7wOD/gcc-5.0.0/gcc-5.0.0/gcc'
Makefile:4414: recipe for target 'all-stage2-gcc' failed
make[2]: *** [all-stage2-gcc] Error 2

Any bell rings?
Alexey Neyman | 24 Mar 22:26 2015

Bug with compound literal initializer?


I am seeing a strange behavior when a compound initializer is used in a 
structure initialization. A test case:

struct s {
     int y;
     unsigned long *x;

struct s foo = {
     .y = 25,
     .x = (unsigned long [SZ]){},

If SZ is defined to non-zero, the expected output is produced:

/tmp$ gcc -S -o- 1.c -Wall -DSZ=1
     .file    "1.c"
     .local    __compound_literal.0
     .comm    __compound_literal.0,8,8
     .globl    foo
     .align 16
     .type    foo,  <at> object
     .size    foo, 16
(Continue reading)

Richard Allen | 24 Mar 12:54 2015


sent from my I Phonek

David Kunsman | 24 Mar 00:14 2015

gcc wiki project

Hello, I was just reading through the current projects wiki page and I
noticed how out of date pretty much all of them are.  So I was
planning on doing "spring cleaning" by going down the list tracking
down what has been and what needs to be down and updating all the
wikis.  Do you think this is something that is worthwhile to work on?