cloog static build
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I build my gcc windows versions (*-pc-cygwin, *-pc-mingw32, *-w64-mingw32) using static build libraries gmp, mpfr, mpc, ppl and cloog. Configuration and building of gcc is really easy using the --with-host-libstdcxx configure switch. That's not true for cloog. If configured against static versions of gmp and ppl I have to edit the Makefile manually and add -lstdc++ to LIBS. Is there a possibility to check at configure time if a static version of gmp is used and add -lstdc++ dependent on the result? Cheers, Rainer P.S.: I'm using cloog-ppl-0.15.3. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkp/5sMACgkQoUhjsh59BL5dCACgwYYfY7smYWA5RdkT0O7W9y6f BkwAoKmRvsfykaF7tGPsY3BFjuj2f31n =1jaE -END PGP SIGNATURE-
Re: regarding optimization options in phase ordering
pms writes: > thanks, But b=a is a assignment statement. It is doing some memory operations > isn't it. Assuming b=a is a dead statement, how r the following i386 > assembly statements generated > pushl %ebp > movl%esp, %ebp > andl$-16, %esp > subl$16, %esp > movl$5, 4(%esp) > movl$.LC0, (%esp) > callprintf The first four statements set up the stack. The last three do the printf statement. What is your real question? Ian
Re: How to link a static lib when build a shared lib ?
Andy writes: > I got that, glibc can support SHA in crypt lib since v2.7. > > There is a requirement in my application to use SHA, but update the > whole glibc is too risky. So I want to build a specific crypt lib for > the module using crypt function in my application. > > Now the calling graph seems like this, from a simple view. > > crypt_user.c > call crypt() function in libcrypt.so > > myutil.c -> call functions in crypt_user.c, and it will be build > to a shared lib, libmyutil.so > > Executable program : server -> need to use libmyutil.so to work. > > Now I can ONLY use the latest static lib libcrypt.a from the new > glibc. How should I use it ？ Link it when build libmyutil.so or build > server ? > > I tried to update my Makefile to link the libcrypt.a, but seems that > the called crypt function is not as I expected, it's still from the old glibc. > > Could anybody give me a help with how to use the gcc option and write > a working Makefile ? This is the wrong mailing list. gcc@gcc.gnu.org is for discussion by gcc developers. You can try gcc-h...@gcc.gnu.org. What you are trying to do is not supported. I would recommend simply finding source code for the SHA function--you should be able to find it on the web--and using that. Ian
ifcvt.c question.
Hi,
While experimenting to see if some of the bits in the ARM backend which
do predicated execution can be removed in favour of the more generic
bits in ifcvt.c. I attempted to turn on conditional calls using the
predicable attribute on the ARM port.
I've run into an ICE in the ifcvt pass for the following testcase.
typedef int SItype __attribute__ ((mode (SI)));
typedef int DItype __attribute__ ((mode (DI)));
SItype
__mulvsi3 (SItype a, SItype b)
{
const DItype w = (DItype) a * (DItype) b;
if ((SItype) (w >> (4 * 8)) != (SItype) w >> ((4 * 8) - 1))
abort ();
return w;
}
test.c:14:1: internal compiler error: in merge_if_block, at ifcvt.c:2968
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
The ICE is because the following assert fails.
/* We cannot merge the JOIN. */
/* The outgoing edge for the current COMBO block should already
be correct. Verify this. */
gcc_assert (single_succ_p (combo_bb)
&& single_succ (combo_bb) == join_bb);
Here's what ifcvt does before the crash .
IF-THEN block found, pass 1, start block 2 [insn 5], then 3 [14], join 1
[-1]
rescanning insn with uid = 15.
deleting insn with uid = 15.
1 insn was converted to conditional execution.
merging block 3 into block 2
deleting insn with uid = 13.
deleting insn with uid = 14.
changing bb of uid 15
from 3 to 2
The insns deleted are :
(jump_insn 13 12 14 2 test.c:9 (set (pc)
(if_then_else (eq (reg:CC 24 cc)
(const_int 0 [0x0]))
(return)
(pc))) 258 {*cond_return} (expr_list:REG_DEAD (reg:CC 24 cc)
(expr_list:REG_BR_PROB (const_int 9996 [0x270c])
(nil
(note 14 13 15 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
insn 15 whose bb is changed from 3 to 2 is the call to abort.
(call_insn 15 14 16 3 test.c:10 (parallel [
(call (mem:SI (symbol_ref:SI ("abort") [flags 0x41]
) [0 S4 A32])
(const_int 0 [0x0]))
(use (const_int 0 [0x0]))
(clobber (reg:SI 14 lr))
]) 251 {*call_symbol} (expr_list:REG_NORETURN (const_int 0
[0x0])
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil)))
(nil))
In this case before if-conversion you have a basic block structure of
the following form.
[2] (cond_return is the last instruction)
|
[3] (call abort) (REG_EH_NO_RETURN)
|
[1] - Exit block
ifcvt then goes ahead and converts the call to abort into a conditional
call and should ideally convert the conditional return as a normal
return i.e. by moving the last instruction in [2] into [3] as an
unconditional return. It does the first part correctly which is
converting the call to a conditional call but incorrectly removes the
unconditional return.
Note however that thread_prologue_and_epilogue inserts an extra return
instruction in basic block 4 but this gets removed by cfg_cleanup the
next time it is run before dse2 because bb4 is unreachable. The ARM
backend is correct in generating a conditional return in this case,
because it is capable of generating a load multiple instruction that
restores the PC as well as the saved integer registers.
I wonder if the best way to fix this is to teach ifcvt.c to handle
conditional returns. Should I be fixing this inside ifcvt.c by handling
conditional returns specially or should I be looking elsewhere ?
I've attached the dumps and the original patch to turn on the predicable
attribute for the ARM backend with this email.
Thanks in advance for the answers.
cheers
Ramana
Attachments
1. Patch to turn on predicable attributes on all the ARM call patterns.
2. Dumps of the testcase that are relevant, test.c.*.peephole2,
test.c.*.dse2, test.c.*.ce3. (dumps.tar.bz2)
3. Testcase test.c
--
Ramana Radhakrishnan
GNU Tools
ARM Ltd.
Index: arm.md
===
--- arm.md (revision 150565)
+++ arm.md (working copy)
@@ -4860,7 +4860,8 @@ (define_insn "*arm_movdi"
[(set_attr "length" "8,12,16,8,8")
(set_attr "type" "*,*,*,load2,store2")
(set_attr "pool_range" "*,*,*,1020,*")
- (set_attr "neg_pool_range" "*,*,*,1008,*")]
+ (set_attr "neg_pool_range" "*,*,*,1008,*")
+ (set_attr "predicable" "yes")]
)
(define_split
@@ -8446,7 +8447,8 @@ (define_insn "*call_value_reg_armv5"
(clobber (reg:SI LR_REGNUM))]
"TARGET_ARM && arm_arch5"
"blx%?\\t%1"
- [(set_attr "type" "call")]
+ [(set_attr "type" "call")
+ (set_attr "predicable" "yes")]
)
(define_insn "*call_value_reg_arm"
@@ -8460,7 +8462,8 @@ (define_insn "*call_value_reg_arm"
return output_call (&operands[1]);
"
[(set_attr "length" "12")
- (set_attr "type" "call")]
+ (set_attr "type" "call")
+ (set_attr "predicable" "yes")]
)
(define_insn "*call_value_mem"
@@ -8474,7 +8477,8 @@ (define_insn "*call_value_mem"
return output_call_mem (&operands[1]);
"
[(set_attr "length" "12")
- (
Re: regarding optimization options in phase ordering
Thanx Ian,
My question is as follwos
We've a problem here. we were trying to use cc1 with & without -O option to
verify the optimizations happening in our sample code.
the sample code is given below
file name : 1.c
#include
int main()
{ int a=5;
int b;
b=a;
printf("the number is :%d",b); }
Here, in 1.c.026t.copyrename1, we get the following output
1.c.026t.copyrename1
;; Function main (main)
main ()
{ int b; int a; : a_2 = b_1(D); return; }
but in 1.c.027t.ccp1, the output does not contain the actual assignment
b=a.
;; Function main (main)
main ()
{ int b; int a; : return; }
We want to know, without b=a, how is it generating the following final code
for b=a
pushl %ebp
> movl%esp, %ebp
> andl$-16, %esp
> subl$16, %esp
> movl$5, 4(%esp)
> movl$.LC0, (%esp)
> callprintf
Kindly help
> thanks, But b=a is a assignment statement. It is doing some memory
> operations
> isn't it. Assuming b=a is a dead statement, how r the following i386
> assembly statements generated
> pushl %ebp
> movl%esp, %ebp
> andl$-16, %esp
> subl$16, %esp
> movl$5, 4(%esp)
> movl$.LC0, (%esp)
> callprintf
The first four statements set up the stack. The last three do the
printf statement.
What is your real question?
Ian
--
View this message in context:
http://www.nabble.com/regarding-optimization-options-in-phase-ordering-tp24863416p24898021.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: regarding optimization options in phase ordering
pms writes:
> My question is as follwos
>
> We've a problem here. we were trying to use cc1 with & without -O option to
> verify the optimizations happening in our sample code.
> the sample code is given below
> file name : 1.c
> #include
> int main()
> { int a=5;
> int b;
> b=a;
> printf("the number is :%d",b); }
> Here, in 1.c.026t.copyrename1, we get the following output
>
> 1.c.026t.copyrename1
> ;; Function main (main)
> main ()
> { int b; int a; : a_2 = b_1(D); return; }
> but in 1.c.027t.ccp1, the output does not contain the actual assignment
> b=a.
> ;; Function main (main)
> main ()
> { int b; int a; : return; }
> We want to know, without b=a, how is it generating the following final code
> for b=a
> pushl %ebp
>> movl%esp, %ebp
>> andl$-16, %esp
>> subl$16, %esp
>> movl$5, 4(%esp)
>> movl$.LC0, (%esp)
>> callprintf
No code is generated for the statement "b=a". In effect, the program is
optimized into
printf("the number is :%d",5);
as that is equivalent to the original program.
This is a very simple compiler optimization. Please consider taking
future questions about code generation to the mailing list
gcc-h...@gcc.gnu.org. The mailing list gcc@gcc.gnu.org is for gcc
developers. Thanks.
Ian
>> thanks, But b=a is a assignment statement. It is doing some memory
>> operations
>> isn't it. Assuming b=a is a dead statement, how r the following i386
>> assembly statements generated
>> pushl %ebp
>> movl%esp, %ebp
>> andl$-16, %esp
>> subl$16, %esp
>> movl$5, 4(%esp)
>> movl$.LC0, (%esp)
>> callprintf
>
> The first four statements set up the stack. The last three do the
> printf statement.
>
> What is your real question?
>
> Ian
Re: Notes toward re-implementing EH in gimple
Hi, On Fri, 7 Aug 2009, Richard Henderson wrote: > On 08/07/2009 12:31 PM, Richard Guenther wrote: > > > L.N: > > > exc_ptr.1 = EXC_PTR_EXPR (N); > > > filter.1 = FILTER_EXPR (N); > > > > Does the above have > > virtual operands, thus are there any aliases to whatever EXP_PTR_EXPR > > or FILTER_EXPR load? > > No and no. They will eventually resolve to pseudos generated during > rtl eh expansion. But to avoid silliness at the gimple level I don't > want to allow them to appear at random. Shouldn't it be enough to have EXC_PTR_EXPR/FILTER_EXPR simply be builtin functions with proper attributes. They wouldn't be moved upwards over the EH edge because that would introduce effects after the throwing stmt, and they wouldn't be moved downwards due to use-def relationships on exc_ptr.1/filter.1 in the EH_DISPATCH/RESX uses. > Ideally, the rtl would generate what it needs directly into exc_ptr.1, > but I couldn't figure out any way to do that cleanly. In the end, > generating an extra pseudo for register allocation to coalesce is not > the worst sin I could commit here. > > > Can we CSE FILTER_EXPR (N) and EXC_PTR_EXPR (N)? > > Yes. Which also would just work with builtin functions of proper attributes. Ciao, Michael.
Is the git mirror still syncing ?
Hello, It seems the git mirror git://gcc.gnu.org/git/gcc.git didn't sync'ed to the gcc svn tree since last Friday as git fetch wont grab any bits newer than that date. Cloning from that address works OK though. It's just that the bits are a bit old. Is this a known issue ? Thanks. -- Dodji Seketeli Red Hat
Re: Notes toward re-implementing EH in gimple
On Mon, Aug 10, 2009 at 2:53 PM, Michael Matz wrote: > Hi, > > On Fri, 7 Aug 2009, Richard Henderson wrote: > >> On 08/07/2009 12:31 PM, Richard Guenther wrote: >> > > L.N: >> > > exc_ptr.1 = EXC_PTR_EXPR (N); >> > > filter.1 = FILTER_EXPR (N); >> > >> > Does the above have >> > virtual operands, thus are there any aliases to whatever EXP_PTR_EXPR >> > or FILTER_EXPR load? >> >> No and no. They will eventually resolve to pseudos generated during >> rtl eh expansion. But to avoid silliness at the gimple level I don't >> want to allow them to appear at random. > > Shouldn't it be enough to have EXC_PTR_EXPR/FILTER_EXPR simply be builtin > functions with proper attributes. They wouldn't be moved upwards over the > EH edge because that would introduce effects after the throwing stmt, and > they wouldn't be moved downwards due to use-def relationships on > exc_ptr.1/filter.1 in the EH_DISPATCH/RESX uses. What would these attributes be? If you want to have the builtin having side-effects it can't be pure or const. >> Ideally, the rtl would generate what it needs directly into exc_ptr.1, >> but I couldn't figure out any way to do that cleanly. In the end, >> generating an extra pseudo for register allocation to coalesce is not >> the worst sin I could commit here. >> >> > Can we CSE FILTER_EXPR (N) and EXC_PTR_EXPR (N)? >> >> Yes. > > Which also would just work with builtin functions of proper attributes. Which would require either pure or const attributes. Richard.
Re: ifcvt.c question.
On Mon, Aug 10, 2009 at 1:16 PM, Ramana Radhakrishnan wrote: > I wonder if the best way to fix this is to teach ifcvt.c to handle > conditional returns. Yes. This is a bug in the middle-end. I can only guess why you are the first to run into this (the ia64 return instruction is not predicable?) but clearly the assert is bogus if the conditional branch of the IF-block is actually a conditional return. > Should I be fixing this inside ifcvt.c by handling > conditional returns specially I think you should fix this inside ifcvt.c, but try to make the handing of cond_return not too specially ;-) Alternatively, you could add a conditional call pattern and a post-reload splitter to the ARM backend, and disallow the EXIT_BLOCK_PTR as the JOIN-block in ifcvt.c. Ciao! Steven
Re: Notes toward re-implementing EH in gimple
Hi, On Mon, 10 Aug 2009, Richard Guenther wrote: > >> No and no. They will eventually resolve to pseudos generated during > >> rtl eh expansion. But to avoid silliness at the gimple level I don't > >> want to allow them to appear at random. > > > > Shouldn't it be enough to have EXC_PTR_EXPR/FILTER_EXPR simply be > > builtin functions with proper attributes. They wouldn't be moved > > upwards over the EH edge because that would introduce effects after > > the throwing stmt, and they wouldn't be moved downwards due to use-def > > relationships on exc_ptr.1/filter.1 in the EH_DISPATCH/RESX uses. > > What would these attributes be? If you want to have the builtin having > side-effects it can't be pure or const. Ah, you got me, I conciously wrote 'proper' :) Theoretically these functions are pure, with the EH edges clobbering global state. The latter might possibly be modeled with PHI nodes on .MEM. But that would probably prevent the below CSEing again :-/ Hmm. Ciao, Michael.
Re: GOMP project OpenMP 3.0 design document
On Mon, Aug 10, 2009 at 02:05, Qihang Huang wrote: > I found some preliminary documents for the initial GOMP project, but > it is old and not much detail. I was wondering whether there is a > design document for OpenMP 3.0? Or something similar. That would be > really helpful. The design document is the standard itself, available at http://www.openmp.org. For some design notes on the OpenMP implementation in GCC, look for the 2005 or 2006 GCC Summit proceedings available at http://gcc.gnu.org/wiki/GettingStarted Diego.
Re: Notes toward re-implementing EH in gimple
On Mon, Aug 10, 2009 at 3:21 PM, Michael Matz wrote: > Hi, > > On Mon, 10 Aug 2009, Richard Guenther wrote: > >> >> No and no. They will eventually resolve to pseudos generated during >> >> rtl eh expansion. But to avoid silliness at the gimple level I don't >> >> want to allow them to appear at random. >> > >> > Shouldn't it be enough to have EXC_PTR_EXPR/FILTER_EXPR simply be >> > builtin functions with proper attributes. They wouldn't be moved >> > upwards over the EH edge because that would introduce effects after >> > the throwing stmt, and they wouldn't be moved downwards due to use-def >> > relationships on exc_ptr.1/filter.1 in the EH_DISPATCH/RESX uses. >> >> What would these attributes be? If you want to have the builtin having >> side-effects it can't be pure or const. > > Ah, you got me, I conciously wrote 'proper' :) Theoretically these > functions are pure, with the EH edges clobbering global state. The latter > might possibly be modeled with PHI nodes on .MEM. But that would probably > prevent the below CSEing again :-/ For pure functions there should indeed be PHI nodes for .MEM because we have new state on the incoming EH edges. So it might even work. It doesn't prevent the function from being sinked somewhere, but nobody is going to do that for reads anyway (fingers crossing). Richard. > Hmm. > > > Ciao, > Michael.
Re: ifcvt.c question.
On Mon, 2009-08-10 at 15:09 +0200, Steven Bosscher wrote: > On Mon, Aug 10, 2009 at 1:16 PM, Ramana > Radhakrishnan wrote: > > I wonder if the best way to fix this is to teach ifcvt.c to handle > > conditional returns. > > Yes. This is a bug in the middle-end. I can only guess why you are > the first to run into this (the ia64 return instruction is not > predicable?) but clearly the assert is bogus if the conditional branch > of the IF-block is actually a conditional return. I did try to see what happened with the ia64 port - The ia64 return insn is predicable but th port doesn't like to conditionalize the return for this particular case because current_frame_info.r[reg_save_b0] is 32 and not 0 as required. Not knowing enough about the ia64 backend I gave up at this point assuming that the port was DTRT. > > > Should I be fixing this inside ifcvt.c by handling > > conditional returns specially > > I think you should fix this inside ifcvt.c, but try to make the > handing of cond_return not too specially ;-) > > Alternatively, you could add a conditional call pattern and a > post-reload splitter to the ARM backend, and disallow the > EXIT_BLOCK_PTR as the JOIN-block in ifcvt.c. I have added a conditional call pattern by saying that the call pattern is predicable - I don't see what else you mean here. What do you want to split here ? The conditional return + call into a cond_call + return or conditional return into a conditional branch and return ... ( both of which are impossible really ! ) I don't see how one can fix this without special casing for a return here. Either fix it inside ifcvt.c as a special case or look for a way of doing this from the hooks that ifcvt appears to provide . Thanks, Ramana > > Ciao! > Steven
Re: Notes toward re-implementing EH in gimple
On 08/10/2009 05:53 AM, Michael Matz wrote: Shouldn't it be enough to have EXC_PTR_EXPR/FILTER_EXPR simply be builtin functions with proper attributes. Yes, that would be entirely possible. I thought about that later, after I'd posted that message. Yall worry about pure/const'ness downthread: they could be const. There are absolutely no side effects at the site of the builtin at all. Really, it's just a placeholder for a pseudo that rtl eh expanders created elsewhere at the landing pad. Cleaning that up won't be in my initial patch, I don't think, but it will be easy to do later. r~
Re: Notes toward re-implementing EH in gimple
Hi, On Mon, 10 Aug 2009, Richard Henderson wrote: > On 08/10/2009 05:53 AM, Michael Matz wrote: > > Shouldn't it be enough to have EXC_PTR_EXPR/FILTER_EXPR simply be builtin > > functions with proper attributes. > > Yes, that would be entirely possible. I thought about that later, > after I'd posted that message. > > Yall worry about pure/const'ness downthread: they could be const. If they were const (implying no dependency on global memory state) they could be hoisted out of loops right to the functions start (if EH edges aren't magic). You certainly don't want that and IMHO it would be good to make EH edges less magic than more. > There are absolutely no side effects at the site of the builtin > at all. It's not that they _create_ side-effects, but they depend on some. Really, it's just a placeholder for a pseudo that rtl eh > expanders created elsewhere at the landing pad. Right, but conceptually this magic setting of registers happens on the traversal of the EH edge there and it is this change of global state that these two builtins would need to depend on. A VUSE would be one method of modelling it and that's exactly the difference between const and pure functions, only the latter have VUSE<.MEM>. > Cleaning that up won't be in my initial patch, I don't think, but > it will be easy to do later. Btw, it's really wonderful that someone tackles EH-on-gimple ;-) Ciao, Michael.
Re: Notes toward re-implementing EH in gimple
On 08/10/2009 08:20 AM, Michael Matz wrote: It's not that they _create_ side-effects, but they depend on some. Ah, fair enough. I hadn't actually thought that all through. Btw, it's really wonderful that someone tackles EH-on-gimple ;-) I hadn't been planning on it, but my trans-mem branch is stalled on the dominator-breaking representation we have in gimple atm. I tried fixing that, but ran quite afoul of Honza's critical edge splitting pass. There's absolutely no way to split a resx edge in the current representation, and we're saved only by the fact that resx statements don't have edges at the moment. Though you wouldn't know it by looking at the code. Lots of places seem to think resx should have edges. But deep down in the middle you'd find that resx doesn't satisfy stmt_could_throw_p, which stops the eh edge creation right in its tracks. So it seems there's nothing to do but rewrite it all. ;-) r~
Re: Is the git mirror still syncing ?
On 08/10/2009 09:00 AM, Dodji Seketeli wrote: It seems the git mirror git://gcc.gnu.org/git/gcc.git didn't sync'ed to the gcc svn tree since last Friday as git fetch wont grab any bits newer than that date. Cloning from that address works OK though. It's just that the bits are a bit old. I was just noticing that myself; guess I'll update with git svn. Incidentally, have you tried the procedure I wrote out at http://gcc.gnu.org/wiki/GitMirror ? Jason
Re: Is the git mirror still syncing ?
Le 10/08/2009 18:47, Jason Merrill a écrit : > Incidentally, have you tried the procedure I wrote out at > http://gcc.gnu.org/wiki/GitMirror ? Yeah, but I haven't exercised the git-svn setup yet, as git-svn and I stopped being friends long ago. It looks like I am going to try and visit him again :) Thanks. -- Dodji Seketeli Red Hat
Re: i370 port
Paul Edwards wrote:
> GCC 4 complained (on my Linux system) that I didn't have
> various things (gimp etc) installed, which means I would need
> that other software to be ported too, which is not a project
> I want to work on at the moment. However, at least it means
> that i have successfully merged all the GCCMVS changes
> to 3.2.3 in with the (last available) 3.4.6 development, which
> was a precursor to any GCC 4 port anyway. I'll see over time
> how GCC 3.4.6 pans out.
This probably is not gimp (the graphics editor) but gmp (the
multi-precision integer operation library) and mpfr (same for
floating-point). To build any recent GCC you'll indeed need
these two libraries. Fortunately, they're already available
on s390(x) on Linux, and shouldn't really contain anything
that is OS-specific, so porting those to MVS should hopefully
be straightforward ...
> Until then, back at GCC 3.2.3, I have a "need" to make the entry
> point 0 in my MVS modules.
> Currently I generate this:
[snip]
> for a main program. In order to get the entry point to 0, I need to move
> that
> @@MAIN function to the top of the file.
I don't think there is a reliable way to change the sequence of
functions / objects in the output file.
However, it seems to me it shouldn't really be necessary to treat "main"
special. Usually, the "entry point" isn't really "main", but rather some
function in crt0.o, which then in turn *calls* main after all startup
processing has been done. As crt0.o can be (and usually is) completely
written in assembler, you can arrange for everything to be in the sequence
that is required. (On the linker command line, crt0.o would be placed
first, so if the entry point is the first thing in crt0.o it will then
also be the first thing in the executable.)
> And I have another question - where is the code for __asm__?
>
> Currently that is generating garbage for me:
>
> unsigned int bytes = 258;
>
> __asm__("? :");
>
> int main(void)
>
> BYTESEQU *
> DCF'258'
> o...@z
> * Program text area
>
> when done in cross-compiler mode, and need to find out where
> the literal is being translated (or more likely - failing to be
> translated in the first instance). Any idea where that is?
Hmm, this seems to be the bug fixed by Eric Christopher in 2004:
http://gcc.gnu.org/ml/gcc-cvs/2004-02/msg01425.html
> And final thing - the interest in the __asm__ comes from the hope
> that in the generated 370 assembler, it would be possible to have
> the C code interspersed to whatever extent possible. The plan was
> to basically somehow get every line of C code, e.g. "int main(void)"
> above, and automatically generate an:
> __asm__("int main void)");
As you note, this doesn't seem workable as the result wouldn't
be syntactically valid ...
> which gives a syntax error. Any idea how to get the mixed
> C/assembler when I'm running with the "-S" option and don't
> have the luxury of calling the normal "as" which would
> normally handle that?
There doesn't seem to be an easy way to do this from the
compiler. At the time compiler output is generated, the
original source code text isn't even kept any more; you'd
have to go back and re-read the original source files using
the line-number debug data, just as the assembler would ...
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
Re: i370 port
This probably is not gimp (the graphics editor) but gmp (the
multi-precision integer operation library) and mpfr (same for
floating-point). To build any recent GCC you'll indeed need
these two libraries. Fortunately, they're already available
on s390(x) on Linux, and shouldn't really contain anything
that is OS-specific, so porting those to MVS should hopefully
be straightforward ...
Ok, thanks Ulrich.
Until then, back at GCC 3.2.3, I have a "need" to make the entry
point 0 in my MVS modules.
Currently I generate this:
[snip]
for a main program. In order to get the entry point to 0, I need to move
that
@@MAIN function to the top of the file.
I don't think there is a reliable way to change the sequence of
functions / objects in the output file.
Sorry, my question may not have been clear.
When I see main(), I generate the normal MAIN code, and I don't
care where this goes.
However, given that I now know that a main() exists somewhere
in this source file, I need to change the ASM_FILE_START
output.
I expected that the assembler generation wouldn't happen until
after the optimization was completed, and thus, by then, I
would know whether this was a main.
However, it seems to me it shouldn't really be necessary to treat "main"
special. Usually, the "entry point" isn't really "main", but rather some
function in crt0.o, which then in turn *calls* main after all startup
processing has been done.
That is roughly the case, yes.
As crt0.o can be (and usually is) completely
written in assembler, you can arrange for everything to be in the sequence
that is required. (On the linker command line, crt0.o would be placed
first, so if the entry point is the first thing in crt0.o it will then
also be the first thing in the executable.)
Yes, I can do that, but that means I need to have a linker command
line! The way the MVS linker works, I can link my main program,
(which obviously doesn't have crt0 in it), and, thanks to the "END"
statement, I can specify an entry point. This means no complaint
from the linker about a default (and wrong) entry point, and no
need for any linker statements. It all automatically resolves.
It all works really great!
Except - I would ideally like to have an entry point of 0, instead
of the typical "58" or whatever my static variables happen to be.
(my main is normally at the top).
And I have another question - where is the code for __asm__?
Currently that is generating garbage for me:
unsigned int bytes = 258;
__asm__("? :");
int main(void)
BYTESEQU *
DCF'258'
o...@z
* Program text area
when done in cross-compiler mode, and need to find out where
the literal is being translated (or more likely - failing to be
translated in the first instance). Any idea where that is?
Hmm, this seems to be the bug fixed by Eric Christopher in 2004:
http://gcc.gnu.org/ml/gcc-cvs/2004-02/msg01425.html
Thanks again! That didn't seem to make it into 3.4.6. I was able
to apply most of his stuff to 3.4.6, and I will see how far that gets
me, before trying to find it in 3.2.3.
Or maybe I'll skip it, since the problem doesn't occur on a pure
EBCDIC system. :-)
And final thing - the interest in the __asm__ comes from the hope
that in the generated 370 assembler, it would be possible to have
the C code interspersed to whatever extent possible. The plan was
to basically somehow get every line of C code, e.g. "int main(void)"
above, and automatically generate an:
__asm__("int main void)");
As you note, this doesn't seem workable as the result wouldn't
be syntactically valid ...
which gives a syntax error. Any idea how to get the mixed
C/assembler when I'm running with the "-S" option and don't
have the luxury of calling the normal "as" which would
normally handle that?
There doesn't seem to be an easy way to do this from the
compiler. At the time compiler output is generated, the
original source code text isn't even kept any more; you'd
have to go back and re-read the original source files using
the line-number debug data, just as the assembler would ...
Ok, well - I would be content with just the source line number
appearing in the output assembler. Is this information
available as each assembler line is output?
Thanks. Paul.
Re: What happens when you --enable libgomp but not --enable-languages=fortran?
Hello Dave, * Dave Korn wrote on Wed, Aug 05, 2009 at 11:58:31AM CEST: > > libtool: link: /gnu/gcc/obj-patched-gnat2/./gcc/xgcc > > -B/gnu/gcc/obj-patched-gnat > > 2/./gcc/ -B/opt/gcc-tools/i686-pc-cygwin/bin/ > > -B/opt/gcc-tools/i686-pc-cygwin/li > > b/ -isystem /opt/gcc-tools/i686-pc-cygwin/include -isystem > > /opt/gcc-tools/i686-p > > c-cygwin/sys-include-shared .libs/alloc.o .libs/barrier.o > > .libs/critical.o [...] > > o .libs/bar.o .libs/ptrlock.o .libs/time.o .libs/fortran.o .libs/affinity.o > >- > > pthread -Wl,-O1 -o .libs/libgomp-1.dll -Wl,--enable-auto-image-base > > -Xlinker - > > -out-implib -Xlinker .libs/libgomp-1.dll > > xgcc: unrecognized option '-pthread' > > Creating library file: .libs/libgomp-1.dll > > libtool: link: (cd ".libs" && rm -f "libgomp.lib" && ln -s "libgomp-1.dll" > > "libg > > omp.lib") > > libtool: link: /opt/gcc-tools/i686-pc-cygwin/bin/ar rc .libs/libgomp.lib > > alloc. > > o barrier.o critical.o env.o error.o iter.o iter_ull.o loop.o loop_ull.o > > ordered [...] > > /opt/gcc-tools/i686-pc-cygwin/bin/ar: .libs/libgomp.lib: File format not > > recogni > > zed > > make[4]: *** [libgomp.la] Error 1 > > > > $ file i686-pc-cygwin/libgomp/.libs/libgomp.lib > > i686-pc-cygwin/libgomp/.libs/libgomp.lib: symbolic link to `libgomp-1.dll' > > I configured the exact same sandbox yesterday with "--enable-libgomp > --enable-languages=c,c++,ada,fortran" and it bootstrapped fine. I tried it > today with libgomp but without fortran, and this happens. I noticed that this > problem has been observed by someone on the MinGW users list, without much > resolution. Something must have gone wrong with the libtool configuration > somehow; there's no such thing as a libgomp.lib (whether symlink to a DLL or > otherwise) in my previous successful build. > > Should I not be surprised that libgomp can't be built without fortran > enabled, > or should I open a PR? Yes, and Cc: me in the PR, please; thanks. Cheers, Ralf
Re: cloog static build
On Mon, Aug 10, 2009 at 04:22, Rainer Emrich wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I build my gcc windows versions (*-pc-cygwin, *-pc-mingw32, *-w64-mingw32) > using > static build libraries gmp, mpfr, mpc, ppl and cloog. Configuration and > building > of gcc is really easy using the --with-host-libstdcxx configure switch. That's > not true for cloog. If configured against static versions of gmp and ppl I > have > to edit the Makefile manually and add -lstdc++ to LIBS. > > Is there a possibility to check at configure time if a static version of gmp > is > used and add -lstdc++ dependent on the result? > Fixed in the git repo: http://repo.or.cz/w/cloog-ppl.git and I will put a new tar.gz on ftp://gcc.gnu.org/pub/gcc/infrastructure/ Thanks for reporting this problem, Sebastian
[lambda] Latest experimental polymorphic lambda patches
Attached are my latest experimental polymorphic lambda patches against the
latest lambda branch. Template parameters
implied by auto in the lambda's call parameter list no longer lose qualifiers.
The following examples produce
equivalent functions:
1. [] (auto x, auto& y, auto const& z) { return x + y + z; }
2. [] (X x, Y& y, Z const& z) {
return x + y + z; }
3. [] (auto x, Y& y, auto const& z) { return x + y + z; }
Note that using an explicit template parameter is only really useful if you
wish to either a) ensure consistency among
a number of call parameters, b) use a non-type template parameter or c) specify
a call parameter type constraint (or
other complex parameter type).
I have flattened the latest auto-template-inference changes with the previous
one to remove complexity due to
re-arrangement. In particular it no longer abuses decl.c -- those changes have
currently moved into parser.c but it
is pretty clear that they have more in common with pt.c owing to a need to pull
in some local static functions from
that file. I intend to split or move parts (or most) into pt.c on my next
attempt (if I get time to make one!)
There are currently many issues:
- efficiency of template parameter list growing.
- implicit return type deduction doesn't work from
inside a template context if the lambda's return
expression involves a dependent type. Specifying
decltype explicitly in these contexts is a
workaround.
- dependent inferred return type needs to be
deferred and decayed. This may go some way (all
the way?) to solving the previous point.
- location of implementation.
- only a few use-cases have been considered.
Adam
Summary:
Subject: [PATCH] First pass polymorphic lambda support.
This commit adds experimental support for an optional template-parameter-list
in angle-brackets at the start of a
lambda-parameter-declaration.
---
Subject: [PATCH] Restored decltype in lambda return type deduction for when
expr is dependent.
---
Subject: [PATCH] Second version of typename inference from auto parameters in
lambda call operator.
Still quite hacky -- though better than previous. No longer loses
qualifiers on replaced auto parameters so is functionally closer to
what's really needed.
- This is just a behavioural proof to find out how things work.
- Need to shuffle some stuff into pt.c and do away with code dup.
- Not sure how to free tree_vec's and tidy up the counts and sizes
(looks like they're only intended to grow.)
- Added `type_decays_to (non_reference (finish_decltype_type' as
suggested by Jason. Currently doesn't remove cv-quals from
non-class types though. Need to treat implicit return type
differently for dependent types -- should defer and mark that it
needs to be computed later.
---
0001-First-pass-polymorphic-lambda-support.patch
Description: Binary data
0002-Restored-decltype-in-lambda-return-type-deduction-fo.patch
Description: Binary data
0003-Second-version-of-typename-inference-from-auto-param.patch
Description: Binary data
Restrictive addressing mode
Hello all, I am trying to port a 32bit target in GCC 4.4.0 Of the addressing modes that are allowed by my target the one with (base register + offset) is restrictive in QImode. The restriction is that if the base register is not Stack Pointer then this kind of address cannot come in a load instruction but only in store instruction. So how can i implement this? Should i do a define_expand for movQi3 and force it to a register when i get this addressing mode? Please let me know your thoughts on this. Regards, shafi
