Re: ICE on valid code, cse related
> (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 (reg:SI 138) ? Am I right on this ? Because the expander generates the following while storing the return value (insn 17 18 19 testcase-min.i:8 (set (subreg:SI (reg:SF 139) 0) (mem/c/i:SI (reg/f:SI 129 virtual-stack-vars) [2 S4 A32])) -1 (expr_list:REG_LIBCALL_ID (const_int 1 [0x1]) (insn_list:REG_RETVAL 14 (expr_list:REG_EQUAL (float:SF (reg:SI 138)) (nil) The answer to this question will help me decide where to fix the problem, In the expander itself or while processing REG_EQUAL in the cse pass. Thanks, Pranav
RE: ICE on valid code, cse related
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 be some integer mode, in
>>> which case it is wrong to be using a CONST_DOUBLE in SFmode.
>>>
>>> (I don't know where the bug is; I'm just trying to help pin it down.)
>> Here it is!!
>> The problem is that for the following insn(insn 20 19 21 2 (set (reg:SI
>> 141) (xor:SI (subreg:SI (reg:SF 139) 0)
>> (reg:SI 140))) 65 {xorsi3} (expr_list:REG_EQUAL
>> (const_double:SF 0 [0x0] -0.0 [-0x0.0p+0])
>> (nil)))
>>
>> reg:SI 140 is known to have the constant value
>> (const_int -2147483648 [0x8000]))
>> and (subreg:SI (reg:SF 139) 0) is known to have the value
>> (const_double:SF 0 [0x0] 0.0 [0x0.0p+0]) [ as described by my
>> previous post in the same thread ]
>
> (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.
>
> Ian
Yes, absolutely so, we already know that there are problems there. For
references, see the threads "Deep CSE bug!"[*] and "Bogus REG_EQUIV note
generation"[**] (subject line was wrong, should have been REG_EQUAL all along)
from June last year, where we got some way into analysing the problem. I
/think/ that the presence of REG_RETVAL in this particular case is only
tangential to the problem; from what I remember of the discussion, this is
just about Gcc incorrectly handling reg notes when it decomposes
multi-word-size-mode moves into individual word-sized moves.
Pranav, although there is indeed a bug in the mid-end here, from your point
of view the simple and effective workaround should be to implement a movdi
pattern (and movsf and movdf if you don't have them yet: it's an absolute
requirement to implement movMM for any modes you expect your machine to
handle) in the backend. This won't fix the underlying bug, but it'll stop it
from affecting you, and you'll get better codegen all round into the bargain
if you expand movdi early.
cheers,
DaveK
[*] - http://gcc.gnu.org/ml/gcc/2004-06/msg00993.html
[**] - http://gcc.gnu.org/ml/gcc/2004-06/msg01178.html
--
Can't think of a witty .sigline today
RE: GCC compile models -- theory of operation?
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 directives) is >>> --static? If not, which of the various specfile macros need to be >>> updated? I know how to write specfile lines, I just want to make sure >>> that I don't miss one somewhere. >> >> >> Just to address this one: I suggest using DRIVER_SELF_SPECS, since that >> runs first of all, before anything else, and ensures that you will end up >> passing consistent specs to all of the individual sub-executables without >> having to worry that you could have missed one out somehow. > > Hmm. This is definitely not the type of answer I was expecting. Before I > ask stupid questions, let me go read about this. Is DRIVER_SELF_SPECS > documented somewhere? Yes. oh, ok then. It's in the internals manual! :-) cheers, DaveK -- Can't think of a witty .sigline today
Re: Semicolons at the end of member function definitions
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
| > {
| > void foo() {};
| > }
|
| That is indeed still legal in the current working draft. (The reason
| that I copied the grammar productions above the parser functions was so
| that it would be easy to check things like this...)
|
| > Therefore, IMHO the patch is wrong and should be reverted.
|
| Yes, please go ahead and revert it. And, if you have time, please add a
| test-case specifically for this case. The previous patch removed
| semicolons from lots of valid code, but probably none of those test
| cases were specifically for this case.
I agree with Mark.
Sorry for the confusion.
-- Gaby
RE: GCC compile models -- theory of operation?
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 specfile lines, I just want to make sure > that I don't miss one somewhere. Just to address this one: I suggest using DRIVER_SELF_SPECS, since that runs first of all, before anything else, and ensures that you will end up passing consistent specs to all of the individual sub-executables without having to worry that you could have missed one out somehow. cheers, DaveK -- Can't think of a witty .sigline today
Re: GCC compile models -- theory of operation?
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
> crtbegin.o?
crtbeginT.o is used for -static; crtbegin.o is used without -static.
I don't recall why they have to be different.
> 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 specfile lines, I just want to make sure
> that I don't miss one somewhere.
Like Dave I recommend DRIVER_SELF_SPECS. Or you can just not put
shared libraries in your default linker search path; that's basically
equivalent.
> 3. At least on i386, there are GOT sections appearing in
> crt{begin,end}.o and libgcc.a. Our target does not have any dynamic
> linking/loading support AT ALL. Are these sections fully resolved after
> link time?
Yes.
But it sounds like you are modelling after the wrong target, a Linux
one when you should be using an ELF one as base instead. You don't
need three CRT files or a separate -static option if you don't have
dynamic linking. And then you don't need to build libgcc with PIC
code in it, and there won't be GOT references any more.
--
Daniel Jacobowitz
CodeSourcery
Re: GCC compile models -- theory of operation?
"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, the only > difference is that crtbeginT is calling > > register_frame_info_bases > deregister_frame_info_bases > > I suspect that these are related to the exception frame walker, because > if --static (therefore crtbeginT) is provided then --eh-frame-header is > not applied by default. That is: I suspect that --static does not > support exception frame walking. This smells like a Linux legacy issue > that may not apply to us. Can anybody confirm or correct that guess? If you pass --eh-frame-header to the linker, it will create a PT_GNU_EH_FRAME segment in the output file. The code in gcc/unwind-dw2-fde-glibc.c will locate that segment by using dl_iterate_phdr. dl_iterate_phdr is provided by glibc. At one time it only worked for dynamically linked binaries, but I believe that it currently also works for statically linked binaries. So I believe that in principle it would now be possible to use --eh-frame-header and unwind-dw2-fde-glibc.c with statically linked binaries. But I haven't actually tried. In order for you to use --eh-frame-header, your libc will need to provide dl_iterate_phdr. The advantage of this approach is that it does not require registering the exceptions at program start time, thus saving a bit of startup time. Also, if everything works correctly, the linker will create a sorted list of FDEs, which will permit faster lookup of the required stack unwinding information when an exception occurs. If you don't have dl_iterate_phdr, then you will need to call register_frame_info_bases at startup time. And you won't want to use --eh-frame-header. All of this is completely ELF specific, by the way. Ian
RE: ARM constant folding bug?
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 code > fragment is: > > const unsigned long ul = 0x04030201llu; > > if ( *((char *) &ul) == 0x1 ) > ASMDEF(LITTLE_ENDIAN); > else > ASMDEF(BIG_ENDIAN); > > The expectation is that when run with -O2, the compiler should > constant-fold all of this stuff away, resulting in exactly one ASMDEF. > On i386 and m68k, the constant folding occurs as expected. For ARM it > does not(!). > > 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 independent. 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? cheers, DaveK -- Can't think of a witty .sigline today
RE: GCC compile models -- theory of operation?
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 specfile macros need to be > > updated? I know how to write specfile lines, I just want to make sure > > that I don't miss one somewhere. > > > Just to address this one: I suggest using DRIVER_SELF_SPECS, since that runs > first of all, before anything else, and ensures that you will end up passing > consistent specs to all of the individual sub-executables without having to > worry that you could have missed one out somehow. Hmm. This is definitely not the type of answer I was expecting. Before I ask stupid questions, let me go read about this. Is DRIVER_SELF_SPECS documented somewhere? shap
Re: ICE on valid code, cse related
"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 (reg:SF 139), 0) shouldnt be able to hold the value > (float:SF (reg:SI 138) ? Am I right on this ? (subreg:SI (reg:SF 139), 0) implies an SImode lvalue. You can't store an SFmode value into an SImode lvalue. You could store (reg:SI 138) there, or you could store (subreg:SI (float:SF (reg:SI 138)) 0) there. > Because the expander > generates the following while storing the return value > (insn 17 18 19 testcase-min.i:8 (set (subreg:SI (reg:SF 139) 0) > (mem/c/i:SI (reg/f:SI 129 virtual-stack-vars) [2 S4 A32])) -1 > (expr_list:REG_LIBCALL_ID (const_int 1 [0x1]) > (insn_list:REG_RETVAL 14 (expr_list:REG_EQUAL (float:SF (reg:SI 138)) > (nil) I guess that insn arguably has a mismatch between the mode of the REG_EQUAL node and the mode of the destination of the set. It's a confusing situation. Ian
vect failures at -m64 on darwin
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 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vectorized 1 loops 0 FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump-times vectorization not profitable 1 FAIL: gcc.dg/vect/vect-28.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-33.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times Vectorizing an unaligned access 2 FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-44.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-70.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/vect-91.c scan-tree-dump-times Vectorizing an unaligned access 0 FAIL: gcc.dg/vect/vect-91.c scan-tree-dump-times Alignment of access forced using peeling 3 FAIL: gcc.dg/vect/vect-93.c scan-tree-dump-times Alignment of access forced using peeling 3 FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times Vectorizing an unaligned access 1 FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times Alignment of access forced using peeling 1 FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors) FAIL: gcc.dg/vect/section-anchors-vect-69.c (test for excess errors) FAIL: gcc.dg/vect/section-anchors-vect-69.c scan-tree-dump-times Alignment of access forced using peeling 4 FAIL: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times Alignment of access forced using peeling 2 A quick look at the *.vect files show that there is no lines with "peeling". Is this a bug in the build or in the testsuite? Dominique
Re: [CFG] what are class 3 edges ?
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:
exit(1);
}
Regards
--
Emmanuel Fleury
A thing is not necessarily true because a man dies for it.
-- Oscar Wilde
GCC compile models -- theory of operation?
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. 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
crtbegin.o?
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 specfile lines, I just want to make sure
that I don't miss one somewhere.
3. At least on i386, there are GOT sections appearing in
crt{begin,end}.o and libgcc.a. Our target does not have any dynamic
linking/loading support AT ALL. Are these sections fully resolved after
link time?
Thanks
Jonathan Shapiro
Re: ARM constant folding bug?
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 at compile time and /have/ to test it at runtime? > > No. You can't generate code in general that works on both! Then it seems very curious that the constant folding should fail on this platform. Any idea what may be going on here? shap
Re: delete LIBCALL note after split
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 REG_LIBCALL note and with REG_RETVAL note > > + after split. */ > + note_libcall > += find_reg_note (trial, REG_LIBCALL, NULL); You don't need to look up the note again in TRIAL, you already have it in the NOTE variable. > + REG_NOTES (insn_last) = note_libcall; Notes are a linked list, so this will 1) move the whole linked list to INSN_LAST; 2) clobber the existing notes on INSN_LAST. You need to do something like REG_NOTES (insn_last) = gen_rtx_EXPR_LIST (REG_LIBCALL, XEXP (note_libcall, 0), REG_NOTES (insn_last)); Ian
Re: [CFG] what are class 3 edges ?
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.
>
> why ? there is no way there will be flow from BB1 to BB2. so why to create
> those edges in the first place ?
I can't tell with so few details, but it might happen in some specific
cases and under some optimization algorithms that an 'if' will be
changed into a 'switch' (e.g. if your 'condition' is a chain of and/or).
Regards
--
Emmanuel Fleury
Men are born ignorant, not stupid. They are made stupid by education.
-- Bertrand Russel (A History of Western Philosophy, 1945)
Re: [CFG] what are class 3 edges ?
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 ?
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.
why ? there is no way there will be flow from BB1 to BB2. so why to create
those edges in the first place ?
thank you
sunzir
RE: ARM constant folding bug?
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 independent. > > 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? That seems counter-intuitive, since a given compiler instance is configured for a target with a particular endian-ness. Even if the compiler can evade knowledge, the assembler surely must know. Of course, I am not running the assembler here. In any case, an interesting hypothesis. Would also explain some code pessimization issues for ARM targets more generally. shap
Link start address
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 to GCC, and I am wondering if this may make things more complicated. This is an ELF target. If we simply issue a --section-start for the .init section from GCC, will the other sections get adjusted accordingly under the generic linker script, or do we need to do something more involved? If it's more involved, where to look? Bother. I used to know how to do this. :-) shap
[CFG] what are class 3 edges ?
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
Re: GCC compile models -- theory of operation?
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
Re: ARM constant folding bug?
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 generate code in general that works on both! -- Daniel Jacobowitz CodeSourcery
Re: ARM constant folding bug?
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. 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 generate code in general that works on both! > > 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 accessing a 32-bit int as type char. I tested several compilers (4.2, 4.1 and 3.4 x86, 4.2 m68k and 4.2 arm) and the only one that eliminated the comparison was 3.4-x86. My guess is that most optimization passes see this type punning, and leave well alone. You're probably relying on the low-level RTL optimizers to spot this, which depending on architecture may be too late for it to be provably safe. I'm fairly surprised it got caught at all. Paul
Re: delete LIBCALL note after split
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-rtl.c +++ gcc/emit-rtl.c @@ -3121,7 +3121,7 @@ try_split (rtx pat, rtx trial, int last) rtx before = PREV_INSN (trial); rtx after = NEXT_INSN (trial); int has_barrier = 0; - rtx tem; + rtx tem, note_retval; rtx note, seq; int probability; rtx insn_last, insn; @@ -3257,6 +3257,17 @@ try_split (rtx pat, rtx trial, int last) break; #endif + case REG_LIBCALL: + /* Relink the insns with REG_LIBCALL note and with REG_RETVAL note + after split. */ + REG_NOTES (insn_last) + = gen_rtx_EXPR_LIST (REG_LIBCALL, +XEXP (note, 0), +REG_NOTES (insn_last)); + note_retval = find_reg_note (XEXP (note, 0), REG_RETVAL, NULL); + XEXP (note_retval, 0) = insn_last; + break; + default: break; } Sa
ARM constant folding bug?
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; if ( *((char *) &ul) == 0x1 ) ASMDEF(LITTLE_ENDIAN); else ASMDEF(BIG_ENDIAN); The expectation is that when run with -O2, the compiler should constant-fold all of this stuff away, resulting in exactly one ASMDEF. On i386 and m68k, the constant folding occurs as expected. For ARM it does not(!). 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 independent. Can somebody explain what is going on here? shap
Re: GCC compile models -- theory of operation?
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 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 exception frame walker, because if --static (therefore crtbeginT) is provided then --eh-frame-header is not applied by default. That is: I suspect that --static does not support exception frame walking. This smells like a Linux legacy issue that may not apply to us. Can anybody confirm or correct that guess? I think I need to understand the eh-frame support better. Where should I look for documentation on that? > > 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 specfile lines, I just want to make sure > > that I don't miss one somewhere. > > Like Dave I recommend DRIVER_SELF_SPECS. Or you can just not put > shared libraries in your default linker search path; that's basically > equivalent. I can try this, and I'll look at the docs on that. > But it sounds like you are modelling after the wrong target, a Linux > one when you should be using an ELF one as base instead. You don't > need three CRT files or a separate -static option if you don't have > dynamic linking. And then you don't need to build libgcc with PIC > code in it, and there won't be GOT references any more. We are going to want to have the PIE and shared models later, so I don't want to disable those. At the moment all I am really trying to do is to get --static working correctly.
Re: GCC compile models -- theory of operation?
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 exception frame walker, because > if --static (therefore crtbeginT) is provided then --eh-frame-header is > not applied by default. That is: I suspect that --static does not > support exception frame walking. This smells like a Linux legacy issue > that may not apply to us. Can anybody confirm or correct that guess? Close but no. Exception unwinding works fine. But it's done using register_frame_info_bases instead of --eh-frame-header, IIRC. Yes, it probably does not apply to you. > > But it sounds like you are modelling after the wrong target, a Linux > > one when you should be using an ELF one as base instead. You don't > > need three CRT files or a separate -static option if you don't have > > dynamic linking. And then you don't need to build libgcc with PIC > > code in it, and there won't be GOT references any more. > > We are going to want to have the PIE and shared models later, so I don't > want to disable those. At the moment all I am really trying to do is to > get --static working correctly. Trying to configure the compiler to support anything involving dynamic linking before you have the linker and execution support ready is definitely going to be a headache. -- Daniel Jacobowitz CodeSourcery
Re: delete LIBCALL note after split
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 notes at all. It's quite unusual to be able to > split a libcall insn, so it's not surprising that this has not been > noticed previously. > > Ian Thanks for replying, Ian! 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. Index: gcc/emit-rtl.c === --- gcc.orig/emit-rtl.c +++ gcc/emit-rtl.c @@ -3121,7 +3121,7 @@ try_split (rtx pat, rtx trial, int last) rtx before = PREV_INSN (trial); rtx after = NEXT_INSN (trial); int has_barrier = 0; - rtx tem; + rtx tem, note_libcall, note_retval; rtx note, seq; int probability; rtx insn_last, insn; @@ -3257,6 +3257,17 @@ try_split (rtx pat, rtx trial, int last) break; #endif + case REG_LIBCALL: + /* Relink the insns with REG_LIBCALL note and with REG_RETVAL note + after split. */ + note_libcall += find_reg_note (trial, REG_LIBCALL, NULL); + REG_NOTES (insn_last) = note_libcall; + note_retval += find_reg_note (XEXP (note_libcall, 0), REG_RETVAL, NULL); + XEXP (note_retval, 0) = insn_last; + break; + default: break; } Thanks, Sa
Re: GCC compile models -- theory of operation?
"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 whether this is documented somewhere. Jakub Jelinek (CC'ed) wrote some of this stuff, let's see what he has to say about it. Ian
Re: ARM constant folding bug?
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 accessing a 32-bit int as > type char. I tested several compilers (4.2, 4.1 and 3.4 x86, 4.2 m68k and 4.2 > arm) and the only one that eliminated the comparison was 3.4-x86. FWIW, rewriting it with the "obvious" union approach seems to give the desired results on 4.2 arm with and without -mbig-endian. -Nathan
RE: ARM constant folding bug?
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? >> >> You're exploiting a hole in the C aliasing rules by accessing a 32-bit int >> as type char. I tested several compilers (4.2, 4.1 and 3.4 x86, 4.2 m68k >> and 4.2 arm) and the only one that eliminated the comparison was 3.4-x86. > > FWIW, rewriting it with the "obvious" union approach seems to give the > desired results on 4.2 arm with and without -mbig-endian. Shouldn't it also work by changing the (char *) cast to (unsigned char *), since IIUIC the standard guarantees you're allowed to access any object as an array of unsigned char and not get into aliasing difficulties? cheers, DaveK -- Can't think of a witty .sigline today
RE: ARM constant folding bug?
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 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 accessing a 32-bit int as type char. I tested several compilers (4.2, 4.1 and 3.4 x86, 4.2 m68k and 4.2 arm) and the only one that eliminated the comparison was 3.4-x86. >>> >>> FWIW, rewriting it with the "obvious" union approach seems to give the >>> desired results on 4.2 arm with and without -mbig-endian. >> >> Shouldn't it also work by changing the (char *) cast to (unsigned char >> *), since IIUIC the standard guarantees you're allowed to access any >> object as an array of unsigned char and not get into aliasing difficulties? > > The standard makes the same guarantee about (char *). This is not > "exploiting a hole"; it is standard C that you can access anything > as (char *). Well, the compiler's not doing anything invalid by failing to optimise a constant expression, so everything's all still valid and compliant. Shame it can't recognize the cast case same as the union case and optimise them the same though. cheers, DaveK -- Can't think of a witty .sigline today
Re: ARM constant folding bug?
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 fail on this > >>> platform. Any idea what may be going on here? > >> > >> You're exploiting a hole in the C aliasing rules by accessing a 32-bit int > >> as type char. I tested several compilers (4.2, 4.1 and 3.4 x86, 4.2 m68k > >> and 4.2 arm) and the only one that eliminated the comparison was 3.4-x86. > > > > FWIW, rewriting it with the "obvious" union approach seems to give the > > desired results on 4.2 arm with and without -mbig-endian. > > Shouldn't it also work by changing the (char *) cast to (unsigned char *), > since IIUIC the standard guarantees you're allowed to access any object as an > array of unsigned char and not get into aliasing difficulties? The standard makes the same guarantee about (char *). This is not "exploiting a hole"; it is standard C that you can access anything as (char *).
Re: ARM constant folding bug?
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 here? > > > > You're exploiting a hole in the C aliasing rules by accessing a 32-bit int > > as > > type char. I tested several compilers (4.2, 4.1 and 3.4 x86, 4.2 m68k and > > 4.2 > > arm) and the only one that eliminated the comparison was 3.4-x86. > > FWIW, rewriting it with the "obvious" union approach seems to give the > desired results on 4.2 arm with and without -mbig-endian. Curiously, rewriting it with the "obvious" union approach didn't work at all on gcc-3.4.6. We're going to move forward go gcc-4.x anyway, but there are other priorities at the moment. shap
Re: vect failures at -m64 on darwin
> 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://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00447.html, http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00082.html). I outlined possible fixes, if this is indeed the case, in http://gcc.gnu.org/ml/fortran/2007-08/msg00067.html. dorit > FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-33.c scan-tree-dump- > times vectorization not profitable 1 > FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump- > times vectorized 1 loops 0 > FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-76b.c scan-tree-dump- > times vectorization not profitable 1 > FAIL: gcc.dg/vect/vect-28.c scan-tree-dump-times Alignment of access > forced using peeling 1 > FAIL: gcc.dg/vect/vect-33.c scan-tree-dump-times Alignment of access > forced using peeling 1 > FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times Vectorizing an > unaligned access 2 > FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times Alignment of access > forced using peeling 1 > FAIL: gcc.dg/vect/vect-44.c scan-tree-dump-times Alignment of access > forced using peeling 1 > FAIL: gcc.dg/vect/vect-50.c scan-tree-dump-times Alignment of access > forced using peeling 1 > FAIL: gcc.dg/vect/vect-70.c scan-tree-dump-times Alignment of access > forced using peeling 1 > FAIL: gcc.dg/vect/vect-87.c scan-tree-dump-times Alignment of access > forced using peeling 1 > FAIL: gcc.dg/vect/vect-88.c scan-tree-dump-times Alignment of access > forced using peeling 1 > FAIL: gcc.dg/vect/vect-91.c scan-tree-dump-times Vectorizing an > unaligned access 0 > FAIL: gcc.dg/vect/vect-91.c scan-tree-dump-times Alignment of access > forced using peeling 3 > FAIL: gcc.dg/vect/vect-93.c scan-tree-dump-times Alignment of access > forced using peeling 3 > FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times Vectorizing an > unaligned access 1 > FAIL: gcc.dg/vect/vect-96.c scan-tree-dump-times Alignment of access > forced using peeling 1 > FAIL: gcc.dg/vect/section-anchors-pr27770.c (test for excess errors) > FAIL: gcc.dg/vect/section-anchors-vect-69.c (test for excess errors) > FAIL: gcc.dg/vect/section-anchors-vect-69.c scan-tree-dump-times > Alignment of access forced using peeling 4 > FAIL: gcc.dg/vect/no-section-anchors-vect-69.c scan-tree-dump-times > Alignment of access forced using peeling 2 > > A quick look at the *.vect files show that there is no lines with "peeling". > Is this a bug in the build or in the testsuite? > > Dominique >
gcc-4.3-20070803 is now available
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 revision 127188 You'll find: gcc-4.3-20070803.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070803.tar.bz2 C front end and core compiler gcc-ada-4.3-20070803.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070803.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070803.tar.bz2 C++ front end and runtime gcc-java-4.3-20070803.tar.bz2 Java front end and runtime gcc-objc-4.3-20070803.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070803.tar.bz2The GCC testsuite Diffs from 4.3-20070727 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
