I'm investigating an ICE on m68k architecture. I'm not quite sure what
is the right way to fix the bug so I welcome any feedback on the below
analysis.
Compilation fails on the assert in dwarf2out.c:based_loc_descr():
/* We only use "frame base" when we're sure we're talking about the
Amker.Cheng wrote:
Hi :
I'm puzzled when looking into speculative scheduling in gcc, the 4.2.4 version.
First, I noticed the document describing IBM haifa instruction
scheduler(as PowerPC Reference Compiler Optimization Project).
It presents that the instruction motion from bb s(dominated by t)
On Sun, Sep 20, 2009 at 3:43 PM, Maxim Kuvyrkov wrote:
> Amker.Cheng wrote:
>>
>> Hi :
>> I'm puzzled when looking into speculative scheduling in gcc, the 4.2.4
>> version.
>>
>> First, I noticed the document describing IBM haifa instruction
>> scheduler(as PowerPC Reference Compiler Optimization
On Sun, 20 Sep 2009, Dave Korn wrote:
> Richard Guenther wrote:
>
> > The trunk is in Stage 1. Stage 1 will end on Sep 30th. After Stage 1
> > Stage 3 follows with only bugfixes and no new features allowed.
> > Stage 3 will end Nov 30th.
I'll answer your and Jacks question together.
> I do
On Sun, Sep 20, 2009 at 9:38 AM, Maxim Kuvyrkov wrote:
> I'm investigating an ICE on m68k architecture. I'm not quite sure what is
> the right way to fix the bug so I welcome any feedback on the below
> analysis.
>
> Compilation fails on the assert in dwarf2out.c:based_loc_descr():
>
> /* We on
G++ currently accepts the following code:
char *
alloc(unsigned a, unsigned b)
{
typedef char array[a];
return &**(new array[b]);
}
Is this intentional? The equivalent "new char[a][b]" is rejected (as
required by the C++ standard).
Richard Guenther wrote:
On Sun, Sep 20, 2009 at 9:38 AM, Maxim Kuvyrkov wrote:
...
This code uses eliminate_regs(), which implicitly assumes reload_completed
as it uses reg_eliminate[], which assumes that frame_pointer_needed is
properly set, which happens in ira.c. However, in some cases thi
On Sun, Sep 20, 2009 at 1:18 PM, Maxim Kuvyrkov wrote:
> Richard Guenther wrote:
>>
>> On Sun, Sep 20, 2009 at 9:38 AM, Maxim Kuvyrkov
>> wrote:
>
> ...
>>>
>>> This code uses eliminate_regs(), which implicitly assumes
>>> reload_completed
>>> as it uses reg_eliminate[], which assumes that frame_
Richard Guenther wrote:
> Note that Stage 3 isn't that strict as it may sound. Maintainers have
> quite amount of flexibility deciding what is considered a bug and thus
> a bugfix during Stage 3 (note that Stage3 is _not_ only for regression
> fixes). This includes obviously Graphite and LTO as
On Sun, 20 Sep 2009, Dave Korn wrote:
> Richard Guenther wrote:
>
> > Note that Stage 3 isn't that strict as it may sound. Maintainers have
> > quite amount of flexibility deciding what is considered a bug and thus
> > a bugfix during Stage 3 (note that Stage3 is _not_ only for regression
> > fi
Richard Guenther wrote:
> On Sun, 20 Sep 2009, Dave Korn wrote:
>> BTW, why don't we call this more-flexible-stage-3 "stage 2" any more? It
>> sounds a lot like the way that's still described on develop.html.
>
> Because "New functionality may not be introduced during this period." is
> still
As commented to my last status report develop.html does not reflect
reality anymore. The following tries to adjust it carefully in
this respect.
Ok for www?
Thanks,
Richard.
2009-09-20 Richard Guenther
* develop.html: Adjust to reflect recent practice.
Index: develop.html
I wonder if there would be at least a theoretical support by the
developers to a proposal for volatile bitfields:
When a HW register (thus most likely declared as volatile) is defined as
a bitfield, as far as I know gcc treats each bitfield assignment as a
separate read-modify-write operation. Tha
Hi :
In function new_ready, it calls to min_insn_conflict_delay with
"min_insn_conflict_delay (curr_state, next, next)".
But the function's comments say that it returns minimal delay of issue of
the 2nd insn after issuing the 1st in given state.
Why the last two parameter for the call are both "
Richard Guenther wrote:
> * develop.html: Adjust to reflect recent practice.
TYVM :)
cheers,
DaveK
reg.field1 = val1, reg.field2 = val2;
would then turn into fetch, mask with a combined mask of field1 and
field2, or val1, or val2, store.
You can also do the RMW yourself: declare the register volatile, but not
the fields of it, and copy in/out of the register manually.
volatile struct re
Paolo Bonzini wrote:
Is it a completely brain-dead idea?
If I understood it correctly, it would not be standard compliant.
But it's an extension, so I don't see that is an issue of itself.
Paolo
Why is postreload converting (set (REGX) (CONST_INT A)) ... (set (REGX)
(CONST_INT B)) into (set (STRICT_LOW_PART (REGX)) (CONST_INT B))? That
looks like a pessimisation especially if the constants are small, since
STRICT_LOW_PART must not touch the high part. Is there a way for the
backend to st
Richard Guenther wrote:
> 2009-09-20 Richard Guenther
>
> * develop.html: Adjust to reflect recent practice.
OK.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713
On Sun, Sep 20, 2009 at 6:10 PM, Andreas Schwab wrote:
> Why is postreload converting (set (REGX) (CONST_INT A)) ... (set (REGX)
> (CONST_INT B)) into (set (STRICT_LOW_PART (REGX)) (CONST_INT B))? That
> looks like a pessimisation especially if the constants are small, since
> STRICT_LOW_PART mus
On 09/20/2009 06:31 PM, Richard Guenther wrote:
On Sun, Sep 20, 2009 at 6:10 PM, Andreas Schwab wrote:
Why is postreload converting (set (REGX) (CONST_INT A)) ... (set (REGX)
(CONST_INT B)) into (set (STRICT_LOW_PART (REGX)) (CONST_INT B))? That
looks like a pessimisation especially if the con
All,
I have been debugging AVR port to see why we fail to match so many bit
test opportunities.
When dealing with longer modes I have come across a problem I can not solve.
Expansion in RTL for a bit test can produce two styles.
STYLE 1 Bit to be tested is NOT LSB (e.g. if ( longthing & 0x1
Richard Guenther wrote:
As commented to my last status report develop.html does not reflect
reality anymore. The following tries to adjust it carefully in
this respect.
Schedule
-Development on our main branch will proceed in three stages. Each
-stage will be two months in length.
+Devel
On Sun, 20 Sep 2009, Theodore Papadopoulo wrote:
> Richard Guenther wrote:
> > As commented to my last status report develop.html does not reflect
> > reality anymore. The following tries to adjust it carefully in
> > this respect.
> >
> > Schedule
> > -Development on our main branch will pro
On Sun, 20 Sep 2009, Zolt??n K??csi wrote:
> I wonder if there would be at least a theoretical support by the
> developers to a proposal for volatile bitfields:
It has been proposed (and not rejected, but not yet implemented) that
volatile bit-fields should follow the ARM EABI specification (on
Snapshot gcc-4.3-20090920 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090920/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Si gasolina gratis para su automovil
desde un 17% por cada tanque de combustible
con el original maxifuel
www.maxifuel.com.mx
estamos en busca de distribuidores
unete a la familia maxifuel
normamaxif...@gmail.com
utilidades garantizadas plazas disponibles
On Sun, 20 Sep 2009, Joseph S. Myers wrote:
> On Sun, 20 Sep 2009, Zolt??n K??csi wrote:
>
> > I wonder if there would be at least a theoretical support by the
> > developers to a proposal for volatile bitfields:
>
> It has been proposed (and not rejected, but not yet implemented) that
> volatile
28 matches
Mail list logo
