> (reg:SF 139) can hold the value (const_double:SF 0) but (subreg:SI
> (reg:SF 139)) should be the value (const_int 0). Perhaps the problem
> is how we handle a REG_EQUAL note when the destination of the set is a
> SUBREG.
(subreg:SI (reg:SF 139), 0) shouldnt be able to hold the value
(float:SF (
On 02 August 2007 15:00, Ian Lance Taylor wrote:
> "Pranav Bhandarkar" <[EMAIL PROTECTED]> writes:
>
>>> How can we have a PLUS on a CONST_DOUBLE and a CONST_INT? That does
>>> not make sense, as there is no MODE argument that could make this work
>>> correctly. From your description, MODE must
On 03 August 2007 16:40, Jonathan S. Shapiro wrote:
> On Fri, 2007-08-03 at 15:58 +0100, Dave Korn wrote:
>> On 03 August 2007 15:48, Jonathan S. Shapiro wrote:
>>
>>> 2. Is there a simple way to configure the compiler so that the default
>>> compilation model (in the absence of command-line dire
On Wed, 1 Aug 2007, Mark Mitchell wrote:
| Volker Reichelt wrote:
|
| > 2007-03-26 Dirk Mueller <[EMAIL PROTECTED]>
| >
| >* parser.c (cp_parser_member_declaration): Pedwarn
| >about stray semicolons after member declarations.
| >
|
| > It makes
| >
| > struct A
| > {
|
On 03 August 2007 15:48, Jonathan S. Shapiro wrote:
> 2. Is there a simple way to configure the compiler so that the default
> compilation model (in the absence of command-line directives) is
> --static? If not, which of the various specfile macros need to be
> updated? I know how to write specfil
On Fri, Aug 03, 2007 at 10:47:44AM -0400, Jonathan S. Shapiro wrote:
> 1. Versions of crtbegin
>
> There are three versions of crtbegin: crtbegin.o, crtbeginS.o,
> crtbeginT.o. 'S' is for shared/PIE -- I understand about that. Can
> somebody explain what the distinction is between crtbeginT.o and
"Jonathan S. Shapiro" <[EMAIL PROTECTED]> writes:
> On Fri, 2007-08-03 at 11:06 -0400, Daniel Jacobowitz wrote:
> > crtbeginT.o is used for -static; crtbegin.o is used without -static.
> > I don't recall why they have to be different.
>
> So far as we can tell from looking at the linux versions,
On 03 August 2007 17:09, Jonathan S. Shapiro wrote:
> This is observed on gcc-3.4.6. It may be a known issue, and/or it may be
> fixed in later compilers.
>
> For bringup purposes, I wrote an inline assembly hack to get the cross
> compiler to tell me whether the target is little/big endian. The
On Fri, 2007-08-03 at 15:58 +0100, Dave Korn wrote:
> On 03 August 2007 15:48, Jonathan S. Shapiro wrote:
>
> > 2. Is there a simple way to configure the compiler so that the default
> > compilation model (in the absence of command-line directives) is
> > --static? If not, which of the various spe
"Pranav Bhandarkar" <[EMAIL PROTECTED]> writes:
> > (reg:SF 139) can hold the value (const_double:SF 0) but (subreg:SI
> > (reg:SF 139)) should be the value (const_int 0). Perhaps the problem
> > is how we handle a REG_EQUAL note when the destination of the set is a
> > SUBREG.
>
> (subreg:SI (r
Jack Howarth has reported vect failures at -m64 on darwin with gfortran:
http://gcc.gnu.org/ml/fortran/2007-08/msg00041.html
I see the same kind of failures with gcc 4.3.0 revision 127178:
FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c scan-tree-dump-times
vectorization not profitable 1
FA
Sunzir Deepur wrote:
> hello,
>
> what are class 3 edges ?
> why make them ?
> if i understand ok, they do not represent a legit flow of code...
Switches:
switch (c) {
case '0':
do some stuff;
break;
case '1':
do some other stuff;
break;
default:
We're targeting a new OS with GCC. I've done some of these before, but
I've run into one issue I don't recognize, and a second that I have
obviously messed up. I have looked at "Using and Porting" and "GCC
Internals". The answers may be there, but I did not find them --
pointers welcome.
1. Versi
On Fri, 2007-08-03 at 12:46 -0400, Daniel Jacobowitz wrote:
> On Fri, Aug 03, 2007 at 05:24:28PM +0100, Dave Korn wrote:
> > I'm a bit surprised too. But it occurs to me that the ARM, unlike the
> > i386
> > and m68k, is bi-endian. Perhaps you can't actually know which mode it's
> > running in
Sa Liu <[EMAIL PROTECTED]> writes:
> I have added a piece of code in try_split to handle the links. Not sure
> whether this is O.K. for the other platforms.
Thanks. The general idea looks right, but the implementation is
incorrect.
> + case REG_LIBCALL:
> + /* Relink the insns with
Sunzir Deepur wrote:
>
> ok, that's one example where class 3 edges are created, but why is that ?
> they obviously do not represent a legit flow of code.
> e.g.
> if(condition) {
> BB1
> }
> else {
>BB2
> }
>
> here i get (besides the obvious edges) a class 3 edge between BB1 to BB2.
>
On 8/3/07, Emmanuel Fleury <[EMAIL PROTECTED]> wrote:
> Sunzir Deepur wrote:
> > hello,
> >
> > what are class 3 edges ?
> > why make them ?
> > if i understand ok, they do not represent a legit flow of code...
>
> Switches:
ok, that's one example where class 3 edges are created, but why is that ?
On Fri, 2007-08-03 at 17:24 +0100, Dave Korn wrote:
> > I am not surprised that there is different behavior for different
> > targets, but I am very surprised that *this* behavior is different. This
> > optimization ought to be happening in the mid-end, and it ought to be
> > entirely machine inde
This is probably a question that should be directed to the binutils
list.
We need to set the default link start address used by ld. Unfortunately
ld doesn't have a nice porting guide like GCC does. :-)
Actually, we need to choose one of two possible start addresses based on
command line options t
hello,
what are class 3 edges ?
why make them ?
if i understand ok, they do not represent a legit flow of code...
thank you
sunzir
Ian:
Thanks for the explanation of eh-frame-header. All of what you say makes
sense. Before I dig in to this, is the eh-frame-header stuff documented
somewhere? If so I should read that as well.
shap
On Fri, Aug 03, 2007 at 05:24:28PM +0100, Dave Korn wrote:
> I'm a bit surprised too. But it occurs to me that the ARM, unlike the i386
> and m68k, is bi-endian. Perhaps you can't actually know which mode it's
> running in at compile time and /have/ to test it at runtime?
No. You can't genera
On Friday 03 August 2007, Jonathan S. Shapiro wrote:
> On Fri, 2007-08-03 at 12:46 -0400, Daniel Jacobowitz wrote:
> > On Fri, Aug 03, 2007 at 05:24:28PM +0100, Dave Korn wrote:
> > > I'm a bit surprised too. But it occurs to me that the ARM, unlike
> > > the i386 and m68k, is bi-endian. Perhap
Ian Lance Taylor <[EMAIL PROTECTED]> wrote on 03.08.2007 17:24:45:
> Thanks. The general idea looks right, but the implementation is
> incorrect.
>
Thank you! I have made the correction:
Index: gcc/emit-rtl.c
===
--- gcc.orig/emit
This is observed on gcc-3.4.6. It may be a known issue, and/or it may be
fixed in later compilers.
For bringup purposes, I wrote an inline assembly hack to get the cross
compiler to tell me whether the target is little/big endian. The code
fragment is:
const unsigned long ul = 0x04030201llu;
First, thanks to Dave and Daniel for taking the time to reply.
On Fri, 2007-08-03 at 11:06 -0400, Daniel Jacobowitz wrote:
> crtbeginT.o is used for -static; crtbegin.o is used without -static.
> I don't recall why they have to be different.
So far as we can tell from looking at the linux versio
On Fri, Aug 03, 2007 at 11:58:47AM -0400, Jonathan S. Shapiro wrote:
> So far as we can tell from looking at the linux versions, the only
> difference is that crtbeginT is calling
>
> register_frame_info_bases
> deregister_frame_info_bases
>
> I suspect that these are related to the e
Ian Lance Taylor <[EMAIL PROTECTED]> wrote on 30.07.2007 18:59:28:
> If the compiler splits an insn with a REG_LIBCALL note, it needs to
> remove the corresponding REG_RETVAL note, or it needs to relink the
> insns. This looks like a compiler bug, in that try_split doesn't
> handle REG_LIBCALL no
"Jonathan S. Shapiro" <[EMAIL PROTECTED]> writes:
> Thanks for the explanation of eh-frame-header. All of what you say makes
> sense. Before I dig in to this, is the eh-frame-header stuff documented
> somewhere? If so I should read that as well.
All I can say is that I would also like to know whe
On Fri, Aug 03, 2007 at 06:24:06PM +0100, Paul Brook wrote:
> On Friday 03 August 2007, Jonathan S. Shapiro wrote:
> > Then it seems very curious that the constant folding should fail on this
> > platform. Any idea what may be going on here?
>
> You're exploiting a hole in the C aliasing rules by
On 03 August 2007 18:35, Nathan Froyd wrote:
> On Fri, Aug 03, 2007 at 06:24:06PM +0100, Paul Brook wrote:
>> On Friday 03 August 2007, Jonathan S. Shapiro wrote:
>>> Then it seems very curious that the constant folding should fail on this
>>> platform. Any idea what may be going on here?
>>
>> Y
On 03 August 2007 18:49, Joe Buck wrote:
> On Fri, Aug 03, 2007 at 06:45:55PM +0100, Dave Korn wrote:
>> On 03 August 2007 18:35, Nathan Froyd wrote:
>>
>>> On Fri, Aug 03, 2007 at 06:24:06PM +0100, Paul Brook wrote:
On Friday 03 August 2007, Jonathan S. Shapiro wrote:
> Then it seems ve
On Fri, Aug 03, 2007 at 06:45:55PM +0100, Dave Korn wrote:
> On 03 August 2007 18:35, Nathan Froyd wrote:
>
> > On Fri, Aug 03, 2007 at 06:24:06PM +0100, Paul Brook wrote:
> >> On Friday 03 August 2007, Jonathan S. Shapiro wrote:
> >>> Then it seems very curious that the constant folding should fa
On Fri, 2007-08-03 at 10:34 -0700, Nathan Froyd wrote:
> On Fri, Aug 03, 2007 at 06:24:06PM +0100, Paul Brook wrote:
> > On Friday 03 August 2007, Jonathan S. Shapiro wrote:
> > > Then it seems very curious that the constant folding should fail on this
> > > platform. Any idea what may be going on
> Jack Howarth has reported vect failures at -m64 on darwin with gfortran:
>
> http://gcc.gnu.org/ml/fortran/2007-08/msg00041.html
>
> I see the same kind of failures with gcc 4.3.0 revision 127178:
>
My guess is it's related to the recent patch that does not allow peeling on
64bit darwin (http://
Snapshot gcc-4.3-20070803 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070803/
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/trunk
36 matches
Mail list logo
