Salvador Severs | 28 Jan 16:02 2015

SAUR FRANCE (CISE)

SAUR FRANCE (CISE)
46 Rue David D Angers 49130 Les Ponts De Ce
Ce
FRANCE
+33 241 72 56 78
Attachment (saur_france_cise.cab): application/vnd.ms-cab-compressed, 25 KiB
Leonel Goetsch | 28 Jan 12:23 2015

tottering

LAMY LUTTI SA
15 Av Cida 7170 Bois-D'Haine
Bois-D'Haine
BELGIUM
+32 64 67 11 01
Attachment (lamy_lutti_sa.cab): application/vnd.ms-cab-compressed, 25 KiB
Lu, Kangjie | 27 Jan 23:52 2015
Picon

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.

Thanks,
Ken

David Edward Cleasby | 27 Jan 19:15 2015

Hello

Hi,

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> gmail.com for more details.

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

Slow gcc.gnu.org/sourceware.org?

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

--

-- 
H.J.

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));
     return(0);
}

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
vs.
(Continue reading)

Martin Uecker | 26 Jan 20:53 2015
Picon

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
missing.

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
Picon

gcc-5-20150125 is now available

Snapshot gcc-5-20150125 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150125/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 220097

You'll find:

 gcc-5-20150125.tar.bz2               Complete GCC

  MD5=65a8f64d4a4f915b0c1921bb82a3a4d0
  SHA1=09e5477ecc0d8107e0fae409019a9e781a15d154

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
Picon

minor: 2014 instead of 2015 in the timeline

https://gcc.gnu.org/develop.html#timeline

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

Please, fix this.

Leonid.

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
the 
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
such 
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
should 
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
transition 
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
Picon

Is there a way to dump LTO IR?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64754

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?

Thanks.

--

-- 
H.J.


Gmane