Hi, I just came across an optimization issue in pass peephole2:
Regs that are "naturally" dead because the function ends are not marked as dead,
and therefore some optimization opportunities pass by unnoticed, e.g. together
with recog.c::peep2_reg_dead_p() et. al.
As I could not find a related PR
> "Radu Hobincu" writes:
>
2. I have another piece of code that fails to compile with -O3.
-
struct desc{
int int1;
int int2;
int int3;
};
int bugTest(struct desc *tDesc){
return *((int*)
Hi Ian,
On 19 October 2010 15:31, Ian Lance Taylor wrote:
> It should not be necessary to use STARTING_FRAME_OFFSET when using
> virtual_stack_vars_rtx, as it should be added in by the vregs pass. See
> instantiate_new_reg, and note that var_offset is set to
> STARTING_FRAME_OFFSET.
Yes, but he
Sayın Yetkili;
TRT1 Ekranlarında 24 Ekim Pazar Günü STADYUM programında Fenerbahçe -
Galatasaray maçının ilk özet görüntüleri yayınlanacaktır.
Geçen sene görüntüler sadece TRT1'de değilken bile Galatasaray-Fenerbahçe
maçının yayınlandığı hafta program açık ara GÜN 1.si olmuştu.
Bu sene ise öze
On Thu, Oct 21, 2010 at 02:14:15PM +0200, Frederic Riss wrote:
> On 19 October 2010 15:31, Ian Lance Taylor wrote:
> > However, I agree that it does seem that it should be added to or
> > subtracted from hard_frame_pointer_rtx before setting
> > virtual_stack_vars_rtx, or something. I only see on
I need a preprocessor macro to detect c++0x support. For now, that is
__GXX_EXPERIMENTAL_CXX0X__
but what happens once -std=c++0x is the default? Will this macro still
be defined?
Don't we need a
__GXX_CXX0X__ ?
Michael Meissner wrote:
> Note, the 64-bit ABI requires that r2 have the current function's GOT in it
> when the function is called, while the 32-bit ABI uses r2 as a small data
> pointer (and possibly r13 as a second small data pointer).
If the 32-bit ABI is the SYSV-ABI, then you got the registe
On Thu, Oct 21, 2010 at 08:17:51PM +0200, Gunther Nikl wrote:
> Michael Meissner wrote:
> > Note, the 64-bit ABI requires that r2 have the current function's GOT in it
> > when the function is called, while the 32-bit ABI uses r2 as a small data
> > pointer (and possibly r13 as a second small data
Georg Lay writes:
> Regs that are "naturally" dead because the function ends are not marked as
> dead,
> and therefore some optimization opportunities pass by unnoticed, e.g. together
> with recog.c::peep2_reg_dead_p() et. al.
I don't understand what you mean. All registers other than the retu
On 21 October 2010 18:52, Neal Becker wrote:
> I need a preprocessor macro to detect c++0x support. For now, that is
> __GXX_EXPERIMENTAL_CXX0X__
>
> but what happens once -std=c++0x is the default? Will this macro still
> be defined?
>
> Don't we need a
>
> __GXX_CXX0X__ ?
__cplusplus should
Hi,
Is it possible to describe multi-register values in RTL when the
subparts of the value aren't stored in consecutive registers? For
example having a DI value constructed from 2 unrelated SI registers
(without losing the semantic of the original DI value) ?
Thanks a lot,
Fred
Snapshot gcc-4.5-20101021 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20101021/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Frederic Riss writes:
> Is it possible to describe multi-register values in RTL when the
> subparts of the value aren't stored in consecutive registers? For
> example having a DI value constructed from 2 unrelated SI registers
> (without losing the semantic of the original DI value) ?
Not really
On Oct 21, 2010, at 8:15 PM, Ian Lance Taylor wrote:
> Frederic Riss writes:
>
>> Is it possible to describe multi-register values in RTL when the
>> subparts of the value aren't stored in consecutive registers? For
>> example having a DI value constructed from 2 unrelated SI registers
>> (with
Hi,
I am working on huge object files and I am glad to see that gcc
supports -mcmodel=large now. However, my experiment even doesn't work
because of relocation problem in crtbeginS.o
My Source file: t.c
#include
extern int foo(int argc, char **argv);
void *pv1[1024]={(void*)foo,};
char a[214
Paul Koning writes:
> To take that example, on the pdp11 an SImode is two HImodes. Could
> the RTL template in the MD file for, say, addsi3 split that into two
> or three insns that operate on HImode values and describe the actual
> instructions? In this case: add high parts, then add low parts
Wei Li writes:
> I am working on huge object files and I am glad to see that gcc
> supports -mcmodel=large now. However, my experiment even doesn't work
> because of relocation problem in crtbeginS.o
This message was not appropriate for the mailing list gcc@gcc.gnu.org,
which is for the developm
Le jeudi 21 octobre 2010 à 21:11 -0700, Ian Lance Taylor a écrit :
> Paul Koning writes:
>
> > To take that example, on the pdp11 an SImode is two HImodes. Could
> > the RTL template in the MD file for, say, addsi3 split that into two
> > or three insns that operate on HImode values and describe
18 matches
Mail list logo
