On 9 February 2011 06:20, Tony Poppleton wrote:
>
> Out of interest, has their been much communication in the past between
> GCC and Phoronix to address any of these issues in their previous
> benchmarks?
I signed up to their forum to point out that snapshots have additional
checking turned on by
Hello All,
I am trying to understand rtl generation. For the following testcase
I have dumped the rtl... (version: gcc-4.3.3, target: AVR32 not
upstreamed yet)
int main() {
volatile int a, b;
if(a>b) return 1;
else return 2;
}
Expand pass shows that "le"operator is c
On Wed, Feb 9, 2011 at 00:20, Tony Poppleton wrote:
>> While I appreciate Phoronix as a booster site, their benchmarking
>> practice often seems very dodgy; I'd take the results with a large grain
>> of salt
>
> The main reason I posted the link in the first place was because it
> was reflecti
On 9 February 2011 08:34, Sebastian Pop wrote:
>
> For example x264 defines CFLAGS="-O4 -ffast-math $CFLAGS", and so
> building this benchmark with CFLAGS="-O2" would have no effect.
Why not?
Ignoring the fact -O3 is the highest level for GCC, the manual says:
"If you use multiple -O options, wit
On Wed, Feb 09, 2011 at 08:42:05AM +, Jonathan Wakely wrote:
> On 9 February 2011 08:34, Sebastian Pop wrote:
> >
> > For example x264 defines CFLAGS="-O4 -ffast-math $CFLAGS", and so
> > building this benchmark with CFLAGS="-O2" would have no effect.
>
> Why not?
>
> Ignoring the fact -O3 is
On Wed, Feb 9, 2011 at 7:20 AM, Tony Poppleton wrote:
>> While I appreciate Phoronix as a booster site, their benchmarking
>> practice often seems very dodgy; I'd take the results with a large grain
>> of salt
>
> The main reason I posted the link in the first place was because it
> was reflec
On 08/02/2011 16:08, Dave Korn wrote:
> Sorry all, been offline for a couple of days after my pc blew up.
>
> On 07/02/2011 20:50, Angelo Graziosi wrote:
>
>> I do not understand the logic here: break GCC trunk for something that
>> hasn't been yet released.
>
> But GCC trunk has not been re
Hello Pierre!
It is an interesting plugin. I'll keep an eye on your repository.
Thanks!
Daniel Marjamäki
2011/2/9 Pierre Vittet :
> Hello,
>
> I would like to present you a small plugin, which could be a good exemple of
> a MELT use case.
> This plugin allows to monitor that after every call to
Hi,
I am facing a problem with code hoisting from a loop in our backend.
This problem seems to be hinted at on:
-fbranch-target-load-optimize
Perform branch target register load optimization before prologue /
epilogue threading. The use of target registers can typically be exposed
only dur
At
http://gcc.gnu.org/onlinedocs/libstdc++/manual/streambufs.html
Under section 'Buffering', Particularly is written as 'Chaptericularly'.
Regards
Hi Everyone,
I've been following the thread already from the start (I'm on the list).
Matthew Tippett (CC'ed now as well) and I have already been working on
some ways to help further and one of us should have some more
information to be presented shortly. If any of you have any other
question
On 02/09/2011 01:44 PM, Anonymous bin Ich wrote:
> At
>
> http://gcc.gnu.org/onlinedocs/libstdc++/manual/streambufs.html
>
> Under section 'Buffering', Particularly is written as 'Chaptericularly'.
Fixed in SVN. Thanks.
Paolo.
Anitha Boyapati writes:
> int main() {
> volatile int a, b;
> if(a>b) return 1;
> else return 2;
>
> }
>
> Expand pass shows that "le"operator is chosen.
>
> (jump_insn 9 8 10 3 gt_int.c:4 (set (pc)
> (if_then_else (le:CC (cc0)
> (const_int 0 [0x0
"Paulo J. Matos" writes:
> But then this is combined by cse into:
>
> (set (mem/s:QI (reg:QI 41)) (const_int 0))
>
> and bammm, same problem. No loop hoisting. What's the best way to
> handle this? Any suggestions?
You need to set TARGET_RTX_COSTS to indicate that this operation is
relatively ex
On 09/02/11 15:07, Ian Lance Taylor wrote:
You need to set TARGET_RTX_COSTS to indicate that this operation is
relatively expensive. That should stop combine from generating it.
Thanks, I will give it a try. One of the things that are not as polished
as it should is exactly the rtx costs. I
"Paulo J. Matos" writes:
> It is slightly confusing for me the way it works. I have added a debug
> printf in it so I can debug the costs and when they are called and I
> get a list like this:
>
> == RTXCOST[pass]: outer_code rtx => cost rec/done==
>
> And it starts with:
> == RTXCOST[]: UnKnown
Cf. http://gcc.gnu.org/ml/gcc/2011-02/msg00109.html and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47032
Seems as if one needs to add link-time tests to libgfortran for some of
the C99 functions - the compile checks exists and succeed.
Tobias
Original Message
Subject: AIX
On 9 February 2011 20:34, Ian Lance Taylor wrote:
>> I would like to know what prompts gcc to decide if "le" can be used in
>> the expand pass rather than "gt" operator. Or more precisely why it
>> differs incase of float.
>
> The choice of LE when using int is just a happenstance of the way that
On Wed, Feb 9, 2011 at 5:55 PM, Anitha Boyapati
wrote:
> On 9 February 2011 20:34, Ian Lance Taylor wrote:
>
>>> I would like to know what prompts gcc to decide if "le" can be used in
>>> the expand pass rather than "gt" operator. Or more precisely why it
>>> differs incase of float.
>>
>> The ch
On 9 February 2011 22:28, Richard Guenther wrote:
> On Wed, Feb 9, 2011 at 5:55 PM, Anitha Boyapati
> wrote:
>> On 9 February 2011 20:34, Ian Lance Taylor wrote:
>>
I would like to know what prompts gcc to decide if "le" can be used in
the expand pass rather than "gt" operator. Or more
This testcase is ill-formed (and breaks in C++0x mode), because it
declares puts to have the wrong return type. I note that changing it to
have the right return type causes it to no longer be inlined. What do
you suggest we do about this?
Jason
On Wed, Feb 9, 2011 at 11:39 PM, Jason Merrill wrote:
> This testcase is ill-formed (and breaks in C++0x mode), because it declares
> puts to have the wrong return type. I note that changing it to have the
> right return type causes it to no longer be inlined. What do you suggest we
> do about t
Hello.
The file gcc/config/m68k/math-68881.h is distributed with GCC. It is about
inlining the libm functions using FPU instructions on m68k targets.
But -ffast-math seems to serve the same purpose, even better.
My question: Is math-68881.h still useful for some purpose ?
BTW: That file does
On Wed, Feb 9, 2011 at 2:42 AM, Jonathan Wakely wrote:
> On 9 February 2011 08:34, Sebastian Pop wrote:
>>
>> For example x264 defines CFLAGS="-O4 -ffast-math $CFLAGS", and so
>> building this benchmark with CFLAGS="-O2" would have no effect.
>
> Why not?
>
> Ignoring the fact -O3 is the highest l
Hi all,
I am trying to port a private target in GCC 4.5.1. Following are the
properties of the target
#define BITS_PER_UNIT 32
#define BITS_PER_WORD32
#define UNITS_PER_WORD 1
#define CHAR_TYPE_SIZE32
#define SHORT_TYPE_SIZE 32
#define INT_TYPE_SIZE
25 matches
Mail list logo
