Hi,
I had a big piece of code that ran smoothly on gcc 3.2.2. For some reason,
I had to start using that code on a machine with GCC 4.2.1. Now, it would throw
segmentation faults (invalid free pointer etc) and abort the program. I presume
this happens because the glibc with gcc 4.2.1 is sm
On 09/29/2010 08:07 AM, #SINHA SHARAD# wrote:
> Hi,
>
> I had a big piece of code that ran smoothly on gcc 3.2.2. For
> some reason, I had to start using that code on a machine with GCC
> 4.2.1. Now, it would throw segmentation faults (invalid free pointer
> etc) and abort the program. I pres
On 28/09/2010 22:24, Frédéric Buclin wrote:
> Le 28. 09. 10 11:25, Dave Korn a écrit :
>> I'm no longer
>> receiving my nightly emails that the whine is supposed to be sending me.
>
> This should be fixed now. Let me know if you still don't get nightly emails.
>
> Frédéric
Working fine now, th
On 29 September 2010 10:29, Andrew Haley wrote:
> On 09/29/2010 08:07 AM, #SINHA SHARAD# wrote:
>> Hi,
>>
>> I had a big piece of code that ran smoothly on gcc 3.2.2. For
>> some reason, I had to start using that code on a machine with GCC
>> 4.2.1. Now, it would throw segmentation faults (inv
Hello,
I have been examining a significant performance regression
between 4.5 and 4.4 in our port. I found that Partial Redundancy
Elimination introduced in 4.5 causes the issue. The following
pseudo code explains the problem:
BB 3:
r118 <- r114 + 2
BB 4:
R114 <- r114 + 2
...
Conditional jum
On Wed, Sep 29, 2010 at 2:16 PM, Bingfeng Mei wrote:
> Hello,
> I have been examining a significant performance regression
> between 4.5 and 4.4 in our port. I found that Partial Redundancy
> Elimination introduced in 4.5 causes the issue. The following
> pseudo code explains the problem:
>
> BB 3
Richard,
Here is the test code.
typedef short int16_t;
typedef unsigned short uint16_t;
void MemSet16(
int16_t *pBuf, /* Buffer address */
int16_t Val,/* Value to be set */
uint16_tBytes /* Total size in bytes */
The optimization does look bad -- splitting backedge to allow
expression hoisting rarely removes any redundancy -- unless the loop
is really short trip counted. Besides it introduces extra copy, jump
instruction and increases register pressure.
David
On Wed, Sep 29, 2010 at 5:55 AM, Bingfeng Mei
Thanks Joseph
Is it confirmed that this is the opinion of the C++ FE maintainers as well ?
Can we get that clarified ? Do they want to review Objective-C++ patches ?
(I'm still personally of the opinion the Objective-C++ maintainer should
approve Objective-C++
patches, but Mike tells me he's b
The test program in target-supports.exp is broken, since
it doesn't preclude the use of cleanups instead. Indeed,
the init/cleanup3.C seems to be essentially identical to
the target-supports test.
Any suggestions that doesn't essentially reverse this
situation? I.e. I could switch the target-sup
On 29 September 2010 08:07, #SINHA SHARAD# wrote:
> Hi,
>
> I presume this happens because the glibc with gcc 4.2.1 is smarter than the
> one with gcc 3.2.2. Hence, what was missed during execution with 3.2.2 was
> caught in 4.2.1
N.B. glibc does not come with GCC, you can generally use a new
Hi --
I'm working with a processor which sets the condition
bits when a NaN is used as an operand in a compare
in a way which is the same as a valid ordered compare.
There is a flag bit which is set for a NaN compare,
but it may also be set in a non-NaN compare.
float a = 1.0, b = 2.0, x = NaN;
On 09/29/2010 04:31 PM, Michael Eager wrote:
> float a = 1.0, b = 2.0, x = NaN;
> (a < b) generates the same condition flags as (a < x).
...
> Are there other processors which do this? How do they
> handle generating IEEE std compliant code?
It looks like there is a bunch of code under config
tha
13 matches
Mail list logo
