Re: No ifcvt during ce1 pass (fails i386/ssefp-2.c)
On 3/15/07, Alexandre Oliva <[EMAIL PROTECTED]> wrote:
> Recent committed patch breaks i386ssefp-2.c testcase, where maxsd is
> not generated anymore.
FWIW, I saw it both before and after the patch for PR 31127. I've
just tried reverting PR 30643 as well, but the problem remains. So
it's unrelated.
Have you been able to narrow it down to any other patch?
Yes, bisection found that steven's patch is guilty as charged ;>
--- gcc/ChangeLog (revision 122856)
+++ gcc/ChangeLog (revision 122858)
@@ -1,3 +1,12 @@
+2007-03-12 Steven Bosscher <[EMAIL PROTECTED]>
+
+ * tree-pass.h (pass_into_cfg_layout_mode,
+ pass_outof_cfg_layout_mode): Declare.
+ * cfglayout.c (into_cfg_layout_mode, outof_cfg_layout_mode,
+ pass_into_cfg_layout_mode, pass_outof_cfg_layout_mode): New.
+ * passes.c (pass_into_cfg_layout_mode): Schedule before jump2.
+ (pass_outof_cfg_layout_mode): Schedule after pass_rtl_ifcvt.
+
Steven, I have been looking into this failure a bit, and found that
ifcvt during first pass is rejected in find_if_block(), at:
/* The THEN block of an IF-THEN combo must have exactly one predecessor,
other than any || blocks which jump to the THEN block. */
if ((EDGE_COUNT (then_bb->preds) - ce_info->num_or_or_blocks) != 1)
return FALSE;
For some reason, EDGE_COUNT (then_bb->preds) returns 2 (where
ce_info->n_o_o_blocks = 0). Strangely, bb3 ("else" block that fails)
has:
Basic block 3 , prev 2, next 4, loop_depth 0, count 0, freq 4600, maybe hot.
Predecessors: 2 [46.0%]
Successors: 4 [100.0%] (fallthru)
The testcase is:
double x;
q()
{
x=x<5?5:x;
}
compile this with -O2 -msse2 -mfpmath=sse, and this testcase should
compile to maxsd.
Uros.
Re: No ifcvt during ce1 pass (fails i386/ssefp-2.c)
On 3/15/07, Uros Bizjak <[EMAIL PROTECTED]> wrote: compile this with -O2 -msse2 -mfpmath=sse, and this testcase should compile to maxsd. I'll look into it this weekend. Gr. Steven
Re: No ifcvt during ce1 pass (fails i386/ssefp-2.c)
On 3/15/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: On 3/15/07, Uros Bizjak <[EMAIL PROTECTED]> wrote: > compile this with -O2 -msse2 -mfpmath=sse, and this testcase should > compile to maxsd. I'll look into it this weekend. Thanks! BTW: Your patch also causes FAIL: gcc.dg/torture/pr25183.c -O0 (internal compiler error) FAIL: gcc.dg/torture/pr25183.c -O0 (test for excess errors) on i386 [1]: gcc/cc1 -O0 pr25183.c error pr25183.c: In function âerrorâ: pr25183.c:22: internal compiler error: in cfg_layout_merge_blocks, at cfgrtl.c:2552 Please submit a full bug report, [1] http://gcc.gnu.org/ml/gcc-testresults/2007-03/msg00672.html Uros.
Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)
On Wed, 14 Mar 2007, Joe Buck wrote: > If we allow XFAILing tests that ICE, it should be an extremely rare thing. > I worry that once the precedent is set, the number of XFAIL ICEs will > go up with time, making it more likely that users will experience > compiler crashes. What's so bad about an ICE compared to e.g. wrong-code? The latter is IMNSHO much much worse. Is it just the technical matter of xfailing it or is there a *logical* reason that I've missed in this discussion and elsewere? brgds, H-P
Re: No ifcvt during ce1 pass (fails i386/ssefp-2.c)
On 3/15/07, Uros Bizjak <[EMAIL PROTECTED]> wrote: BTW: Your patch also causes FAIL: gcc.dg/torture/pr25183.c -O0 (internal compiler error) FAIL: gcc.dg/torture/pr25183.c -O0 (test for excess errors) Yes. Known. I bootstrapped a fix and had a box test it yesterday. I'll look at the test results tonight and commit the fix if there are no new failures (and this one is fixed). This failure is caused by problems with dead jump tables. There's another bug (with a PR filed for it) that is also related to dead jump tables. The fix I have should fix both these cases. Gr. Steven
MMX instruction and gcc
Hi, I want ask, if there is posibilities that gcc will be automaticaly generates MMX instruction? I tried -mtune, -march -mmmx. But gcc stil generates code without MMX instruction. On net I found only information about inline assembler function or citation from man page. I tried to compile program for adding two arrays of 24 chars. Thank for help -- Jan Kastil [EMAIL PROTECTED]
Re: Constrain not satisfied - floating point insns.
Hi all, I had a single movsf insn that accepts all alternatives for the reload to work. (define_insn "movsf" [(set (match_operand:SF 0 "nonimmediate_operand" "=f,m,f,f,d,d") (match_operand:SF 1 "general_operand" "m,f,f,d,f,i")) ] But for moving an immediate value, compiler should use a data register but it is using a floating point register. Still i get an ICE for constrain not satisfied. Regards, Rohit On 3/15/07, Jim Wilson <[EMAIL PROTECTED]> wrote: Rohit Arul Raj wrote: > (define_insn "movsf_store" > [(set (match_operand:SF 0 "memory_operand" "=m") > (match_operand:SF 1 "float_reg""f"))] You must have a single movsf define_insn that accepts all alternatives so that reload will work. You can't have separate define_insns for movsf and movsf_store. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
RE: What to do when constraint doesn't match
On 15 March 2007 05:00, Mohamed Shafi wrote: > I have a define_expand with the pattern name mov and a > define_insn mov_store > The predicate in define_expand is general_operand, so that all > operands are matched. > While in define_insn i have a predicate which allows only two class of > registers say 'a' and 'b'. But the constraint for define_insn only > allows registers of class 'b'. > > I also have a pattern for register move from 'a' to 'b', call it > mova2b. So if for mov_store define_insn constraint > doesn't satisfy why is that the compiler is not trying to match the > constraint by generating a mova2b pattern? Is there something > that i am missing here? Secondary reloads. IIUIC (I'm up to my neck in this area of the compiler myself ATM!) you use them to tell the compiler it needs to use a temporary register of class 'a' to move any value (that isn't a REG or SUBREG already in class 'b') into a reg of class 'b'. Look at `SECONDARY_RELOAD_CLASS', and `reload_inM' and `reload_outM' in the internals docs. cheers, DaveK -- Can't think of a witty .sigline today
RE: Constrain not satisfied - floating point insns.
On 14 March 2007 21:21, Jim Wilson wrote: > Rohit Arul Raj wrote: >> (define_insn "movsf_store" >> [(set (match_operand:SF 0 "memory_operand" "=m") >> (match_operand:SF 1 "float_reg""f"))] > > You must have a single movsf define_insn that accepts all alternatives > so that reload will work. You can't have separate define_insns for > movsf and movsf_store. But it is ok to use a define_expand (that accepts all alternatives) for movsf and use that to generate one of several movsf_ insns, isn't it? cheers, DaveK -- Can't think of a witty .sigline today
Re: can't find VCG viewer
Sunzir Deepur wrote on 03/14/07 05:36:
> any idea where I can find a (free) graphical VCG viewer suitable
> for gcc's vcg outputs ?
I'd recommend the attached script. Feed the output to GraphViz. The
script may need changes if you are using RTL dumps.
#!/bin/sh
#
# (C) 2005 Free Software Foundation
# Contributed by Diego Novillo <[EMAIL PROTECTED]>.
#
# This script is Free Software, and it can be copied, distributed and
# modified as defined in the GNU General Public License. A copy of
# its license can be downloaded from http://www.gnu.org/copyleft/gpl.html
if [ "$1" = "" ] ; then
echo "usage: $0 file"
echo
echo "Generates a GraphViz .dot graph file from 'file'."
echo "It assumes that 'file' has been generated with -fdump-tree-...-blocks"
echo
exit 1
fi
file=$1
out=$file.dot
echo "digraph cfg {"> $out
echo " node [shape=box]" >>$out
echo ' size="11,8.5"' >>$out
echo>>$out
(grep -E '# BLOCK|# PRED:|# SUCC:' $file | \
sed -e 's:\[\([0-9\.%]*\)*\]::g;s:([a-z_,]*)::g' | \
awk '{ #print $0; \
if ($2 == "BLOCK") \
{ \
bb = $3;\
print "\t", bb, "[label=\"", bb, "\", style=filled,
color=gray]"; \
} \
else if ($2 == "PRED:") \
{ \
for (i = 3; i <= NF; i++) \
print "\t", $i, "->", bb, ";"; \
} \
}') >> $out
echo "}">> $out
Re: error: unable to find a register to spill in class 'FP_REGS'
Hello, thanks for your answer. Here is an excerpt of the .00.expand file for insn 45: ---snip--- (insn 45 47 46 1 (set (subreg:SI (reg:DI 92 [ D.1212 ]) 4) (reg:SI 93 [ D.1211 ])) -1 (nil) (expr_list:REG_NO_CONFLICT (reg:SI 93 [ D.1211 ]) (nil))) ---snap--- That means the compiler has to reload the pseudo registers 92 and 93 for this instruction, right? Jim Wilson wrote: > and lreg ones. The greg one will have a section listing all of the > reloads generated, find the list of reloads generated for this insn 45. The relevant data for instruction 45 in .greg looks like that: ---snip--- ;; Function main ;; Need 2 regs of class FP_REGS (for insn 15). ;; Need 2 regs of class ALL_REGS (for insn 15). Spilling reg 32. Spilling reg 33. ;; Register dispositions: 69 in 3 70 in 8 71 in 4 72 in 8 73 in 5 74 in 8 75 in 6 76 in 1 77 in 8 78 in 9 79 in 10 80 in 9 81 in 8 82 in 9 83 in 8 84 in 10 85 in 8 86 in 9 87 in 8 88 in 8 89 in 9 90 in 7 91 in 9 92 in 9 93 in 10 94 in 2 ;; Hard regs used: 1 2 3 4 5 6 7 8 9 10 29 30 31 32 33 (insn 45 44 47 (use (reg:SI 8 r8)) -1 (nil) (nil)) ---snap--- > lreg will have info about register class preferencing. It will tell you > what register class the compiler wants to use for this insn. Same for the .lreg file: ---snip--- ;; Function main 95 registers. Register 69 used 7 times across 0 insns. Register 70 used 2 times across 0 insns; pointer. Register 71 used 6 times across 0 insns. Register 72 used 2 times across 0 insns. Register 73 used 6 times across 0 insns. Register 74 used 2 times across 0 insns; pointer. Register 75 used 7 times across 0 insns. Register 76 used 2 times across 0 insns; pref FP_REGS. Register 77 used 4 times across 0 insns. Register 78 used 2 times across 0 insns. Register 79 used 2 times across 0 insns. Register 80 used 2 times across 0 insns. Register 81 used 2 times across 0 insns. Register 82 used 2 times across 0 insns. Register 83 used 2 times across 0 insns. Register 84 used 2 times across 0 insns. Register 85 used 2 times across 0 insns; pref FP_REGS; pointer. Register 86 used 2 times across 0 insns. Register 87 used 2 times across 0 insns. Register 88 used 4 times across 0 insns. Register 89 used 2 times across 0 insns. Register 90 used 6 times across 0 insns. Register 91 used 2 times across 0 insns. Register 92 used 2 times across 0 insns; pointer. Register 93 used 2 times across 0 insns. Register 94 used 2 times across 0 insns; crosses 1 call; pref FP_REGS. 0 basic blocks. ;; Register 69 in 3. ;; Register 70 in 8. ;; Register 71 in 4. ;; Register 72 in 8. ;; Register 73 in 5. ;; Register 74 in 8. ;; Register 75 in 6. ;; Register 76 in 1. ;; Register 77 in 8. ;; Register 78 in 9. ;; Register 79 in 10. ;; Register 80 in 9. ;; Register 81 in 8. ;; Register 82 in 9. ;; Register 83 in 8. ;; Register 84 in 10. ;; Register 85 in 8. ;; Register 86 in 9. ;; Register 87 in 8. ;; Register 88 in 8. ;; Register 89 in 9. ;; Register 90 in 7. ;; Register 91 in 9. ;; Register 92 in 9. ;; Register 93 in 10. ;; Register 94 in 2. (insn 45 44 47 (use (reg:SI 88)) -1 (nil) (nil)) ---snap--- > The fact that this insn doesn't do FP isn't important. What is > important is how the pseudo-regs are used. If the pseudo-reg 92 is used > in 10 insns, and 8 of them are FP insns and 2 are integer move insns, > then the register allocator will prefer an FP reg, since that should > give the best overall result, as only 2 insns will need reloads. If it > used an integer reg, then 8 insns would need reloads. Ok that's clear. Thanks for explaining. Nevertheless I can't figure out from the above files what's wrong and maybe I am just lacking of the right interpretation of these intermediate files. Can you figure out any abnormal behaviour from the above file excerpts? Thanks in advance, Markus Franke
Re: core changes for mep port
DJ Delorie <[EMAIL PROTECTED]> writes: > > Again my first reaction is whether it is necessary to compile code > > which runs in two completely different modes in the same > > compilation. If the functions can't call each other, why do they > > need to be compiled together? > > Why do *any* two functions need to be compiled together? This is very > much like arm/thumb or mips/mips16, except that the available > *functionality* changes. So, if you want to have a static function > that does coprocessor work in an otherwise non-coprocessor source > file, you have to have a multi-mode compiler. Yeah, I'm not sure arm/thumb or mips/mips16 are the best examples, because in those cases we do require separate compilation. Ian
Re: core changes for mep port
DJ Delorie <[EMAIL PROTECTED]> writes: > It sounds like we're not communicating properly. The total patch set > to support core vs vliw modes, the part that needs to manage inlined > functions by attribute, is a total of four lines of code in the core > (not including prototypes). The two hooks are: > > > /* Return true if function CALLER cannot call CALLEE. Report an >error if so. CALLER is a decl and CALLEE is an arbitrary >function expression. */ > bool (* disallow_call_p) (tree caller, tree callee); > > /* Return true if function CALLER cannot inline calls to CALLEE. >Both arguments are decls. */ > bool (* disallow_inlining_p) (tree caller, tree callee); > > > and their calls: > > if (targetm.disallow_inlining_p (node->decl, decl)) >return false; > > if (targetm.disallow_call_p (current_function_decl, function)) >return error_mark_node; I don't see a real problem with this, but I would prefer to see "allow_XX" rather than "disallow_XX". It's easier to understand code which is expressed in the positive. Ian
Re: setting a breakpoint on a break statement
On Mar 14, 2007, at 3:16 PM, Ian Lance Taylor wrote: Tristan Gingold <[EMAIL PROTECTED]> writes: in some cases, a breakpoint can't be set on a continue or break statement. Here is a simple example: The reason is quiet simple: even at -O0 -g, there is no insn (and no BB) corresponding to the break/continue statement. Here is a small patch which fixes the issue. I wonder if this is the right approach. This patch makes the code generated at -O0 uglier... Thanks for sending the patch. Procedural note: patches should be sent to [EMAIL PROTECTED], and should have a ChangeLog entry. Thank you for the procedure. I will follow it when I submit the patch formally I don't think it is appropriate to change the meaning of forwarder_block_p. And I'm not sure why you need that patch anyhow, considering the existing code in cleanup_tree_cfg_1. Without that change, the rtl jump pass cleans the jump and all the previous work is useless. Also you should ideally add a test case. The effects are only visible for the debugger. How to write a compiler test case for this case ? Thanks, Tristan.
Re: setting a breakpoint on a break statement
Tristan Gingold <[EMAIL PROTECTED]> writes: > > I don't think it is appropriate to change the meaning of > > forwarder_block_p. And I'm not sure why you need that patch anyhow, > > considering the existing code in cleanup_tree_cfg_1. > Without that change, the rtl jump pass cleans the jump and all the > previous work is useless. I see. Then I think we shoulid tweak the RTL jump pass along the lines of cleanup_tree_cfg_1. A function like forwarder_block_p is conceptually easy to understand. It becomes harder to understand if it turns into forwarder_block_when_optimizing_p. > > Also you should ideally add a test case. > The effects are only visible for the debugger. How to write a > compiler test case for this case ? For tree level changes, you do it by grepping the dump file. See many of the test cases in testsuite/gcc.dg/tree-ssa, and their use of scan-tree-dump. For RTL level changes, the dump files are harder to interpret. But maybe you could do it by compiling with -gdwarf-2 and looking for a .loc pseudo-op with the right value in the assembler file (using scan-assembler). I don't know if that would really work but it seems feasible at first glance. My concern, of course, is that this kind of change is fragile, and we want to make sure that it does not break accidentally. Ian
ANNOUNCE: Gelato ICE GCC track, San Jose, CA, April 16-18, 2007
The GCC track will be on Mon 16/Apr and Tue 17/Apr. The program should be complete by now - Program at-a-glance: http://ice.gelato.org/pdf/gelatoICE_ataglance.pdf - Speaker list and abstracts: http://ice.gelato.org/program/program.php - The following GCC track is part of the Gelato ICE (Itanium Conference & Expo) technical program, April 16-18, 2007, San Jose, CA. All interested GCC developers are invited to attend . A working list of speakers and topics can be found here: This year there is a strong focus on Linux. Andrew Morton and Wim Coekaerts, Senior Director for Linux Engineering at Oracle, are keynote speakers. In addition to the GCC track, there are tracks covering the Linux IA-64 kernel, virtualization, tools and tuning, multi-core programming, and research. GCC Track at Gelato ICE: - Update on Scheduler Work & Discussion of New Software Pipelining Work, Arutyun Avetisyan, Russian Academy of Science - GPL2 and GPL3, Dan Berlin, Google - Update on the Gelato GCC Build Farm, Matthieu Delahaye, Gelato Central Operations - Update on Prefetching Work, Zdenek Dvorak, SuSE - Interprocedural Optimization Framework, Jan Hubicka, SuSE - Update on Superblock Work, Bob Kidd, University of Illinois - GCC and Osprey Update, Shin-Ming Liu, HP - Compiling Debian Using GCC 4.2 and Osprey, Martin Michlmayr, Debian - Update on Alias Analysis Work, Diego Novillo, Redhat - Update on LTO, Kenneth Zadeck, NaturalBridge
Re: MMX instruction and gcc
Galloth <[EMAIL PROTECTED]> writes: > I want ask, if there is posibilities that gcc will be automaticaly > generates MMX instruction? I tried -mtune, -march -mmmx. But gcc stil > generates code without MMX instruction. On net I found only > information about inline assembler function or citation from man page. > I tried to compile program for adding two arrays of 24 chars. This question is appropriate for the mailing list [EMAIL PROTECTED], not for [EMAIL PROTECTED] Please take any follow-ups to gcc-help. Thanks. In some cases gcc may be able to automatically generate MMX instructions if you use the -ftree-vectorize option. Otherwise, you need to write your code using the macros defined in the header file mmintrin.h. This can be found in the gcc source code in gcc/config/i386/mmintrin.h. It will also be installed with gcc somewhere on your system. It implements an interface documented by Intel; the documentation is available somewhere on the Intel web site. Ian
Re: ANNOUNCE: Gelato ICE GCC track, San Jose, CA, April 16-18, 2007
Diego Novillo wrote: The following GCC track is part of the Gelato ICE (Itanium Conference & Expo) OK, OK, I'm slow, I know - but this one I finally got: Gelato - Ice [ B ] "I scream, you scream, we all scream for ice cream ... " -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html
regclass oddity?
Hi all,
When regclass determines that placing an operand into either one of several
register classes would have the same cost, it picks the numerically highest
one in enum reg_class ordering.
In my particular circumstances this is not good, because a lot of the
high-numbered reg classes (which correspond to special-purpose registers) only
have one member in them. I am aware of the ordering rule that says that class
x must be numerically lower than class y if y is a superset of x, but in this
case the classes are entirely disjoint.
What makes it even worse is that regclass insists on picking these classes,
despite the fact that a) there is no way to load a memory operand into one, it
has to go via a secondary reload into a GPR, and b) there is no way to load an
immediate constant into one either. The only way to access these registers is
via a gpr.
So, is there actually anything inconsistent or incorrect about setting up my
reg classes in this fashion?
#define REG_CLASS_CONTENTS { \
{ 0x, 0x, 0x }, /* NO_REGS */ \
{ 0x, 0x, 0x }, /* GENERAL_REGS */ \
{ 0x, 0x, 0x0001 }, /* MPD_REG 64 */ \
{ 0x, 0x, 0x0002 }, /* MPR_REG 65 */ \
{ 0x, 0x, 0x0004 }, /* MPRA_REG 66 */ \
{ 0x, 0x, 0x0008 }, /* MPRL_REG 67 */ \
{ 0x, 0x, 0x0010 }, /* MPRH_REG 68 */ \
{ 0x, 0x, 0x0020 }, /* MPC_REG 69 */ \
{ 0x, 0x, 0x0040 }, /* MPV_REG 70 */ \
{ 0x, 0x, 0x0080 }, /* MPRLS_REG 71 */ \
{ 0x, 0x, 0x0100 }, /* MPAR_REG 72 */ \
{ 0x, 0x, 0x }, /* SPECIAL_REGS */ \
{ 0x, 0x, 0x } /* ALL_REGS */ \
}
I might be able to 'disguise' the problem by moving GENERAL_REGS after
SPECIAL_REGS, so that it would be picked if it was as favourable as any other,
but I'm curious: should regalloc really not care about the size of classes?
ISTM that given an equal cost for putting some operand into a class with 1
member and a class with 32 members, it would be highly preferable to choose
the bigger class to try and avoid register pressure. The nearest I can see to
any such logic in regclass would be the part of record_reg_classes that says
/* If this insn is a single set copying operand 1 to operand 0
and one operand is a pseudo with the other a hard reg or a pseudo
that prefers a register that is in its own register class then
we may want to adjust the cost of that register class to -1.
but that isn't coming into play in this case because it only cares about
reg->reg moves and I'm having trouble with a mem->reg move.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: MMX instruction and gcc
On 15 Mar 2007 08:12:21 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: Galloth <[EMAIL PROTECTED]> writes: > I want ask, if there is posibilities that gcc will be automaticaly > generates MMX instruction? I tried -mtune, -march -mmmx. But gcc stil > generates code without MMX instruction. On net I found only > information about inline assembler function or citation from man page. > I tried to compile program for adding two arrays of 24 chars. This question is appropriate for the mailing list [EMAIL PROTECTED], not for [EMAIL PROTECTED] Please take any follow-ups to gcc-help. Thanks. Actually this one I think belongs still here because ... In some cases gcc may be able to automatically generate MMX instructions if you use the -ftree-vectorize option. This is not true right now. GCC is not able to automatically use the MMX instructions at all, this is already filed as PR 22076 and others. There was a patch posted as an RFC to fix this but it caused regression on x86_64 and the person who submitted has not updated it yet for the mainline. Thanks, Andrew Pinski
RE: regclass oddity?
On 15 March 2007 15:53, Dave Korn wrote:
> Hi all,
>
> When regclass determines that [ ... ]
> So, is there actually anything inconsistent or incorrect about setting up
> my reg classes in this fashion?
>
> #define REG_CLASS_CONTENTS { \
> { 0x, 0x, 0x }, /* NO_REGS */ \
> { 0x, 0x, 0x }, /* GENERAL_REGS */ \
> { 0x, 0x, 0x0001 }, /* MPD_REG 64 */ \
> { 0x, 0x, 0x0002 }, /* MPR_REG 65 */ \
> { 0x, 0x, 0x0004 }, /* MPRA_REG 66 */ \
> { 0x, 0x, 0x0008 }, /* MPRL_REG 67 */ \
> { 0x, 0x, 0x0010 }, /* MPRH_REG 68 */ \
> { 0x, 0x, 0x0020 }, /* MPC_REG 69 */ \
> { 0x, 0x, 0x0040 }, /* MPV_REG 70 */ \
> { 0x, 0x, 0x0080 }, /* MPRLS_REG 71 */ \
> { 0x, 0x, 0x0100 }, /* MPAR_REG 72 */ \
> { 0x, 0x, 0x }, /* SPECIAL_REGS */ \
> { 0x, 0x, 0x } /* ALL_REGS */ \
> }
Hmm, further reading in the manual suggests another question I should be
asking about now:
Because my movsi3 pattern that allows both GENERAL_REGS through an 'r'
constraint, and MPD_REG and MPRL_REG through custom constraint letters ('a'
and 'd'), does that mean I need to define a union class or I'm actually doing
something wrong?
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: MMX instruction and gcc
"Andrew Pinski" <[EMAIL PROTECTED]> дÈëÏûÏ¢ÐÂÎÅ:[EMAIL PROTECTED] > On 15 Mar 2007 08:12:21 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: >> Galloth <[EMAIL PROTECTED]> writes: >> >> > I want ask, if there is posibilities that gcc will be automaticaly >> > generates MMX instruction? I tried -mtune, -march -mmmx. But gcc stil >> > generates code without MMX instruction. On net I found only >> > information about inline assembler function or citation from man page. >> > I tried to compile program for adding two arrays of 24 chars. >> >> This question is appropriate for the mailing list >> [EMAIL PROTECTED], not for [EMAIL PROTECTED] Please take any >> follow-ups to gcc-help. Thanks. > > Actually this one I think belongs still here because ... > >> In some cases gcc may be able to automatically generate MMX >> instructions if you use the -ftree-vectorize option. > > This is not true right now. GCC is not able to automatically use the > MMX instructions at all, this is already filed as PR 22076 and others. > There was a patch posted as an RFC to fix this but it caused > regression on x86_64 and the person who submitted has not updated it > yet for the mainline. I remembered that Uros said that the biggest problem is to determine which mode (x87 or MMX) is active; MMX/3DNow! autovectorization isn't so useful when SSE2/SSE is available so maybe we can turn it off with x86_64? -- Zuxy
Summer of Code 2007 mentors
GCC has been approved as a supported project for Google's Summer of Code 2007. Summer of Code is a program in which Google pays students to work on open source projects. Now we need people to sign up as mentors. As a rule of thumb I think mentors should be restricted to people listed in the MAINTAINERS file, which still gives us plenty to choose from. If you are interested, please sign up at http://code.google.com/soc/mentor_step1.html The benefits of being a mentor for a student are the chance to help him or her learn about gcc and increase the number of people who work on it. And, of course, gcc will improve. Plus I think that the mentor gets a T-shirt. If you sign up as a mentor, you will be able to vote on the projects submitted to Summer of Code for gcc. That will be helpful even if you don't wind up acting as a mentor for any specific project. For each approved and completed project, the student will receive $4500, and the gcc project will receive $500. As we did last year, our share of the money will go to the Free Software Foundation. That URL again: http://code.google.com/soc/mentor_step1.html Thanks! Ian
Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)
On Thu, Mar 15, 2007 at 04:58:51AM -0400, Hans-Peter Nilsson wrote: > On Wed, 14 Mar 2007, Joe Buck wrote: > > If we allow XFAILing tests that ICE, it should be an extremely rare thing. > > I worry that once the precedent is set, the number of XFAIL ICEs will > > go up with time, making it more likely that users will experience > > compiler crashes. > > What's so bad about an ICE compared to e.g. wrong-code? > The latter is IMNSHO much much worse. > Is it just the technical matter of xfailing it or is there a > *logical* reason that I've missed in this discussion and elsewere? The reason for not supporting XFAIL for a ICE is that a test that was already XFAIL for failing to compile didn't report a new ICE. It made sense at the time. Janis
Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)
On 3/15/07, Janis Johnson <[EMAIL PROTECTED]> wrote: On Thu, Mar 15, 2007 at 04:58:51AM -0400, Hans-Peter Nilsson wrote: > On Wed, 14 Mar 2007, Joe Buck wrote: > > If we allow XFAILing tests that ICE, it should be an extremely rare thing. > > I worry that once the precedent is set, the number of XFAIL ICEs will > > go up with time, making it more likely that users will experience > > compiler crashes. > > What's so bad about an ICE compared to e.g. wrong-code? > The latter is IMNSHO much much worse. > Is it just the technical matter of xfailing it or is there a > *logical* reason that I've missed in this discussion and elsewere? The reason for not supporting XFAIL for a ICE is that a test that was already XFAIL for failing to compile didn't report a new ICE. It made sense at the time. So we need a XICE instead? Richard.
Fwd: Query regarding struct variables in GIMPLE
Thanks. Can you point me to documentation / code where I can get more information about these artificial tags ? On 3/13/07, Diego Novillo < [EMAIL PROTECTED]> wrote: Karthikeyan M wrote on 03/13/07 21:32: > appears as x.j = 10 inside the GIMPLE dump of the function body . Is > there some place from where I can get it in the following( or any > other simpler ) form No, we don't unnecessarily take addresses of variables. Structure references are left intact. For some aggregates that cannot be scalarized we try to create artificial tags to represent the fields (to get field sensitive results in points-to resolution). -- Karthik To laugh often and love much; to win the respect of intelligent persons and the affection of children; to earn the approbation of honest critics; to appreciate beauty; to give of one's self; to leave the world a bit better, whether by a healthy child, a garden patch or a redeemed social condition; to have played and laughed with enthusiasm and sung with exultation; to know even one life has breathed easier because you have lived--that is to have succeeded. --Ralph Waldo Emerson
Re: Constrain not satisfied - floating point insns.
Dave Korn wrote: But it is ok to use a define_expand (that accepts all alternatives) for movsf and use that to generate one of several movsf_ insns, isn't it? No. You have to have a single movsf insn that accepts all constraints. reload knows that it can fix practically anything by emitting a move insn to move an operand into a reg or mem. However, you can't fix a move insn by emitting yet another move insn. That doesn't actually fix anything. That just moves the same problem to the new move insn. So the rules are different for move insns. You have to have a single pattern that accepts all alternatives that might be generated by reload. If you want to be pedantic, you can actually have multiple movsf patterns if you have operands that can't be generated by reload. For instance if you have EXTRA_CONSTRAINTS R, S, and T, then you could have 3 patterns one which accepts R and all usual operand combinations, one which accepts S and all usual operand combinations, and one which accepts T and all usual operand combinations. Doing that would be pointless though. You would be much better off just having the one pattern that accepts R, S, T and the usual operand combinations. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: What to do when constraint doesn't match
Mohamed Shafi wrote: I have a define_expand with the pattern name mov and a define_insn mov_store I also have a pattern for register move from 'a' to 'b', call it mova2b. You have to have a single mov pattern that accepts all valid constraint combinations. You can't use two separate patterns like this. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Constrain not satisfied - floating point insns.
Dave Korn wrote: But it is ok to use a define_expand (that accepts all alternatives) for movsf and use that to generate one of several movsf_ insns, isn't it? Reload doesn't use the move define_expands. It can't. A define_expand is allowed to do stuff like generate new RTL that would completely mess up what reload is trying to do. So reload has to generate move insns directly, and hope they match. And since emitting a move insn to fix another move insn makes no sense, existing move insns are fixed in place, and not rerecognized after they are fixed. Hence, you need a single move insn pattern that accepts all of the usual operand combinations. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
frv minmax predicate
The minmax_operator predicate also checks the operands of the operator to be appropriate, but the minmax_operator predicate is used for both integer and floating point operations. The predicate, as is, only matches the integer operands. Taking out the check on XEXP(...) in minmax_operator seems to get around the ICE we're seeing, but is this the right thing to do? Or do we need separate predicates for integer vs floating point?
Broken debug info with G++ anon struct typedefs
Hello,
in debugging a failing GDB test case I've come upon what looks like bad
DWARF-2 debug info being generated by G++.
The problem has to do with typedefs of anonymous structs like:
typedef struct {
int one;
int two;
} tagless_struct;
tagless_struct v_tagless;
This causes the following DWARF-2 to be generated:
.uleb128 0x2 # (DIE (0x6c) DW_TAG_structure_type)
.ascii "\0"# DW_AT_name
.byte 0x8 # DW_AT_byte_size
.byte 0x1 # DW_AT_decl_file (xxx.ii)
.byte 0x1 # DW_AT_decl_line
.4byte 0xa4 # DW_AT_sibling
.uleb128 0x3 # (DIE (0x87) DW_TAG_member)
.ascii "one\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file (xxx.ii)
.byte 0x2 # DW_AT_decl_line
.4byte 0xa4 # DW_AT_type
.byte 0x2 # DW_AT_data_member_location
.byte 0x23 # DW_OP_plus_uconst
.uleb128 0x0
.uleb128 0x3 # (DIE (0x95) DW_TAG_member)
.ascii "two\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file (xxx.ii)
.byte 0x3 # DW_AT_decl_line
.4byte 0xa4 # DW_AT_type
.byte 0x2 # DW_AT_data_member_location
.byte 0x23 # DW_OP_plus_uconst
.uleb128 0x4
.byte 0x0 # end of children of DIE 0x6c
.uleb128 0x4 # (DIE (0xa4) DW_TAG_base_type)
.byte 0x4 # DW_AT_byte_size
.byte 0x5 # DW_AT_encoding
.ascii "int\0" # DW_AT_name
.uleb128 0x5 # (DIE (0xab) DW_TAG_variable)
.ascii "v_tagless\0" # DW_AT_name
.byte 0x1 # DW_AT_decl_file (xxx.ii)
.byte 0x5 # DW_AT_decl_line
.4byte 0x6c # DW_AT_type
.byte 0x1 # DW_AT_external
.byte 0x5 # DW_AT_location
.byte 0x3 # DW_OP_addr
.4byte v_tagless
Note how the v_tagless variable records DIE 0x6c as type, which is
the anonymous struct -- the typedef is completely missing.
This is incorrect; we should see "tagless_struct" as type of
"v_tagless".
The reason for this appears to be the following optimization in
cp/decl.c (grokdeclarator):
/* If the user declares "typedef struct {...} foo" then the
struct will have an anonymous name. Fill that name in now.
Nothing can refer to it, so nothing needs know about the name
change. */
if (type != error_mark_node
&& unqualified_id
&& TYPE_NAME (type)
&& TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
&& TYPE_ANONYMOUS_P (type)
/* Don't do this if there are attributes. */
&& (!attrlist || !*attrlist)
&& cp_type_quals (type) == TYPE_UNQUALIFIED)
{
tree oldname = TYPE_NAME (type);
tree t;
/* Replace the anonymous name with the real name everywhere. */
for (t = TYPE_MAIN_VARIANT (type); t; t = TYPE_NEXT_VARIANT (t))
if (TYPE_NAME (t) == oldname)
TYPE_NAME (t) = decl;
This attempts to change the name to the typedef name.
However, it comes too late. The original anonymous struct type has already
run through rest_of_type_compilation at this stage, which has already called
dwarf2out_decl on it. This in turn has already allocated the DIE and set up
the name information. Changing TYPE_NAME afterwards has no effect on the
debug data any more.
Any suggestions how to fix this?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
[EMAIL PROTECTED]
Re: Constrain not satisfied - floating point insns.
Rohit Arul Raj wrote: But for moving an immediate value, compiler should use a data register but it is using a floating point register. Sometimes it is impossible to avoid using an FP reg where we would prefer to have a data register. This is why reload exists, to fix things that don't match their constraints after register allocation. Still i get an ICE for constrain not satisfied. It isn't clear what the problem is. Reload should have either forced the constant into memory, or else added a move insn so that we could load it into a data reg and then move the data reg to an FP reg. Try looking at the RTL dumps to see what reloads were generated for this insn. If the constraint failure happened after reload was done, what was the pre- and post- reload RTL for this insn? Did a following pass like post-reload cse accidentally break the insn? If the constraint failure is during reload, then you may have to spend a little time stepping through reload to see what went wrong. The interesting bit would be in find_reloads, you can set a conditional breakpoint on the insn number to stop here when it processes this insn. This function might be called multiple times for the same insn, as we have to iterate until all insns are fixed. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: We're out of tree codes; now what?
Ian Lance Taylor wrote: > "Doug Gregor" <[EMAIL PROTECTED]> writes: > >> Of course, one could use TREE_CODE to see through the difference >> between these two, e.g., >> >> #define TREE_CODE(NODE) >> ((enum tree_code) (NODE)->base.code == LANG_TYPE? >> (enum tree_code)((TYPE_LANG_SPECIFIC (NODE)->base.subcode + >> LAST_AND_UNUSED_TREE_CODE)) >> : (enum tree_code) (NODE)->base.code) >> >> Then, the opposite for TREE_SET_CODE: >> #define TREE_SET_CODE(NODE, VALUE) >> ((VALUE) >= LAST_AND_USED_TREE_CODE)? >> ((NODE)->base.code = LANG_TYPE, get_type_lang_specific >> (NODE)->base.subcode = (VALUE) - LAST_AND_USED_TREE_CODE) >> : ((NODE)->base.code = (VALUE)) > > Somehow I didn't quite see that you were proposing a change to > TREE_CODE itself. It doesn't make sense to change TREE_CODE for > something which is language specific: that would affect the whole > compiler. But I think it would be reasonable to introduce > LANG_TREE_CODE along the lines of what you wrote above, and use that > only in the frontend code. I think that this approach (language-specific subcodes) is the right way to go. I disagree with Andrew's sentiments about not using trees at all for C++. But, in any case, that's an academic disagreement; nobody's about to sign up for that project. So, the only real solutions are (a) expand the width of the code field and (b) use subcodes. And, I agree that we should do all we can to avoid expanding the size of tree nodes. So, I think the subcode approach is the best choice. Like Ian, I think the macros above are fine. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: error: unable to find a register to spill in class 'FP_REGS'
Markus Franke wrote: That means the compiler has to reload the pseudo registers 92 and 93 for this instruction, right? First we do register allocation. Then, after register allocation, if the chosen hard registers don't match the constraints, then we use reload to fix it. The relevant data for instruction 45 in .greg looks like that: Insn 45 in the greg dump looks nothing like the insn 45 in the expand dump, which means you are looking at the wrong insn here. But it was insn 45 in the original mail. Did you change the testcase perhaps? Or use different optimization options? The info we are looking for should look something like this Reloads for insn # 13 Reload 0: reload_out (SI) = (reg:SI 97) R1_REGS, RELOAD_FOR_OUTPUT (opnum = 0) reload_out_reg: (reg:SI 97) reload_reg_rtx: (reg:SI 1 %r1) ;; Register 92 in 9. ;; Register 93 in 10. This tells us that pseudo 92 was allocated to hard reg 9, and pseudo 93 was allocated to hard reg 10. I didn't see reg class preferencing info for these regs, but maybe it is in one of the other dump files. The earlier message has rtl claiming that pseudo 92 got allocated to register 1 (r1). I seem to be getting inconsistent information here. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
RE: regclass oddity?
On 15 March 2007 16:12, Dave Korn wrote:
>> So, is there actually anything inconsistent or incorrect about setting up
>> my reg classes in this fashion?
>>
>> #define REG_CLASS_CONTENTS { \
>> { 0x, 0x, 0x }, /* NO_REGS */ \
>> { 0x, 0x, 0x }, /* GENERAL_REGS */ \
>> { 0x, 0x, 0x0001 }, /* MPD_REG 64 */ \
>> { 0x, 0x, 0x0002 }, /* MPR_REG 65 */ \
>> { 0x, 0x, 0x0004 }, /* MPRA_REG 66 */ \
>> { 0x, 0x, 0x0008 }, /* MPRL_REG 67 */ \
>> { 0x, 0x, 0x0010 }, /* MPRH_REG 68 */ \
>> { 0x, 0x, 0x0020 }, /* MPC_REG 69 */ \
>> { 0x, 0x, 0x0040 }, /* MPV_REG 70 */ \
>> { 0x, 0x, 0x0080 }, /* MPRLS_REG 71 */ \
>> { 0x, 0x, 0x0100 }, /* MPAR_REG 72 */ \
>> { 0x, 0x, 0x }, /* SPECIAL_REGS */ \
>> { 0x, 0x, 0x } /* ALL_REGS */ \
>> }
>
> Hmm, further reading in the manual suggests another question I should be
> asking about now:
>
> Because my movsi3 pattern that allows both GENERAL_REGS through an 'r'
> constraint, and MPD_REG and MPRL_REG through custom constraint letters ('a'
> and 'd'), does that mean I need to define a union class or I'm actually
> doing something wrong?
Well, it certainly /appears/ to have helped. I also moved GENERAL_REGS to
last entry before ALL_REGS just to make it preferred over the smaller classes.
cheers,
DaveK
--
Can't think of a witty .sigline today
Re: regclass oddity?
Dave Korn wrote: When regclass determines that placing an operand into either one of several register classes would have the same cost, it picks the numerically highest one in enum reg_class ordering. One possible solution is to give the special registers a higher REGISTER_MOVE_COST to discourage their use. Another solution is to use ! and ? in the constraints to increase the cost of alternatives that are inconvenient. There is also CLASS_LIKELY_SPILLED_P which is supposed to discourage local-alloc from using registers in single-reg classes. At least there is code for this in gcc-2.95.3. It looks like things have changed in this area since then. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: regclass oddity?
Dave Korn wrote:
Because my movsi3 pattern that allows both GENERAL_REGS through an 'r'
constraint, and MPD_REG and MPRL_REG through custom constraint letters ('a'
and 'd'), does that mean I need to define a union class or I'm actually doing
something wrong?
Adding the union classes would certainly help. The mips port for
instance has union classes for hi, lo, the general regs, along with some
others.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)
On Mar 14, 2007, at 11:12 PM, Mark Mitchell wrote: Zero FAILs may not be achievable on all targets, but if I had a magic XFAIL wand, that would put the right XFAIL goo into all tests before every release so that all users who built the toolchain correctly always got zero FAILs, I would do it. I can wire up a robot to revert all patches that introduce unexpected failures on darwin. By kicking out the patches early and often, we increase the likely hood that as we go to release it, there would be 0 of them. That, coupled with marking or fixing the existing unexpected failures, and we'd be at and stay at 0. You want to wave that wand?
Re: No ifcvt during ce1 pass (fails i386/ssefp-2.c)
On 3/15/07, Uros Bizjak <[EMAIL PROTECTED]> wrote:
The testcase is:
double x;
q()
{
x=x<5?5:x;
}
compile this with -O2 -msse2 -mfpmath=sse, and this testcase should
compile to maxsd.
This happens because a "fallthrough edge" is meaningless in cfglayout
mode, but ifcvt.c still gives special meaning to the fallthrough edge.
This should not matter, but it does for some reason, and I'm
investigating this right now. I'll try to come up with a fix asap.
Gr.
Steven
Re: frv minmax predicate
DJ Delorie <[EMAIL PROTECTED]> writes: > The minmax_operator predicate also checks the operands of the operator > to be appropriate, but the minmax_operator predicate is used for both > integer and floating point operations. The predicate, as is, only > matches the integer operands. > > Taking out the check on XEXP(...) in minmax_operator seems to get > around the ICE we're seeing, but is this the right thing to do? Or do > we need separate predicates for integer vs floating point? It should be safe to use a single predicate. And it would also work to use two predicates. So it's just a style issue. You just have to make sure that the predicate only accepts the types of operands the insn and constraints are prepared to handle. I would be a little bit skeptical of removing the gpr_or_int10_operand test, for example. But it would be reasonable to check something else for a floating point mode. Ian
Re: GCC 4.2 branch comparision failure building Java
On Tue, 13 Mar 2007, Mark Mitchell wrote: > The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: > > Comparing stages 2 and 3 > Bootstrap comparison failure! > ./java/parse.o differs > ./java/parse-scan.o differs > > Has anyone else seen this? I'm now looking at this (or at a possibly related bootstrap comparison failure seen on i686-pc-linux-gnu). -- Joseph S. Myers [EMAIL PROTECTED]
Re: GCC 4.2 branch comparision failure building Java
Joseph S. Myers wrote: > On Tue, 13 Mar 2007, Mark Mitchell wrote: > >> The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: >> >> Comparing stages 2 and 3 >> Bootstrap comparison failure! >> ./java/parse.o differs >> ./java/parse-scan.o differs >> >> Has anyone else seen this? > > I'm now looking at this (or at a possibly related bootstrap comparison > failure seen on i686-pc-linux-gnu). Thanks! That's a big help. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: frv minmax predicate
> You just have to make sure that the predicate only accepts the types > of operands the insn and constraints are prepared to handle. I would > be a little bit skeptical of removing the gpr_or_int10_operand test, > for example. But it would be reasonable to check something else for a > floating point mode. That was my concern too, but the define_insn_and_split *also* has the predicates for the operands. Do they need to be duplicated?
Re: core changes for mep port
> > if (targetm.disallow_inlining_p (node->decl, decl)) > >return false; > > > > if (targetm.disallow_call_p (current_function_decl, function)) > >return error_mark_node; > > I don't see a real problem with this, but I would prefer to see > "allow_XX" rather than "disallow_XX". It's easier to understand code > which is expressed in the positive. Ok. Where is the best place to put these? Most of today's inline logic only looks at the callee, not both the caller and callee.
Re: frv minmax predicate
DJ Delorie <[EMAIL PROTECTED]> writes: > > You just have to make sure that the predicate only accepts the types > > of operands the insn and constraints are prepared to handle. I would > > be a little bit skeptical of removing the gpr_or_int10_operand test, > > for example. But it would be reasonable to check something else for a > > floating point mode. > > That was my concern too, but the define_insn_and_split *also* has the > predicates for the operands. Do they need to be duplicated? Oh, I get it now. No, there is no reason for the duplication between minmax_operator and the insn itself. You should be able to remove the tests from minmax_operator. I wonder why they are there at all? Ian
Re: core changes for mep port
In addition, my current email conversation with Dorit about GPU integration would be better suited to high level optimisation and code separation with multiple backends. Eric Christopher wrote: This and the register changes come close to multi-arch gcc. Is that a direction we want to go? Historically we have not tried to support Personally I'd love to see us go this way if it doesn't inconvenience us too much. From what I remember of the MeP port it was pretty clean and wouldn't be an inconvenience. -eric
Re: frv minmax predicate
> Oh, I get it now. No, there is no reason for the duplication between > minmax_operator and the insn itself. You should be able to remove the > tests from minmax_operator. I wonder why they are there at all? This, then? 2007-03-15 DJ Delorie <[EMAIL PROTECTED]> * config/frv/predicates.md (minmax_operator): Don't check operands here. Index: config/frv/predicates.md === --- config/frv/predicates.md(revision 122960) +++ config/frv/predicates.md(working copy) @@ -1271,12 +1271,6 @@ break; } - if (! integer_register_operand (XEXP (op, 0), mode)) -return FALSE; - - if (! gpr_or_int10_operand (XEXP (op, 1), mode)) -return FALSE; - return TRUE; })
Re: frv minmax predicate
DJ Delorie <[EMAIL PROTECTED]> writes: > 2007-03-15 DJ Delorie <[EMAIL PROTECTED]> > > * config/frv/predicates.md (minmax_operator): Don't check operands > here. Looks good to me. (Not that I know anything about the FRV). Ian
Re: Query regarding struct variables in GIMPLE
Karthikeyan M wrote on 03/15/07 15:06: > Thanks. > Can you point me to documentation / code where I can get more > information about these artificial tags ? gcc/tree-ssa-alias.c:create_structure_vars() The section on Structural alias analysis in the internals documentation should also help.
Re: GCC 4.2 branch comparision failure building Java
"Joseph S. Myers" <[EMAIL PROTECTED]> writes: > On Tue, 13 Mar 2007, Mark Mitchell wrote: > > > The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: > > > > Comparing stages 2 and 3 > > Bootstrap comparison failure! > > ./java/parse.o differs > > ./java/parse-scan.o differs > > > > Has anyone else seen this? > > I'm now looking at this (or at a possibly related bootstrap comparison > failure seen on i686-pc-linux-gnu). For what it's worth, I bootstrapped on a few different GNU/Linux systems with different kernels and base compilers. I only saw bootstrap comparison failures on one; that one was running Red Hat 9 and had gcc 3.2.2 installed in /usr/bin. On that one, a bootstrap4 worked. So I assumed that that one was due to some miscompilation of stage1. I saw one other similar case recently: an older compiler miscompiled stage1 in a way that introduced a bootstrap comparison failure; unfortunately I don't recall the exact details. Anyhow, the point is: first see if a bootstrap4/compare3 works. If it does, look at your base compiler. Ian
Re: GCC 4.2 branch comparision failure building Java
On Thu, Mar 15, 2007 at 04:11:29PM -0700, Ian Lance Taylor wrote: > "Joseph S. Myers" <[EMAIL PROTECTED]> writes: > > > On Tue, 13 Mar 2007, Mark Mitchell wrote: > > > > > The GCC 4.2.0 RC1 build has failed (on x86_64-unknown-linux-gnu) with: > > > > > > Comparing stages 2 and 3 > > > Bootstrap comparison failure! > > > ./java/parse.o differs > > > ./java/parse-scan.o differs > > > > > > Has anyone else seen this? > > > > I'm now looking at this (or at a possibly related bootstrap comparison > > failure seen on i686-pc-linux-gnu). > > For what it's worth, I bootstrapped on a few different GNU/Linux > systems with different kernels and base compilers. I only saw > bootstrap comparison failures on one; that one was running Red Hat 9 > and had gcc 3.2.2 installed in /usr/bin. On that one, a bootstrap4 > worked. So I assumed that that one was due to some miscompilation of > stage1. Yes, this has been reported before (I've also seen bootstrap failures when using Red Hat's version 3.2.3 on an x86 RHEL3 box). While we could tell people to use a different compiler to bootstrap, a lot of people will run into this, because there are still a lot of older systems with 3.2.x compilers out there. It might be possible to isolate and work around the failure.
Re: GCC 4.2 branch comparision failure building Java
Joe Buck wrote: >> For what it's worth, I bootstrapped on a few different GNU/Linux >> systems with different kernels and base compilers. I only saw >> bootstrap comparison failures on one; that one was running Red Hat 9 >> and had gcc 3.2.2 installed in /usr/bin. On that one, a bootstrap4 >> worked. So I assumed that that one was due to some miscompilation of >> stage1. > > Yes, this has been reported before (I've also seen bootstrap failures > when using Red Hat's version 3.2.3 on an x86 RHEL3 box). I do indeed generally build GCC releases on an RHEL3 box. However, I believe that I was using a version of GCC 3.4.x (built by CodeSourcery) as the bootstrap compiler. It does seem like a suspiciously similar situation, though; I'm sure that Joseph will be able to tell us if the problem is reproducible with GCC 3.4.x. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: core changes for mep port
DJ Delorie <[EMAIL PROTECTED]> writes: > > > if (targetm.disallow_inlining_p (node->decl, decl)) > > >return false; > > > > > > if (targetm.disallow_call_p (current_function_decl, function)) > > >return error_mark_node; > > > > I don't see a real problem with this, but I would prefer to see > > "allow_XX" rather than "disallow_XX". It's easier to understand code > > which is expressed in the positive. > > Ok. Where is the best place to put these? Most of today's inline > logic only looks at the callee, not both the caller and callee. Do you mean where is the best place to call these functions? Look at the calls to cgraph_mark_edge in ipa-inline.c--that has both caller and callee--and look at inline_forbidden_p--there I assume that cfun will hold the caller. Ian
Re: GCC 4.2 branch comparision failure building Java
On Thu, Mar 15, 2007 at 05:30:48PM -0700, Mark Mitchell wrote: > Joe Buck wrote: > > >> For what it's worth, I bootstrapped on a few different GNU/Linux > >> systems with different kernels and base compilers. I only saw > >> bootstrap comparison failures on one; that one was running Red Hat 9 > >> and had gcc 3.2.2 installed in /usr/bin. On that one, a bootstrap4 > >> worked. So I assumed that that one was due to some miscompilation of > >> stage1. > > > > Yes, this has been reported before (I've also seen bootstrap failures > > when using Red Hat's version 3.2.3 on an x86 RHEL3 box). > > I do indeed generally build GCC releases on an RHEL3 box. However, I > believe that I was using a version of GCC 3.4.x (built by CodeSourcery) > as the bootstrap compiler. It does seem like a suspiciously similar > situation, though; I'm sure that Joseph will be able to tell us if the > problem is reproducible with GCC 3.4.x. The problem does not happen with 3.4.x at least for x==2. I regularly use gcc 3.4.2 as the bootstrap compiler for my gcc testing. Here's last night's run for the 4.2 branch: http://gcc.gnu.org/ml/gcc-testresults/2007-03/msg00710.html At one point I considered trying a search to see which files get miscompiled, by combining stage1 object files from a run with 3.2.3 and 3.4.2 and trying to do the rest of the bootstrap with that, then varying which .o files come from which compilers. But then I got much busier and lost the motivation.
Re: frv minmax predicate
> "DJ" == DJ Delorie <[EMAIL PROTECTED]> writes: >> Oh, I get it now. No, there is no reason for the duplication between >> minmax_operator and the insn itself. You should be able to remove the >> tests from minmax_operator. I wonder why they are there at all? > This, then? Ok.
Re: GCC 4.2 branch comparision failure building Java
On Thu, Mar 15, 2007 at 05:48:12PM -0700, Joe Buck wrote: > At one point I considered trying a search to see which files get > miscompiled, by combining stage1 object files from a run with 3.2.3 and > 3.4.2 and trying to do the rest of the bootstrap with that, then varying > which .o files come from which compilers. But then I got much busier and > lost the motivation. I suppose another possibility would be to determine the first revision of the compiler that fails bootstrap compare when built with 3.2.3; it was months ago if I recall correctly (4.1.x works).
Re: frv minmax predicate
> Ok. Thanks! Applied.
Re: core changes for mep port
> Do you mean where is the best place to call these functions? Yup. > Look at the calls to cgraph_mark_edge in ipa-inline.c There is no such function. I couldn't find anything in ipa-inline that (1) had access to both ends of the call edge, (2) was actually called, and (3) was called before the inlining happened. > and look at inline_forbidden_p--there I assume that cfun will hold > the caller. cfun holds the callee. I found a lot of functions that only had access to the callee (no help there). I also found lots of functions that looked promising but were never called.
Problem with building libgfortran on PPC
Hello, I get the following error on PPC while bootstrapping mainline. Re-runing make I get: collect2: ld terminated with signal 11 [Segmentation fault] make[8]: *** [libstdc++.la] Error 1 Thanks, Revital ranlib .libs/libgfortran.a creating libgfortran.la (cd .libs && rm -f libgfortran.la && ln -s ../libgfortran.la libgfortran.la) make[6]: Nothing to be done for `all-am'. make[6]: Leaving directory `/home/eres/check_ifcvt_fix/build/ppc64-yellowdog-linux/nof/libgfortran' make[5]: Leaving directory `/home/eres/check_ifcvt_fix/build/ppc64-yellowdog-linux/nof/libgfortran' make[4]: Leaving directory `/home/eres/check_ifcvt_fix/build/ppc64-yellowdog-linux/libgfortran' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/eres/check_ifcvt_fix/build/ppc64-yellowdog-linux/libgfortran' make[2]: Leaving directory `/home/eres/check_ifcvt_fix/build/ppc64-yellowdog-linux/libgfortran' make[1]: Leaving directory `/home/eres/check_ifcvt_fix/build' make: *** [bootstrap] Error 2
Re: core changes for mep port
DJ Delorie <[EMAIL PROTECTED]> writes: > > Do you mean where is the best place to call these functions? > > Yup. > > > Look at the calls to cgraph_mark_edge in ipa-inline.c > > There is no such function. I couldn't find anything in ipa-inline > that (1) had access to both ends of the call edge, (2) was actually > called, and (3) was called before the inlining happened. Sorry, I meant cgraph_mark_inline. It looks like what you want to me. But maybe I'm misreading it. > > and look at inline_forbidden_p--there I assume that cfun will hold > > the caller. > > cfun holds the callee. I found a lot of functions that only had > access to the callee (no help there). I also found lots of functions > that looked promising but were never called. Sorry, you're right, inline_forbidden_p is different. Ian
