* Nikolaus Dunn:
> I've run into an issue where turning on compiler optimization using
> -O1 or higher causes an issue in my program. Specifically, I am
> replacing the new and delete operators globally to perform some real
> time allocation tracking. When I compile with -O1 or -O2, my
> implement
Hi guys,
I've run into an issue where turning on compiler optimization using -O1
or higher causes an issue in my program. Specifically, I am replacing
the new and delete operators globally to perform some real time
allocation tracking. When I compile with -O1 or -O2, my implementation
of new
Am Thu, 21 May 2015 07:45:19 -0500
schrieb mark maule :
>
>
> On 5/20/2015 2:13 PM, Martin Uecker wrote:
> > mark maule :
> >> On 5/20/2015 3:27 AM, Richard Biener wrote:
> >>> On Mon, May 18, 2015 at 10:01 PM, mark maule
> >>> wrote:
> >>> The usual issue with this kind of behavior is out-o
On 5/20/2015 2:13 PM, Martin Uecker wrote:
mark maule :
On 5/20/2015 3:27 AM, Richard Biener wrote:
On Mon, May 18, 2015 at 10:01 PM, mark maule wrote:
The usual issue with this kind of behavior is out-of-bound accesses of
arrays in a loop
or invoking undefined behavior when signed integer
mark maule :
> On 5/20/2015 3:27 AM, Richard Biener wrote:
> > On Mon, May 18, 2015 at 10:01 PM, mark maule wrote:
> > The usual issue with this kind of behavior is out-of-bound accesses of
> > arrays in a loop
> > or invoking undefined behavior when signed integer operations wrap.
> >
> >
> >
On 05/20/2015 01:04 PM, mark maule wrote:
> Is this one of those areas where if
> there's a bug in the code all bets are off and your mileage may vary?
Yes. Do not access beyond the end of an array: daemons may fly out
of your nose. [1]
Andrew.
[1]
https://groups.google.com/forum/?hl=en#!msg/
On 5/20/2015 3:27 AM, Richard Biener wrote:
On Mon, May 18, 2015 at 10:01 PM, mark maule wrote:
I have a loop which hangs when compiled with -O2, but runs fine when
compiled with -O1. Not sure what information is required to get an answer,
so starting with the full src code. I have not atte
On Mon, May 18, 2015 at 10:01 PM, mark maule wrote:
> I have a loop which hangs when compiled with -O2, but runs fine when
> compiled with -O1. Not sure what information is required to get an answer,
> so starting with the full src code. I have not attempted to reduce to a
> simpler test case ye
On 5/19/2015 10:28 AM, Andrew Haley wrote:
On 05/19/2015 04:14 PM, mark maule wrote:
Thanks again Martin. I started going down that road yesterday, and got
lost in the forest of options. What I was looking for was some option
that would tell me what was being done with dgHandle specifically
On 05/19/2015 04:14 PM, mark maule wrote:
> Thanks again Martin. I started going down that road yesterday, and got
> lost in the forest of options. What I was looking for was some option
> that would tell me what was being done with dgHandle specifically. I
> played around with -fopt-info-al
On 5/19/2015 10:09 AM, Martin Sebor wrote:
I'm not very familiar with the optimizations that are done in O2 vs O1,
or even what happens in these optimizations.
So, I'm wondering if this is a bug, or a subtle valid optimization that
I don't understand. Any help would be appreciated.
Another
I'm not very familiar with the optimizations that are done in O2 vs O1,
or even what happens in these optimizations.
So, I'm wondering if this is a bug, or a subtle valid optimization that
I don't understand. Any help would be appreciated.
Another approach to debugging a suspected optimization
On 19/05/15 12:58, mark maule wrote:
> Thank you for taking a look Martin. I will attempt to pare this down,
> provide a sample with typedefs/macros expanded, etc. and repost to
> gcc-help. To address a couple of your points:
If you haven’t already, you can have a look at
https://gcc.gnu.org/
Thank you for taking a look Martin. I will attempt to pare this down,
provide a sample with typedefs/macros expanded, etc. and repost to
gcc-help. To address a couple of your points:
This code does work when compiled -O2 with 4.4.6 (failing is 4.8.3). It
also works on 4.8.3 when dgHandle is
On 05/18/2015 02:01 PM, mark maule wrote:
I have a loop which hangs when compiled with -O2, but runs fine when
compiled with -O1. Not sure what information is required to get an
answer, so starting with the full src code. I have not attempted to
reduce to a simpler test case yet.
Typically a
On Fri, Oct 10, 2014 at 3:27 PM, Vincent Lefevre wrote:
> On 2014-10-10 11:07:52 +0200, Jakub Jelinek wrote:
>> Though, is such optimization desirable even for fast-math?
>
> I wonder whether fast-math has a well-defined spec, but it should be
> noted that because of possible cancellations, even i
On 2014-10-10 11:07:52 +0200, Jakub Jelinek wrote:
> Though, is such optimization desirable even for fast-math?
I wonder whether fast-math has a well-defined spec, but it should be
noted that because of possible cancellations, even if the final result
is a float, it may be better to keep intermedi
On Thu, Oct 09, 2014 at 03:55:34PM -0700, Steve Ellcey wrote:
> On Thu, 2014-10-09 at 19:50 +, Joseph S. Myers wrote:
> > On Thu, 9 Oct 2014, Steve Ellcey wrote:
> >
> > > Do you know which pass does the simple
> > > '(float)function((double)float_val)' demotion? Maybe that would be a
> > > g
On Fri, Oct 10, 2014 at 12:55 AM, Steve Ellcey wrote:
> On Thu, 2014-10-09 at 19:50 +, Joseph S. Myers wrote:
>> On Thu, 9 Oct 2014, Steve Ellcey wrote:
>>
>> > Do you know which pass does the simple
>> > '(float)function((double)float_val)' demotion? Maybe that would be a
>> > good place to
On Thu, 2014-10-09 at 19:50 +, Joseph S. Myers wrote:
> On Thu, 9 Oct 2014, Steve Ellcey wrote:
>
> > Do you know which pass does the simple
> > '(float)function((double)float_val)' demotion? Maybe that would be a
> > good place to extend things.
>
> convert.c does such transformations. May
On Thu, 9 Oct 2014, Steve Ellcey wrote:
> Do you know which pass does the simple
> '(float)function((double)float_val)' demotion? Maybe that would be a
> good place to extend things.
convert.c does such transformations. Maybe the transformations in there
could move to the match-and-simplify in
On October 9, 2014 8:40:49 PM CEST, Andrew Pinski wrote:
>On Thu, Oct 9, 2014 at 11:32 AM, Steve Ellcey wrote:
>> On Thu, 2014-10-09 at 11:27 -0700, Andrew Pinski wrote:
>>
>>> > Is there a reason why GCC couldn't (under -ffast-math) call the
>single
>>> > precision routines for the first case?
>
On Thu, Oct 9, 2014 at 11:32 AM, Steve Ellcey wrote:
> On Thu, 2014-10-09 at 11:27 -0700, Andrew Pinski wrote:
>
>> > Is there a reason why GCC couldn't (under -ffast-math) call the single
>> > precision routines for the first case?
>>
>> There is no reason why it could not. The reason why it doe
On Thu, 2014-10-09 at 11:27 -0700, Andrew Pinski wrote:
> > Is there a reason why GCC couldn't (under -ffast-math) call the single
> > precision routines for the first case?
>
> There is no reason why it could not. The reason why it does not
> currently is because there is no pass which does the
On Thu, Oct 9, 2014 at 11:23 AM, Steve Ellcey wrote:
> I have a -ffast-math (missing?) optimization question. I noticed on MIPS
> that if I compiled:
>
> #include
> extern x;
> void foo() { x = sin(log(x)); }
>
> GCC will extend 'x' to
I have a -ffast-math (missing?) optimization question. I noticed on MIPS
that if I compiled:
#include
extern x;
void foo() { x = sin(log(x)); }
GCC will extend 'x' to double precision, call the double precision log and sin
functions and then truncate the
On Thu, 2013-06-20 at 03:16 -0700, Stephen Clarke wrote:
> > why (and where) did ivopts decide to move the post-increments above the
> > usages in the first loop?
>
> It looks rather like the transformation described next to
> tree-ssa-loop-ivopts.c/adjust_iv_update_pos.
Yes, that looks like th
> why (and where) did ivopts decide to move the post-increments above the
> usages in the first loop?
It looks rather like the transformation described next to
tree-ssa-loop-ivopts.c/adjust_iv_update_pos.
2013/6/18 Steve Ellcey :
> On Mon, 2013-06-17 at 21:36 +0200, Oleg Endo wrote:
>
>>
>> Sorry for not having an answer. I got curious, because just yesterday I
>> was looking at this one
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190
>> and thought that this is related, although it doesn't se
On Mon, 2013-06-17 at 21:36 +0200, Oleg Endo wrote:
>
> Sorry for not having an answer. I got curious, because just yesterday I
> was looking at this one
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55190
> and thought that this is related, although it doesn't seem to.
> I've tried the two func
On Mon, 2013-06-17 at 10:07 -0700, Steve Ellcey wrote:
> I have a loop induction variable question involving post increment.
> If I have this loop:
>
> [...]
> My question is is: why (and where) did ivopts decide to move the
> post-increments above the usages in the first loop? In my case
> (MIP
I have a loop induction variable question involving post increment.
If I have this loop:
void *memcpy_word_ptr(int * __restrict d, int * __restrict s, unsigned int n )
{
int i;
for(i=0; i:
# d_22 = PHI
# s_23 = PHI
# i_24 = PHI
d_10 = d_22 + 4;
s_11 = s_23 + 4;
_12 = *s_23;
*
>
void foo<0>(int id, DecodeContext& dc) {}
int main(){
DecodeContext& dc= *(DecodeContext*)0;// junk for now
int id=std::rand(); // runtime dependent
foo<50>(id,dc);
return 0;
}
-Original Message-
From: Piotr Rak [mailto:piotr@gma
On 07/28/10 10:26, Richard Guenther wrote:
[snip]
You can use the flatten attribute to tell the compiler to inline all
calls in a given function, like
void __attribute__((flatten)) foo(void)
{
...
decode1();
...
}
and it will inline decode1() (and recursively all its callees).
[snip]
Will th
On 07/28/10 13:16, Piotr Rak wrote:
[snip]
Or you could just initialize static array of pointers, like that
(please note, that I never compiled code below):
[snip]
Piotr, something similar was proposed here:
http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/364c0dd5
Hi,
2010/7/28 Hite, Christopher :
>> Generally without knowing the compiler version you are using
>> it is hard to tell.
> I'll use whatever's best. Right now I'm still on 4.4.3. I'll probably
> upgrade soon to 4.5.
>
>> The same is true without a complete compilable testcase.
> I didn't want to
On 07/28/10 10:53, Hite, Christopher wrote:
[snip]
struct DecodeContext;
struct M1{
static const int id=1;
static void decode(DecodeContext& ){}
};
struct M2{
static const int id=2;
static void decode(DecodeContext& ){}
};
struct M3{
static const int id=
> Generally without knowing the compiler version you are using
> it is hard to tell.
I'll use whatever's best. Right now I'm still on 4.4.3. I'll probably
upgrade soon to 4.5.
> The same is true without a complete compilable testcase.
I didn't want to make a test case that depends on boost::mp
On 07/28/10 09:37, Hite, Christopher wrote:
[snip]
I'm tring to use the template compiler to generate equivalent code. I
have a mpl::list of packet descriptions like this:
struct Packet1{
static const int id=1;
void decode();
};
I then use boost::
On Wed, Jul 28, 2010 at 4:37 PM, Hite, Christopher
wrote:
>
>
>
> I'm writing a decoder using a meta programming techniques alla
> boost::mpl and I'd like to know if I'm asking too much of the compiler.
>
> Basically I've got lots of packet types with different ids. The
> classical way to write t
I'm writing a decoder using a meta programming techniques alla
boost::mpl and I'd like to know if I'm asking too much of the compiler.
Basically I've got lots of packet types with different ids. The
classical way to write these would be a switch case
int id;
switch(id){
On Tue, May 19, 2009 at 2:02 AM, Daniel Berlin wrote:
> On Sat, May 16, 2009 at 5:49 AM, Richard Guenther
> wrote:
>> On Sat, May 16, 2009 at 11:41 AM, VandeVondele Joost
>> wrote:
>>>
>> I think it is useful to have a bugzilla here.
>
> will do.
>>>
>>> http://gcc.gnu.org/bugzilla/
On Sat, May 16, 2009 at 5:49 AM, Richard Guenther
wrote:
> On Sat, May 16, 2009 at 11:41 AM, VandeVondele Joost
> wrote:
>>
> I think it is useful to have a bugzilla here.
will do.
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
>>
>>>
>>> Btw, complete unrolling is also hi
On Sat, May 16, 2009 at 11:41 AM, VandeVondele Joost wrote:
>
I think it is useful to have a bugzilla here.
>>>
>>> will do.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
>
>>
>> Btw, complete unrolling is also hindred by the artificial limit of
>> maximally
>> unrolling 16 iterations
I think it is useful to have a bugzilla here.
will do.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40168
Btw, complete unrolling is also hindred by the artificial limit of maximally
unrolling 16 iterations. Your inner loops iterate 27 times. Also by the
artificial limit of the maximal u
On Sat, May 16, 2009 at 11:29 AM, VandeVondele Joost wrote:
>
>
> thanks for the info
>
>> I think it is useful to have a bugzilla here.
>
> will do.
Btw, complete unrolling is also hindred by the artificial limit of maximally
unrolling 16 iterations. Your inner loops iterate 27 times. Also by
thanks for the info
I think it is useful to have a bugzilla here.
will do.
I tested 4.4, what did you test?
4.3 4.4 4.5
Joost
On Sat, May 16, 2009 at 10:28 AM, VandeVondele Joost wrote:
> the attached code (see contract__sparse) is a kernel which I hope gets
> optimized well. Unfortunately, compiling (on opteron or core2) it as
>
> gfortran -O3 -march=native -ffast-math -funroll-loops -ffree-line-length-200
> test.f
the attached code (see contract__sparse) is a kernel which I hope gets
optimized well. Unfortunately, compiling (on opteron or core2) it as
gfortran -O3 -march=native -ffast-math -funroll-loops
-ffree-line-length-200 test.f90
./a.out
Sparse: time[s] 0.66804099
New: time[s] 0.2080
Dave Korn wrote:
> Andrew Haley wrote:
>> Dave Korn wrote:
>
>>> So, this is a real bug then - but it's a missed optimisation in the first
>>> case, not a bogus one in the second case?
>> Probably, but it's not a very interesting one. For what it's worth, the
>> tree dumps are identical right u
Andrew Haley wrote:
> Dave Korn wrote:
>> So, this is a real bug then - but it's a missed optimisation in the first
>> case, not a bogus one in the second case?
>
> Probably, but it's not a very interesting one. For what it's worth, the
> tree dumps are identical right up to the very last tree
Dave Korn wrote:
> Andrew Haley wrote:
>> eCos@ wrote:
>
>>> ===
>>> int *p;
>>>
>>> int main(void)
>>> {
>>> p++;
>>> __asm__ __volatile__ (""::);
>>> p++;
>>> }
>>> ===
>
>>> assembly
On Thu, May 7, 2009 at 3:05 PM, Andrew Haley wrote:
> Dave Korn wrote:
>> Andrew Haley wrote:
>>> eCos@ wrote:
>>
===
int *p;
int main(void)
{
p++;
__asm__ __volatile__ (""::);
p++;
}
>
Dave Korn wrote:
> Andrew Haley wrote:
>> eCos@ wrote:
>
>>> ===
>>> int *p;
>>>
>>> int main(void)
>>> {
>>> p++;
>>> __asm__ __volatile__ (""::);
>>> p++;
>>> }
>>> ===
>
>>> assembly
Andrew Haley wrote:
> eCos@ wrote:
>> ===
>> int *p;
>>
>> int main(void)
>> {
>> p++;
>> __asm__ __volatile__ (""::);
>> p++;
>> }
>> ===
>> assembly code is like:
>> 'addl $4, %eax'
e...@sunnorth.com.cn wrote:
> Here is an optimization question about gcc compiler, we wonder whether it
> is a bug or not.
>
> A simple test program here:
> ===
> int *p;
>
> int main(void)
> {
> p++;
Hi
Here is an optimization question about gcc compiler, we wonder whether it
is a bug or not.
A simple test program here:
===
int *p;
int main(void)
{
p++;
__asm__ __volatile__ (""::);
El Mon, Jan 29, 2007 at 02:28:34PM -0500, Daniel Berlin ens deleit� amb les
seg�ents paraules:
> On 1/29/07, Razya Ladelsky <[EMAIL PROTECTED]> wrote:
>> Razya Ladelsky/Haifa/IBM wrote on 29/01/2007 13:46:33:
>>
>>> Hi,
>>>
>>> Does gcc apply inter-procedural optimizations across functions call
On 1/29/07, Razya Ladelsky <[EMAIL PROTECTED]> wrote:
Razya Ladelsky/Haifa/IBM wrote on 29/01/2007 13:46:33:
> Hi,
>
> Does gcc apply inter-procedural optimizations across functions called
using
> a function pointer? I guess that gcc performs conservatively assuming
that
> the pointer could poin
Razya Ladelsky/Haifa/IBM wrote on 29/01/2007 13:46:33:
> Hi,
>
> Does gcc apply inter-procedural optimizations across functions called
using
> a function pointer? I guess that gcc performs conservatively assuming
that
> the pointer could point everywhere because the pointer is a declared as
Hi,
Does gcc apply inter-procedural optimizations across functions called using
a function pointer? I guess that gcc performs conservatively assuming that
the pointer could point everywhere because the pointer is a declared as a
global variable and could be changed in any place. Is it true?
In
On Mon, 2005-12-26 at 21:41, Ivan Petrov wrote:
> I have one question. So... have small sample programm.
>
> [code]
> int bar( int );
>
> int foo( int a, int b )
> {
>return bar( a + b );
> }
> [/code]
>
> If I compille it with out -thumb parameter, i have very clean code.
>
> add r0, r1
I have one question. So... have small sample programm.
[code]
int bar( int );
int foo( int a, int b )
{
return bar( a + b );
}
[/code]
If I compille it with out -thumb parameter, i have very clean code.
add r0, r1, r0
bx lr
But with -thumb parameter have unopimized code.
add r1, r1, r0
mov
63 matches
Mail list logo
