TREE_LIST removals and cleanups for 4.7

2011-01-22 Thread Nathan Froyd
Since people are starting to post interesting patches for 4.7, I thought it would be good to talk about bits I plan to cleanup in 4.7. Comments on other ugly things would also be welcome. TREE_LIST related things: - TREE_VECTOR_CST_ELTS. I have a patch for this. - ASM_EXPR operands, clobbers,

Re: IA64: short data segment overflowed issue

2011-01-22 Thread Sergei Trofimovich
On Thu, 20 Jan 2011 17:27:14 -0800 Richard Henderson wrote: > Depending on how Haskell programs are built, it may be better > to avoid the GOT entirely. E.g. > > -mcmodel=large > > a-la the x86_64 port. This generates full 64-bit absolute > relocations. For ia64 code this would look like >

Re: TREE_LIST removals and cleanups for 4.7

2011-01-22 Thread Michael Matz
Hi, On Sat, 22 Jan 2011, Nathan Froyd wrote: > - Similarly to the work I did for s/TREE_CHAIN/DECL_CHAIN/, I'd like to > replace TREE_TYPE for things like {POINTER,FUNCTION,ARRAY}_TYPE, etc. > This work would be a good step towards both staticizing trees and > tuplification of types. While

Re: Does TYPE_MAX_VALUE (size_type_node) overflow?

2011-01-22 Thread Florian Weimer
* Richard Guenther: >> Thanks for the suggestion.  TYPE_MAX_VALUE (sizetype) appears to be >> -1, as the result of this code in stor-layout.c: >> >>  /* sizetype is unsigned but we need to fix TYPE_MAX_VALUE so that it is >>     sign-extended in a way consistent with force_fit_type.  */ >>  max =

Re: operator new[] overflow (PR 19351)

2011-01-22 Thread Florian Weimer
* Gabriel Dos Reis: >>> Still, it's certainly an improvement on the current >>> situation and the cost is negligible compared to the call to the >>> allocator.  Since it's a security issue, some form of the patch should >>> go in. >> >> Well, should I resubmit, with the fix for the problem buildin

Re: IA64: short data segment overflowed issue

2011-01-22 Thread Richard Henderson
On 01/22/2011 10:48 AM, Sergei Trofimovich wrote: > I've attached dirty patch. It has not very nice comments, tabs and spaces yet. Steve perhaps should weigh in here... > As I understand, TARGET_AUTO_PIC, TARGET_CONSTANT_GP, > TARGET_NO_PIC should somehow fall into different memory models. > I do

Oho! VisLatvijas miiklu mineshanas maratons! Tev ir miikla Nr. 21329

2011-01-22 Thread Julija Airijana
Atmini miiklu: Taatad - Kas tas ir: seksigs augums, skaistas kruutis, apeteligs dupsis.. Runaa pa latviski, ir lunkana un slaida kaa melnaa pantera.. Nav izslegts, ka vina ir tava kaiminiene! Atrisinajumu uzzini te: http://iespeja-tev.is-a-cubicle-slave.com Uzmanies, reebusa atminejums var sh

[SPAM] Visa Latvijas kaa aptrakushi Zinaatnieki min miiklas! Nem dalibu ari tu!!! Jums ir tikusi miikla Nr. 40823

2011-01-22 Thread Asnate Akermane(tel.2953..)
Noprovee atmineet shaadu miik1u: Taatad - Kas tas ir: seksigs augums, skaistas kruutis, apeteligs dupsis.. Runaa pa latviski, ir lunkana kaa melnaa pantera.. Dzivo, iespejams, tev kaiminos... At-bildi dabon te: http://atminejums.likes-pie.com Uzmanies, miklas atminejums var paarsteigt!

gcc-4.6-20110122 is now available

2011-01-22 Thread gccadmin
Snapshot gcc-4.6-20110122 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110122/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk

Re: Turn on -funroll-loops at -O3?

2011-01-22 Thread Andi Kleen
"H.J. Lu" writes: > Hi, > > SInce -O3 turns on vectorizer, should it also turn on > -funroll-loops? In my experience gcc already unrolls very aggressively at -O3, due to the vector unroller which is enabled by default. -Andi