Hi,
I found a few more cases that still cause internal compiler errors, I
managed to fix them. I have attached an updated patch.
Sean
On Tue, Mar 17, 2009 at 12:45 PM, Fu, Chao-Ying wrote:
> Sean D'Epagnier wrote:
>>
>> I think I found a generic problem for fixed point constant folding.
>>
>>
Sean D'Epagnier wrote:
>
> I think I found a generic problem for fixed point constant folding.
>
> In fold-const.c:11872 gcc tries to apply:
> /* Transform (x >> c) << c into x & (-1< c) >> c
> into x & ((unsigned)-1 >> c) for unsigned types. */
>
> I attached a simple patch whic
Bingfeng Mei wrote:
> I am tracking a bug, not sure whether it is a generic GCC bug or my porting
> goes wrong.
>
> To access the below structure,
>
> typedef struct { long int p_x, p_y; } Point; ... p1.p_x = -1; ...
>
> It is expanded to follwing RTL ;; p1.p_x = -1;
>
> (insn 19 18 20
> /pro
On Tue, Mar 17, 2009 at 04:21:18PM +0100, Joel Porquet wrote:
> Problem is how can you find the symbol referenced by the relocation
> when the symbol index is null??
> Then, should we consider that a null symbol index means that the
> module relocation is the DSO itself?
Yes, that's what I said.
2009/3/17 Daniel Jacobowitz :
> On Tue, Mar 17, 2009 at 04:03:45PM +0100, Joel Porquet wrote:
>> 2009/3/17 Daniel Jacobowitz :
>> > On Tue, Mar 17, 2009 at 10:26:05AM +0100, Joel Porquet wrote:
>> >> I don't understand how the runtime loader could know that! As far as I
>> >> know, the tls model is
On Tue, Mar 17, 2009 at 04:03:45PM +0100, Joel Porquet wrote:
> 2009/3/17 Daniel Jacobowitz :
> > On Tue, Mar 17, 2009 at 10:26:05AM +0100, Joel Porquet wrote:
> >> I don't understand how the runtime loader could know that! As far as I
> >> know, the tls model is not embedded in reloc information.
2009/3/17 Daniel Jacobowitz :
> On Tue, Mar 17, 2009 at 10:26:05AM +0100, Joel Porquet wrote:
>> I don't understand how the runtime loader could know that! As far as I
>> know, the tls model is not embedded in reloc information.
>
> Sure it is. I suggest you go back to Ulrich Drepper's TLS paper
>
On Tue, Mar 17, 2009 at 10:26:05AM +0100, Joel Porquet wrote:
> I don't understand how the runtime loader could know that! As far as I
> know, the tls model is not embedded in reloc information.
Sure it is. I suggest you go back to Ulrich Drepper's TLS paper
for more information about the relocat
I am tracking a bug, not sure whether it is a generic GCC bug or my porting
goes wrong.
To access the below structure,
typedef struct {
long int p_x, p_y;
} Point;
...
p1.p_x = -1;
...
It is expanded to follwing RTL
;; p1.p_x = -1;
(insn 19 18 20
/projects/firepath/tools/work/bmei/gcc-he
2009/3/17 Ian Lance Taylor :
> The local labels used for blocks are normally discarded by the assembler
> and thus are never seen by tools like oprofile. Using named symbols for
> basic blocks seems like a reasonable option if it will indeed give
> better information from oprofile, but it should
Thanks for the reply. There should be more opportunties for strictly aligned
machines. In my example, the structure is a local variable allocated on stack.
I don't see why it is marked as BLKmode. Compiler has full freedom to make it
aligned and use DImode instead.
Bingfeng
> -Original Messag
2009/3/16 Daniel Jacobowitz :
> On Mon, Mar 16, 2009 at 06:19:01PM +0100, Joel Porquet wrote:
>> 2009/3/12 Daniel Jacobowitz :
>> > On Thu, Mar 12, 2009 at 02:02:36PM +0100, Joel Porquet wrote:
>> >> > Check what symbol is at, or near, 0x4003 + 22368. It's probably
>> >> > the GOT plus a const
On Fri, Mar 13, 2009 at 06:06:41PM +0100, Paolo Bonzini wrote:
>
> >>> Hm. In fold-const.c we try to make sure to produce the same result
> >>> as the target would for constant-folding shifts. Thus, Paolo, I think
> >>> what fold-const.c does is what we should assume for
> >>> !SHIFT_COUNT_TRUNC
13 matches
Mail list logo
