Re: Segment registers support for i386
Remy Saissy wrote:
>if I understand well, to make gcc generating rtx according to an
>__attribute__((far("fs"))) on a pointer I only have to add or modify
>rtx in the i386.md file and add an UNSPEC among the constants ?
No, the work you need to on the backend, adding an UNSPEC constant to
"i386.md" and writing code to handle the UNSPEC in "i386.c" is just the
easy part.
> What I understand is that there is two kind of managment for attribute :
Attributes are handled in various different ways depending on what the
attribute does. To handle your case correctly, you'ld have to change how
the tree to RTL conversion generates RTL addresses expressions whenever
a pointer with the "far" attribute is dereferenced. This is probably
going to be a lot work.
> Therefore, I can consider the following relationship:
> (mem:SI (plus:SI (unspec:SI [(reg:HI fs)] SEGREF) (reg:SI var)))
> | |||
> \/ \/ \/ \/
> int * __attribute__((far("fs"))) p;
No, that's not what the RTL expression represents. Declarations aren't
represented in RTL. The example RTL expression I gave is just an
expression, not a full RTL instruction. It's something that could be
used as the memory operand of an instruction. The RTL expression I gave
would correspond to a C expression (not a statement) like this:
*(int * __atribute__((far("fs" var
> does (reg:HI fs) care about the type of the parameter fs ?
See the GCC Internals documentation. In my example, since I don't know
what the actual hard register number you assigned to the FS segment
register, I just put "fs" in the place where the actual register number
would appear. Similarily, the "var" in "(reg:SI var)" represents
the number of the pseudo-register GCC would allocate for an automatic
variable named "var".
> how does gcc recognize such an expression ?
Since this expression is a memory operand, it's recognized by the
GO_IF_LEGITIMATE_ADDRESS() macro. In the i386 port, that's implemented
by legitimate_address_p() in "i386.c".
Ross Ridge
Documentating the removal of -fshared-data
The -fshared-data option has been removed in GCC 4.2, but as far as I can tell this is not documented anywhere. Would it be possible to mention this at http://gcc.gnu.org/gcc-4.2/changes.html, and possibly in a section of the GCC manual? 2006-02-21 Richard Sandiford <[EMAIL PROTECTED]> * doc/tm.texi (ASM_OUTPUT_SHARED_COMMON, ASM_OUTPUT_SHARED_BSS) ASM_OUTPUT_SHARED_LOCAL): Delete. * doc/invoke.texi (-fshared-data): Delete. * common.opt (fshared-data): Delete. -- Martin Michlmayr http://www.cyrius.com/
RE: [wwwdocs] RE: Gosh, GCC 3.4.6 does so exist...
On Sun, 28 May 2006, Dave Korn wrote: > Rightyho, I just inferred the date from the timestamps on the FTP server; > I've used 6th march in the announce message. However from where I'm sitting > the gcc.gnu.org front page still says March 10th - can you give it a tweak? Done. (I was going to change it, but Saurabh Verma now provided a patch, and I committed that one.) Gerald
RE: [wwwdocs] RE: Gosh, GCC 3.4.6 does so exist...
On 29 May 2006 15:18, Gerald Pfeifer wrote: > On Sun, 28 May 2006, Dave Korn wrote: >> Rightyho, I just inferred the date from the timestamps on the FTP server; >> I've used 6th march in the announce message. However from where I'm >> sitting the gcc.gnu.org front page still says March 10th - can you give it >> a tweak? > > Done. (I was going to change it, but Saurabh Verma now provided a patch, > and I committed that one.) > > Gerald Thanks! Bernard, you can cancel that cron job now! Thanks for reminding us :) cheers, DaveK -- Can't think of a witty .sigline today
Re: Segment registers support for i386
Ross Ridge wrote:
Remy Saissy wrote:
What I understand is that there is two kind of managment for attribute :
Attributes are handled in various different ways depending on what the
attribute does. To handle your case correctly, you'ld have to change how
the tree to RTL conversion generates RTL addresses expressions whenever
a pointer with the "far" attribute is dereferenced. This is probably
going to be a lot work.
I've looked for a target specific callback to modify but I've found
nothing, even in the gcc internals info pages. Do you mean I would
have to modify some code outside of the i386 directory ? Or maybe to
add such a callback if it doesn't exist ;)
In which file does the tree to RTL conversion code is located ?
Therefore, I can consider the following relationship:
(mem:SI (plus:SI (unspec:SI [(reg:HI fs)] SEGREF) (reg:SI var)))
| |||
\/ \/ \/ \/
int * __attribute__((far("fs"))) p;
No, that's not what the RTL expression represents. Declarations aren't
represented in RTL. The example RTL expression I gave is just an
expression, not a full RTL instruction. It's something that could be
used as the memory operand of an instruction. The RTL expression I gave
would correspond to a C expression (not a statement) like this:
*(int * __atribute__((far("fs" var
Ok, I thanks for the precisions :)
does (reg:HI fs) care about the type of the parameter fs ?
See the GCC Internals documentation. In my example, since I don't know
what the actual hard register number you assigned to the FS segment
register, I just put "fs" in the place where the actual register number
would appear. Similarily, the "var" in "(reg:SI var)" represents
the number of the pseudo-register GCC would allocate for an automatic
variable named "var".
Does it mean that an RTL expression which use reg: force gcc to use a
particular pseudo
register ? Is there something I should care about when I choose the
number of this pseudo
register ?
how does gcc recognize such an expression ?
Since this expression is a memory operand, it's recognized by the
GO_IF_LEGITIMATE_ADDRESS() macro. In the i386 port, that's implemented
by legitimate_address_p() in "i386.c".
Ok thank you very much.
Ross Ridge
--
Rémy SaissyJabberID: [EMAIL PROTECTED]
Web: http://remysaissy.free.fr
"L'homme qui a le plus vécu n'est pas celui qui a compté le plus d'années,
mais celui qui a le plus senti la vie."
J.-J. Rousseau, Emile.
Re: [wwwdocs] RE: Gosh, GCC 3.4.6 does so exist...
Dear List. my, that's good to have sorted. The prospect of having to start crond in my init scripts was truly frightening. Thanks, all! Bernard Leak -- Still fighting the good fight. Fights are good when I win them.
Freeing memory for basic-blocks and edges
I am looking for code that corresponds to freeing memory for BBs and Edges. For example, I know to allocate a chunk of memory to hold BB information is done by "ggc_alloc_cleared()". But after a function analysis/optimization is done, the memory should be freed. I tried to read code in rest_of_clean_state() in passes.c, which calls free_basic_block_vars(). But I did not see it actually free memory usage. Can someone show me the procedure related to the above process? Thanks, Sean _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: Freeing memory for basic-blocks and edges
On 5/29/06, sean yang <[EMAIL PROTECTED]> wrote: I am looking for code that corresponds to freeing memory for BBs and Edges. It's called gcc-page.c on most systems. Gr. Steven
c++ regression in trunk
In building xplor-nih against the gcc trunk, I noticed that there is a c++ related regression that isn't present when building xplor-nih against gcc 4.1.1 or the gfortran of gcc trunk and the gcc/g++ of Apple's current Xcode 2.3 release. The error shows up in xplor-nih's dipCoup.inp test which aborts as follows when built with g++ from the trunk... --- -- POWELL -- step= 5 --- stepsize= 0.020455 --- energy evals=2 -- | Etotal =181.583grad(E)=4.894 E(BOND)=6.068 E(ANGL)=160.218| | E(IMPR)=5.596 E(XDIP)=9.701| --- Powell::step: irregular exit: Line search abandoned: gradient may be incorrect terminate called after throwing an instance of 'Integrator::Finished' Program received signal SIGABRT, Aborted. 0x9004802c in kill () (gdb) bt #0 0x9004802c in kill () #1 0x9012dfb4 in abort () #2 0x052a9df4 in __gnu_cxx::__verbose_terminate_handler () at ../../../../gcc-4.2-20060526/libstdc++-v3/libsupc++/vterminate.cc:98 #3 0x052a78b8 in __cxxabiv1::__terminate (handler=0) at ../../../../gcc-4.2-20060526/libstdc++-v3/libsupc++/eh_terminate.cc:43 #4 0x052a67a4 in __cxa_call_terminate (ue_header=0x5a346d0) at ../../../../gcc-4.2-20060526/libstdc++-v3/libsupc++/eh_call.cc:59 #5 0x052a75fc in __gxx_personality_v0 (version=0, actions=2, exception_class=11529286998044974156, ue_header=0x5a346d0, context=0xbfffcb2c) at ../../../../gcc-4.2-20060526/libstdc++-v3/libsupc++/eh_personality.cc:639 #6 0x91429918 in _Unwind_RaiseException_Phase2 () #7 0x91429a18 in _Unwind_Resume () #8 0x0022d19c in Powell::step (this=0x5a3d940, stepsize=0.00039998906256061956) at dint-powell.cc:321 #9 0x00207728 in IVM::step (this=0x5a0d050, [EMAIL PROTECTED]) at dinternal.cc:813 #10 0x0023c268 in XplorIVM::entry (this=0x5a0d050) at dint-xplor.cc:804 #11 0x02970b34 in dynmcs_ (fbeta=0x0, x=0x0, y=0xa0004170, z=0xa0001c4c, dx=0x5a346d0, dy=0xbfffb33c, dz=0x5a24230, xv=0x900227b4, yv=0x6287600, zv=0x6289000, amass=0x628c400, imove=0x628de00, res=0x6292400, resid=0x6293200, type=0x6294000, ib=0x600b400, jb=0x600ce00, _res=-1073750708, _resid=12192, _type=12200) at dynamc.f:86 #12 0x000634c4 in xplor_parse_ ([EMAIL PROTECTED]) at xplorFunc.f:423 #13 0x27b4 in main (argc=2, argv=0xbfffde58) at xplor.c:116 The "Powell::step: irregular exit: Line search abandoned: gradient may be incorrect" output is normal, but the terminate called isn't of course. Building the c++ code in xplor-nih with -O0 doesn't eliminate this problem. Does this issue resemble any existing PR or should I attempt to pin this one done (which may be difficult since the code is pretty complex)? Jack
Re: Expansion of __builtin_frame_address
Mark Shinwell wrote: > Hi, > > I'd like to gather some opinions and advice on the expansion of > __builtin_frame_address, as discussed on gcc-patches last year [1, 2]. > This centres on the following comment in expand_builtin_return_addr > arising from revision 103294 last year: I've explicitly Cc'd Jim Wilson on this email, since he did the work in this area that you cite. I'm not sure whether Jim is reading GCC email presently or not, but I want to give him every opportunity to comment. > Let us come back to the more general case. As identified above, when > expand_builtin_return_addr is used to expand __builtin_frame_address (), > we do care about the count == 0 case. I believe that the comment should > be adjusted to reflect this whatever other changes, if any, are made. I think this is non-controversial. > As for the remaining problem, I suggest that we could: > > (i) always return the hard frame pointer, and disable FP elimination in > the current function; or > > (iii) ...the same as option (i), but allow targets to define another macro > that will cause the default code to use the soft frame pointer rather than > the hard frame pointer, and hence allow FP elimination. (If such a macro > were set by a particular target, am I right in thinking that it would be > safe to use the soft frame pointer even in the count >= 1 cases?) > I tend to think that option (iii) might be best, although perhaps it > is overkill and option (i) would do. But I'm not entirely sure; > still being a gcc novice I have to admit to not being quite thoroughly > clear on this myself at this stage. So any advice or comments would be > appreciated! I agree that option (iii) is best, as it provides the ability to optimize on platforms where that is feasible, and still provides a working default elsewhere. I will review and approve a suitable patch to implement (iii), assuming that there are no objections from Jim or others. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
typeof and const qualifier
Hi,
gcc 4.1 changed the typeof behaviour and now includes the type const
qualifier, which unfortunately breaks existing code. The example below is
simplified example from the Linux kernel (i386 was "fixed", but that's
not the only arch).
The first get_user() produces nice code with 4.0 and earlier, but it
breaks with 4.1 and so far I have not been able to produce an equivalent
version. It either produces warnings and/or it produces worse code or it
is less flexible (the second get_user() is one example).
How can I get this working? How can get rid of the const qualifier? In
other examples (like max()), it's possible to work around it by including
the initialization with the definition, but if the variable is initialized
via an asm() this isn't possible.
bye, Roman
#if 1
#define get_user(p) ({ \
typeof (*(p)) _v; \
\
switch (sizeof(*(p))) { \
case 1: \
asm volatile ("#1: %0 = %1" : "=r" (_v) : "m" (*p));\
break; \
case 2: \
asm volatile ("#2: %0 = %1" : "=r" (_v) : "m" (*p));\
break; \
case 4: \
asm volatile ("#4: %0 = %1" : "=r" (_v) : "m" (*p));\
break; \
case 8: \
asm volatile ("#8: %0 = (%1)" : "=r" (_v) : "a" (p)); \
break; \
} \
_v; \
})
#else
#define get_user(p) ({ \
long long _v; \
\
switch (sizeof(*(p))) { \
case 1: { \
char __v; \
asm volatile ("#1: %0 = %1" : "=r" (__v) : "m" (*p)); \
_v == __v; \
break; } \
case 2: { \
short __v; \
asm volatile ("#2: %0 = %1" : "=r" (__v) : "m" (*p)); \
_v == __v; \
break; } \
case 4: { \
int __v;\
asm volatile ("#4: %0 = %1" : "=r" (__v) : "m" (*p)); \
_v == __v; \
break; } \
case 8: { \
long long __v; \
asm volatile ("#8: %0 = (%1)" : "=r" (__v) : "a" (p)); \
_v == __v; \
break; } \
} \
(typeof (*(p)))_v; \
})
#endif
typedef void *void_ptr;
char test1(char *p)
{
return get_user(p);
}
short test2(short *p)
{
return get_user(p);
}
int test3(int *p)
{
return get_user(p);
}
long long test4(long long *p)
{
return get_user(p);
}
void_ptr test5(void_ptr *p)
{
return get_user(p);
}
int test6(short *p)
{
return get_user(p);
}
char test7(short *p)
{
return get_user(p);
}
char test8(const char *p)
{
return get_user(p);
}
short test9(const short *p)
{
return get_user(p);
}
int test10(const int *p)
{
return get_user(p);
}
long long test11(const long long *p)
{
return get_user(p);
}
void_ptr test12(const void_ptr *p)
{
return get_user(p);
}
int test13(const short *p)
{
return get_user(p);
}
char test14(const short *p)
{
return get_user(p);
}
call_insns in RTX form--two questions
The first question is: If I want to find a BB that containing a specific
function call (say 'foo'), is there an easy way in the RTX level?
The second one is: how can i get the order of different call foo in the
final assembly code. Can I get it by dumping some information, say the order
of the instruction link list, in RTL representation?
Many thanks,
Sean
---
FOR_EACH_BB(bb){
for (cur_insn = BB_HEAD (bb); cur_insn != NEXT_INSN (BB_END (bb));
cur_insn = NEXT_INSN (cur_insn)){
if (GET_CODE (cur_insn)==CALL_INSN && /*test if the call is 'foo'*/){
//Question (1)
fprintf ("this is %dth call foo instruction \n", /*some dump*/);
//Question (2)
}
}
}
_
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
RE: call_insns in RTX form--two questions
I guess maybe the 2nd question is a little uncommon, but thank for any
advice.
From: "sean yang" <[EMAIL PROTECTED]>
To: gcc@gcc.gnu.org
Subject: call_insns in RTX form--two questions
Date: Tue, 30 May 2006 04:09:03 +
The first question is: If I want to find a BB that containing a specific
function call (say 'foo'), is there an easy way in the RTX level?
The second one is: how can i get the order of different call foo in the
final assembly code. Can I get it by dumping some information, say the
order of the instruction link list, in RTL representation?
Many thanks,
Sean
---
FOR_EACH_BB(bb){
for (cur_insn = BB_HEAD (bb); cur_insn != NEXT_INSN (BB_END (bb));
cur_insn = NEXT_INSN (cur_insn)){
if (GET_CODE (cur_insn)==CALL_INSN && /*test if the call is 'foo'*/){
//Question (1)
fprintf ("this is %dth call foo instruction \n", /*some dump*/);
//Question (2)
}
}
}
_
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
_
Express yourself instantly with MSN Messenger! Download today - it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
Re: configure: error: expected an absolute directory name for --prefix
On May 28, 2006, at 2:06 PM, Manuel López-Ibáñez wrote: Thanks Andrew, that is exactly what I did, although I was expecting configure to be smart enough to use that trick on my behalf. but that would be guessing what you meant and not requiring you to explicitly say what you meant. -eric
Re: Errors while building bootstrap GCC for "mipsisa32-elf" target
On May 28, 2006, at 11:06 PM, Monika Sapra wrote: Hi all, I am new to this list and GCC compiler. I am trying to build GCC4.1.0 for "mipsisa32-elf" target. I would appreciate if someone could help me out in resolving the errors during build process. You should really use a combined tree for this. There are also docs on the web page on how to build a cross toolchain: http://gcc.gnu.org/simtest-howto.html -eric
