Salvador Severs | 28 Jan 16:02 2015


46 Rue David D Angers 49130 Les Ponts De Ce
+33 241 72 56 78
Attachment ( application/, 25 KiB
Leonel Goetsch | 28 Jan 12:23 2015


15 Av Cida 7170 Bois-D'Haine
+32 64 67 11 01
Attachment ( application/, 25 KiB
Lu, Kangjie | 27 Jan 23:52 2015

Replace all stack pointer with frame pointer in rtl level

Hi All,

I am a beginner of gcc. 

My goal of modifying gcc is to maintain two stacks.
One is accessed by rbp, the other is accessed by rsp.
rsp is only used by call/ret. All other accesses (e.g., access parameters, access local variables) 
to stack are via rbp.

For easy implementation, I would use flags "-fomit-frame-pointer -ffixed-rbp" to
compile the target program, which prevents gcc using rbp. And in the RTL level, 
I will replace all rsp with rbp (I may also change push/pop into mov instructions).

My question is how to iterate all registers used in insns in rtl level, and replace all
rsp with rbp.


David Edward Cleasby | 27 Jan 19:15 2015



Am David Edward Cleasby, Group financial director of Bidvest Bank. I will like discuss an Inheritance deal
with you which be of help to both of us, if interested kindly reply to: davidecleasby <at> for more details.

H.J. Lu | 27 Jan 17:02 2015


For the past couple days, is
quite slow for me when accessing git and bugzilla.  Am
I the only one who has  experienced it?



Fredrik Tolf | 27 Jan 00:50 2015

Why is floor() only compiled to roundsd when using -funsafe-math-optimizations?

Dear list,

Consider the following small program:

#include <math.h>
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
     double a;

     a = strtod(argv[0], NULL);
     printf("%f\n", floor(a));

When compiling this with a -march that supports the roundsd instruction, 
the floor() call seems to only be compiled to such an instruction if 
-funsafe-math-optimizations is specified.

Why is this? I notice the glibc's floor() implementation (for 
SSE4.1-enabled processors) consists of only this instruction, so barring a 
bug in glibc, that would seem to imply to me the roundsd is IEEE-compliant 
and safe. Why does GCC consider it unsafe?

For reference, these are the complete compile commands I'm using to test:

gcc -O -march=haswell -c -S -o test.s test.c
(Continue reading)

Martin Uecker | 26 Jan 20:53 2015

array bounds, sanitizer, safe programming, and cilk array notation

Hi all,

I am writing numerical code, so I am trying to make the use 
of arrays in C (with gcc) suck a bit less. In general, the long term
goal would be to have either a compile-time warning or the possibility
to get a run-time error if one writes beyond the end of an array as 
specified by its type.

So one example (see below) I looked at is where I pass an array of
too small size to a function, to see how see can be diagnosed. In some
cases, we can get a runtime error with the address sanitizer, but this
is fairly limited (e.g. it does not work when the array is embedded
in a struct) and I also got mixed results when the function
is inlined.

For pointers to arrays with static size one can get an "incompatible
pointer" warning - which is nice. With clang, I also get warning for 
pointers which are declared as array parameters and use the 'static' 
keyword to specify a minimum size. This a diagnostic we are currently

The next step would be to have diagnostics also for the VLA
case if the size is known at compilation time (as in the
example below) and a run-time error when it is not (maybe 
with the undefined behaviour sanitizer?).

If we have the later, I think this might also help with safer 
programming in C, because one would get either a compile time or 
runtime error when I passing a buffer which is too small to
(Continue reading)

gccadmin | 26 Jan 05:31 2015

gcc-5-20150125 is now available

Snapshot gcc-5-20150125 is now available on
and on various mirrors, see for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn:// revision 220097

You'll find:

 gcc-5-20150125.tar.bz2               Complete GCC


Diffs from 5-20150118 are available in the diffs/ subdirectory.

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

Leonid Yuriev | 25 Jan 18:04 2015

minor: 2014 instead of 2015 in the timeline

s/GCC 5 Stage 4 (starts 2014-01-17)/GCC 5 Stage 4 (starts 2015-01-17)/

Please, fix this.


Ajit Kumar Agarwal | 25 Jan 10:55 2015

Rematerialization and Live Range Splitting on Region Frequency

Hello All:

Looks like Live range splitting and rematerialization are connected to each other. If  the boundary of Live range
Splitting is in the high frequency of the region then the move connected to splitted live ranges are inside the
High frequency region which is the performance bottleneck for many benchmarks.

Live range splitting based on the frequency of the region should be considered. The Live range splitting in
High frequency region is beneficial if the splitted live range is assigned the color(hard registers)
which is better
Spilling inside the high frequency region, although there will be move instruction or shuffle code which
is still 
Better.  If one of the splitted live range does not have any use points and all the partner live ranges gets the
Hard register, then the move instruction due to splitting will be costly for the high frequency region. In
Case the  split point should be move up at the boundary of the transition from low frequency region to high
Frequency region, and the splitted live ranges still get hard registers.  This require increment check of 
colorabity which increases the compile time but beneficial with respect to run time. The above heuristic
be incorporated on top of the below  Live range splitting Algorithm. Live range splitting algorithm should  consider
the blocks in the decreasing order of frequency with the first block should be taken from the high frequency
region and incrementally updates till it become colorable. Thus split points should be at the edge of the
from high frequency to low frequency region or from low frequency region to high frequency region. 

The above Live range splitting should be incorporated  for all the flavors of Graph Coloring.

Regarding the rematerialization the Chaitin's Rematerialization try to recalculate the expression at
all the 
Use points of the Live ranges and Simpson based approach for Rematerialized try to move the arithmetic
(Continue reading)

H.J. Lu | 23 Jan 21:26 2015

Is there a way to dump LTO IR?

is a LTO bug where stage 1 and stage 2 compilers generate
different LTO IR.  Is there  a way to dump LTO IR to see the
actual difference in LTO IR?