Re: Regarding bug 22480, vectorisation of shifts
Uros Bizjak wrote (privately, but I forwarded to GCC in order to get help):
Hello Paolo!
I was looking at PR middle-end/22480 if there is something to fix at the i386
backend. However, there is no documentation at all regarding vec_shl_ and
vec_shr_ builtins.
Heh, I'm quite at a loss regarding PR22480. I don't know exactly what
to do because i386 does not support, e.g. { 2, 4 } << { 1, 2 } (which
would give {4, 16} as a result). There is indeed a back-end problem,
because ashl3 is supposed to have two operands of the same mode,
not one vector and one SI!
On the other hand, I'm not keen on using vec_shl_ because these
shift the *whole* register, not each byte/word/dword. i.e. { 0x4000,
0x8000 } << 2 = { 2, 0 } which is not really what is expected.
One simple way to fix the PR could be *not* to define ashl3 insns
for i386. These however would lose vectorization of a shift by
constant.
Another way could be to
1) in the vectorizer, check in the optab if the predicate for each
operand of an insn accepts a register. If not, refuse vectorization if
the corresponding gimple operand is not constant.
2) and add a new predicate to i386 that only accepts CONST_VECTORs whose
items are all the same. Make ashl3 use it, with a define_expand,
and add a new insn which is the old ashl3:
(define_predicate "vec_shift_operand"
(and (match_code "const_vector")
(match_test "GET_MODE_CLASS (mode) == MODE_VECTOR_INT"))
{
unsigned elt = GET_MODE_NUNITS (mode) - 1;
HOST_WIDE_INT ref = INTVAL (CONST_VECTOR_ELT (op, elt));
while (--elt >= 0)
{
if (INTVAL (CONST_VECTOR_ELT (op, elt)) != ref)
return 0;
}
return 1;
})
(define_expand "ashl3"
[(set (match_operand:SSEMODE248 0 "register_operand" "=x")
(ashift:SSEMODE248
(match_operand:SSEMODE248 1 "register_operand" "0")
(match_operand:SSEMODE248 2 "vec_shift_operand" "xi")))]
"TARGET_SSE2"
{
operand[2] = CONST_VECTOR_ELT (operand[2], 0);
}
(define_insn "*sse_psll3"
[(set (match_operand:SSEMODE248 0 "register_operand" "=x")
(ashift:SSEMODE248
(match_operand:SSEMODE248 1 "register_operand" "0")
(match_operand:SI 2 "nonmemory_operand" "xi")))]
"TARGET_SSE2"
"psll\t{%2, %0|%0, %2}"
[(set_attr "type" "sseishft")
(set_attr "mode" "TI")])
And similarly for ashr3 and lshr3.
This however will not fix "a << b" shifts, which right now should (my
guess) ICE with something similar to PR22480.
By the way, it is time to remove the mmx_ prefix from the MMX insns!
Paolo
porting gcc can't compile libgcc2.c
Hello, Here is a question about porting gcc. After I modified machine.md and other backend files, I can make cc1 and xgcc now. But libgcc2.o still failed. I'd like to know does we must make libgcc2.o since the target machine don't have float registers and 64bit registers. Thanks a lot. Eric
Incorrect use of anti-dependency to order instructions in the DFA scheduler
Hi all,
I maintain a port for a 16-bit VLIW machine, and I have encountered a
problem with the DFA instruction scheduler. Consider the following two
instructions:
BNE someLabel
STW R5,(R3) 0 // Mem[R3] := R5
The second instruction will only be executed if the branch isn't taken.
However, when I switch on the DFA scheduler, the memory store is
scheduled in the same cycle as the branch, using VLIW:
BNE someLabel\STW R5,R3(0)
which obviously changes the meaning of the code, as the store is now
always performed, whereas previously it was conditional. I believe that
this incorrect schedule is caused because an anti-dependence is used to
enforce the ordering of the two instructions, and a VLIW machine allows
anti-dependent instructions to be scheduled in the same cycle. I have
attached the RTL code showing this anti-dependency below.
The problem isn't limited to having a memory store instruction following
the branch. I see the same problem with other types of instruction as well.
Why is an anti-dependence used to enforce the ordering of the branch and
the subsequent instruction? What type of dependency should I use
instead, and if I changed it, would this break other ports?
thanks,
dan.
Daniel Towner
picoChip Designs Ltd, Riverside Buildings, 108, Walcot Street, BATH, BA1 5BG
[EMAIL PROTECTED]
+44 (0) 7786 702589
;#(jump_insn:TI 80 78 102 2 (parallel [
;#(set (pc)
;#(if_then_else (compare:HI (reg:CC 16 pseudoCC)
;#(const_int 0 [0x0]))
;#(pc)
;#(label_ref 93)))
;#(use (const_int 72 [0x48]))
;#]) 11 {*reversed_branch} (insn_list:REG_DEP_TRUE 79
(insn_list:REG_DEP_ANTI 19
(nil)))
;#(expr_list:REG_DEAD (reg:CC 16 pseudoCC)
;#(expr_list:REG_BR_PROB (const_int 1490 [0x5d2])
;#(nil
BEQ _L15\ // (Reversed branch) ;# 80 *reversed_branch
[length
= 6]
;#(insn 31 102 98 3 (set (mem/v/i:HI (reg:HI 3 R3 [4]) [2 dwt+0 S2 A16])
;#(reg:HI 5 R5)) 15 {movhi} (insn_list:REG_DEP_TRUE 78
(insn_list:REG_DEP_TRUE 1
9 (insn_list:REG_DEP_ANTI 80 (nil
;#(expr_list:REG_DEAD (reg:HI 5 R5)
;#(nil)))
STW R5,(R3)0// Mem((R3)0{byte}) := R5 ;# 31 movhi/5
[length
= 4]
RE: porting gcc can't compile libgcc2.c
Original Message >From: Eric Fisher >Sent: 01 September 2005 09:43 > Hello, > > Here is a question about porting gcc. After I modified machine.md and > other backend files, I can make cc1 and xgcc now. But libgcc2.o still > failed. I'd like to know does we must make libgcc2.o since the target > machine don't have float registers and 64bit registers. > > Thanks a lot. > > Eric If it doesn't have float registers, get libgcc2 to use fp emulation: -- File: gccint.info, Node: Target Fragment, Next: Host Fragment, Up: Fragments Target Makefile Fragments = Target makefile fragments can set these Makefile variables. -- `Floating Point Emulation' To have GCC include software floating point libraries in `libgcc.a' define `FPBIT' and `DPBIT' along with a few rules as follows: # We want fine grained libraries, so use the new code # to build the floating point emulation libraries. FPBIT = fp-bit.c DPBIT = dp-bit.c fp-bit.c: $(srcdir)/config/fp-bit.c echo '#define FLOAT' > fp-bit.c cat $(srcdir)/config/fp-bit.c >> fp-bit.c dp-bit.c: $(srcdir)/config/fp-bit.c cat $(srcdir)/config/fp-bit.c > dp-bit.c You may need to provide additional #defines at the beginning of `fp-bit.c' and `dp-bit.c' to control target endianness and other options. -- As for the 64-bit registers, just don't tell it you have any: -- File: gccint.info, Node: Values in Registers, Next: Leaf Functions, Prev: Al\ location Order, Up: Registers How Values Fit in Registers --- This section discusses the macros that describe which kinds of values (specifically, which machine modes) each register can hold, and how many consecutive registers are needed for a given mode. `HARD_REGNO_NREGS (REGNO, MODE)' A C expression for the number of consecutive hard registers, starting at register number REGNO, required to hold a value of mode MODE. On a machine where all registers are exactly one word, a suitable definition of this macro is #define HARD_REGNO_NREGS(REGNO, MODE)\ ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \ / UNITS_PER_WORD) `HARD_REGNO_MODE_OK (REGNO, MODE)' A C expression that is nonzero if it is permissible to store a value of mode MODE in hard register number REGNO (or in several registers starting with that one). For a machine where all registers are equivalent, a suitable definition is #define HARD_REGNO_MODE_OK(REGNO, MODE) 1 -- With those macros you can tell it to store floats and 64-bit ints in two (or more) consecutive hard registers. cheers, DaveK -- Can't think of a witty .sigline today
Re: Running ranlib after installation - okay or not?
Hi Peter, * Peter O'Gorman wrote on Thu, Sep 01, 2005 at 07:09:35AM CEST: > Peter O'Gorman wrote: > | The problem is that libtool tries to run ranlib after install and that > | ranlib can fail if the library is not writable? Thanks for the pointer. > When I look more closely at this, I see in libtool.m4: > old_postinstall_cmds='chmod 644 $oldlib' > > and a little later: > old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds" > > Should that be: > old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib" > ?? Yes, I believe so (both CVS HEAD and branch-1-5). Unless there exists ranlib's that change file mode.. > > The problem is that libtool tries to run ranlib after install and > > that ranlib can fail if the library is not writable? Note that on > > darwin running ranlib on a 444 lib works and changes permissions to > > 644, remind me to file a bug. Hmm. The change to 644 should be OK. What happens to libraries with other modes (say, not group- or world-readable)? So how about changing the order as you suggest above, and filing a bug with darwin ranlib? Someone in this thread suggested saving and restoring the mode used for installation; in a way, it would be a nice service to serve the user's wish here (for example, for supposed-to-be private code); one danger would be if we then found issues similar to with shared libraries (where on some systems, weird permissions are necessary for them to work right). Not that I know of any such issues. > > Another alternative would be to set RANLIB=: before configure if > > your system does not need to ranlib anything. Improving upon this situation has been on our TODO list anyway: http://lists.gnu.org/archive/html/libtool-patches/2005-05/msg00092.html Cheers, Ralf
Re: Successfull gcc-3.4.4 build on hppa1.1-hp-hpux10.20
> Thanks! Do you know if this includes pthreads support in C++? There's support for the older DCE threads in 10.X. This is dropped in 11.X, but there's POSIX thread support. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Selective Mudflap
Hi, I'm trying to debug a large C application that (amongst other things) starts a JVM and uses Java's JDBC to connect to databases via JNI. If I use the sourceforge bounds checking patch I get a sensible list of errors (none from the JVM). I'd also like to use Mudflap however running the program with mudflap generates huge numbers of errors caused by the (uninstrumented) libjvm.so. I don't much care about errors in the JVM, whether they are real or imagined - I'm not going to be altering that code, is there any way to ask mudflap to suppress errors from all uninstrumented code or from a certain library or use a valgrind style suppressions file etc. Any advice appreciated. Jon.
Re: Selective Mudflap
"Jon Levell" <[EMAIL PROTECTED]> writes:
> I'm trying to debug a large C application that (amongst other things)
> starts a JVM and uses Java's JDBC to connect to databases via JNI.
Brave!
> If I use the sourceforge bounds checking patch I get a sensible list
> of errors (none from the JVM). I'd also like to use Mudflap however
> running the program with mudflap generates huge numbers of errors
> caused by the (uninstrumented) libjvm.so. [...]
Do these errors arise from malloc-type operations performed by the
JVM? Or from your code's use of JVM-provided pointers? Sadly, there
is no valgrind-style exclusion facility around. However, if the JVM
interface is used predominantly in one direction (C code calling into
the JVM), it may be possible to programatically turn off mudflap
enforcement when your code is about to jump into the jvm. Maybe
something similar can be done for JVM-invoked C code too.
#ifdef _MUDFLAP
__mf_set_options("-mode-nop");
#endif
... invoke JVM
#ifdef _MUDFLAP
__mf_set_options("-mode-check"); /* IIRC */
#endif
- FChE
Re: Running ranlib after installation - okay or not?
If you do change how this is implemented in the config* files, please make sure that you still support cross compiling to Darwin. In that case, the runtime libraries for the target would still run into this issue, because you'd be using the Darwin ranlib, even on a Linux build/host. Shantonu On Aug 31, 2005, at 12:28 PM, Ian Lance Taylor wrote: Still, all this really means is that we should be host specific when deciding whether or not to run ranlib. In fact we are already host specific as to what flags we use. On Darwin we use -c, which we do not use on any other system. Maybe we should remove AC_PROG_RANLIB from configure.ac, and add something to config.host instead. Except that probably this has to get into libtool somehow or something. Hmmm. Ian
Re: Running ranlib after installation - okay or not?
[EMAIL PROTECTED] (Andrew Pinski) wrote on 31.08.05 in <[EMAIL PROTECTED]>: > On Aug 31, 2005, at 2:02 PM, Ian Lance Taylor wrote: > > > Gerald Pfeifer <[EMAIL PROTECTED]> writes: > > > >> Does anyone disagree (and if not, have suggestions how to address this > >> in GCC)? > > > > ranlib is basically never required on a modern system. It is really > > only needed if the archive is built with the S option to ar. > > > > So I think the best way to address this is to not run ranlib. > > If you consider Darwin "modern", then that statement is not correct > as moving/copying an archive on darwin, requires ranlib to be run. Is there a point to this behaviour? It sounds as if someone confused an archive with a nethack scorefile ... MfG Kai
Re: Running ranlib after installation - okay or not?
Ralf Wildenhues wrote: Should that be: old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib" ?? Yes, I believe so (both CVS HEAD and branch-1-5). Unless there exists ranlib's that change file mode.. Okay, the attached pathces are applied to libtool HEAD and branch-1-5. Thank you, Peter 2005-09-01 Peter O'Gorman <[EMAIL PROTECTED]> * libltdl/m4/libtool.m4 (old_postintall_cmds): chmod 644 before running ranlib. Reported by Gerald Pfeifer <[EMAIL PROTECTED]> Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.10 diff -u -3 -p -u -r1.10 libtool.m4 --- libltdl/m4/libtool.m4 1 Sep 2005 14:16:08 - 1.10 +++ libltdl/m4/libtool.m4 1 Sep 2005 16:03:08 - @@ -1200,10 +1200,10 @@ old_postuninstall_cmds= if test -n "$RANLIB"; then case $host_os in openbsd*) -old_postinstall_cmds="\$RANLIB -t \$oldlib~$old_postinstall_cmds" +old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$oldlib" ;; *) -old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds" +old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib" ;; esac old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib" 2005-09-01 Peter O'Gorman <[EMAIL PROTECTED]> * libtool.m4 (old_postintall_cmds): chmod 644 before running ranlib. Reported by Gerald Pfeifer <[EMAIL PROTECTED]> Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.105 diff -u -3 -p -u -r1.314.2.105 libtool.m4 --- libtool.m4 31 Aug 2005 18:29:21 - 1.314.2.105 +++ libtool.m4 1 Sep 2005 16:04:15 - @@ -176,10 +176,10 @@ old_postuninstall_cmds= if test -n "$RANLIB"; then case $host_os in openbsd*) -old_postinstall_cmds="\$RANLIB -t \$oldlib~$old_postinstall_cmds" +old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB -t \$oldlib" ;; *) -old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds" +old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib" ;; esac old_archive_cmds="$old_archive_cmds~\$RANLIB \$oldlib"
Re: Regarding bug 22480, vectorisation of shifts
On Thu, Sep 01, 2005 at 09:24:26AM +0200, Paolo Bonzini wrote: > 1) in the vectorizer, check in the optab if the predicate for each > operand of an insn accepts a register. If not, refuse vectorization if > the corresponding gimple operand is not constant. That sounds plausible, yes. > By the way, it is time to remove the mmx_ prefix from the MMX insns! No, it isn't. The emms patch doesn't work yet. r~
Re: Incorrect use of anti-dependency to order instructions in the DFA scheduler
On Thu, Sep 01, 2005 at 11:12:51AM +0100, Daniel Towner wrote: > Why is an anti-dependence used to enforce the ordering of the branch and > the subsequent instruction? Because gcc doesn't target true vliw machines, and given strict program ordering of insn, anti-dependence is correct. > ... and if I changed it, would this break other ports? Yes. You need to be special-casing branches in your backend's bundling hooks. r~
Re: Incorrect use of anti-dependency to order instructions in the DFA scheduler
Daniel Towner <[EMAIL PROTECTED]> writes: > I maintain a port for a 16-bit VLIW machine, and I have encountered a > problem with the DFA instruction scheduler. Consider the following two > instructions: > > BNE someLabel > STW R5,(R3) 0 // Mem[R3] := R5 > > The second instruction will only be executed if the branch isn't > taken. However, when I switch on the DFA scheduler, the memory store > is scheduled in the same cycle as the branch, using VLIW: > > BNE someLabel\STW R5,R3(0) > > which obviously changes the meaning of the code, as the store is now > always performed, whereas previously it was conditional. I believe > that this incorrect schedule is caused because an anti-dependence is > used to enforce the ordering of the two instructions, and a VLIW > machine allows anti-dependent instructions to be scheduled in the same > cycle. I have attached the RTL code showing this anti-dependency below. You unfortunately can't rely on the DFA scheduler to do proper VLIW instruction bundling. The scheduler thinks that every instruction runs separately. It doesn't understand the notion of two or more instructions running in parallel. The scheduler also doesn't understand that in a typical VLIW machine every instruction slot must be occupied by an instruction, even if only a NOP. You generally have to do actual instruction bundling in a separate machine dependent pass which tracks dependencies when deciding whether to bundle instructions. This is slightly awkward when bundling instructions with a branch instruction at the start of a bundle. In the output of the scheduler, the instructions which follow the branch are expected to be executed after the branch. One technique to get around this (other than doing a lot of rescheduling in the bundling pass) is to use define_delay to pretend that branch instructions have a delay slot. The delay slot filling pass will then find instructions whose dependencies permit them to be bundled with a branch instruction. Your bundling pass will then find them in the right place to bundle them--i.e., just after the branch instruction. Ian
Re: Running ranlib after installation - okay or not?
[EMAIL PROTECTED] (Kai Henningsen) writes: > [EMAIL PROTECTED] (Andrew Pinski) wrote on 31.08.05 in <[EMAIL PROTECTED]>: > > > If you consider Darwin "modern", then that statement is not correct > > as moving/copying an archive on darwin, requires ranlib to be run. > > Is there a point to this behaviour? It sounds as if someone confused an > archive with a nethack scorefile ... a.out archives used to work this way too, e.g. on SunOS 4. The idea was that people would often use ar without updating the symbol table. Thus the symbol table has a timestamp. The linker checks that the timestamp of the symbol table is not older than the file modification time of the archive. In practice this turned out to be a mistake, as everybody always updated the symbol table with every use of ar, and it caused trouble when simply copying archives around. So the notion was abandoned in the move to COFF and ELF. >From my perspective Darwin lives in its own little world, and I guess they never abandoned the symbol table timestamp checking. Ian
Re: -fprofile-generate and -fprofile-use
> >you may try adding -fmove-loop-invariants flag, which enables new > >invariant motion pass. > > That cleaned up both my simplified test case, and the code it > originated from. It also cleaned up a few other cases where I > was noticing worse performance with FDO enabled. Thanks!! > > Perhaps this option should be enabled by default when doing FDO > to replace the loop invariant motions done by the recently > disabled loop optimize pass. This sounds like sane idea. Zdenek, is -fmove-loop-invariants dangerous in some way or just disabled because old loop does the same? Honza > > Pete
Consulting Opportunity - Ph.D. Preferred
Dear Business Professional, Im writing you today because Id like to invite you to list your CV or resume with our expert witness referral service. There are literally in excess of 2 million litigation cases filed each year which require industry-specific expertise of individuals such as yourself who are in a position to provide support, advise counsel, and navigate through the volumes of information on which these cases are based all at very lucrative hourly rates. Expert Witness Bank, the worlds premier referral service, actively markets your skills to legal industry and charges no fees upon engagement. Expert Witness Bank will notify you whenever a project becomes available which is suitably matched to your expertise. Please visit www.expertwitnessbank.com/info.html and learn more about the benefits of joining our premier network. As an Expert Witness Bank member you will be able to upload your resume and list all areas of your expertise. You will also have the opportunity to upgrade to our Premium Membership program and receive weekly notifications of every active case for which we are currently seeking experts. For more information and to receive our special introductory rate for 1st-time members, visit www.expertwitnessbank.com/info.html. Please list with us only if you are a qualified expert in your field. Your listing will be declined otherwise. As I have reached you directly however, I apologize in advance if I have misunderstood your area of expertise. I hope that you choose to join our referral service. If you have any questions or require assistance listing your resume with us, please dont hesitate to email me directly at [EMAIL PROTECTED] I sincerely look forward to working with you, Karene Karene France Expert Witness Bank | [EMAIL PROTECTED] A Service of Micro Survivor, Inc. Tel: 650-248-4831 Fax: 650-249-3557 www.ExpertWitnessBank.com Bridging Valuable Expertise with Opportunity P.S. Please reply with "Exclude" in your email if you want to be excluded from well-paid expert witness opportunities.
MEM_NONTRAP_P and push/pop alias set (Was: Re: [attn port maintainers] fix 23671)
My current thinking is that, with a few exceptions like prologue and epilogue generation, it should be considered a BUG if a port uses gen_rtx_MEM. Almost always one should be using something from the adjust_address family of routines. What are the exact semantics of MEM_NOTRAP_P ? The documentation does not agree with the source. reload sets MEM_NOTRAP_P on registers that are spilled to memory. However, writing to these MEMs can trap if we have a stack overflow. Ports also have to write to stack memory - in the prologue, and for copies that use secondary memory (the SH doesn't allocate seondary memory through the reload mechanisms, but it uses push / pop for 64 bit copies between general purpose and floating point registers). Thus, this question is probably relevant for every port maintainer. Moreover, register pushes/pops (other than for the return address in the presence of builtin_return_address) in the prologue / epilogue can't alias other memory accesses, and on ACCUMULATE_OUTGOING_ARGS, neither can temporary pushes/pops (unless shrinkwrapping gets implemented). Therefore, I think it would make sense to have a utility function that generates a MEM with MEM_NONTRAP_P set to the appropriate value, and a specific alias set. We already have gen_const_mem for readonly memory, so maybe that could be gen_pushpop_mem.
Re: Running ranlib after installation - okay or not?
On Sep 1, 2005, at 4:10 PM, Joe Buck wrote: On Thu, Sep 01, 2005 at 12:16:23PM +0900, Peter O'Gorman wrote: I would suggest continuing to run ranlib after install, but not failing if it does not work. Won't you then get warning messages on Darwin every time someone tries to use the installed library (since the symbol table timestamp will be older than the file timestamp)? It will not be a warning on darwin, it will be straight error as Darwin's linker does not like the timestamp to be out of date at all. -- pinski
Re: Running ranlib after installation - okay or not?
On Thu, Sep 01, 2005 at 12:16:23PM +0900, Peter O'Gorman wrote: > I would suggest continuing to run ranlib after install, but not failing if > it does not work. Won't you then get warning messages on Darwin every time someone tries to use the installed library (since the symbol table timestamp will be older than the file timestamp)?
Re: MEM_NONTRAP_P and push/pop alias set (Was: Re: [attn port maintainers] fix 23671)
On Thu, Sep 01, 2005 at 08:52:29PM +0100, Joern RENNECKE wrote: > What are the exact semantics of MEM_NOTRAP_P ? The documentation > does not agree with the source. reload sets MEM_NOTRAP_P on > registers that are spilled to memory. However, writing to these > MEMs can trap if we have a stack overflow. We don't consider stack overflow at all. Given that the stack is full, we can't actually do anything about it in many cases. For instance, we don't support unwinding through sigaltstack, even if the target supports it. Given libjava as the common use case, we're mostly interested in null pointer dereferences. But there is some amount of disagreement about what MEM_NOTRAP_P and TREE_THIS_NOTRAP mean. The later is documented to *not* be set for out-of-bounds array accesses, including accessing one past the end of an array in the local stack frame. Which is not consistent with the rtl-level "anything based off the frame pointer can't trap", and doesn't consider the offset at all. I'm not actually sure what the Correct stance is here. > Ports also have to write to stack memory - in the prologue, and > for copies that use secondary memory (the SH doesn't allocate seondary > memory through the reload mechanisms, but it uses push / pop for 64 bit > copies between general purpose and floating point registers). Thus, > this question is probably relevant for every port maintainer. Indeed, which is why my message was addressed to all port maintainers. As a practical short-term concern, rtx_addr_can_trap_p will not return true for any stack based reference, including push/pop. So for 4.1, nothing need be done. Longer term, the answer to the "what does notrap mean" may demand that rtx_addr_can_trap_p *not* be queried, so it would be better to set the bit when possible. The hppa problem is due to manual reloading of the address into a scratch register, so the frame pointer was no longer visible, and then discarding the reload-supplied MEM that had NOTRAP set. > Therefore, I think it would make sense to have a utility function that > generates a MEM with MEM_NONTRAP_P set to the appropriate value, and > a specific alias set. We already have gen_const_mem for readonly > memory, so maybe that could be gen_pushpop_mem. I agree completely. This should be done before a lot of target code gets uglified. r~
Re: -fprofile-generate and -fprofile-use
Sorry I still did not follow. This is what I understood. During Feedback optimization apart from the -fprofile-generate, one needs to turn on -fmove-loop-invariants. However this option is not recognized by the gcc 3.4.4 or 3.4.3 compilers. What am I missing? -girish --- Eric Christopher <[EMAIL PROTECTED]> wrote: > > On Aug 31, 2005, at 3:40 PM, girish vaitheeswaran > wrote: > > > I do not see this flag in gcc3.4.4. > > > > > > Am I missing something? > >> > > >> you may try adding -fmove-loop-invariants flag, > >> which enables new > >> invariant motion pass. > > The "new invariant motion pass". > > -eric >
Re: Running ranlib after installation - okay or not?
i think Peter's point is: if mode(archive) == 444 if target == Darwin Darwin ranlib will upgrade it to 644 anyway and succeed, and/or use a temp file and rename(2) else ranlib isn't really needed anyway, so ignore the error fi else ranlib should be used, and should succeed, but still, ignore errors fi On Sep 1, 2005, at 1:15 PM, Andrew Pinski wrote: On Sep 1, 2005, at 4:10 PM, Joe Buck wrote: On Thu, Sep 01, 2005 at 12:16:23PM +0900, Peter O'Gorman wrote: I would suggest continuing to run ranlib after install, but not failing if it does not work. Won't you then get warning messages on Darwin every time someone tries to use the installed library (since the symbol table timestamp will be older than the file timestamp)? It will not be a warning on darwin, it will be straight error as Darwin's linker does not like the timestamp to be out of date at all. -- pinski
Re: -fprofile-generate and -fprofile-use
On Thursday 01 September 2005 23:19, girish vaitheeswaran wrote: > Sorry I still did not follow. This is what I > understood. During Feedback optimization apart from > the -fprofile-generate, one needs to turn on > -fmove-loop-invariants. You don't "need to". It just might help iff you are using a gcc 4.1 based compiler. > However this option is not > recognized by the gcc 3.4.4 or 3.4.3 compilers. What > am I missing? You are missing that 1) this whole thread does not concern gcc 3.4.x; and 2) the option -fmove-loop-invariants does not exist in 3.4.x. Gr. Steven
Re: help: about enum
Gaurav Gautam, Noida wrote: > I want to know, how enums are handled in gcc. How do we map an enum value to > the corresponding integer size. Look at start_enum and finish_enum in c-decl.c. > What does the option -fshort-enums does. Plz explain me in detail. Look at the code in start_num and finish_enum that uses flag_short_enum. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: -fprofile-generate and -fprofile-use
On Thu, Sep 01, 2005 at 11:45:35PM +0200, Steven Bosscher wrote: > On Thursday 01 September 2005 23:19, girish vaitheeswaran wrote: > > Sorry I still did not follow. This is what I > > understood. During Feedback optimization apart from > > the -fprofile-generate, one needs to turn on > > -fmove-loop-invariants. > > You don't "need to". It just might help iff you are using a gcc 4.1 > based compiler. > > > However this option is not > > recognized by the gcc 3.4.4 or 3.4.3 compilers. What > > am I missing? > > You are missing that > 1) this whole thread does not concern gcc 3.4.x; and > 2) the option -fmove-loop-invariants does not exist in 3.4.x. Girish started this thread about problems he is seeing with GCC 3.4.3 (see http://gcc.gnu.org/ml/gcc/2005-07/msg00866.html). Others of us chimed in about similar issues with later versions. Suggestions for avoiding the problems have been about those later versions, not the version he is using. Janis
Re: -fprofile-generate and -fprofile-use
On Friday 02 September 2005 00:53, Janis Johnson wrote: > Girish started this thread about problems he is seeing with GCC 3.4.3 > (see http://gcc.gnu.org/ml/gcc/2005-07/msg00866.html). Others of us > chimed in about similar issues with later versions. Suggestions for > avoiding the problems have been about those later versions, not the > version he is using. Ah. Sorry then. My bad. Gr. Steven
Re: MASK_GNU_AS == MASK_GAS
Fred Fish wrote: > It appears that the ia64 port introduced the internal define > MASK_GNU_AS that is used the same was as the historical MASK_GAS > define. There was some discussion of this about 5 years ago as part > of a larger discussion about possible user level changes. Is there a reason why you are asking? Since target flag macros are target dependent, there is no particular need for them to be consistent across different targets. For this particular case, I prefer the name MASK_GNU_AS because "GNU as" is the correct name for the program in question, not gas. rms has corrected me about this issue in the past, so I have a strong tendency to prefer GNU as over gas. I realize that there is a lot of history for MASK_GAS, but I couldn't bring myself to deliberately use an incorrect name, particularly when using the correct name was so easy. It probably wouldn't bother me too much if someone changed it while I wasn't looking, but I'd rather not change it myself. At the same time, I'm not asking anyone else to change, since others may not want to change their ports, so we are left with a minor harmless inconsistency. The same inconsistency appears in other places. For instance we have a configure option --with-gnu-as that sets an internal variable gas_flag. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
G++ question
Hi,
While working on a project involing checking the internal (logic)
consistency of the C++ front-end, I came across the following code in
cp/parser.c:cp_parser_translation_unit():
while (true)
{
cp_parser_declaration_seq_opt (parser);
/* If there are no tokens left then all went well. */
if (cp_lexer_next_token_is (parser->lexer, CPP_EOF))
{
/* Get rid of the token array; we don't need it any more. */
cp_lexer_destroy (parser->lexer);
parser->lexer = NULL;
/* This file might have been a context that's implicitly extern
"C". If so, pop the lang context. (Only relevant for PCH.) */
if (parser->implicit_extern_c)
{
pop_lang_context ();
parser->implicit_extern_c = false;
}
/* Finish up. */
finish_translation_unit ();
success = true;
break;
}
else
{
cp_parser_error (parser, "expected declaration");
success = false;
break;
}
}
Both branches of the if-statement contain an unconditional "break",
which implies that the apparant unbounded while-loop is executed only
once. If that reasoning is correct, why do we have the while-loop in
the first place?
-- Gaby
Re: http://gcc.gnu.org is turning away MS Internet Explorer 5
Mike Ainley wrote: > This web site is turning away Microsoft Internet Explorer 5. Are you using a download accelerator? The gcc.gnu.org site refuses most of them, as they cause load issues on our server. They are also popular with spammers, who use them for spam bots. The message you are seeing is a bit confusing, since it doesn't mention the download accelerator problem. It only mentions the spam bot problem. I asked for this to be fixed once, but apparently nothing was done. IE5, without a download accelerator, should work just fine. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: G++ question
Gabriel Dos Reis wrote: Both branches of the if-statement contain an unconditional "break", which implies that the apparant unbounded while-loop is executed only once. If that reasoning is correct, why do we have the while-loop in the first place? Historical accident; a patch to remove it is pre-approved after testing. -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Re: building gcc 4.0.1 using CAS (part of the sun v8plus arch)
Andrew B. Lundgren wrote: > Is there a macro I can ifdef on to check to see if I can use the v8plus > instructions, otherwise use the existing spinlock implementation? It looks like we have __sparc_v8__ and __sparc_v9__ but not a macro for v8plus. If you need one, you may have to add it. See CPP_CPU_SPEC in gcc/config/sparc/sparc.h. Since v8plus is really an ABI not a cpu, it might make sense to create a CPP_ABI_SPEC or similar. FYI You can use the cpp -dM option to see what predefined macros are available. Try it with -mv8, -mv8plus, -mv9 to see what the differences are. If you have access to the Sun compiler, you might want to check to see what Sun does. They may already have predefined preprocessor macros for this. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: MASK_GNU_AS == MASK_GAS
On Thursday 01 September 2005 19:16, James E Wilson wrote: > > Is there a reason why you are asking? Since target flag macros are > target dependent, there is no particular need for them to be consistent > across different targets. I was checking to see exactly what differences configuring a current mips-elf toolchain with and without --with-gnu-as makes, and that led me to the MASK_GNU_AS and MASK_GAS issue. Your first instinct is to think that they are somehow different, and I guess I was a little surprised to find out that they weren't. > At the same time, I'm not asking anyone else to > change, since others may not want to change their ports, so we are left > with a minor harmless inconsistency. Yes it's a small nit. -Fred
Re: Running ranlib after installation - okay or not?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrew Pinski wrote: |> Won't you then get warning messages on Darwin every time someone tries |> to use the installed library (since the symbol table timestamp will be |> older than the file timestamp)? | | | It will not be a warning on darwin, it will be straight error as | Darwin's linker does not like the timestamp to be out of date at | all. Doesn't matter, the solution I applied to GNU libtool cvs last night is probably most appropriate, i.e. chmod 644 before ranlib. I guess I'll look at gcc cvs over the weekend to figure out where that would go in your tree. Peter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (Darwin) iQCVAwUBQxeQrLiDAg3OZTLPAQIZjQP9H3NKZd2r/AMNrqG+0pJ4WEdBgo8J/WUC JZMY0l3JElo81UugL/2T5OOJvESmO6N5iiZj4blACg3m3cgPIuuFZ+K+UmV6rQW0 ypOauMYu6Un5SLlGV3KHm5qdLYqPPzyOLJfjCDvnNGcdBst0SG/jkfgiSAqq8hDt c6YrkYmCWq0= =dRag -END PGP SIGNATURE-
gcc-4.0-20050901 is now available
Snapshot gcc-4.0-20050901 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050901/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 CVS branch with the following options: -rgcc-ss-4_0-20050901 You'll find: gcc-4.0-20050901.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20050901.tar.bz2 C front end and core compiler gcc-ada-4.0-20050901.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20050901.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20050901.tar.bz2 C++ front end and runtime gcc-java-4.0-20050901.tar.bz2 Java front end and runtime gcc-objc-4.0-20050901.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20050901.tar.bz2The GCC testsuite Diffs from 4.0-20050825 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 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.
sign/zero extending pointer offsets?
Consider this sample code:
x = foo[i];
when pointers are larger than integers and size_t [*], we compute the
offset (i) and extend it to pointer size. However, there's no check
to see if a sign or zero extension should be used. If the offset is
unsigned (say, i is "unsigned int") it sign extends it anyway,
resulting in an incorrect offset. Does it make sense to check for
signed vs unsigned offsets and pass the right flag to convert_to_mode?
This results in smaller code on m32c, where HI moves to address
registers (PSI) are zero extended.
Alternately, we should at least use the POINTERS_EXTEND_UNSIGNED
*value* in convert_to_mode.
[*] There aren't any pointer-sized math operations on m32c, just SI
and HI sized ones. Pointers are 24 bits. Thus, pointers and
addresses are 24 bits, but no single data item can exceed 64k, so
offsets are 16 bits.
Index: expr.c
===
RCS file: /cvs/gcc/gcc/gcc/expr.c,v
retrieving revision 1.814
diff -p -U3 -r1.814 expr.c
--- expr.c 1 Sep 2005 01:06:45 - 1.814
+++ expr.c 2 Sep 2005 05:01:10 -
@@ -7210,6 +7210,7 @@ expand_expr_real_1 (tree exp, rtx target
if (offset != 0)
{
+ int unsigned_p = TYPE_UNSIGNED (TREE_TYPE (offset));
rtx offset_rtx = expand_expr (offset, NULL_RTX, VOIDmode,
EXPAND_SUM);
@@ -7217,10 +7218,10 @@ expand_expr_real_1 (tree exp, rtx target
#ifdef POINTERS_EXTEND_UNSIGNED
if (GET_MODE (offset_rtx) != Pmode)
- offset_rtx = convert_to_mode (Pmode, offset_rtx, 0);
+ offset_rtx = convert_to_mode (Pmode, offset_rtx, unsigned_p);
#else
if (GET_MODE (offset_rtx) != ptr_mode)
- offset_rtx = convert_to_mode (ptr_mode, offset_rtx, 0);
+ offset_rtx = convert_to_mode (ptr_mode, offset_rtx, unsigned_p);
#endif
if (GET_MODE (op0) == BLKmode
[4.0] libgfortran/io/read.c:230: error: invalid storage class for function 'eat_leading_spaces'
This is on: Aurora SPARC Linux release 2.0 (Kashmir FC3) UltraSparc IIi (Sabre) sun4u: (auroralinux corona + rathann's and rzm's FC3 updates) binutils-2.16.91.0.2-4.sparc bison-1.875c-2.sparc dejagnu-1.4.4-2.noarch expect-5.42.1-1.sparc gcc-3.4.3-22.sparc.sparc gcc4-4.0.0-0.41.sparc.sparc glibc-2.3.5-0.fc3.1.sparcv9 glibc-2.3.5-0.fc3.1.sparc64 glibc-devel-2.3.5-0.fc3.1.sparc glibc-devel-2.3.5-0.fc3.1.sparc64 glibc-headers-2.3.5-0.fc3.1.sparc glibc-kernheaders-2.6-20sparc.sparc gmp-4.1.4-3sparc.sparc gmp-4.1.4-3sparc.sparc64 gmp-devel-4.1.4-3sparc.sparc gmp-devel-4.1.4-3sparc.sparc64 kernel-2.6.11-1.1305sp1.sparc64 package kernel-devel is not installed package kernel-smp is not installed libgcc-3.4.3-22.sparc.sparc libgcc-3.4.3-22.sparc.sparc64 libstdc++-3.4.3-22.sparc.sparc libstdc++-3.4.3-22.sparc.sparc64 libstdc++-devel-3.4.3-22.sparc.sparc libstdc++-devel-3.4.3-22.sparc.sparc64 make-3.80-5.sparc nptl-devel-2.3.5-0.fc3.1.sparcv9 tcl-8.4.7-2.sparc with: ../gcc/configure --enable-__cxa_atexit --enable-shared --with-cpu=v7 --with-gcc-version-trigger=/usr/local/src/branch/gcc/gcc/version.c --enable-languages=c,ada,c++,f95,java,objc,treelang Currently, on the 4.0 branch, I get this: /bin/sh ./libtool --mode=compile /usr/local/src/branch/objdir/gcc/xgcc -B/usr/local/src/branch/objdir/gcc/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem /usr/local/sparc64-unknown-linux-gnu/include -isystem /usr/local/sparc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran -I. -iquote../../../gcc/libgfortran/io -std=gnu99 -Wall -O2 -g -O2 -c -o read.lo `test -f 'io/read.c' || echo '../../../gcc/libgfortran/'`io/read.c /usr/local/src/branch/objdir/gcc/xgcc -B/usr/local/src/branch/objdir/gcc/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -B/usr/local/sparc64-unknown-linux-gnu/lib/ -isystem /usr/local/sparc64-unknown-linux-gnu/include -isystem /usr/local/sparc64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../gcc/libgfortran -I. -iquote../../../gcc/libgfortran/io -std=gnu99 -Wall -O2 -g -O2 -c ../../../gcc/libgfortran/io/read.c -fPIC -DPIC -o .libs/read.o ../../../gcc/libgfortran/io/read.c: In function 'convert_real': ../../../gcc/libgfortran/io/read.c:230: error: invalid storage class for function 'eat_leading_spaces' ../../../gcc/libgfortran/io/read.c:246: error: invalid storage class for function 'next_char' ../../../gcc/libgfortran/io/read.c:796: error: syntax error at end of input make[3]: *** [read.lo] Error 1 make[3]: Leaving directory `/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/libgfortran' make[2]: *** [all] Error 2 make[2]: Leaving directory `/usr/local/src/branch/objdir/sparc64-unknown-linux-gnu/libgfortran' make[1]: *** [all-target-libgfortran] Error 2 make[1]: Leaving directory `/usr/local/src/branch/objdir' make: *** [bootstrap] Error 2 any ideas? -- Cheers, /ChJ
