On Wed, May 9, 2012 at 1:24 AM, Gabriel Dos Reis
wrote:
> On Tue, May 8, 2012 at 5:14 PM, DJ Delorie wrote:
>>
>> I assume this is a size_t vs int type problem, but the diagnostic
>> points to the function declaration, not to an actual binary
>> expression, and I can't figure out what it's compla
07/05/2012 17:53, Aurelien Buhrig :
>
> I have another issue in DCE pass after changing word_mode from SImode to
> HImode.
> (insn 98 97 99 2 (set (subreg:HI (reg:SI 106) 0) (reg:HI 104))
> (insn 99 98 100 2 (set (subreg:HI (reg:SI 106) 2) (reg:HI 105 [+2 ]))
> (insn 100 99 47 2 (set (reg:SI 8 a1
On Wed, 9 May 2012, Richard Guenther wrote:
On Wed, May 9, 2012 at 1:24 AM, Gabriel Dos Reis
wrote:
On Tue, May 8, 2012 at 5:14 PM, DJ Delorie wrote:
I assume this is a size_t vs int type problem, but the diagnostic
points to the function declaration, not to an actual binary
expression, and
On Wed, May 9, 2012 at 3:27 AM, Richard Guenther
wrote:
> On Wed, May 9, 2012 at 1:24 AM, Gabriel Dos Reis
> wrote:
>> On Tue, May 8, 2012 at 5:14 PM, DJ Delorie wrote:
>>>
>>> I assume this is a size_t vs int type problem, but the diagnostic
>>> points to the function declaration, not to an act
On Wed, May 9, 2012 at 3:41 AM, Marc Glisse wrote:
> On Wed, 9 May 2012, Richard Guenther wrote:
>
>> On Wed, May 9, 2012 at 1:24 AM, Gabriel Dos Reis
>> wrote:
>>>
>>> On Tue, May 8, 2012 at 5:14 PM, DJ Delorie wrote:
I assume this is a size_t vs int type problem, but the diagnos
On Wed, 9 May 2012, Gabriel Dos Reis wrote:
On Wed, May 9, 2012 at 3:41 AM, Marc Glisse wrote:
necessary because of platforms where size_t is unsigned short (I didn't know
those existed...)
Well, I suspect AVR might be such platform but I do not seem to have an
ABI document for AVR yet... (h
> I have another issue in DCE pass after changing word_mode from SImode to
> HImode.
> Indeed, in subreg1 pass, SI moves such as
> ...
> (insn 42 41 43 (set (reg:SI 85) (reg/f:SI 83))
> (insn 46 45 47 (set (reg:SI 8 a1) (reg:SI 85))
>
> are split into HImode word moves:
> ...
> (insn 98 97 99 2 (se
On 08/05/12 21:57, Jan Hubicka wrote:
In expanded form it is
(set (reg5) (const 10))
(parallel [(set (reg2) (const 0))
(set (reg0) (plus (reg3) (reg5)))
(set (reg1) (plus (reg4) (reg5)))
(set (mem (reg3)) (mem (reg4)))])
(set (reg0) (plus (reg0) (cons
On May 9, 2012, at 5:34 AM, Paulo J. Matos wrote:
> On 08/05/12 21:57, Jan Hubicka wrote:
>>
>> In expanded form it is
>>
>> (set (reg5) (const 10))
>>
>> (parallel [(set (reg2) (const 0))
>>(set (reg0) (plus (reg3) (reg5)))
>>(set (reg1) (plus (reg4) (reg5)))
>>
On 09/05/12 11:53, paul_kon...@dell.com wrote:
He was showing the RTL expansion of the example he gave:
Ah, right. I interpreted it as if it was what the movmem expanded to.
--
PMatos
Steven Bosscher wrote:
> On Tue, May 8, 2012 at 1:56 PM, Ulrich Weigand wrote:
> > Steven Bosscher wrote:
> >
> >> 2. HP-UX 10 is also the last target that only supports SJLJ exceptions.
> >
> > Hmm, SPU also supports only SJLJ exceptions ...
>
> Then why is force_sjlj_exceptions not set for it?
Andrew Pinski wrote:
> On Tue, May 8, 2012 at 4:56 AM, Ulrich Weigand wrote:
> > Hmm, SPU also supports only SJLJ exceptions ...
>
> IIRC the main reason is because SJLJ exceptions produced smaller
> binary size. Though I wonder if this should not be looked at again to
> see if dwarf2 eh_frame p
Hi,
While debugging an issue related to my movmem rule, I noticed that
fwprop seems to be doing some really strange.
The problem occurs when setting the argument to the block copy
instruction. The full C code is:
int **
t25 (int *d, int **s)
{
memcpy (d, *s, 16);
return s;
}
Before fwpr
09/05/2012 11:16, Eric Botcazou:
>> I have another issue in DCE pass after changing word_mode from SImode to
>> HImode.
>> Indeed, in subreg1 pass, SI moves such as
>> ...
>> (insn 42 41 43 (set (reg:SI 85) (reg/f:SI 83))
>> (insn 46 45 47 (set (reg:SI 8 a1) (reg:SI 85))
>>
>> are split into HImode
Daniel Marschall writes:
> As I was optimizing my program, I found a few things which looked odd
> to me in the assembler code.
Thanks. It's often best to report missed optimizations at
http://gcc.gnu.org/bugzilla/ . They will tend to be forgotten on the
mailing list.
> I am on an AMD x64_32
Forget about this question. Doesn't make sense at all.
I wonder if the thing I drank during lunch was really water...
On 09/05/12 14:40, Paulo J. Matos wrote:
Hi,
While debugging an issue related to my movmem rule, I noticed that
fwprop seems to be doing some really strange.
The problem occu
Hello and thanks for your quick reply!
Am 09.05.2012 15:59, schrieb Ian Lance Taylor:
Note that the current GCC release is 4.7.0.
The problem with Debian Squeeze is always that I have to use "medieval"
software... ;-) Maybe I should develop the server software on a local
box using "unstab
Daniel Marschall writes:
> I did understand that the compiler used "signed" multiplication
> instead of an unsigned one because char*char needs to be extended.
>
> Maybe I am wrong, but couldn't the compiler "know" that the result
> will be at least unsigned because unsigned * unsigned = unsigned
Hello,
Look for the Intel Optimization Manual on intel.com. The appendixes
have latency and throughput information for the instruction set on
various Intel processors.
Uh-oh, that's hard. I tried to find the information, but I did only
found a part of the informations I was looking for.
Fi
On Wed, 9 May 2012, Daniel Marschall wrote:
1. I do not know my DisplayName/DisplayFamily (0f_2h or 0f_3h?).
Ask your processor (cpuid). Or your kernel (/proc/cpuinfo on linux).
3. Should I compare Latency or Throughput if I want to produce fast code? Or
doesn't it matter which value I compa
Am 09.05.2012 21:48, schrieb Marc Glisse:
On Wed, 9 May 2012, Daniel Marschall wrote:
1. I do not know my DisplayName/DisplayFamily (0f_2h or 0f_3h?).
Ask your processor (cpuid). Or your kernel (/proc/cpuinfo on linux).
/proc/cpuinfo says:
processor : 0
vendor_id : GenuineIntel
Greetings,
I've been debugging a Fedora 17 build problem on ppc64-redhat-linux, and
ran into an issue with bitsizetype. I have a patch that fixes the
problem, but I'm not yet convinced it's the right fix. I'm hoping
someone here can help me sort it out.
The problem occurs when compiling some Ja
On Wed, May 9, 2012 at 1:36 PM, William J. Schmidt
wrote:
> Greetings,
>
> I've been debugging a Fedora 17 build problem on ppc64-redhat-linux, and
> ran into an issue with bitsizetype. I have a patch that fixes the
> problem, but I'm not yet convinced it's the right fix. I'm hoping
> someone he
On Wed, 2012-05-09 at 13:47 -0700, Andrew Pinski wrote:
> On Wed, May 9, 2012 at 1:36 PM, William J. Schmidt
> wrote:
> > Greetings,
> >
> > I've been debugging a Fedora 17 build problem on ppc64-redhat-linux, and
> > ran into an issue with bitsizetype. I have a patch that fixes the
> > problem,
Am 09.05.2012 20:30, schrieb Ian Lance Taylor:
Daniel Marschall writes:
I did understand that the compiler used "signed" multiplication
instead of an unsigned one because char*char needs to be extended.
Maybe I am wrong, but couldn't the compiler "know" that the result
will be at least unsig
On Wed, 9 May 2012, Daniel Marschall wrote:
I could sucessfully do a benchmark of my code. I found out that the
no-typecast-version (imull+movslq) needed 47 secs for 12 working packages,
while the typecast-version (imulq) needed only 38 secs per 12 working
packages. That is incredible!
Maybe
A TPF stack frame has up to two return addresses in it. The second
one is used when the call crosses a shared object domain, where a stub
is between the two functions. The stub does not change the stack, but
it does eventually chain to the "correct" return address.
In the TPF unwinder, a fallba
27 matches
Mail list logo
