Re: We're out of tree codes; now what?
Hi Mike,
[I'm replying in this thread to the Objective-C patch you posted in
the type-traits discussion, because both that post and this one are
about reducing the number of tree codes]
On 3/13/07, Mike Stump <[EMAIL PROTECTED]> wrote:
I just converted the Objective-C front-end to free up enough tree
codes so that Objective-C++ can compile again. I know it can be
done. If you want a new tree code, you can convert some other tree
code into a subcode. pick one one.
Thanks for doing this!
For ideas, please see the below patch. I glanced at the C++ front
end, I see 8 tree codes (all the tcc_type codes) that you can reclaim
using the technique below.
For those that want to begin reviewing it, have at it, I'd be
interested in, do we even want to go in this direction (we don't have
hard numbers on the compile time costs yet, I don't think)? If so,
any better way to do this in the short term?
Emboldened by your patch, I took a quick swing at introducing subcodes
for the simplest tcc_type node in the C++ front end - TYPEOF_TYPE. The
patch is attached. Here are some observations:
- C++ already uses the LANG_TYPE tree code, although certainly not
the way it was intended: UNKNOWN_TYPE is #define'd to LANG_TYPE. This
is probably keeping Objective-C++ from working with your patch (I
didn't try it).
- C++ already uses TYPE_LANG_SPECIFIC, for class types and for
pointers to member functions. Those are both based on RECORD_TYPE
nodes (ugh). That's okay: it turns out that we can use
TYPE_LANG_SPECIFIC for RECORD_TYPE nodes and LANG_TYPE nodes with no
problems whatsoever.
- If C++ uses LANG_TYPE, and Objective C uses LANG_TYPE, we're
heading for a collision with Objective-C++. Either we'll need use
different top-level codes (LANG_TYPE vs. OBJC_LANG_TYPE, for example),
or we need to consolidate LANG_TYPE by making the subtype codes
extensible by Objective-C++ (just like normal tree codes are). The
latter seems like the right thing to do.
- We're also heading toward collisions with lang_type_class, etc.,
but those are easy to fix.
- It doesn't seem to happen in the Objective-C front end, but in the
C++ front end we have a lot of large switches on the TREE_CODE of a
type. With subcodes, these switches become very clunky. We go from
something like this:
switch (TREE_CODE (t))
{
case TYPEOF_TYPE:
/* Handle `typeof' */
break;
default:
/* Default case */
break;
}
to a two-level solution:
switch (TREE_CODE (t))
{
case LANG_TYPE:
switch (LANG_TYPE_SUBCODE (t))
{
case TYPEOF_TYPE_SUBCODE:
/* Handle `typeof' */
break;
default:
/* Default case. */
break;
}
break;
default:
/* Default case */
break;
}
Notice how I had to duplicate the code in the default case? The
situation gets worse when the TYPEOF_TYPE case was combined with other
cases (more duplication) or there was a fall-through either into or
out of the TYPEOF_TYPE case. The latter doesn't happen often with
TYPEOF_TYPE, but it does with other C++ _TYPE nodes.
While reviewing your Objective-C patch, the approach seemed very
clean. The data structures were more explicit than they are today (I
immediately started thinking, "hey, we could use this to shrink the
size of the common bits for types!"), and the few comparisons against
existing _TYPE nodes just because predicate checks.
Unfortunately, it doesn't look like the approach transfers well to the
C++ front end, where the two-level structure forced on us by subcodes
becomes unwieldy pretty quickly. I fear that the code duplication in
switch statements for default and fall-through cases is going to cause
maintenance headaches for a long time to come.
Still, please take a peek at the attached patch to decide for
yourself... I may have missed something obvious. The patch itself
doesn't actually save any nodes, because it introduces a real
UNKNOWN_TYPE node while removing the TYPEOF_TYPE node. But, it makes
TYPEOF_TYPE a subcode'd type, and the other tcc_type nodes (including
UNKNOWN_TYPE) could then be subcode'd for an actual savings. Browse
through the patch to see if the effort is well-spent.
My conclusion from this is that, even if we don't store it in
tree_base, we really, really want a TREE_CODE that is > 8 bits, or we
want *gasp* separate codes for tcc_type vs. tcc_expression. If it
doesn't work in a switch statement, it's not a viable solution for the
C++ front end.
Just FYI on your patch:
+struct lang_type_header GTY(()) {
+ BOOL_BITFIELD subcode : 3;
+};
That should be an ENUM_BITFIELD (subcode);
Cheers,
Doug
Index: cp-tree.def
===
--- cp-tree.def (revision 122840)
+++ cp-tree.def (working copy)
@@ -166,7 +166,7 @@ DEFTREECODE (TEMPLATE_TEMPLATE_PARM, "te
/* The ordering of the following codes
Re: bootstrap broke in 4.2
[EMAIL PROTECTED] (Mike Stump) writes: > ../../gcc/gcc/var-tracking.c: In function âvariable_tracking_mainâ: > ../../gcc/gcc/var-tracking.c:2961: warning: assuming signed overflow does not > occur when assuming that (X - c) >= X is always true > ../../gcc/gcc/var-tracking.c:2961: warning: assuming signed overflow does not > occur when assuming that (X - c) >= X is always true > make[3]: *** [var-tracking.o] Error 1 > > :-( Luckly, we had a chance to break it right before release... :-) > > Anyway else seeing these? I see it now. My apologies. I just committed a patch to the 4.2 branch to fix it. Ian
Re: libgomp failures on powerpc-apple-darwin8
On Tue, Mar 13, 2007 at 10:28:41PM -0400, Jack Howarth wrote: > Interestingly, while... > > gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp > -lstdc++ -lm -m32 -o ./pr30703.exe > /usr/bin/ld: Undefined symbols: > __Unwind_Resume > collect2: ld returned 1 exit status > > fails on powerpc-apple-darwin8 > > gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp > -lstdc++ -lm -m32 -shared-libgcc -o ./pr30703.exe > > ...links fine. On powerpc-apple-darwin8, libgcc.a is missing __Unwind_Resume. > I wonder why this doesn't show up > on any other architectures? Because libstdc++.so links against libgcc_s.so.1 which exports that symbol (was linked with -shared-libgcc). Or, on ELFish targets that use recent binutils when neither -shared-libgcc nor -static-libgcc is used, libgcc_s.so.1 is linked in --as-needed. libgcc.a doesn't contain the unwinder on purpose, it is only in libgcc_s.so and libgcc_eh.a, so that every binary or library doesn't have its own copy of the unwinder (which causes severe problems). Jakub
Re: RTL representations and virtual addresses
On 3/13/07, Jim Wilson <[EMAIL PROTECTED]> wrote: Sunzir Deepur wrote: > My wish is to generate a CFG in which I would know, for each basic block > and RTL command, what is the virtual address this command will be at > in the binary.. You can already find much of this info in the gcov profiling files. See profile.c and gcov.c and other related files. splendid idea ! Thanks ! -- Jim Wilson, GNU Tools Support, http://www.specifix.com
can't find VCG viewer
Hello group, any idea where I can find a (free) graphical VCG viewer suitable for gcc's vcg outputs ? seems like the old 1995 package is not applicable on newest linux systems (am working on fedora). Thank You sunzir
Re: Question for removing trailing whitespaces (not vertical tab) from source
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Mar 13, 2007 at 11:15:27AM -0700, Brian Dessent wrote:
> Kai Tietz wrote:
> > Ok, I will try for this. I have to find a different editor, which is
> > not too smart as to remove trailing whitespaces ...
>
> Or just add -w to the diff options when generating the patch.
No, please don't. While -w is nice for generating diffs that are for
*human* consumption (reviewing changes), if you try to *apply* them you
will run into trouble. patch may not recognize the context so it won't
apply, or if it does apply, you can easily screw up the indentation of
the changed code. Consider what happens if the change you make is the
addition of an if () { ... } around an existing block of code. After
applying a -w patch, you'll end up with
blah();
if (cond)
..{
hello();
world();
..}
(blanks replaced by '.' to avoid MUA mangling)
BTW if you're going to do TAB->space conversion anyway, watch out for
sed expressions. I know there are a couple of those in the tree.
- --
Meetings are indispensable when you don't want to do anything.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFF98MRwyMv24BBd/gRAkiyAKCkxr3rkYUqJnx0NUq0uinfbNGaWwCfbPqo
jYhaKhK4BVP4bYwkxC0NbPQ=
=ZJm+
-END PGP SIGNATURE-
No ifcvt during ce1 pass (fails i386/ssefp-2.c)
Hello!
Recent committed patch breaks i386ssefp-2.c testcase, where maxsd is
not generated anymore.
I have looked a bit into this failure and noticed that for some reason
we don't perform ifcvt transformations during ce1 RTL pass. The second
transformation is still performed during ce2 pass, but this is late as
combine already combined some patterns into patterns that can't be
split into maxsd pattern.
Previously, ce1 pass generated:
IF-THEN block found, pass 1, start block 2 [insn 5], then 3 [15], join 4 [17]
Replacing insn 10 by jump 35
Conversion succeeded on pass 1.
1 possible IF blocks searched.
1 IF blocks converted.
2 true changes made.
(insn 34 9 19 2 (set (reg:DF 58 [ iftmp.0 ])
(unspec:DF [
(reg:DF 60)
(reg:DF 58 [ iftmp.0 ])
] 52)) 564 {*ieee_smaxdf3} (nil)
(nil))
but now all relevant insns remain unaffected at the end of ce1 pass:
(insn 9 8 10 2 (set (reg:CCFPU 17 flags)
(compare:CCFPU (reg:DF 60)
(reg:DF 58 [ iftmp.0 ]))) 26 {*cmpfp_iu_sse} (nil)
(nil))
(jump_insn 10 9 14 2 (set (pc)
(if_then_else (gt (reg:CCFPU 17 flags)
(const_int 0 [0x0]))
(label_ref:SI 14)
(pc))) 365 {*jcc_1} (nil)
(expr_list:REG_BR_PROB (const_int 4600 [0x11f8])
(nil)))
Uros.
Re: We're out of tree codes; now what?
On 3/14/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
Hi Mike,
[I'm replying in this thread to the Objective-C patch you posted in
the type-traits discussion, because both that post and this one are
about reducing the number of tree codes]
On 3/13/07, Mike Stump <[EMAIL PROTECTED]> wrote:
> I just converted the Objective-C front-end to free up enough tree
> codes so that Objective-C++ can compile again. I know it can be
> done. If you want a new tree code, you can convert some other tree
> code into a subcode. pick one one.
Thanks for doing this!
> For ideas, please see the below patch. I glanced at the C++ front
> end, I see 8 tree codes (all the tcc_type codes) that you can reclaim
> using the technique below.
>
> For those that want to begin reviewing it, have at it, I'd be
> interested in, do we even want to go in this direction (we don't have
> hard numbers on the compile time costs yet, I don't think)? If so,
> any better way to do this in the short term?
Emboldened by your patch, I took a quick swing at introducing subcodes
for the simplest tcc_type node in the C++ front end - TYPEOF_TYPE. The
patch is attached. Here are some observations:
- C++ already uses the LANG_TYPE tree code, although certainly not
the way it was intended: UNKNOWN_TYPE is #define'd to LANG_TYPE. This
is probably keeping Objective-C++ from working with your patch (I
didn't try it).
- C++ already uses TYPE_LANG_SPECIFIC, for class types and for
pointers to member functions. Those are both based on RECORD_TYPE
nodes (ugh). That's okay: it turns out that we can use
TYPE_LANG_SPECIFIC for RECORD_TYPE nodes and LANG_TYPE nodes with no
problems whatsoever.
- If C++ uses LANG_TYPE, and Objective C uses LANG_TYPE, we're
heading for a collision with Objective-C++. Either we'll need use
different top-level codes (LANG_TYPE vs. OBJC_LANG_TYPE, for example),
or we need to consolidate LANG_TYPE by making the subtype codes
extensible by Objective-C++ (just like normal tree codes are). The
latter seems like the right thing to do.
- We're also heading toward collisions with lang_type_class, etc.,
but those are easy to fix.
- It doesn't seem to happen in the Objective-C front end, but in the
C++ front end we have a lot of large switches on the TREE_CODE of a
type. With subcodes, these switches become very clunky. We go from
something like this:
switch (TREE_CODE (t))
{
case TYPEOF_TYPE:
/* Handle `typeof' */
break;
default:
/* Default case */
break;
}
to a two-level solution:
switch (TREE_CODE (t))
{
case LANG_TYPE:
switch (LANG_TYPE_SUBCODE (t))
{
case TYPEOF_TYPE_SUBCODE:
/* Handle `typeof' */
break;
default:
/* Default case. */
break;
}
break;
default:
/* Default case */
break;
}
#define LANG_TYPE_CODE (t) (TREE_CODE (t) == LANG_TYPE ?
LANG_TYPE_SUBCODE (t) : INVALID_SUBCODE)
and then INVALID_SUBCODE will fall through to the default case as well.
Richard.
Re: Error in checking compat.exp
> > I'll find a way to fix that. > > Revital, please try this. I've tested it but know better than to check > things in at the end of the day; I'll post it tomorrow. It fixes the problem. Thanks, Revital
Re: Error in checking compat.exp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
NotDashEscaped: You need GnuPG to verify this message
On Tue, Mar 13, 2007 at 02:22:06PM -0700, Jim Wilson wrote:
> Revital1 Eres wrote:
> >ERROR: tcl error sourcing
> >/home/eres/mve_mainline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/compat.exp.
> >ERROR: couldn't open
> >"/home/eres/mve_xline_zero_12_3/gcc/gcc/testsuite/g++.dg/compat/abi/bitfield1_main.C":
>
> Note that mainline got changed to xline. Also note that the directory
> has files bitfield_main.C, bitfield_x.C, and bitfield_y.C.
>
> So it looks like there is a tcl script somewhere to replace "main" with
> "x", which fails if the directory path contains "main" anywhere in it
> other than in the filename at the end.
Would this do it in compat.exp: compat-execute?
regsub "_main" $src1 "_x" src2
Does this fix your problem?
diff -up gcc/gcc/testsuite/lib/compat.exp.borig gcc/gcc/testsuite/lib/compat.exp
--- gcc/gcc/testsuite/lib/compat.exp.borig 2005-07-15 17:43:56.0
+0200
+++ gcc/gcc/testsuite/lib/compat.exp2007-03-14 11:54:48.0 +0200
@@ -260,8 +260,8 @@ proc compat-execute { src1 sid use_alt }
# Set up the names of the other source files.
regsub "_main.*" $src1 "" base
regsub ".*/" $base "" base
-regsub "_main" $src1 "_x" src2
-regsub "_main" $src1 "_y" src3
+regsub "_main(\[^/\]*)$" $src1 "_x\\1" src2
+regsub "_main(\[^/\]*)$" $src1 "_y\\1" src3
# Use the dg-options mechanism to specify extra flags for this test.
# The extra flags in each file are used to compile that file, and the
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFF98bRwyMv24BBd/gRAgfwAKCRWDBedJY/CBZ+W49w9ZOodkVCNwCgkhGS
D2a0mw7qMVEmiGuI4bdJpBc=
=pIoP
-END PGP SIGNATURE-
bad edge created in CFG ?
Hello,
I have used -da and -dv to produce vcg files of the CFG of this simple program:
int main(int argc, char**argv)
{
if(argc)
printf("positive\n");
else
printf("zero\n");
return 0;
}
I have expected to get a CFG as follows:
---
| BB 0 |
---
/ \
--- ---
| BB 1 | | BB 2 |
--- ---
\ /
---
| END |
---
But instead, I was surprised to get this CFG:
---
| BB 0 |
---
/ \
--- ---
| BB 1 | > | BB 2 |
--- ---
\ /
---
| END |
---
as if one case of the "if" can lead to the other !
Can someone please explain to me why it is so ?
I am attaching the VCG representation, the VCG text file, and the original
test program..
Thank You
sunzir
<>
#include
int main(int argc, char**argv)
{
if(argc)
printf("positive\n");
else
printf("zero\n");
return 0;
}
graph: {
port_sharing: no
graph: { title: "main"
folding: 1
hidden: 2
node: { title: "main.0" }
graph: {
title: "main.BB0"
folding: 1
color: lightblue
label: "basic block 0"
edge: { sourcename: "main.0" targetname: "main.11" color: blue }
node: {
title: "main.11"
color: lightgrey
label: "note 11
NOTE_INSN_BASIC_BLOCK"
}
edge: { sourcename: "main.11" targetname: "main.50" }
node: {
title: "main.50"
color: green
label: "insn 50
(set (reg:SI 2 cx)
(plus:SI (reg/f:SI 7 sp)
(const_int 4 [0x4])))
"
}
edge: { sourcename: "main.50" targetname: "main.51" }
node: {
title: "main.51"
color: green
label: "insn 51
(parallel [
(set (reg/f:SI 7 sp)
(and:SI (reg/f:SI 7 sp)
(const_int -16 [0xfff0])))
(clobber (reg:CC 17 flags))
])
"
}
edge: { sourcename: "main.51" targetname: "main.52" }
node: {
title: "main.52"
color: green
label: "insn 52
(set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(mem/c:SI (plus:SI (reg:SI 2 cx)
(const_int -4 [0xfffc])) [7 S4 A8]))
"
}
edge: { sourcename: "main.52" targetname: "main.53" }
node: {
title: "main.53"
color: green
label: "insn 53
(set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg/f:SI 6 bp))
"
}
edge: { sourcename: "main.53" targetname: "main.54" }
node: {
title: "main.54"
color: green
label: "insn 54
(set (reg/f:SI 6 bp)
(reg/f:SI 7 sp))
"
}
edge: { sourcename: "main.54" targetname: "main.55" }
node: {
title: "main.55"
color: green
label: "insn 55
(set (mem:SI (pre_dec:SI (reg/f:SI 7 sp)) [0 S4 A8])
(reg:SI 2 cx))
"
}
edge: { sourcename: "main.55" targetname: "main.56" }
node: {
title: "main.56"
color: green
label: "insn 56
(parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -4 [0xfffc])))
(clobber (reg:CC 17 flags))
(clobber (mem:BLK (scratch) [0 A8]))
])
"
}
edge: { sourcename: "main.56" targetname: "main.66" }
node: {
title: "main.66"
color: green
label: "insn 66
(set (reg:SI 0 ax)
(mem/c/i:SI (reg:SI 2 cx [59]) [2 argc+0 S4 A32]))
"
}
edge: { sourcename: "main.66" targetname: "main.67" }
node: {
title: "main.67"
color: green
label: "insn 67
(set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 0 ax)
(const_int 0 [0x0])))
"
}
edge: { sourcename: "main.67" targetname: "main.15" }
node: {
title: "main.15"
color: darkgreen
label: "jump_insn 15
(set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 23)
(pc)))
"
}
}
edge: { sourcename: "main.15" targetname: "main.23" color: blue }
edge: { sourcename: "main.15" targetname: "main.17" color: blue }
edge: { sourcename: "main.15" targetname: "main.19" }
graph: {
title: "main.BB1"
folding: 1
color: lightblue
label: "basic block 1"
node: {
title: "main.17"
color: lightgrey
label: "note 17
NOTE_INSN_BASIC_BLOCK"
}
edge: { sourcename: "main.17" targetname: "main.19" }
node: {
title: "main.19"
color: green
label: "insn 19
(set (mem:SI (reg/f:SI 7 sp) [0 S4 A32])
(symbol_ref/f:SI (\"*.LC0\") [flags 0x2] ))
"
}
edge: { sourcename: "main.19" targetname: "main.20" }
node: {
title: "main.20"
color: darkgreen
label: "call_insn 20
(set (reg:SI 0 ax)
(call (mem:QI (symbol_ref:SI (\"puts\") [flags 0x41] ) [0 S1 A8])
(const_int 4 [0x4])))
"
}
edge: { sourcename: "main.20" targetname: "main.59" }
node: {
title: "main.59"
color: green
label: "insn 59
(parallel [
(set (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
Re: Manipulating the tree Structure
Hi all, first of all i want to thank you for the aid that i have receveid from this mailing list. I have another little question: if i have a statemente that is an expression, for example x+5 , how can i know if the operation is plus (+), or minus (-), or equal(=) or less (<) etc.. Can you give me the name of the file containing all these definition?? Thanks to all, Andrea
setting a breakpoint on a break statement
Hi,
in some cases, a breakpoint can't be set on a continue or break
statement. Here is a simple example:
void foc (void)
{
int a, i;
for (i = 1; i <= 10; i++) {
if (i < 3)
a = 1;
else
break; // line 9
a = 5;
}
}
int main(void)
{
foc ();
}
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...
I think this issue has already been discussed, at least for gcc 3.4
Tristan.
bp.diff
Description: Binary data
Re: Manipulating the tree Structure
Andrea Callia D'Iddio wrote on 14/03/2007 12:36:59: > Hi all, > first of all i want to thank you for the aid that i have receveid from > this mailing list. I have another little question: > if i have a statemente that is an expression, for example x+5 , how > can i know if the operation is plus (+), or minus (-), or equal(=) or > less (<) etc.. > Can you give me the name of the file containing all these definition?? in tree.def, look for all the tree code definitions (DEFTREECODE): for example: /* Simple arithmetic. */ DEFTREECODE (PLUS_EXPR, "plus_expr", tcc_binary, 2) DEFTREECODE (MINUS_EXPR, "minus_expr", tcc_binary, 2) DEFTREECODE (MULT_EXPR, "mult_expr", tcc_binary, 2) Tehila. > Thanks to all, > Andrea
Re: libgomp failures on powerpc-apple-darwin8
Jakub, So shouldn't we either XFAIL pr30703.C on *-apple-darwin* or specify that the -shared-libgcc flag should be used on that target for pr30703.C? Jack On Wed, Mar 14, 2007 at 10:11:35AM +0100, Jakub Jelinek wrote: > On Tue, Mar 13, 2007 at 10:28:41PM -0400, Jack Howarth wrote: > > Interestingly, while... > > > > gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp > > -lstdc++ -lm -m32 -o ./pr30703.exe > > /usr/bin/ld: Undefined symbols: > > __Unwind_Resume > > collect2: ld returned 1 exit status > > > > fails on powerpc-apple-darwin8 > > > > gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/lib -lgomp > > -lstdc++ -lm -m32 -shared-libgcc -o ./pr30703.exe > > > > ...links fine. On powerpc-apple-darwin8, libgcc.a is missing > > __Unwind_Resume. I wonder why this doesn't show up > > on any other architectures? > > Because libstdc++.so links against libgcc_s.so.1 which exports that symbol > (was linked with -shared-libgcc). Or, on ELFish targets that use recent > binutils when neither -shared-libgcc nor -static-libgcc is used, > libgcc_s.so.1 is linked in --as-needed. > libgcc.a doesn't contain the unwinder on purpose, it is only in libgcc_s.so > and libgcc_eh.a, so that every binary or library doesn't have its own copy > of the unwinder (which causes severe problems). > > Jakub
question on verify_ssa failure due to ccp in dom3 (PR30784)
Hi,
We have a '{2,2}' expression (vector initializer) propagated by dom into a
BIT_FIELD_REF:
before (bug.c.105t.vrp2):
vector long int vect_cst_.47;
vect_cst_.47_66 = {2, 2};
D.2103_79 = BIT_FIELD_REF ;
after (bug.c.106t.dom3):
"
Optimizing block #7
Optimizing statement :;
Optimizing statement D.2102_78 = BIT_FIELD_REF ;
Optimizing statement D.2103_79 = BIT_FIELD_REF ;
Replaced 'vect_cst_.47_66' with constant '{2, 2}'
"
D.2103_79 = BIT_FIELD_REF <{2, 2}, 64, 0>;
...which causes he following ICE:
"
bug.c:8: error: invalid reference prefix
{2, 2}
bug.c:8: internal compiler error: verify_stmts failed
"
Several testcases are available in the bugzilla report (PR30784).
So, the question is - what needs to be fixed - is it copy propagation that
allows propagating the initializer into a BIT_FIELD_REF? or vect_lower pass
that creates these BIT_FIELD_REFs after vectorization?
thanks,
dorit
[SOLVED] RE: How to hide registers from local RA but not reload?
On 13 March 2007 19:56, Ian Lance Taylor wrote: > "Dave Korn" <[EMAIL PROTECTED]> writes: > >> The intermediate cause is that lreg considers all the special-purpose reg >> classes when allocating, and for some reason decides that several of the >> special-purpose classes have equal cost (zero) to GENERAL_REGS. The bit I >> find strange about this is that it then decides to take the >> highest-numbered class as the preferred register class, despite the fact >> that it has a lot less members in it than GENERAL_REGS. (There is no >> overlap between the classes, so I haven't put them in the "wrong order", >> as one is not a subset of the other). > > Did you set REGISTER_MOVE_COST for your new registers? > > >> Q. Is it possible to do what I really want: to make the compiler aware of >> some registers, but limit their usage to a single insn; to allow reload to >> use these registers when directed to by a constraint letter, but for the >> rest of the compiler to basically pretend they don't even exist. > > This is more or less what the MIPS backend does with the HI and LO > registers. You might want to look at that. Thanks Ian, that was just the ticket. The solution was indeed to define REGISTER_MOVE_COST to a high value for moves between general regs and the special purpose regs; that prevents RA from considering them to be preferred classes for operands that aren't constrained to occupy a SPR. Adding secondary reloads via gprs when reloading from/to memory wrapped it up nicely. cheers, DaveK -- Can't think of a witty .sigline today
Re: question on verify_ssa failure due to ccp in dom3 (PR30784)
On 3/14/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
Hi,
We have a '{2,2}' expression (vector initializer) propagated by dom into a
BIT_FIELD_REF:
before (bug.c.105t.vrp2):
vector long int vect_cst_.47;
vect_cst_.47_66 = {2, 2};
D.2103_79 = BIT_FIELD_REF ;
after (bug.c.106t.dom3):
"
Optimizing block #7
Optimizing statement :;
Optimizing statement D.2102_78 = BIT_FIELD_REF ;
Optimizing statement D.2103_79 = BIT_FIELD_REF ;
Replaced 'vect_cst_.47_66' with constant '{2, 2}'
"
D.2103_79 = BIT_FIELD_REF <{2, 2}, 64, 0>;
...which causes he following ICE:
"
bug.c:8: error: invalid reference prefix
{2, 2}
bug.c:8: internal compiler error: verify_stmts failed
"
Several testcases are available in the bugzilla report (PR30784).
So, the question is - what needs to be fixed - is it copy propagation that
allows propagating the initializer into a BIT_FIELD_REF? or vect_lower pass
that creates these BIT_FIELD_REFs after vectorization?
I think the BIT_FIELD_REF should be properly folded to a constant or
the propagation
not done. fold_stmt_inplace is the candidate to look at,
propagate_rhs_into_lhs in
tree-ssa-dom.c to reject propagation into BIT_FIELD_REF. fold_ternary should be
able to fold the BIT_FIELD_REF in question, it would be interesting to
know why it
doesn't.
Richard.
Re: We're out of tree codes; now what?
On 3/14/07, Richard Guenther <[EMAIL PROTECTED]> wrote:
#define LANG_TYPE_CODE (t) (TREE_CODE (t) == LANG_TYPE ?
LANG_TYPE_SUBCODE (t) : INVALID_SUBCODE)
and then INVALID_SUBCODE will fall through to the default case as well.
But that doesn't put the subcodes and the codes into the same
"namespace". We want to be able to write:
switch (TREE_CODE (t))
{
case FUNCTION_TYPE:
/* do something with function types. */
break;
case TYPEOF_TYPE_SUBCODED:
/* do something with TYPEOF_TYPE. */
break;
}
even though FUNCTION_TYPE is (and will always be) a top-level tree
code, whereas TYPEOF_TYPE should be subcoded and stashed away in a
LANG_TYPE.
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))
Yuck.
Cheers,
Doug
Re: setting a breakpoint on a break statement
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. 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. Also you should ideally add a test case. Thanks. Ian
Re: question on verify_ssa failure due to ccp in dom3 (PR30784)
Dorit Nuzman <[EMAIL PROTECTED]> writes:
> D.2103_79 = BIT_FIELD_REF <{2, 2}, 64, 0>;
>
>
> ...which causes he following ICE:
> "
>bug.c:8: error: invalid reference prefix
>{2, 2}
>bug.c:8: internal compiler error: verify_stmts failed
> "
Maybe fold-const.c needs to recognize this case? Actually it seems
like it already does. Why didn't it get folded by
substitute_and_fold?
Ian
Re: question on verify_ssa failure due to ccp in dom3 (PR30784)
On 14 Mar 2007 07:22:10 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
Dorit Nuzman <[EMAIL PROTECTED]> writes:
> D.2103_79 = BIT_FIELD_REF <{2, 2}, 64, 0>;
>
>
> ...which causes he following ICE:
> "
>bug.c:8: error: invalid reference prefix
>{2, 2}
>bug.c:8: internal compiler error: verify_stmts failed
> "
Maybe fold-const.c needs to recognize this case? Actually it seems
like it already does. Why didn't it get folded by
substitute_and_fold?
Dom doesn't use the propagator engine but relies on
fold_stmt_in_place. That one
eventually calls fold() on the rhs, either that didn't work out or
set_rhs rejected the
folding result. I leave the resolution as an excercise for the reader ;)
Richard.
Re: We're out of tree codes; now what?
"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)) > > Yuck. I would use 256 instead of LAST_AND_USED_TREE_CODE, but other than that it doesn't seem so yucky to me. Maybe my sense of taste has become degraded. Ian
Re: gcc gcov and --coverage on x86_64
>From: Ben Elliston <[EMAIL PROTECTED]> >> gcc --coverage appears to be broken on x86_64 in gcc 4.1.1 on FC6 >> (works fine with Trunk). I'm almost certain that this is a known >> issue, but cannot find a reference in Bugzilla. > >I implemented that option, so can probably help you. Contact me in >private mail and we'll try and troubleshoot it. If necessary, you can >then file a bug report. FYI, this is an issue with ccache and not gcc (I forgot about that possibility). Guess it's time to dig into ccache. Thanks, Matt
Re: We're out of tree codes; now what?
"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. Ian
Re: can't find VCG viewer
On Wed, Mar 14, 2007 at 11:36:24AM +0200, Sunzir Deepur wrote: > Hello group, > > any idea where I can find a (free) graphical VCG viewer suitable > for gcc's vcg outputs ? > > seems like the old 1995 package is not applicable on newest linux systems > (am working on fedora). See http://www.graphviz.org/ This stuff is packaged for Fedora; make sure you have graphviz and graphviz-tcl installed. I'm old-school and usually use the dot program from graphviz to make Postscript plots, but there are also programs to display with Tk or to generate PNGs.
Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)
On Wed, Mar 14, 2007 at 03:47:57AM +, Joseph S. Myers wrote: > On Tue, 13 Mar 2007, Andrew Pinski wrote: > > > Anyways the best way to fix this is just to fix the bug. Someone > > We should have 0 unexpected FAILs in 4.2.0 on common platforms (in > particular the primary release criteria ones for the testsuites of the > languages in the release criteria). How this is achieved is secondary, > but if the bug isn't fixed for 4.2.0 the test should be XFAILed - and we > know from experience that many regressions aren't fixed for releases, > especially where they were present in many previous releases. > > > exposed the regression back in 4.0 time frame, I reported the bug > > before getting approval for the patch. They were not willing to fix > > it so why punish the testcase which is obviously is a regression. > > It's not punishing the testcase; it's recognising that we have a bug > tracking system to track regressions and having "expected unexpected > FAILs" is helpful neither to users wishing to know if their compiler built > as expected nor to developers glancing over test results to see if they > seem OK. I've come to agree with that point of view and I'll look into allowing XFAIL for tests that ICE. Torture tests are handled differently, though, and this particular test can be XFAILed with the example .x file I sent earlier. Janis
Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)
On Wed, Mar 14, 2007 at 03:47:57AM +, Joseph S. Myers wrote: > > It's not punishing the testcase; it's recognising that we have a bug > > tracking system to track regressions and having "expected unexpected > > FAILs" is helpful neither to users wishing to know if their compiler built > > as expected nor to developers glancing over test results to see if they > > seem OK. On Wed, Mar 14, 2007 at 08:39:05AM -0800, Janis Johnson wrote: > I've come to agree with that point of view and I'll look into allowing > XFAIL for tests that ICE. Torture tests are handled differently, > though, and this particular test can be XFAILed with the example .x > file I sent earlier. 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. So, while Joseph does have a good argument, I hope that calling the test an XFAIL instead of fixing the crash will be a rare last resort.
MIPS bootstrap broken, make compare fails...
Bootstrapping the trunk (Revision: 122847) on a mipsel-linux system configured thusly: $ ../gcc/configure --with-arch=mips32 --with-float=soft --disable-java-awt --without-x --disable-tls --enable-__cxa_atexit --disable-jvmpi --disable-static --disable-libmudflap --enable-languages=c,c++,java I get: $ make compare Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs Bootstrap comparison failure! ./cp/call.o differs ./cp/decl.o differs ./cp/pt.o differs ./cp/class.o differs ./cp/error.o differs ./cp/rtti.o differs ./cp/init.o differs ./cp/search.o differs ./cp/semantics.o differs ./cp/tree.o differs ./cp/mangle.o differs ./cp/name-lookup.o differs ./java/class.o differs ./java/verify-impl.o differs ./java/jcf-parse.o differs ./java/jcf-dump.o differs ./build/genmodes.o differs ./build/rtl.o differs ./build/gensupport.o differs ./build/genflags.o differs ./build/genpreds.o differs ./build/genconfig.o differs ./build/genattrtab.o differs ./build/genautomata.o differs ./build/genextract.o differs ./c-pragma.o differs ./c-decl.o differs ./c-typeck.o differs ./c-common.o differs ./c-opts.o differs ./c-format.o differs ./prefix.o differs ./ggc-page.o differs ./alias.o differs ./bt-load.o differs ./builtins.o differs ./caller-save.o differs ./cfg.o differs ./cfgbuild.o differs ./cfgcleanup.o differs ./cfgexpand.o differs ./cfglayout.o differs ./cfgloop.o differs ./cfgloopanal.o differs ./cfgloopmanip.o differs ./cfgrtl.o differs ./combine.o differs ./coverage.o differs ./cse.o differs ./cselib.o differs ./ddg.o differs ./df-core.o differs ./df-problems.o differs ./df-scan.o differs ./dominance.o differs ./dwarf2asm.o differs ./dwarf2out.o differs ./emit-rtl.o differs ./except.o differs ./expmed.o differs ./final.o differs ./flow.o differs ./fold-const.o differs ./function.o differs ./gcse.o differs ./gimplify.o differs ./global.o differs ./gtype-desc.o differs ./haifa-sched.o differs ./jump.o differs ./lambda-code.o differs ./local-alloc.o differs ./loop-invariant.o differs ./loop-iv.o differs ./loop-unroll.o differs ./lower-subreg.o differs ./modulo-sched.o differs ./omega.o differs ./omp-low.o differs ./opts.o differs ./passes.o differs ./pointer-set.o differs ./postreload-gcse.o differs ./postreload.o differs ./profile.o differs ./real.o differs ./recog.o differs ./regclass.o differs ./regmove.o differs ./regrename.o differs ./reload.o differs ./reload1.o differs ./rtl.o differs ./rtlanal.o differs ./sbitmap.o differs ./sched-deps.o differs ./sched-rgn.o differs ./simplify-rtx.o differs ./stmt.o differs ./struct-equiv.o differs ./toplev.o differs ./tree-cfg.o differs ./tree-complex.o differs ./tree-data-ref.o differs ./tree-dump.o differs ./tree-eh.o differs ./tree-if-conv.o differs ./tree-outof-ssa.o differs ./tree-pretty-print.o differs ./tree-ssa-address.o differs ./tree-ssa-coalesce.o differs ./tree-ssa-dom.o differs ./tree-ssa-live.o differs ./tree-ssa-loop-im.o differs ./tree-ssa-loop-ivopts.o differs ./tree-ssa-loop-manip.o differs ./tree-ssa-loop-niter.o differs ./tree-ssa-operands.o differs ./tree-ssa-phiopt.o differs ./tree-ssa-pre.o differs ./tree-ssa-structalias.o differs ./tree-ssa.o differs ./tree-vect-analyze.o differs ./tree-vect-patterns.o differs ./tree-vect-transform.o differs ./tree-vectorizer.o differs ./tree-vn.o differs ./tree.o differs ./value-prof.o differs ./var-tracking.o differs ./varasm.o differs ./mips.o differs ./cgraphunit.o differs ./ipa-inline.o differs ./ipa-utils.o differs ./gcov.o differs ./gcc.o differs ./jvspec.o differs make: *** [compare] Error 1 My last successful bootstrap on this system was from March 6 (revision 122630). I am going to update and try again. David Daney
Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)
Joe Buck <[EMAIL PROTECTED]> writes: > On Wed, Mar 14, 2007 at 03:47:57AM +, Joseph S. Myers wrote: > > > It's not punishing the testcase; it's recognising that we have a bug > > > tracking system to track regressions and having "expected unexpected > > > FAILs" is helpful neither to users wishing to know if their compiler > > > built > > > as expected nor to developers glancing over test results to see if they > > > seem OK. > > On Wed, Mar 14, 2007 at 08:39:05AM -0800, Janis Johnson wrote: > > I've come to agree with that point of view and I'll look into allowing > > XFAIL for tests that ICE. Torture tests are handled differently, > > though, and this particular test can be XFAILed with the example .x > > file I sent earlier. > > 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. > > So, while Joseph does have a good argument, I hope that calling the > test an XFAIL instead of fixing the crash will be a rare last resort. On the gcc 4.2 release branch can we just turn the ICE into a sorry? Then we don't have to worry about XFAILing an ICE. Ian
Re: bad edge created in CFG ?
On 3/14/07, Sunzir Deepur <[EMAIL PROTECTED]> wrote:
Hello,
I have used -da and -dv to produce vcg files of the CFG of this simple program:
int main(int argc, char**argv)
{
if(argc)
printf("positive\n");
else
printf("zero\n");
return 0;
}
I have expected to get a CFG as follows:
---
| BB 0 |
---
/ \
--- ---
| BB 1 | | BB 2 |
--- ---
\ /
---
| END |
---
But instead, I was surprised to get this CFG:
---
| BB 0 |
---
/ \
--- ---
| BB 1 | > | BB 2 |
--- ---
\ /
---
| END |
---
as if one case of the "if" can lead to the other !
Can someone please explain to me why it is so ?
I am attaching the VCG representation, the VCG text file, and the original
test program..
Thank You
sunzir
I don't know what kind of vcg viewer/converter you're using,
but set it to ignore class 3 edges - you'll get what you expected.
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
List Of Compiler Books
I put the dicussion about compiler books in a WIKI page: http://gcc.gnu.org/wiki/ListOfCompilerBooks since I feel it is of common interest. Please feel free to correct any mistakes and ad more comments or books. Michael Cieslinski
Re: setting a breakpoint on a break statement
On 3/14/07, Tristan Gingold <[EMAIL PROTECTED]> wrote: Hi, in some cases, a breakpoint can't be set on a continue or break statement. Here is a simple example: I think this is also related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609 Yes, yes I have the whole bugzilla memorized. :) -- Pinski
Re: question on verify_ssa failure due to ccp in dom3 (PR30784)
On Wed, 2007-03-14 at 15:06 +0100, Richard Guenther wrote: > I think the BIT_FIELD_REF should be properly folded to a constant or > the propagation not done. Agreed. I'd lean towards folding the BIT_FIELD_REF to a constant, but if that isn't easy I'd recommend avoiding the propagation. Jeff
Re: MIPS bootstrap broken, make compare fails...
* David Daney <[EMAIL PROTECTED]> [2007-03-14 10:01]: > I get: > $ make compare > Comparing stages 2 and 3 Probably the same as PR31169, reported for HPPA. Unfortunately the PR doesn't contain much useful information yet. -- Martin Michlmayr [EMAIL PROTECTED]
Re: Constrain not satisfied - floating point insns.
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: bootstrap broke in 4.2
On Mar 14, 2007, at 1:49 AM, Ian Lance Taylor wrote: I see it now. My apologies. I just committed a patch to the 4.2 branch to fix it. --enable-werror, however, that only works well if you have installed a gcc of the same vintage as your building. If they differ too much, you'll still missing newer warnings.
Re: bootstrap broke in 4.2
[ oops, almost forgot why I stared sending the email ] On Mar 14, 2007, at 1:49 AM, Ian Lance Taylor wrote: I see it now. My apologies. I just committed a patch to the 4.2 branch to fix it. I can confirm that fixed it, thanks.
error: unable to find a register to spill in class 'FP_REGS'
Dear GCC Developers/Users,
I am working on a port of a target backend. I have a problem when
compiling the following program:
---snip---
short b = 5;
short c = 5;
int main(void)
{
long int a[b][c];
a[1][1]=5;
return 0;
}
---snap---
During compilation I get the following error message:
---snip---
simple_alloc.c: In function 'main':
simple_alloc.c:8: error: unable to find a register to spill in class
'FP_REGS'
simple_alloc.c:8: error: this is the insn:
(insn 45 47 46 0 (set (subreg:SI (reg:DI 92 [ D.1212 ]) 4)
(reg:SI 1 r1 [orig:93 D.1211 ] [93])) 40 {movsi_general} (nil)
(expr_list:REG_DEAD (reg:SI 1 r1 [orig:93 D.1211 ] [93])
(expr_list:REG_NO_CONFLICT (reg:SI 1 r1 [orig:93 D.1211 ] [93])
(nil
simple_alloc.c:8: confused by earlier errors, bailing out
---snap---
After a while of diving through gcc source code I can't get a clue
what's going wrong.
The problem is that the reloading stage fails because it can't find any
free registers for spilling, right? But the compiler says that it wants
to spill in class 'FP_REGS' and the above RTL-statement doesn't have
anything to do with floating point arithmetic!?!?!
I found out that in "gcc/reload1.c:find_reg()" the following
if-statement never gets satisfied:
---snip---
if (! TEST_HARD_REG_BIT (not_usable, regno)
&& ! TEST_HARD_REG_BIT (used_by_other_reload, regno)
&& HARD_REGNO_MODE_OK (regno, rl->mode))
---snap---
This causes in the end the error message because no suitable registers
could be found.
Does anybody have an idea what could be wrong in the machine description
or to where start finding the error?
Any suggestions are welcome.
Regards,
Markus Franke
--
Nichts ist so praktisch wie eine gute Theorie!
Re: libgomp failures on powerpc-apple-darwin8
On Mar 14, 2007, at 2:11 AM, Jakub Jelinek wrote: On Tue, Mar 13, 2007 at 10:28:41PM -0400, Jack Howarth wrote: Interestingly, while... gcc-4 pr30703.C -fmessage-length=0 -fopenmp -O0 -L/sw/lib/gcc4.2/ lib -lgomp -lstdc++ -lm -m32 -o ./pr30703.exe Could we please use g++ to compile C++ code. If this was done, the testcases would just work, as it passes -shared-libgcc. The other solution, would be to add -shared-libgcc directly.
Re: error: unable to find a register to spill in class 'FP_REGS'
Markus Franke wrote: Does anybody have an idea what could be wrong in the machine description or to where start finding the error? Compile with -da, and starting looking at the RTL dumps, mainly the greg 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. lreg will have info about register class preferencing. It will tell you what register class the compiler wants to use for this insn. 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. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: libgomp failures on powerpc-apple-darwin8
It looks like modifying the testsuite scripts for libgomp
to properly compile c++ files with g++ will be pretty messy.
Can we just fix PR30703 for now with the simple change...
Index: libgomp/testsuite/libgomp.c++/pr30703.C
===
/usr/local/bin/gccdiff: line 1: i#!/bin/bash: No such file or directory
--- libgomp/testsuite/libgomp.c++/pr30703.C (revision 122939)
+++ libgomp/testsuite/libgomp.c++/pr30703.C (working copy)
@@ -1,5 +1,6 @@
// PR c++/30703
// { dg-do run }
+// { dg-options "-shared-libgcc" }
#include
which at least suppresses the problem on Darwin. I'll file a PR later that
c++.exp in the libgomp/testsuite/libgomp.c++ needs to use g++ for compiling
(right now it calls gfortran-dg-runtest.exp).
Jack
core changes for mep port
I'm working on readying the Toshiba Media Processor (mep-elf) port for contribution to GCC 4.x, but we added some core changes needed to support it. The changes are listed below; I'd like some feedback about these before I go too far with them. Are these concepts acceptable for inclusion in gcc? Coprocessor types - the MeP chip has optional coprocessors, each with their own register sets. They need their own internal types (mostly to keep track of which unit to use), which we've created by prefixing the existing types with COP (i.e. COPSImode, COPDFmode, etc). This affects the generators, some MI files, etc. The types don't exist unless the target calls for them. The CPU supports two operation modes - core and vliw. To properly manage inlining, we need target hooks for when function A can inline function B (both functions' attributes need to be inspected), and for calls that are semantically disallowed (i.e. functions can't call other-mode static inline functions). The core and vliw modes have different instructions, and it's expected that users of this port will make heavy use of intrinsics and asms, so even tree-level inlining needs to be managed. The number of registers available to GCC varies with the coprocessor choice, via pragmas in a sysroot-wide header file. Thus, we need hooks that let us modify (or at least re-calculate) gcc's internal tables (i.e. call init_reg_sets_1 et all, during pragma handling). Also, we need access to reg_class_subclasses[], which was hidden a while back. We added a validate_replace_rtx_subexp() which is like validate_replace_rtx() but only does the replacement on a sub-expression of the insn. There's a chip-specific optimization that uses this, we didn't want to have to recompute it ourselves.
Re: core changes for mep port
DJ Delorie <[EMAIL PROTECTED]> writes: > Coprocessor types - the MeP chip has optional coprocessors, each with > their own register sets. They need their own internal types (mostly > to keep track of which unit to use), which we've created by prefixing > the existing types with COP (i.e. COPSImode, COPDFmode, etc). This > affects the generators, some MI files, etc. The types don't exist > unless the target calls for them. 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 different architectures in the same compiler, even when there are coprocessors on the same chip. We've provided different compilers, and expected people to stich together the .o files. Do you have insns to move values from the main processor to and from the coprocessors? What do those insns look like? movcopsisi2? How do those insns get generated? > The CPU supports two operation modes - core and vliw. To properly > manage inlining, we need target hooks for when function A can inline > function B (both functions' attributes need to be inspected), and for > calls that are semantically disallowed (i.e. functions can't call > other-mode static inline functions). The core and vliw modes have > different instructions, and it's expected that users of this port will > make heavy use of intrinsics and asms, so even tree-level inlining > needs to be managed. 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? We have many ABI changing options which prohibit functions from calling each other, but that doesn't lead to any inlining problems. That said the machine independent changes here are presumably quite small. > We added a validate_replace_rtx_subexp() which is like > validate_replace_rtx() but only does the replacement on a > sub-expression of the insn. There's a chip-specific optimization that > uses this, we didn't want to have to recompute it ourselves. That seems trivial, no objection to that. Ian
Re: core changes for mep port
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: core changes for mep port
> This and the register changes come close to multi-arch gcc. Yup. The core has two modes, core and vliw, and the coprocessor(s) each have their own units. The core manages the opcode processing, but the coprocessor does the work. > Historically we have not tried to support different architectures in > the same compiler, even when there are coprocessors on the same > chip. We've provided different compilers, and expected people to > stich together the .o files. In the case of MeP, the vliw mode combines a core insn and a coprocessor insn into each vliw bundle, so that the two units can run in parallel. Hard to do that with the linker. Plus, the core-mode opcodes are exactly the same as the core portion of the vliw bundle. It's the coprocessor side of the vliw bundle that's different. > Do you have insns to move values from the main processor to and from > the coprocessors? What do those insns look like? movcopsisi2? How > do those insns get generated? It's handled through the regular movsi patterns. I'm not exactly sure how it inserts the subreg conversion, though, but it's just subreg'd. If you want a conversion, you need to use an intrinsic. A pointer to the patch for 3.4 was posted here recently: http://people.redhat.com/dj/mep/ > 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. > That said the machine independent changes here are presumably quite > small. The multi-mode changes are small, just a few target hooks. The big change is support for coprocessor modes.
Re: core changes for mep port
> Personally I'd love to see us go this way if it doesn't > inconvenience us too much. It would be useful to be able to optimize each function as to, for example, arm or thumb mode based on -Os and/or some heuristics. As a long-term goal, at least.
What to do when constraint doesn't match
Hello all, Looking at the internals i couldn't find an answer for my problem. 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? Regards, Shafi
Re: No ifcvt during ce1 pass (fails i386/ssefp-2.c)
On Mar 14, 2007, "Uros Bizjak" <[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? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: core changes for mep port
On 14 Mar 2007 18:42:13 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: DJ Delorie <[EMAIL PROTECTED]> writes: > Coprocessor types - the MeP chip has optional coprocessors, each with > their own register sets. They need their own internal types (mostly > to keep track of which unit to use), which we've created by prefixing > the existing types with COP (i.e. COPSImode, COPDFmode, etc). This > affects the generators, some MI files, etc. The types don't exist > unless the target calls for them. 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 different architectures in the same compiler, even when there are coprocessors on the same chip. We've provided different compilers, and expected people to stich together the .o files. This is what we do for the Cell also, we expect people to compile using two different compilers right now, but we are actually looking into doing an "one source" based compiling where some functions or loops are pushed off to the SPUs via annotations like the OpenMP ones. Thanks, Andrew Pinski
Re: core changes for mep port
> This is what we do for the Cell also, we expect people to compile > using two different compilers right now, but we are actually looking > into doing an "one source" based compiling where some functions or > loops are pushed off to the SPUs via annotations like the OpenMP > ones. 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; That's it for the multi-mode code. The architecture is the same for both modes (registers, modes, ABI, etc). We just have to be careful about inlining one type of function into the other. The big part of the patch is support for coprocessor types, and in the MeP core, the coprocessor insns are in the same insn stream as the core insns (it's like an 80387 or mips fpu that way). The complication happens because there are more opcodes available in vliw mode than in core mode, but that's something that is private to the target-specific code. The MeP backend *does* support different chip configurations in different compilations via command line arguments and multilibs, but that's a complication on top of the ones I'm discussing, and the gcc core doesn't need to know about that (other than the usual ways).
Re: XFAILing gcc.c-torture/execute/mayalias-2.c -O3 -g (PR 28834)
Janis Johnson wrote: >> It's not punishing the testcase; it's recognising that we have a bug >> tracking system to track regressions and having "expected unexpected >> FAILs" is helpful neither to users wishing to know if their compiler built >> as expected nor to developers glancing over test results to see if they >> seem OK. > > I've come to agree with that point of view and I'll look into allowing > XFAIL for tests that ICE. Torture tests are handled differently, > though, and this particular test can be XFAILed with the example .x > file I sent earlier. /me three The testsuite, especially on release branches, is not to highlight regressions, prod developers into fixing things, etc. It's to let developers and users who build from source figure out whether their builds are behaving as we expect them to behave. 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. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
