Jonathan Wakely wrote:
> On Mon, Feb 21, 2005 at 12:32:52PM +0800, Euler Herbert wrote:
>>be somewhere, but I did no find it. Could somebody tell me the
>>outline of the unwinding process?
> I think this behaviour is defined by this spec:
> http://www.codesourcery.com/cxx-abi/abi-eh.html
What
Jonathan Wakely wrote:
$ gcc4x -c bug.c -pedantic -save-temps
bug.c: In function 'main':
bug.c:1: error: floating constant exceeds range of 'long double'
This is easy enough to explain. Grepping for the message shows that it
is printed from c-lex.c, and is only printed when -pedantic.
-save-temp
hi,
thanks for identifying the error.
i have gone through the a.out file after this error. that is producing full
of arm instructions other than the main function(which is compiled for
-mthumb). where should i change for this corresponding error.
i have added one new add instruction in
Richard Guenther wrote:
this is because I'm feeding int_fits_type_p a (constant) pointer type:
The comment at the top of int_fits_type_p says it is supposed to be an
integer type, which seems clear enough.
This question might make more sense if you explain what you are doing,
and why you need to
Matthew J Fletcher wrote:
Is this correct ?, comments in the appropreate config.h files indicate that
HANDLE_PRAGMA_PACK_PUSH_POP, is mostly used for wine compatablity, but is
there any reason why HANDLE_PRAGMA_PACK_PUSH_POP is not present on all
targets ? also there is not a configure option.
T
Pat Haugen wrote:
Is there a reason REG_POINTER isn't propagated to the target register for
rtl insns of the form "reg_x = regP_y + reg_z", where regP_y is a reg
marked as REG_POINTER?
Probably historical oversight.
However, note that the hppa-hp-hpux port relies on the REG_POINTER
settings being
On Tue, Feb 22, 2005 at 02:58:42AM +0100, Marcin Dalecki wrote:
> On 2005-02-22, at 00:25, Steve Kargl wrote:
> >
> >FreeBSD is fairly conservative with updating the system compiler.
>
> That is fairly wrong. Usually FreeBSD current is ahead of the Linux
> gang in terms of the compiler since about
Dylan Cuthbert wrote:
> asm( "some_instruction %0,%1,%2,%3" : "=&j" (blob): "j" (vec1), "j"
> (vec2), "j" (frog) );
> asm( "some_instruction2 %0,%1" : "=&j" (frog) : "j" (blob) );
It is the goal of the register allocator to use as few registers as
possible,
which means that we will try to use the
On 2005-02-22, at 00:25, Steve Kargl wrote:
On Tue, Feb 22, 2005 at 12:22:37AM +0100, Tobias Schl?ter wrote:
Gerald Pfeifer wrote:
On Mon, 21 Feb 2005, Tobias Schl?ter wrote:
To add a concrete example, unlike g77 in earlier versions of GCC,
gfortran
is not and will not be part of the standard gcc4
On Mon, Feb 21, 2005 at 07:36:33PM -0500, DJ Delorie wrote:
> * tree-ssa-loop-ivopts.c (computation_cost): Start register
> numbering at LAST_VIRTUAL_REGISTER+1 to avoid possibly using hard
> registers in unsupported ways.
> * expmed.c (init_expmed): Likewise.
Ok.
r~
Dale Johannesen wrote:
OK, thanks. I can look into doing this in the ObjC-specific hook,
unless you have
a better idea?
I've looked harder.
See PR19148 for details about my patch. I think the key is that you not
recursively call gimplify_expr with fb_lvalue. Since we're calling
recursively wi
On Feb 21, 2005, at 5:21 PM, Mark Mitchell wrote:
Dale Johannesen wrote:
+ /* Postincrements in OBJ_TYPE_REF_OBJECT don't affect the
+ value of the OBJ_TYPE_REF, so force them to be emitted
+ during subexpression evaluation rather than after the
+ OB
Dale Johannesen wrote:
+ /* Postincrements in OBJ_TYPE_REF_OBJECT don't affect the
+ value of the OBJ_TYPE_REF, so force them to be emitted
+ during subexpression evaluation rather than after the
+ OBJ_TYPE_REF. This permits objc_msgSend calls in Obj
Simple Objective C programs such as
#include
void foo(void) {
Object *o;
[o++ free];
}
result in calling objc_msgSend indirectly through a pointer, instead
of directly as they did in 3.3. This seems to happen only at low
optimization
levels; still, it's a performance regression. The reason
> On Jan 19, 2005, at 22:48, Richard Henderson wrote:
> > On Wed, Jan 19, 2005 at 09:19:58PM -0500, DJ Delorie wrote:
> >> - int regno = 0;
> >> + int regno = FIRST_PSEUDO_REGISTER;
> >
> > To be totally safe, you need LAST_VIRTUAL_REGISTER+1.
>
> Also, this definitely needs a comment.
Ok, I'm
Jeffrey A Law wrote:
Sigh. I can't wait for this code to become less critical, both in terms
of runtime and compile time performance. There are so many things in
cse.c that are just plain bad
cse.c has a fair amount of complexity in its hash table management
code to avoid spending too much
On Tue, Feb 22, 2005 at 12:22:37AM +0100, Tobias Schl?ter wrote:
> Gerald Pfeifer wrote:
> > On Mon, 21 Feb 2005, Tobias Schl?ter wrote:
> >
> >>>To add a concrete example, unlike g77 in earlier versions of GCC, gfortran
> >>>is not and will not be part of the standard gcc40 port in FreeBSD.
> >>
On Tue, Feb 22, 2005 at 12:17:05AM +0100, Gerald Pfeifer wrote:
> On Mon, 21 Feb 2005, Tobias Schl?ter wrote:
> >> To add a concrete example, unlike g77 in earlier versions of GCC, gfortran
> >> is not and will not be part of the standard gcc40 port in FreeBSD.
> > Do you have a pointer to where t
Gerald Pfeifer wrote:
> On Mon, 21 Feb 2005, Tobias Schlüter wrote:
>
>>>To add a concrete example, unlike g77 in earlier versions of GCC, gfortran
>>>is not and will not be part of the standard gcc40 port in FreeBSD.
>>
>>Do you have a pointer to where this decision is explained?
>
> That took
On Mon, 21 Feb 2005, Tobias Schlüter wrote:
>> To add a concrete example, unlike g77 in earlier versions of GCC, gfortran
>> is not and will not be part of the standard gcc40 port in FreeBSD.
> Do you have a pointer to where this decision is explained?
That took place in private e-mail, but I hap
On Mon, 2005-02-21 at 14:42 -0500, Kazu Hirata wrote:
> Hi Jeff,
>
> > The second thought is to initialize all of cse_reg_info entries at the
> > beginning of cse_main. Set aside a bitmap with as many bits as
> > max_regs. Whenever we use one of these accessor macros for register
> > k, set a bi
sorry for the cross-posting but this proposal will
require some synergy between the three projects
> * Project Title
Frameworks for GNU Toolchain
> * Project Contributors
Matt Rice
> * Dependencies
Framework support in libc/bfd/binutils
> * Delivery Date
gcc portion is done, but blocked by the
Hi Jeff,
> The second thought is to initialize all of cse_reg_info entries at the
> beginning of cse_main. Set aside a bitmap with as many bits as
> max_regs. Whenever we use one of these accessor macros for register
> k, set a bit k saying "cse_reg_info_table[k] is in use." This way,
> when we
On Mon, 2005-02-21 at 13:26 -0500, Kazu Hirata wrote:
> Hi Jeff,
>
> > Fixing cse.c to not use the accessor macros for REG_IN_TABLE, REG_TICK
> > and SUBREG_TICKED saves about 1% compilation time for the components
> > of cc1. Yes, that's a net 1% improvement by dropping the abstraction
> > layer
On Mon, 2005-02-21 at 19:05 +0100, Steven Bosscher wrote:
> On Feb 21, 2005 06:22 PM, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> > I realize that we are trying to write clean, easy to read code by using
> > a level of abstraction, but the abstraction is really getting in the
> > way of achieving re
Hi Jeff,
> Fixing cse.c to not use the accessor macros for REG_IN_TABLE, REG_TICK
> and SUBREG_TICKED saves about 1% compilation time for the components
> of cc1. Yes, that's a net 1% improvement by dropping the abstraction
> layer.
Yes, I've noticed the problem. In my defense, the code in ques
On Feb 21, 2005 06:22 PM, Jeffrey A Law <[EMAIL PROTECTED]> wrote:
> I realize that we are trying to write clean, easy to read code by using
> a level of abstraction, but the abstraction is really getting in the
> way of achieving reasonable compile-time performance.
I don't think this is a proble
On Mon, Feb 21, 2005 at 06:35:43PM +0100, Tobias Schl?ter wrote:
> (added [EMAIL PROTECTED] to the CC list, as that is the appropriate list for
> this dicussion)
>
> Gerald Pfeifer wrote:
> > To add a concrete example, unlike g77 in earlier versions of GCC, gfortran
> > is not and will not be par
(added [EMAIL PROTECTED] to the CC list, as that is the appropriate list for
this dicussion)
Gerald Pfeifer wrote:
> To add a concrete example, unlike g77 in earlier versions of GCC, gfortran
> is not and will not be part of the standard gcc40 port in FreeBSD.
Do you have a pointer to where this
On Sat, 19 Feb 2005, Bradley Lucier wrote:
> But I think that in many installations people simply won't dance through
> these hoops and gfortran will not be installed in 4.0.
To add a concrete example, unlike g77 in earlier versions of GCC, gfortran
is not and will not be part of the standard gc
Sigh. I can't wait for this code to become less critical, both in terms
of runtime and compile time performance. There are so many things in
cse.c that are just plain bad
cse.c has a fair amount of complexity in its hash table management
code to avoid spending too much time invalidating/re
If I have RTL pattern such as:
(SET (MEM...) (MEM...))
(define_insn in backend target.md)
do I need to guard against the possibility that the two operands
overlap? Or does the front/middle end take care of any C/C++ language
specific needs here? (perhaps by using a register as an intermediate)
T
Further investigation.
(B
(BIf I remove the define_expand for movv16sf and throw in a dummy define_insn
(Bthat supports reg<->reg mem<->reg reg<->mem, then the redundant move is
(Boptimized away.
(B
(BBut of course, the store load and move all use 4 instructions each so this
(Bproduces in
Paolo Bonzini schrieb:
- vector version is about 3% faster than above instead of 10% slower -
wow!
So why is gcc 4.0 producing worse code when using intel style
intrinsics and why isn't the union version using builtins as fast as
using the vector version?
I can answer why unions are slower: that's
Paolo Bonzini <[EMAIL PROTECTED]> writes:
| > > ISTR the name change was to avoid a switch named -fdump-rtl-rtl.
| > To invent an option name alias and use a minor repetition in it
| > as a reason for changing the old behavior is Bad.
|
| It is not merely an option name alias. It came together w
On Mon, Feb 21, 2005 at 12:45:51PM +0100, Mile Davidovic wrote:
> Hello all
>
> I have stupid question regarding constructors and destructors in c++.
> After compilation there are two assembler functions (__ZN4testC2Ev,
> __ZN4testC1Ev)
> that represent constructor, same is for destructors (__ZN
Hello all
I have stupid question regarding constructors and destructors in c++.
After compilation there are two assembler functions (__ZN4testC2Ev,
__ZN4testC1Ev)
that represent constructor, same is for destructors (__ZN4testD2Ev,
__ZN4testD1Ev).
Functions are completely the same.
What is the r
On Feb 21, 2005 11:40 AM, Hans-Peter Nilsson <[EMAIL PROTECTED]> wrote:
> > Date: Mon, 21 Feb 2005 11:19:59 +0100
> > From: Paolo Bonzini <[EMAIL PROTECTED]>
>
> > > Do you know of a reason why that isn't on by default?
> >
> > Because -fdump-rtl-expand-detailed includes *two* copies of the RTL:
On Mon, Feb 21, 2005 at 12:32:52PM +0800, Euler Herbert wrote:
> Hi everyone,
Hi,
> I am trying to find out how g++ implements error handling.
> My environment is CPU AMD Athlon(tm) XP 2000+, Debian GNU/Linux
> 3.1, GCC 3.4.3-6, and Glibc 2.3.2.ds1-20. After researching
> assembling codes ge
> Date: Mon, 21 Feb 2005 11:19:59 +0100
> From: Paolo Bonzini <[EMAIL PROTECTED]>
> > Do you know of a reason why that isn't on by default?
>
> Because -fdump-rtl-expand-detailed includes *two* copies of the RTL: one
> lacks the prologue and epilogue but is interleaved with trees, the other
> i
> Ah, that's triggered by -fdump-rtl-expand-detailed (it is revision 2.28,
> for which I could not find an entry on gcc-patches).
Do you know of a reason why that isn't on by default?
Because -fdump-rtl-expand-detailed includes *two* copies of the RTL: one
lacks the prologue and epilogue but is
41 matches
Mail list logo
