On Thu, Dec 29, 2011 at 8:48 PM, Eric Botcazou wrote:
>> fixed_scalar_and_varying_struct_p passes an _address_ rather than a MEM.
>> So in these cases fixed_scalar_and_varying_struct_p effectively becomes
>> a no-op on targets that don't allow MEMs in addresses and takes on
>> suspicious semantics
On Fri, Dec 30, 2011 at 3:15 PM, sa...@hederstierna.com
wrote:
> Hi!
>
> I'm currently looking into possibilities to improve GCC for
> static-code-analysis features.
> Some weeks ago I proposed re-introducing -Wunreachable-code for finding dead
> code:
>
> http://gcc.gnu.org/ml/gcc-patches/2011
> void *x = __builtin_malloc(sizeof(struct mem));
> struct mem *as = x;
> struct foo **upper = &as->x[rank * 8 - 1];
> *upper = 0;
> bar(upper);
> return *upper;
> }
>
> int main()
> {
> if (foo(0) == 0)
> abort ();
> return 0;
> }
>
>
--
Richard Guenther
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
On Fri, Dec 30, 2011 at 6:53 PM, Jakub Jelinek wrote:
> On Thu, Dec 29, 2011 at 04:24:31PM +, Richard Sandiford wrote:
>> AIUI, the outcome of PR38964 was that we can't use TBAA for testing an
>> anti_dependence between a load X and store Y because Y might be defining
>> a new object in the sa
On Mon, Jan 2, 2012 at 12:37 PM, Amker.Cheng wrote:
> Hi,
> Since SCCVN operates on SSA graph instead of the control flow graph
> for the sake of efficiency,
> it does not handle or value number the conditional expression of
> GIMPLE_COND statement.
> As a result, FRE/PRE does not simplify conditi
On Thu, Dec 29, 2011 at 9:50 AM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: Jiangning Liu
>> Sent: Wednesday, December 28, 2011 5:38 PM
>> To: Jiangning Liu; 'Richard Guenther'
>> Cc: Michael Matz; gcc@gcc.gnu.org
&
On Mon, Jan 2, 2012 at 2:11 PM, Amker.Cheng wrote:
> Thanks Richard,
>
> On Mon, Jan 2, 2012 at 8:33 PM, Richard Guenther
> wrote:
>>
>> I've previously worked on changing GIMPLE_COND to no longer embed
>> the comparison but carry a predicate SSA_NAME only (th
On Mon, Jan 2, 2012 at 3:09 PM, Amker.Cheng wrote:
> On Mon, Jan 2, 2012 at 9:37 PM, Richard Guenther
> wrote:
>
>> Well, with
>>
>> Index: gcc/tree-ssa-pre.c
>> ===
>> --- gcc/tree-ssa-pre.c
On Mon, Jan 2, 2012 at 3:42 PM, Richard Sandiford
wrote:
> Thanks for both replies.
>
> Richard Guenther writes:
>> On Thu, Dec 29, 2011 at 8:48 PM, Eric Botcazou wrote:
>>>> fixed_scalar_and_varying_struct_p passes an _address_ rather than a
On Thu, Jan 5, 2012 at 9:34 AM, Jiangning Liu wrote:
>> >> > In final value replacement, expression "&a + D." can be
>> figured
>> >> out,
>> >> > while "&a[i_xxx]" failed to be CHRECed, so I'm wondering if we
>> should
>> >> > lower
>> >> > &a[i_xxx] to "&a + unitsize(a) * i_xxx" first? It se
Status
==
Stage 3 is now officially over, after a bit more than two months.
The GCC trunk is now in regression and documentation fixes only
state (so-called stage4). The trunk will remain in this state
until it is sufficiently stable for release. At this point we
will create the 4.7 branch
On Thu, Jan 5, 2012 at 5:16 PM, David Malcolm wrote:
> I'm working on a GCC plugin which performs static analysis of Python
> extension code [1]
>
> In various places I need access to a VAR_DECL for various globals from C
> code, many of which potentially aren't used directly within the
> compilat
On Wed, Jan 11, 2012 at 5:43 AM, Ian Lance Taylor wrote:
> The Go language is closing in what we are calling Go version 1. This
> will be a long-term stable release of Go, with no language or library
> API changes. Go 1 is described here:
There is still no official ABI, right? So no chance of
On Thu, Jan 12, 2012 at 3:15 PM, Dennis Clarke wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Any expected date on a 4.7 RC ?
When it's ready. Which we'd usually expect it to be around the
beginning of April.
Richard.
On Fri, Jan 13, 2012 at 9:04 AM, Amker.Cheng wrote:
> Hi,
> I noticed gcc generates inconsistent codes for same function for builtin
> calls.
>
> compile following program:
> --
> #include
> int a(float x) {
> return sqrtf(x);
> }
> int b(float x)
On Mon, Jan 16, 2012 at 7:24 AM, Amker.Cheng wrote:
> On Fri, Jan 13, 2012 at 10:17 PM, Amker.Cheng wrote:
>> On Fri, Jan 13, 2012 at 5:33 PM, Richard Guenther
>> wrote:
>>>
>>> No, I think the check is superfluous and should be removed. I also wonder
>
On Wed, Jan 18, 2012 at 6:37 PM, Alexander Herz wrote:
> Given this piece of code (gcc-4.7-20120114):
>
> static void Test(Batch* block,Batch* new_block,const uint32 offs)
> {
>
> T* __restrict old_values
> =(T*)__builtin_assume_aligned(block->items,16);
> T* __restrict new_val
On Thu, Jan 19, 2012 at 7:37 AM, Marc Glisse wrote:
> On Wed, 18 Jan 2012, willus.com wrote:
>
>> For those who might be interested, I've recently benchmarked gcc 4.6.3
>> (and 3.4.2) vs. Intel v11 and Microsoft (in Windows 7) here:
>>
>> http://willus.com/ccomp_benchmark2.shtml
>
>
> http://en.wi
On Thu, Jan 19, 2012 at 12:56 PM, Alberto Lozano Alelu wrote:
> Hello.
>
> I'm developing a C++ analyzer and I would like to get source text of
> file when I'm analyzing C++ code.
>
> When I'm analyzing source code I would like to get source text line
> from a location of a type. I have got type l
t; expanded_location v_location=expand_location(SOURCE_LOCATION(my_element));
> char * v_line_text = a_function(v_location);
>
> v_line_text is a source code line.
>
> I need to have source text
There is no such thing.
Richard.
> Thanks you very much.
>
> On 19 January 2012 13
e some assembly dumps showing both the vectorized and the
> unvectorized loop?
Assembly does not help. Loop unrolling happens after vectorization.
Richard.
> Alex
>
>
> On 01/19/2012 11:29 AM, Richard Guenther wrote:
>>
>> On Wed, Jan 18, 2012 at 6:37 PM, Alexander Herz
On Thu, Jan 19, 2012 at 3:27 PM, willus.com wrote:
> On 1/19/2012 2:59 AM, Richard Guenther wrote:
>>
>> On Thu, Jan 19, 2012 at 7:37 AM, Marc Glisse wrote:
>>>
>>> On Wed, 18 Jan 2012, willus.com wrote:
>>>
>>>> For those who might be int
On Fri, Jan 20, 2012 at 3:43 AM, willus.com wrote:
> On 1/19/2012 6:29 AM, Richard Guenther wrote:
>>
>> On Thu, Jan 19, 2012 at 3:27 PM, willus.com wrote:
>>>
>>> On 1/19/2012 2:59 AM, Richard Guenther wrote:
>>>>
>>>> On Thu, Jan 19, 201
oesn't know or does not have any
objection.
Thanks,
Richard.
2012-01-24 Richard Guenther
* expr.c (store_field): Do not set MEM_IN_STRUCT_P.
Index: gcc/expr.c
===
--- gcc/expr.c (revision 183470)
+++ gcc/exp
On Tue, Jan 24, 2012 at 4:51 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> On Mon, Jan 2, 2012 at 7:54 PM, Eric Botcazou wrote:
>>>> I'd say open a missed optimization bug with the testcase and go ahead
>>>> with both patches. Let's
On Wed, Jan 25, 2012 at 3:43 PM, Christophe Lyon wrote:
> Hello,
>
> In a one year old thread, there was a discussion about a patch adding
> -fuse-ld=gold and -fuse-ld=bfd options to GCC.
>
> It seems the GCC part of the patch was never actually committed, as there
> were some problems with LTO:
>
On Wed, Jan 25, 2012 at 3:55 PM, Christophe Lyon wrote:
> On 25.01.2012 15:49, Richard Guenther wrote:
>>
>>
>> You can change the linker used by adjusting your path or giving an
>> appropriate -B option to the gcc driver.
>>
>> Richard.
>>
> Yes,
On Thu, Jan 26, 2012 at 12:53 PM, Konstantin Vladimirov
wrote:
> Hi,
>
> If I know what I am doing, and my code itself guarantees, that there
> will be no overflows and UB here, can I switch off this signed char to
> unsigned char expansion in favor of signed char to signed int
> expansion?
No, y
On Wed, Jan 25, 2012 at 8:20 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> I'd say open a missed optimization bug with the testcase and go ahead
>> with both patches.
>
> OK, I committed the patches yesterday and I've just opened PR 52000
> for the
On Thu, Jan 26, 2012 at 4:58 PM, David Brown wrote:
> On 26/01/2012 12:53, Konstantin Vladimirov wrote:
>>
>> Hi,
>>
>> If I know what I am doing, and my code itself guarantees, that there
>> will be no overflows and UB here, can I switch off this signed char to
>> unsigned char expansion in favor
On Fri, Jan 27, 2012 at 10:40 AM, David Brown wrote:
> On 27/01/2012 10:02, Richard Guenther wrote:
>>
>> On Thu, Jan 26, 2012 at 4:58 PM, David Brown
>> wrote:
>>>
>>> On 26/01/2012 12:53, Konstantin Vladimirov wrote:
>>>>
>>>>
&
On Tue, Jan 31, 2012 at 2:31 AM, Alexandre Oliva wrote:
> glibc 2.15 won't build with GCC 4.7ish on ppc64: -fno-inline-functions
> is no longer enough to prevent call_gmon_start from being inlined into
> initfini.c's _init, as required by glibc's somewhat convoluted
> compilation of initfini.c int
On Wed, Feb 1, 2012 at 3:30 AM, Alexandre Oliva wrote:
> On Jan 31, 2012, Richard Guenther wrote:
>
>> What's probably confusing you is the "Don't pay attention to the
>> @code{inline} keyword" sentence.
>
> What really set me down the wrong patch wer
On Wed, 1 Feb 2012, Linus Torvalds wrote:
> On Wed, Feb 1, 2012 at 9:41 AM, Michael Matz wrote:
> >
> > One problem is that it's not a new problem, GCC emitted similar code since
> > about forever, and still they turned up only now (well, probably because
> > ia64 is dead, but sparc64 should have
On Wed, 1 Feb 2012, Linus Torvalds wrote:
> Just out of morbid curiosity, what happens if you have totally
> *separate* variables that just happen to link together? IOW, something
> like
>
>static struct { unsigned bit:1; } onebit;
>static volatile int var;
>
> and they just *happen* to
On Wed, 1 Feb 2012, Linus Torvalds wrote:
> IT IS A GCC BUG.
I think you are wrong when you assume that we think it is not a bug.
Repeating it repeatedly in all-caps doesn't make the fix appear
faster though.
Richard.
On Thu, 2 Feb 2012, David Sterba wrote:
> On Wed, Feb 01, 2012 at 04:19:18PM +0100, Jan Kara wrote:
> > We actually spotted this race in practice in btrfs on structure
> > fs/btrfs/ctree.h:struct btrfs_block_rsv where spinlock content got
> > corrupted due to update of following bitfield and there
On Thu, 2 Feb 2012, James Courtier-Dutton wrote:
> On 1 February 2012 15:19, Jan Kara wrote:
> > Hello,
> >
> > we've spotted the following mismatch between what kernel folks expect
> > from a compiler and what GCC really does, resulting in memory corruption on
> > some architectures. Consider
On Fri, 3 Feb 2012, DJ Delorie wrote:
>
> Jan Kara writes:
> > we've spotted the following mismatch between what kernel folks expect
> > from a compiler and what GCC really does, resulting in memory corruption on
> > some architectures. Consider the following structure:
> > struct x {
> >
On Fri, Feb 3, 2012 at 2:26 PM, Konstantin Vladimirov
wrote:
> Hi,
>
> Consider minimal reproduction code:
>
> #include "math.h"
> #include "stdio.h"
>
> double __attribute__ ((noinline))
> slip(double a)
> {
> return (cos(a) + sin(a));
> }
>
> int main(void)
> {
> double a = 4.47460300787e+182;
On Sun, Feb 5, 2012 at 10:56 AM, Amker.Cheng wrote:
> Hi,
> In PRE, function compute_antic_aux uses bitmap_set_subtract to compute
> value/expression set subtraction.
>
> The comment of bitmap_set_subtract says it subtracts all the values
> and expressions contained in ORIG from DEST.
>
> But the
On Sat, Feb 4, 2012 at 11:20 AM, James Courtier-Dutton
wrote:
> On 4 February 2012 00:06, Vincent Lefevre wrote:
>> On 2012-02-03 17:40:05 +0100, Dominique Dhumieres wrote:
>>> While I fail to see how the "correct value" of
>>> cos(4.47460300787e+182)+sin(4.47460300787e+182)
>>> can be defined in
On Mon, Feb 6, 2012 at 1:29 PM, Vincent Lefevre wrote:
> On 2012-02-06 12:54:09 +0100, Richard Guenther wrote:
>> Note that you are comparing a constant folded sin() result against
>> sincos() (or sin() and cos()). Use
>>
>> #include
>> #include
>>
>
On Mon, Feb 6, 2012 at 7:06 PM, Hans Wennborg wrote:
> Hello all,
>
> I have been measuring compile times for Chromium using different
> versions of GCC and Clang, and I thought it might be a good idea to
> share the results in case someone else finds them interesting.
>
> Two measurements were co
On Tue, Feb 7, 2012 at 1:26 PM, Konstantin Vladimirov
wrote:
> Hi,
>
> Consider some project, consisting of files: a.c, b.c, d.c and e.c
>
> Compiler is gcc 4.6.2
>
> Files a.c and b.c are performance bottlenecks and requires heavy
> cross-module inline, so must be compiled with -flto option
> Fil
ichard.
> ---
> With best regards, Konstantin
>
> On Tue, Feb 7, 2012 at 4:37 PM, Richard Guenther
> wrote:
>> On Tue, Feb 7, 2012 at 1:26 PM, Konstantin Vladimirov
>> wrote:
>>> Hi,
>>>
>>> Consider some project, consisting of files: a.c,
On Tue, Feb 7, 2012 at 2:31 PM, Amker.Cheng wrote:
> On Mon, Feb 6, 2012 at 7:28 PM, Richard Guenther
> wrote:
>> It's probably to have the SET in some canonical form - the resulting
> I am wondering how the canonical form is maintained, since according
> to the paper:
On Mon, Jul 13, 2009 at 5:39 AM, Jack Howarth wrote:
> On Mon, Jul 13, 2009 at 01:52:51AM +0100, Dave Korn wrote:
>> Richard Guenther wrote:
>> > On Sun, Jul 12, 2009 at 9:41 PM, Jack Howarth
>> > wrote:
>> >> I am seeing a new failure on x86_64-apple-da
On Mon, Jul 13, 2009 at 10:31 AM, Dave
Korn wrote:
> Richard Guenther wrote:
>> On Mon, Jul 13, 2009 at 5:39 AM, Jack Howarth
>> wrote:
>>> On Mon, Jul 13, 2009 at 01:52:51AM +0100, Dave Korn wrote:
>
>>>>> __complex__ long long f ()
>>>>
On Mon, Jul 13, 2009 at 2:29 PM, Hendershot, Travis
S wrote:
> Hello,
>
> I am trying to build a cross-compiler of gcc so that I can build an
> application for the Green Hills INTEGRITY RTOS. Has this been tested before
> on recent releases of gcc? Are there any binary files of the cross compi
On Tue, Jul 14, 2009 at 8:01 AM, Li Feng wrote:
> Hi,
>
> I'm now working on Graphite branch and need to know
> the alias set information for each data_reference_p, which
> would be an integer (or alias_set_type) stands for which
> alias set it is in.
>
> I tried to get the alias set information wi
On Tue, Jul 14, 2009 at 11:12 AM, Li Feng wrote:
> Hi Richard,
> On Tue, Jul 14, 2009 at 4:54 PM, Richard
> Guenther wrote:
>> On Tue, Jul 14, 2009 at 8:01 AM, Li Feng wrote:
>>> Hi,
>>>
>>> I'm now working on Graphite branch and need to know
>>
On Tue, Jul 14, 2009 at 5:14 PM, Sebastian Pop wrote:
> Hi Richi,
>
> On Tue, Jul 14, 2009 at 04:40, Richard
> Guenther wrote:
>> You misunderstood what alias-set numbers represent. Alias-set
>> numbers encode type-based alias information only - which in
>> your c
On Tue, Jul 14, 2009 at 6:08 PM, Sebastian Pop wrote:
> On Tue, Jul 14, 2009 at 11:03, Sebastian Pop wrote:
>>> Why do you need alias-set numbers?
>>
>> We want to represent the alias set information as an extra subscript
>> on memory accesses: for example,
>>
>> if we have A[10] and supposing that
On Wed, Jul 15, 2009 at 1:00 PM, Tobias
Grosser wrote:
> On Tue, 2009-07-14 at 23:34 +0200, Richard Guenther wrote:
>> On Tue, Jul 14, 2009 at 6:08 PM, Sebastian Pop wrote:
>> > On Tue, Jul 14, 2009 at 11:03, Sebastian Pop wrote:
>> >>> Why do you need alias-se
On Wed, Jul 15, 2009 at 9:15 PM, Tobias
Grosser wrote:
>> A note on Lis final graph algorithm. I don't understand why you want
>> to allow data-references to be part of multiple alias-sets? (Of course
>> I don't know how you are going to use the alias-sets ...)
>
> Just to pass more information t
On Wed, Jul 15, 2009 at 10:46 PM, Richard
Guenther wrote:
> On Wed, Jul 15, 2009 at 9:15 PM, Tobias
> Grosser wrote:
>>> A note on Lis final graph algorithm. I don't understand why you want
>>> to allow data-references to be part of multiple alias-sets? (Of course
On Thu, Jul 16, 2009 at 1:15 AM, Tobias
Grosser wrote:
> On Wed, 2009-07-15 at 22:48 +0200, Richard Guenther wrote:
>> On Wed, Jul 15, 2009 at 10:46 PM, Richard
>> Guenther wrote:
>> > On Wed, Jul 15, 2009 at 9:15 PM, Tobias
>> > Grosser wrote:
>> >>&g
On Thu, Jul 16, 2009 at 11:00 AM, Li Feng wrote:
> Hi Richard,
> On 7/16/09, Richard Guenther wrote:
>> On Thu, Jul 16, 2009 at 1:15 AM, Tobias
>> Grosser wrote:
>>> On Wed, 2009-07-15 at 22:48 +0200, Richard Guenther wrote:
>>>> On Wed, Jul 15, 2009 a
On Fri, Jul 17, 2009 at 11:08 AM, Dominique Dhumieres wrote:
> Since 4.4.1 is closed to be released, I have bootstrapped and regtested
> 4.4.1 in the 4_4 branch at revision 149690. It took ~2h30 to bootstrap
> and ~5+h to regtest (single thread) on my macbook. The typical times
> for trunk are betw
The C++ frontend drops qualifiers when performing pointer dereference:
void foo(int * __restrict p, int * __restrict__ q, int i)
{
*q = p[i];
}
;; Function void foo(int*, int*, int) (null)
;; enabled by -tree-original
<>>
>>;
while this isn't a big issue for the plain *q (the cast is stripp
On Sat, Jul 18, 2009 at 2:18 PM, dharmendra
pandit wrote:
> According to 6.3.2.1 Para 3, the type conversion from "array of type"
> to "pointer to type" should
> happen irrespective of whether the operand is on right had side or the
> left hand side of assignment
> operator. But GCC is converting o
On Sun, Jul 19, 2009 at 8:18 AM, Revital1 Eres wrote:
>
> Hello,
>
> The following snippet is from a f90 program which contains
> a loop that does not get vectorized.
>
> SUBROUTINE foo1(nx,ny,nz,arr2)
> USE globalvar_mod, ONLY : dyinv, xstart, xstop
>
> k=1
> do j=1,ny
> do i=1,nx
>
> arr1(i,j
On Sun, Jul 19, 2009 at 7:29 PM, Dave
Korn wrote:
>
> Hi team,
>
> I'd like to have some basic BZ perms if I may, so I can help out with
> cygwin/win32-related PRs. I'd like to be able to assign bugs to myself (at
> least ones that I created myself, depending how fine-grained it is), and
> per
On Tue, Jul 21, 2009 at 11:14 PM, Paolo Bonzini wrote:
> Gregory Casamento wrote:
>> As far as I'm aware apple has an assignment for changes to gcc, so it
>> should be possible to pull them in.
>
> You're not forced to assign changes that you do not want to assign.
I don't understand. Yes you are
On Sat, Jul 25, 2009 at 1:19 AM, Alexandre Oliva wrote:
> So... It's been a long journey, but I think I'm at a point in which,
> even though VTA is not completely finished, it's already enough of an
> improvement that it could go in, be useful and get wider testing.
>
> To the best of my knowledge
On Sat, Jul 25, 2009 at 1:28 PM, pms wrote:
>
> Hi Nathan
> I looked into tree.def, I added a case in the new gimple pass to count
> the number of integer variables in the c code. the following is the piece of
> code.
> Here, the first case is working, but I'm not getting the second one. can u
>
Status
==
The 4.3 branch is now frozen in preparation for the GCC 4.3.4 release.
I am creating a release candidate right now. All patches require
release-manager approval.
Quality Data
Priority # Change from Last Report
---
,
Richard
--
Richard Guenther
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex
On Wed, 29 Jul 2009, Dave Korn wrote:
> Richard Guenther wrote:
> > A release candidate for the GCC 4.3.4 is now available at
> >
> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.3.4-RC-20090727
> >
> > I plan to roll out the final release at the beginning of ne
On Fri, Jul 31, 2009 at 9:53 AM, Дмитрий Дьяченко wrote:
> Hello,
> current (gcc version 4.5.0 20090727 (experimental) [trunk revision
> 150136] (GCC))
>
> for code
>
> #include
>
> class a;
> class b;
>
> class c {
> public:
> b *p;
> bool isNull() const { return p == 0; }
> };
>
> cla
On Tue, Aug 4, 2009 at 4:25 AM, Andrew Pinski wrote:
> I was improving tree aliasing for pointers by adding support a+1 and a
> not aliasing. But I ran into a bug in the aliasing where:
> /* If both references are through the same type, they do not alias
> if the accesses do not overlap. Thi
Status
==
The 4.3.4 release has been created and the final bits of the release
process will be carried out soon.
The 4.3 branch is now open again for checkins under the usual release
branch rules (regression and documentation fixes only). A 4.3.5
release is expected shortly after the 4.4.2
On Wed, Aug 5, 2009 at 11:14 PM, ami_stuff wrote:
> Hi,
>
> Please someone change the status of these bug reports to be available in the
> search engine of bugtracker:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40819
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40977
?
You have to be more
On Wed, Aug 5, 2009 at 11:25 PM, ami_stuff wrote:
> Hi,
>
>> You have to be more specific on what you refer to with "search engine
>> of bugtracker".
>
> http://gcc.gnu.org/bugzilla/query.cgi
>
> Sorry, these bugs are available for search, but not with "m68k" keyword.
> Maybe this can be fixed.
ht
questions or comments about
this release. Instead, use the resources available from
http://gcc.gnu.org.
As always, a vast number of people contributed to this GCC release -- far
too many to thank individually!
--
Richard Guenther
Novell / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG
On Fri, Aug 7, 2009 at 1:50 PM, pms wrote:
>
> Hi,
> We've a problem here. we were trying to use cc1 with & without -O
> option to verify the optimizations happening in our sample code. these r the
> list of outputs after each compilation
> without -O
> p...@shiva:~/Desktop/Compilers/GCC/build/
On Fri, Aug 7, 2009 at 9:22 PM, Richard Henderson wrote:
> On 08/06/2009 12:35 PM, Richard Henderson wrote:
>>
>> { exc_ptr, filter } = EH_LANDING_PAD;
>>
>> Placeholder for the landing-pad rtl. Has 2 outputs
>> for both the exception pointer and the filter.
>
> I'm going to drop th
On Sat, Aug 8, 2009 at 11:59 PM, Sriraman Tallam wrote:
> Hi,
>
> Here is a patch to eliminate redundant zero-extension instructions
> on x86_64.
>
> Tested: Ran the gcc regresssion testsuite on x86_64-linux and verified
> that the results are the same with/without this patch.
The patch misses
On Mon, Aug 10, 2009 at 2:53 PM, Michael Matz wrote:
> Hi,
>
> On Fri, 7 Aug 2009, Richard Henderson wrote:
>
>> On 08/07/2009 12:31 PM, Richard Guenther wrote:
>> > > L.N:
>> > > exc_ptr.1 = EXC_PTR_EXPR (N);
>> > > filter.1 = FILTE
On Mon, Aug 10, 2009 at 3:21 PM, Michael Matz wrote:
> Hi,
>
> On Mon, 10 Aug 2009, Richard Guenther wrote:
>
>> >> No and no. They will eventually resolve to pseudos generated during
>> >> rtl eh expansion. But to avoid silliness at the gimple level I don
On Wed, Aug 12, 2009 at 2:03 AM, Pedro
Lamarão wrote:
> I've recently started my contributions to the gcc-in-cxx project, and
> eventually decided on the qsort suggestion because it seems the
> easiest one.
> I've made the change in three places in cp/classes.c; the patch can be
> found here:
>
>
On Thu, Aug 13, 2009 at 4:41 PM, Sebastian Pop wrote:
> Hi,
>
> On Thu, Aug 13, 2009 at 04:02, Eric Fisher wrote:
>> The error is reported in build2_stat, by
>>
>> gcc_assert (POINTER_TYPE_P (tt) && POINTER_TYPE_P (TREE_TYPE (arg0))
>> && INTEGRAL_TYPE_P (TREE_TYPE (arg1))
>>
On Mon, Aug 17, 2009 at 9:19 AM, Kenneth Hoste wrote:
>
> On Aug 16, 2009, at 18:02 , Martin Guy wrote:
>
>> Yes, GCC is bigger and slower and for several architectures generates
>> bigger, slower code with every release, though saying so won't make
>> you very popular on this list! :)
>>
>> One th
On Mon, Aug 17, 2009 at 2:38 AM, ami_stuff wrote:
> Hi,
>
> I found out that when I use "-fno-unswitch-loops" option, it have no effect -
> loops are unswitched anyway:
>
> -O3 -fno-unswitch-loops
>
> Because of that to avoid -funswitch-loops optimization I must use something
> like this:
>
> -O2
On Mon, 17 Aug 2009, Diego Novillo wrote:
> I am merging free_lang_data, which is an IPA pass that scrubs all
> types and symbols from any front end language information.
>
> After free_lang_data all types and symbols are in gimple form.
> This form is much leaner in terms of memory utilization a
On Tue, Aug 18, 2009 at 10:39 AM, Ned Gill wrote:
>
> I'm having a problem with code like the following on all 4.2.x versions of
> gcc (at least on intel and with my port):
>
> unsigned z = 1;
> unsigned *foo()
> {
> return &z;
> }
>
> int main(void)
> {
> z = 1;
> *foo() = 0;
> return
On Tue, Aug 18, 2009 at 11:32 AM, Ned Gill wrote:
> On Tue, 18 Aug 2009 10:14:37 +0100, Richard Guenther
> wrote:
>
>> It sounds like a bug in points-to analysis where it doesn't correctly
>> handle return values of pure/const functions. I would just
>> add a con
2009/8/19 Albert Cohen :
> When debugging graphite, we ran into code bloat issues due to
> pass_complete_unrolli being called very early in the non-ipa
> optimization sequence. Much later, the full-blown pass_complete_unroll
> is scheduled, and this one does not do any harm.
>
> Strangely, this ear
On Wed, Aug 19, 2009 at 2:07 PM, Richard
Guenther wrote:
> 2009/8/19 Albert Cohen :
>> When debugging graphite, we ran into code bloat issues due to
>> pass_complete_unrolli being called very early in the non-ipa
>> optimization sequence. Much later, the full-blown pass_
On Wed, Aug 19, 2009 at 3:54 PM, Albert Cohen wrote:
> Albert Cohen wrote:
>> Thanks a lot for the quick and detailed response.
>>
>> It is more difficult than I thought, then :-( We'll think more, and
>> maybe come up with yet another pass ordering proposal, but definitely
>> this tramp3d code des
On Wed, Aug 19, 2009 at 3:56 PM, Richard
Guenther wrote:
> On Wed, Aug 19, 2009 at 3:54 PM, Albert Cohen wrote:
>> Albert Cohen wrote:
>>> Thanks a lot for the quick and detailed response.
>>>
>>> It is more difficult than I thought, then :-( We'll t
On Thu, Aug 20, 2009 at 2:33 AM, Jeff Law wrote:
> On 08/19/09 17:46, Ian Lance Taylor wrote:
>>
>> My understanding is that that scenario is supposed to not happen because
>> update_equiv_regs is only supposed to equate a register and a memory
>> location in the specific cases where that is OK. I
On Thu, Aug 20, 2009 at 3:19 AM, Albert Cohen wrote:
> Richard Guenther wrote:
>>
>> gfortran.dg/reassoc_4.f, the hottest loop from calculix.
>
> Thanks.
>
> This example is slightly different. Graphite should be able to handle it
> with loop fusion rather than pr
On Thu, Aug 20, 2009 at 11:48 AM, Dominique Dhumieres wrote:
> IIRC another code that is "improved" by complete_unrolli is the polyhedron
> test induct.f90. However it gives worse results for some variants
> (see pr34265: induct_v2/3).
>
>> Can't we use graphite to re-roll loops? ...
>
> Is doing
On Thu, Aug 20, 2009 at 3:37 PM, Jeff Law wrote:
> On 08/20/09 02:45, Richard Guenther wrote:
>>
>> It looks indeed bogus. Do you have a testcase at hand?
>>
>
> Compile the attached testcase with -O3 -mopenmp on i686-pc-linux-gnu. Find
> MAIN__.omp_fn.2 in the
On Wed, Aug 26, 2009 at 12:50 PM, Ned Gill wrote:
>
> FWIW, I'm still looking at this on and off. I beleive the pure function was
> a red herring, as this example also does the wrong thing:
>
> extern int z;
>
> int foo(int *y)
> {
> z = 1;
> *y = 0;
> return z; // returns 1, even though
On Wed, Aug 26, 2009 at 10:47 PM, Peter Bergner wrote:
> On Mon, 2009-08-24 at 23:56 +, Charles J. Tabony wrote:
>> I am seeing a performance regression on the port I maintain, and I would
>> appreciate some pointers.
>>
>> When I compile the following code
>>
>> void f(int *x, int *y){
>> *
On Mon, Aug 31, 2009 at 6:07 PM, Richard Henderson wrote:
> On 08/31/2009 08:26 AM, Pedro Lamarão wrote:
>>
>> I'll try to include cstdlib in system.h to see if that's enough.
>
> Note the existing
>
> #ifdef HAVE_STDLIB_H
> # include
> #endif
>
> You may wish to convert this to
>
> #ifdef __cplus
On Tue, Sep 1, 2009 at 10:55 PM, Toon Moene wrote:
> Diego Novillo wrote:
>
>> On Tue, Sep 1, 2009 at 11:42, Ryan Mansfield wrote:
>
>>> Is it required that the same compiler that generated lto objects be used
>>> to
>>> read them? I've come across a couple ICEs with the current revision
>>> readin
601 - 700 of 2444 matches
Mail list logo
