Re: fatal error: internal consistency failure on Linux/ia64
On Mon, 2006-05-22 21:42:07 -0700, Andrew Pinski <[EMAIL PROTECTED]> wrote: > On May 22, 2006, at 9:36 PM, H. J. Lu wrote: > >on Linux/ia64. The last working revision is 113936. Linux/x86 and > >Linux/x86-64 pass the same spot. Has anyone else seen it? > > Yes for hppa-linux-gnu, PR 27736. > > This is most likely caused by: > 2006-05-22 Richard Sandiford <[EMAIL PROTECTED]> > > PR rtl-optimization/25514 > * combine.c (replaced_rhs_insn): New variable. > (combine_instructions): Set replaced_rhs_insn when trying to > replace > a SET_SRC with a REG_EQUAL note. > (distribute_notes): Use replaced_rhs_insn when determining > the live > range of a REG_DEAD register. Starting with r113983 (which is the commit by Richard you mention above), I'm getting this for vax-linux-uclibc, too. I've bisected it down to this commit, so it is surely the offender for vax-linux-uclibc:-) MfG, JBG -- Jan-Benedict Glaw [EMAIL PROTECTED]. +49-172-7608481 _ O _ "Eine Freie Meinung in einem Freien Kopf| Gegen Zensur | Gegen Krieg _ _ O für einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA)); signature.asc Description: Digital signature
Re: fatal error: internal consistency failure on Linux/ia64
Jan-Benedict Glaw wrote:
On Mon, 2006-05-22 21:42:07 -0700, Andrew Pinski <[EMAIL PROTECTED]> wrote:
On May 22, 2006, at 9:36 PM, H. J. Lu wrote:
on Linux/ia64. The last working revision is 113936. Linux/x86 and
Linux/x86-64 pass the same spot. Has anyone else seen it?
Yes for hppa-linux-gnu, PR 27736.
Hi!
Here is a minimal reproducer if someone needs regression test.
typedef struct fibnode
{
struct fibnode *parent;
__extension__ unsigned long int degree : 31;
__extension__ unsigned long int mark : 1;
} *fibnode_t;
void fibheap_cut (fibnode_t, fibnode_t);
void fibheap_cascading_cut (fibnode_t);
void
fibheap_cascading_cut (fibnode_t y)
{
fibnode_t z;
while ((z = y->parent) != 0)
{
if (y->mark == 0)
{
y->mark = 1;
return;
}
else
{
fibheap_cut (y, z);
y = z;
}
}
}
- Grigory
[PING] RFC cse weirdness
Hi, could please someone help me with this one: http://gcc.gnu.org/ml/gcc/2006-05/msg00337.html Bye, -Andreas-
RE: Wrong link?
On 22 May 2006 20:11, Gerald Pfeifer wrote:
> On Mon, 15 May 2006 [EMAIL PROTECTED] wrote:
>> The link crossgcc FAQ in the middle of the page:
>> "http://gcc.gnu.org/install/build.html"; doesn't seem to link to a page that
>> offers the cross-gcc faq. Instead it appears to be a site of a consultant
>> trying to sell his services.
> * doc/install.texi (Configuration): Remove reference to CrossGCC
> FAQ which was hijacked.
> -See @uref{http://www.objsw.com/CrossGCC/,,CrossGCC} for more information
> -on this option.
Gerald, you've jumped to a false conclusion there; "was hijacked" should
read "has bitrotted".
"Hijacked" is a pejorative term, and also historically and factually
inaccurate. Objsw.com maintained the FAQ initially, but some time ago (around
2001 off the top of my head) it became clear that it had fallen into
disrepair, and Bill Gatliff, who was then and is now an active and valuable
contributing member of the crossgcc community, volunteered to take it over.
He then actively maintained it for several years and it was only when his
website got hacked and wiped out sometime last year that the link became out
of date. He has been slow in getting his website rebuilt and hasn't put the
FAQ back up yet; which is why I've Cc'd him in on this thread.
Bill, you need to make your intentions clear as to whether you are able and
willing to resume your maintainance duties. Are you going to get the crossgcc
FAQ back up there? If not, probably the best thing to do would be to replace
the paragraph with a reference to the mailing list ([EMAIL PROTECTED]) and
to Dan Kegel's crosstool and the related website.
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: RFC cse weirdness
On 17 May 2006 19:48, Andreas Krebbel wrote: >> Doesn't this mean that your insn patterns should be using numerical (aka >> "matching") constraints? > > Oh we are using matching constraints. But of course nobody except reload > does care about them. If the only constraints for an operand are matching > constraints > you can use match_dup what would be honored by validate_canon_reg. But we > have 3 operand ANDs for registers and 2 operand ANDs for memory operands. > To give reload full choice we have put them together in one pattern. > For the memory variants we are using matching constraints and use the > insn condition to make sure that the MEMs on both sides match. Hmm. I note that if you /were/ using match_dups, the problem would be solved because all four changes would go through the 'then' clause of the if...else construct. Maybe it would be more worthwhile for you to have separate patterns after all and find some other way of making reload happy. > Btw. this is not a s390 back end invention. You can see the same in the > i386.md file for "anddi3". Eh? I've looked at 3.3.3 and at HEAD and it seems to be doing everything completely differently: there are no constraints at all, let alone matching ones, the pattern in question is an expander not an insn pattern, and the expander routine ix86_expand_binary_operator takes care of making sure only valid combinations of mem operands are used. >> After all, what CSE has done is valid in general >> given that rD contains the same value as rB; if it's a requirement of the >> s390 backend that all mem operands in a single instruction are identical, >> it should specify so in the .md file, or it should offer expanders for >> mem->mem operations so that reload can deal with them. > > I'm not that sure that the changes done by cse are valid. Usually changing > rtxs should always be followed by a call to recog. Yes I know there are > exceptions like regrename but they are coming with workarounds like leaving > the constraint string empty to protect the insn which I don't see here at > the moment. Well, hang on. The change that you're complaining of is replacing one pseudo by another. It's fairly fundamental that gcc assumes that all pseudos are equivalent and freely interchangeable; there are no reg classes in pseudos. So if your design places special restrictions on gcc's use of and freedom to swap and substitute pseudos, your design is probably making an invalid assumption about gcc's use of pseudos, or it's trying to do something by placing constraints on pseudo-reg numbers that it should be trying to do by some other means. cheers, DaveK -- Can't think of a witty .sigline today
Re: RFC cse weirdness
Hi,
> Hmm. I note that if you /were/ using match_dups, the problem would be
> solved because all four changes would go through the 'then' clause of the
> if...else construct. Maybe it would be more worthwhile for you to have
> separate patterns after all and find some other way of making reload happy.
Yes splitting the pattern and using match_dups would fix it. It already has been
like this some time ago. The patterns were merged to give reload more
alternatives.
>
> > Btw. this is not a s390 back end invention. You can see the same in the
> > i386.md file for "anddi3".
>
> Eh? I've looked at 3.3.3 and at HEAD and it seems to be doing everything
> completely differently: there are no constraints at all, let alone matching
> ones, the pattern in question is an expander not an insn pattern, and the
> expander routine ix86_expand_binary_operator takes care of making sure only
> valid combinations of mem operands are used.
More precisely I should have said "*anddi_1_rex64", "*andsi_1" and others:
(define_insn "*anddi_1_rex64"
[(set (match_operand:DI 0 "nonimmediate_operand" "=r,rm,r,r")
(and:DI (match_operand:DI 1 "nonimmediate_operand" "%0,0,0,qm")
(match_operand:DI 2 "x86_64_szext_general_operand"
"Z,re,rm,L")))
(clobber (reg:CC FLAGS_REG))]
"TARGET_64BIT && ix86_binary_operator_ok (AND, DImode, operands)"
{ ...
For the first 3 alternatives a matching constraint is used and for the last one
the same is achieved calling ix86_binary_operator_ok. This is exactly how we
did it on s390 or am I missing something?
(define_insn "*anddi3"
[(set (match_operand:DI 0 "nonimmediate_operand" "=d,d,d,d,d,d,d,d,AQ,Q")
(and:DI (match_operand:DI 1 "nonimmediate_operand"
"%d,o,0,0,0,0,0,0,0,0")
(match_operand:DI 2 "general_operand"
"M,M,N0HDF,N1HDF,N2HDF,N3HDF,d,m,NxQDF,Q")))
(clobber (reg:CC CC_REGNUM))]
"TARGET_64BIT && !TARGET_EXTIMM && s390_logical_operator_ok_p (operands)"
"@ ...
> Well, hang on. The change that you're complaining of is replacing one
> pseudo by another. It's fairly fundamental that gcc assumes that all pseudos
> are equivalent and freely interchangeable; there are no reg classes in
> pseudos. So if your design places special restrictions on gcc's use of and
> freedom to swap and substitute pseudos, your design is probably making an
> invalid assumption about gcc's use of pseudos, or it's trying to do something
> by placing constraints on pseudo-reg numbers that it should be trying to do by
> some other means.
But doesn't show the code in validate_canon_reg already that it isn't always
applicable to replace one pseudo with another e.g. when match_dups are present?
I don't find these kind of restrictions in the gcc internals manual describing
insn conditions:
It is restricted for named patterns:
"For a named pattern, the condition (if present) may not depend on the data
in the insn being matched, but only the target-machine-type flags. The compiler
needs to test these conditions during initialization in order to learn exactly
which named instructions are available in a particular run."
A second part applies to nameless patterns:
"For nameless patterns ... For an insn where the condition has once matched,
it can't be used to control register allocation, for example by excluding
certain hard registers or hard register combinations. "
An insn condition forcing two pseudos to be the same would be trivially
fulfilled after register allocation as well. So I would say the insn
condition we are using does not try to force an assumption on register
allocation - right?!
If there is no other way than splitting the pattern I'll do this. Probably
somebody then should have a look at the i386 machine description and maybe
it should be made a bit clearer in the gcc internals manual.
Bye,
-Andreas-
RE: RFC cse weirdness
On 23 May 2006 15:42, Andreas Krebbel wrote:
> Hi,
>
>> Hmm. I note that if you /were/ using match_dups, the problem would be
>> solved because all four changes would go through the 'then' clause of the
>> if...else construct. Maybe it would be more worthwhile for you to have
>> separate patterns after all and find some other way of making reload happy.
> Yes splitting the pattern and using match_dups would fix it. It already has
> been like this some time ago. The patterns were merged to give reload more
> alternatives.
Well, merging these patterns may just not be possible given the other
restrictions you have to meet, but read on
>>> Btw. this is not a s390 back end invention. You can see the same in the
>>> i386.md file for "anddi3".
>>
>> Eh? I've looked at 3.3.3 and at HEAD and it seems to be doing everything
>> completely differently: there are no constraints at all, let alone matching
>> ones, the pattern in question is an expander not an insn pattern, and the
>> expander routine ix86_expand_binary_operator takes care of making sure only
>> valid combinations of mem operands are used.
>
> More precisely I should have said "*anddi_1_rex64", "*andsi_1" and others:
> For the first 3 alternatives a matching constraint is used and for the last
> one the same is achieved calling ix86_binary_operator_ok. This is exactly
> how we did it on s390 or am I missing something?
Yes, quite definitely. Looking at those patterns:
> (define_insn "*anddi_1_rex64"
> [(set (match_operand:DI 0 "nonimmediate_operand" "=r,rm,r,r")
> (and:DI (match_operand:DI 1 "nonimmediate_operand" "%0,0,0,qm")
> (match_operand:DI 2 "x86_64_szext_general_operand"
>"Z,re,rm,L"))) (clobber (reg:CC FLAGS_REG))]
> "TARGET_64BIT && ix86_binary_operator_ok (AND, DImode, operands)"
> { ...
> (define_insn "*anddi3"
> [(set (match_operand:DI 0 "nonimmediate_operand" "=d,d,d,d,d,d,d,d,AQ,Q")
> (and:DI (match_operand:DI 1 "nonimmediate_operand"
> "%d,o,0,0,0,0,0,0,0,0")
> (match_operand:DI 2 "general_operand"
>
>"M,M,N0HDF,N1HDF,N2HDF,N3HDF,d,m,NxQDF,Q"))) (clobber (reg:CC
> CC_REGNUM))] "TARGET_64BIT && !TARGET_EXTIMM &&
> s390_logical_operator_ok_p (operands)" "@ ...
The x86 pattern is called "anddi_1_rex64", which is not one of the standard
names: that means the compiler will never emit it directly. The only RTL that
matches that pattern will be that which has already been matched by the x86's
"anddi3" expander, which will have called ix86_expand_binary_operator to munge
the operands into a form that the "anddi_1_rex64" pattern can accept without
problems.
In your case, you're defining the named pattern "anddi3" directly as an
insn, and the compiler is going to assume it's fully capable of dealing with
whatever combination of operands are accepted by the calls to
nonimmediate_operand and general_operand. (I don't think that prefixing
"anddi3" with an asterisk will hide it from the compiler and prevent it being
treated as the named pattern for anddi3; IIRC that doesn't work to protect the
well-known names, and so neither can you have, for example, two patterns
called "anddi3" and "*anddi3").
>> Well, hang on. The change that you're complaining of is replacing one
>> pseudo by another. It's fairly fundamental that gcc assumes that all
>> pseudos are equivalent and freely interchangeable; there are no reg
>> classes in pseudos. So if your design places special restrictions on
>> gcc's use of and freedom to swap and substitute pseudos, your design is
>> probably making an invalid assumption about gcc's use of pseudos, or it's
>> trying to do something by placing constraints on pseudo-reg numbers that
>> it should be trying to do by some other means.
> But doesn't show the code in validate_canon_reg already that it isn't always
> applicable to replace one pseudo with another e.g. when match_dups are
> present?
That's not an 'e.g'; it's *only* when match_dups are present (or if the
instruction has /already/ been changed in either mode or code, but replacing
one pseudo by another won't have that effect) that replacing one pseudo by
another isn't necessarily applicable. Your code doesn't have match dups,
meaning that your code claims to the compiler's mid-end that it *is*
legitimate to replace one pseudo with another. Remember, constraints aren't
used in recognition, only in reload, so re-recognizing the RTL with a
different pseudo in place will just match exactly the same insn anyway, and
it's only when reload comes around that we will care about them being
*matching* operands.
> I don't find these kind of restrictions in the gcc internals manual
> describing insn conditions:
> It is restricted for named patterns:
>
> "For a named pattern, the condition (if present) may not depend on the data
> in the insn being matched, but only the target-machine-type flags. The
> co
optimizing calling conventions for function returns
Looking at assembly listings of the Linux kernel I see thousands of places where function returns are checked to be non-zero to indicate errors. For example something like this: mov bx, 0 .L1 call foo test ax,ax jnz .Lerror inc bx cmp bx, 10 jne .L1 .Lerror process error A new calling convention could push two return addresses for functions that return their status in EAX. On EAX=0 you take the first return, EAX != 0 you take the second. So the above code becomes: push .Lerror mov bx, 0 .L1 call foo inc bx cmp bx, 10 jne .L1 add sp, 2 .Lerror process error The called function then does 'ret' or 'ret 4' depending on the status of EAX != 0. Of course there are many further optimizations that can be done, but this illustrates the concept. Has work been done to evaluate a calling convention that takes error checks like this into account? Are there size/performance wins? Or am I just reinventing a variation on exception handling? -- Jon Smirl [EMAIL PROTECTED]
Pattern names and prefixes (Was: RFC cse weirdness)
On Tue, May 23, 2006 at 04:14:23PM +0100, Dave Korn wrote: > (I don't think that prefixing > "anddi3" with an asterisk will hide it from the compiler and prevent it being > treated as the named pattern for anddi3; IIRC that doesn't work to protect the > well-known names, and so neither can you have, for example, two patterns > called "anddi3" and "*anddi3"). AFAIK, it does work as documented. I'm using (in this order): (define_insn "*addhi3" (define_insn "*neg2" (define_insn "3" (which expands into e.g. addhi3) (define_expand "mulhi3" (define_insn "*mulhi3" (define_expand "neg2" (define_expand "extendhisi2" (define_insn "*extendhisi2" I've not seen a standard or recommended prefix for nonstandard patterns for which you want a gen_foo() function to be generated automatically, so that you can call it from a (define_expand ...). FWIW, I'm using '_' for this purpose. It is permitted in C function names and makes a clash with future standard pattern names unlikely. Just my DKK 0.02 worth. -- Rask Ingemann Lambertsen
Re: optimizing calling conventions for function returns
> Has work been done to evaluate a calling convention that takes error > checks like this into account? Are there size/performance wins? Or am > I just reinventing a variation on exception handling? This introduces an extra stack push and will confuse a call-stack branch predictor. If both the call stack and the test are normally predicted correctly I'd guess this would be a performance loss on modern cpus. Paul
4.1.1 profiledbootstrap failure on amd64
I get this failure when trying to do a proifledbootstrap on amd64. This is
a gentoo Linux machine with gcc 3.4.4, glibc 2.35, binutils 2.16.1,
autoconf 2.59, etc, etc.
make[6]: Entering directory
`/home/matt/src/gcc-bin/x86_64-unknown-linux-gnu/libstdc++-v3'
if [ -z "32" ]; then \
true; \
else \
rootpre=`${PWDCMD-pwd}`/; export rootpre; \
srcrootpre=`cd ../../../gcc-4.1.1-20060517/libstdc++-v3;
${PWDCMD-pwd}`/; export srcrootpre; \
lib=`echo ${rootpre} | sed -e 's,^.*/\([^/][^/]*\)/$,\1,'`; \
compiler="/home/matt/src/gcc-bin/./gcc/xgcc
-B/home/matt/src/gcc-bin/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include"; \
for i in `${compiler} --print-multi-lib 2>/dev/null`; do \
dir=`echo $i | sed -e 's/;.*$//'`; \
if [ "${dir}" = "." ]; then \
true; \
else \
if [ -d ../${dir}/${lib} ]; then \
flags=`echo $i | sed -e 's/^[^;]*;//' -e 's/@/ -/g'`; \
if (cd ../${dir}/${lib}; make "AR_FLAGS=rc" "CC_FOR_BUILD=gcc"
"CC_FOR_TARGET=/home/matt/src/gcc-bin/./gcc/xgcc
-B/home/matt/src/gcc-bin/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/
-B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem
/usr/local/x86_64-unknown-linux-gnu/include -isystem
/usr/local/x86_64-unknown-linux-gnu/sys-include" "CFLAGS=-O2 -g -O2 "
"CXXFLAGS=-g -O2 -D_GNU_SOURCE" "CFLAGS_FOR_BUILD=-g -O2"
"CFLAGS_FOR_TARGET=-O2 -g -O2 " "INSTALL=/usr/bin/install -c"
"INSTALL_DATA=/usr/bin/install -c -m 644"
"INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c"
"LDFLAGS=" "LIBCFLAGS=-O2 -g -O2 " "LIBCFLAGS_FOR_TARGET=-O2 -g -O2 "
"MAKE=make" "MAKEINFO=makeinfo --split-size=500 --split-size=500
--split-size=500" "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/sh"
"RUNTESTFLAGS=" "exec_prefix=/usr/local" "infodir=/usr/local/info"
"libdir=/usr/local/lib" "includedir=/usr/local/include"
"prefix=/usr/local" "tooldir=/usr/local/x86_64-unknown-linux-gnu"
"gxx_include_dir=/usr/local/include/c++/4.1.1" "AR=ar"
"AS=/home/matt/src/gcc-bin/./gcc/as"
"LD=/home/matt/src/gcc-bin/./gcc/collect-ld" "RANLIB=ranlib"
"NM=/home/matt/src/gcc-bin/./gcc/nm" "NM_FOR_BUILD=" "NM_FOR_TARGET=nm"
"DESTDIR=" "WERROR=" \
CFLAGS="-O2 -g -O2 ${flags}" \
FCFLAGS=" ${flags}" \
FFLAGS=" ${flags}" \
ADAFLAGS=" ${flags}" \
prefix="/usr/local" \
exec_prefix="/usr/local" \
GCJFLAGS=" ${flags}" \
CXXFLAGS="-g -O2 -D_GNU_SOURCE ${flags}" \
LIBCFLAGS="-O2 -g -O2 ${flags}" \
LIBCXXFLAGS="-g -O2 -D_GNU_SOURCE
-fno-implicit-templates ${flags}" \
LDFLAGS=" ${flags}" \
MULTIFLAGS="${flags}" \
DESTDIR="" \
INSTALL="/usr/bin/install -c" \
INSTALL_DATA="/usr/bin/install -c -m 644" \
INSTALL_PROGRAM="/usr/bin/install -c" \
INSTALL_SCRIPT="/usr/bin/install -c" \
all); then \
true; \
else \
exit 1; \
fi; \
else true; \
fi; \
fi; \
done; \
fi
make[7]: Entering directory
`/home/matt/src/gcc-bin/x86_64-unknown-linux-gnu/32/libstdc++-v3'
make[7]: *** No rule to make target `all'. Stop.
make[7]: Leaving directory
`/home/matt/src/gcc-bin/x86_64-unknown-linux-gnu/32/libstdc++-v3'
make[6]: *** [multi-do] Error 1
make[6]: Leaving directory
`/home/matt/src/gcc-bin/x86_64-unknown-linux-gnu/libstdc++-v3'
make[5]: *** [all-multi] Error 2
make[5]: Leaving directory
`/home/matt/src/gcc-bin/x86_64-unknown-linux-gnu/libstdc++-v3'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory
`/home/matt/src/gcc-bin/x86_64-unknown-linux-gnu/libstdc++-v3'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/home/matt/src/gcc-bin/x86_64-unknown-linux-gnu/libstdc++-v3'
make[2]: *** [all-target-libstdc++-v3] Error 2
make[2]: Leaving directory `/home/matt/src/gcc-bin'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/matt/src/gcc-bin'
make: *** [profiledbootstrap] Error 2
--
tangled strands of DNA explain the way that I behave.
http://www.clock.org/~matt
Re: RFC cse weirdness
Hi, > The x86 pattern is called "anddi_1_rex64", which is not one of the standard > names: that means the compiler will never emit it directly. Not necessarily. Someone simply could call gen_andidi_1_rex64 (e.g. from i386.c) to emit this pattern. That the insn doesn't use a standard name only means that it is never generated from the optab rtl expander this way. > The only RTL that > matches that pattern will be that which has already been matched by the x86's > "anddi3" expander, which will have called ix86_expand_binary_operator to munge > the operands into a form that the "anddi_1_rex64" pattern can accept without > problems. An insn matched by anddi_1_rex64 must not be emitted via the "anddi3" expander. Potentially a completely AND unrelated expander could have been used and the optimization steps could have transformed it into an AND rtx which is then matched by anddi_1_rex64. Of course the insn definitions better should cover everything emittable by the expanders otherwise you get an ICE. > In your case, you're defining the named pattern "anddi3" directly as an > insn, and the compiler is going to assume it's fully capable of dealing with > whatever combination of operands are accepted by the calls to > nonimmediate_operand and general_operand. (I don't think that prefixing > "anddi3" with an asterisk will hide it from the compiler and prevent it being > treated as the named pattern for anddi3; IIRC that doesn't work to protect the > well-known names, and so neither can you have, for example, two patterns > called "anddi3" and "*anddi3"). Look in the gcc internals manual for the semantics of the asterisk: "For the purpose of debugging the compiler, you may also specify a name beginning with the `*' character. Such a name is used only for identifying the instruction in RTL dumps; it is entirely equivalent to having a nameless pattern for all other purposes." Our "*anddi3" pattern can't be emitted "directly" since it begins with an asterisk. For insn definitions starting with an asterisk gcc does not even generate a gen_... function. If optabs calls gen_anddi3 of course our expander is used which takes care of generating the correct insn. > You are confusing the *condition* with the *constraints*. Your conditions > are "nonimmediate_operand", which accept pretty much anything. It is only the > conditions that are tested in recog, not the constraints. I don't think so and I am aware that only reload considers contraints worth looking at. The chapter I've cited from the gcc internals manual describes insn conditions which are pretty much the things we are arguing about. The "nonimmediate_operand" is neither a constraint nor a condition it's a predicate. > Also, you may have confused gcc by creating a pattern with the same name as > a well-known named pattern but trying to make it nameless with using an > asterisk. Don't try to re-use the well-known pattern names; do something > quite different, such as adding a suffix like the x86 does. As I've described above adding an asterisk is the standard way of providing a pattern name which only appears in the rtl dumps and does not have any other function than this. Since gcc handles such patterns exactly like nameless patterns this is certainly not the source of confusion for gcc. > If you need to > impose conditions on your operands that the condition tests can't handle, then > in the body of an expander is the place to do it. As I said we have an anddi3 expanders which does perfectly the right thing (at least there are no know bugs) will say it doesn't create insns which can't be matched by a define_insn. > > If there is no other way than splitting the pattern I'll do this. > > I'm really very sure this is the way to go. It works for the x86, after > all! So, I would reckon your approach is > > 1) define expanders for the insns Again we have an expander in place. > 2) rename the 'nameless' patterns so that you can call emit/gen_XXX from your > expander and not get into an infinite recursion! As described the patterns are in fact nameless and I see the danger of having an infinite recursion. > > Probably > > somebody then should have a look at the i386 machine description and maybe > > it should be made a bit clearer in the gcc internals manual. As I've pointed out I still think that the i386 back end uses the same trick as we do and if we have to fix something somebody should check whether the i386 could run into the same problems. Bye, -Andreas-
Re: optimizing calling conventions for function returns
On 5/23/06, Paul Brook <[EMAIL PROTECTED]> wrote: > Has work been done to evaluate a calling convention that takes error > checks like this into account? Are there size/performance wins? Or am > I just reinventing a variation on exception handling? This introduces an extra stack push and will confuse a call-stack branch predictor. If both the call stack and the test are normally predicted correctly I'd guess this would be a performance loss on modern cpus. Note that the error return is above the normal return and not placed there by a call, it should look like data to the predictor. The normal return is placed on the stack by a call which should continue to be correctly predicted, I would expect the error return path to be mispredicted but it is supposed to be the unlikely case. Is the callstack branch correctly predicted if the routine being called is complex? This does eliminate the test./jmp after every function call. Further branches could be eliminated by having multiple returns from the called function at the expense of increasing code size. Paul -- Jon Smirl [EMAIL PROTECTED]
Re: RFC cse weirdness
> An insn matched by anddi_1_rex64 must not be emitted via the "anddi3" > expander. "must not" should be replaced here by "does not need to" a common error for Germans ... or well at least for me ;-)
Re: RFC cse weirdness
On Tue, May 23, 2006 at 07:29:59PM +0200, Andreas Krebbel wrote: > > An insn matched by anddi_1_rex64 must not be emitted via the "anddi3" > > expander. > "must not" should be replaced here by "does not need to" > a common error for Germans ... or well at least for me ;-) A German colleague of mine once got into trouble because, though his English was otherwise quite fluent, he thought that "You must not ..." meant "Du musst nicht ...", and then did something he'd been ordered not to do. Warning, Germans: "you must not" does not mean "not(you must)". Oh, and you French folks: careful about making "demands" :-)
Re: optimizing calling conventions for function returns
On May 23, 2006, at 8:21 AM, Jon Smirl wrote: Or am I just reinventing a variation on exception handling? :-)
Re: GCC 4.1.1 RC1
DJ Delorie wrote: > FYI m32c still doesn't build libssp due to the GCC_NO_EXECUTABLES > thing. Works OK with it disabled, though, for C and C++. From whence > will release notes be published? I think there are several kinds of "release notes". One is the manually prepared bug-summaries done by Joe Buck (when he has enough time/energy), and posted on the web site. The second kind is automatically generated with the release from the faq.html and bugs.html files in wwwdocs. (So, if you change wwwdocs, the release automatically gets updated.) The third kind is things on the web-site gcc-N/changes.html, which highlight important changes. I'd imagine you might want to update bugs.html, in this case? -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: GCC 4.1.1 RC1
> I'd imagine you might want to update bugs.html, in this case? Or, perhaps, branch's install.texi's "Host/Target specific installation notes for GCC" ?
Re: GCC 4.1.1 RC1
DJ Delorie wrote: >> I'd imagine you might want to update bugs.html, in this case? > > Or, perhaps, branch's install.texi's "Host/Target specific > installation notes for GCC" ? Yes, that's probably even better. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: optimizing calling conventions for function returns
* Jon Smirl: > Is the callstack branch correctly predicted if the routine being > called is complex? At least the AMD CPUs have implemented a special return stack cache, so the answer is probably "yes". > This does eliminate the test./jmp after every function call. Yes, but the test/jump now happens in the callee, and you need to maintain an additional stack slot. I wouldn't be surprised if the change isn't a win. Some form of exception handling for truly exceptional situations would probably be better (and might have helped to avoid quite a few of the last CVEs 8-).
Re: optimizing calling conventions for function returns
On 5/23/06, Florian Weimer <[EMAIL PROTECTED]> wrote: Yes, but the test/jump now happens in the callee, and you need to maintain an additional stack slot. I wouldn't be surprised if the The callee already had to implement the test/jmp in order to decide to return the error. So this shouldn't introduce another one. change isn't a win. Some form of exception handling for truly exceptional situations would probably be better (and might have helped to avoid quite a few of the last CVEs 8-). -- Jon Smirl [EMAIL PROTECTED]
Re: optimizing calling conventions for function returns
On Tue, May 23, 2006 at 11:21:46AM -0400, Jon Smirl wrote: > Has work been done to evaluate a calling convention that takes error > checks like this into account? Are there size/performance wins? Or am > I just reinventing a variation on exception handling? It's fairly close to Fortran alternate return labels, which were standard in Fortran 77 but have been declared obsolescent in later revisions of the standard. Regards, Gabriel
Re: rtl_loop_init vs try_redirect_by_replacing_jump vs simple jumps
> You're misunderstanding how this code works. In cfglayout mode, > there is no "order" in the basic blocks such that > BLOCK_FOR_INSN(NEXT_INSN(BB_END(BB)) ) == BB->next_bb. This means > that you can fall through to other blocks than next_bb. Thanks for the tip, I figured out what was really happening. Which leads to the next question: What's the right way to keep an asm() from being loop invariant? I've got a case where an inline asm() is passed a pointer (the pointer is invariant) but internally dereferences it (the pointed-at memory is *not* invariant). However, loop-invariant.c is pulling it out of the loop anyway. Making the whole asm() volatile works, but that seems like overkill to me.
Re: rtl_loop_init vs try_redirect_by_replacing_jump vs simple jumps
On 5/23/06, DJ Delorie <[EMAIL PROTECTED]> wrote: > You're misunderstanding how this code works. In cfglayout mode, > there is no "order" in the basic blocks such that > BLOCK_FOR_INSN(NEXT_INSN(BB_END(BB)) ) == BB->next_bb. This means > that you can fall through to other blocks than next_bb. Thanks for the tip, I figured out what was really happening. Which leads to the next question: What's the right way to keep an asm() from being loop invariant? I've got a case where an inline asm() is passed a pointer (the pointer is invariant) but internally dereferences it (the pointed-at memory is *not* invariant). However, loop-invariant.c is pulling it out of the loop anyway. Sounds like you need a memory clobber constraint on the asm... ? Gr. Steven
Re: rtl_loop_init vs try_redirect_by_replacing_jump vs simple jumps
> Sounds like you need a memory clobber constraint on the asm... ? Yup, that looks like it would do the trick. Thanks!
Re: optimizing calling conventions for function returns
On 5/23/06, Gabriel Paubert <[EMAIL PROTECTED]> wrote: On Tue, May 23, 2006 at 11:21:46AM -0400, Jon Smirl wrote: > Has work been done to evaluate a calling convention that takes error > checks like this into account? Are there size/performance wins? Or am > I just reinventing a variation on exception handling? It's fairly close to Fortran alternate return labels, which were standard in Fortran 77 but have been declared obsolescent in later revisions of the standard. I like this method since it can be implemented transparently in C code. That means the Linux kernel could use it without rewriting everything. Regards, Gabriel -- Jon Smirl [EMAIL PROTECTED]
Re: rtl_loop_init vs try_redirect_by_replacing_jump vs simple jumps
> > On 5/23/06, DJ Delorie <[EMAIL PROTECTED]> wrote: > > > > > You're misunderstanding how this code works. In cfglayout mode, > > > there is no "order" in the basic blocks such that > > > BLOCK_FOR_INSN(NEXT_INSN(BB_END(BB)) ) == BB->next_bb. This means > > > that you can fall through to other blocks than next_bb. > > > > Thanks for the tip, I figured out what was really happening. Which > > leads to the next question: What's the right way to keep an asm() from > > being loop invariant? I've got a case where an inline asm() is passed > > a pointer (the pointer is invariant) but internally dereferences it > > (the pointed-at memory is *not* invariant). However, loop-invariant.c > > is pulling it out of the loop anyway. > > Sounds like you need a memory clobber constraint on the asm... ? Or mark the memory as read like so: asm ( "." : : ... , "m" (*pointer) ); -- Pinski
libstdc++.la and libsupc++.la
In building the current gcc trunk under fink on MacOS X, I noticed that 'fink validate' reported... Error: Libtool file points to fink build dir. Offending file: /sw/lib/gcc4/lib/libstdc++.la Offending file: /sw/lib/gcc4/lib/libsupc++.la which alerted me to the fact that both libstdc++.la and libsupc++.la seemed to hardcode in the dependency_libs that reside in the build directory for gcc... # Libraries that this one depends upon. dependency_libs=' -L/sw/src/fink.build/gcc4-4.1.99-20060522/darwin_objdir/powerp c-apple-darwin8/libstdc++-v3/src -L/sw/src/fink.build/gcc4-4.1.99-20060522/darwi n_objdir/powerpc-apple-darwin8/libstdc++-v3/src/.libs -lm' Is this problem being seen on other architectures? Jack
Re: libstdc++.la and libsupc++.la
> >In building the current gcc trunk under fink on MacOS X, I noticed > that 'fink validate' reported... > > Error: Libtool file points to fink build dir. > Offending file: /sw/lib/gcc4/lib/libstdc++.la > Offending file: /sw/lib/gcc4/lib/libsupc++.la > > which alerted me to the fact that both libstdc++.la and > libsupc++.la seemed to hardcode in the dependency_libs that > reside in the build directory for gcc... > > # Libraries that this one depends upon. > dependency_libs=' > -L/sw/src/fink.build/gcc4-4.1.99-20060522/darwin_objdir/powerp > c-apple-darwin8/libstdc++-v3/src > -L/sw/src/fink.build/gcc4-4.1.99-20060522/darwi > n_objdir/powerpc-apple-darwin8/libstdc++-v3/src/.libs -lm' > > Is this problem being seen on other architectures? Yes. This is PR 5291. -- Pinski
Re: GCC 4.1.1 RC1
GCC 4.1.1 RC1 is available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.1.1-20060517 Please download, build, and test these packages -- not trees checked out from SVN -- so that we can detect packaging problems. Please post test results here: http://gcc.gnu.org/wiki/GCC%204.1.1%20RC%20Status Could you please add http://gcc.gnu.org/ml/gcc-testresults/2006-05/ msg01295.html and http://gcc.gnu.org/ml/gcc-testresults/2006-05/ msg01296.html since I have no wiki account to do this myself. together with any comments you might have about the results. If all goes well, we'll do the official release next week. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713 Thanks, Lars P.S.: Sorry if I broke the thread, I am not subscribed to gcc@gcc.gnu.org and faked that "reply" by hand
what should we do next?
Hi, Our company had developed a new 32bit embedded processor many years age, now we had ported GCC4.X for it(c/c++), and we want add its GCC4.x backend to your GCC packages, can you tell me what should we do next? Best Regards Liqin
Re: what should we do next?
On May 23, 2006, at 6:01 PM, [EMAIL PROTECTED] wrote: Our company had developed a new 32bit embedded processor many years age, now we had ported GCC4.X for it(c/c++), and we want add its GCC4.x backend to your GCC packages, can you tell me what should we do next? First step, read our web site: http://gcc.gnu.org/contribute.html :-)
GCC 4.1.1 Freeze
I will be building the GCC 4.1.1 release later tonight, or, at latest, tomorrow (Wednesday) in California. Please refrain from all check-ins on the branch until I have announced the release. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
