Re: Anyone build 4.0.2 on IRIX 6.5?
On Thu, 2005-10-13 at 07:50 +0100, Richard Sandiford wrote: > Unless you're interested in Ada, I'd recommend trying with the GNU > linker instead. I was getting good results with binutils 2.16 on 4.0 > at one stage, although I no longer have access to an IRIX system. > > (There's no intrinsic reason why you can't use the GNU linker for Ada too. > It's just that Rainer has reported problems in the past, and no-one has > cared enough to iron out the creases.) Richard, Rainer, is there a PR for this problem? Laurent
Linker error about relocation
Hello, Sorry, maybe it's not appropriate to put this question here. But I need help. Porting gcc involves the relocation and BFD porting. I've added some relocate type. But after linked, the address is not correct. Are there any documents about the relocation. And what should I do? Thanks. Eric
Re: Anyone build 4.0.2 on IRIX 6.5?
Rainer Orth <[EMAIL PROTECTED]> writes: > Which version of ld do you use? I'm having problems with MIPSpro 7.4.3m ld > on IRIX 6.5.26f which fails to link cc1 in stage2 due to a GOT overflow. > MIPSpro 7.3 ld on IRIX 6.5.10m is ok, though. > > I tried to report this (a regression from the 3.4 branch where both > versions of ld work ok), but failed since gccbug on the new gcc.gnu.org > didn't work at the time. A quick update: gccbug works again, thanks to the tireless efforts of Dan Berlin, and there's now PR target/24334 for this issue. Curiously a C-only mainline bootstrap with SGI cc 7.4.3m instead of gcc 3.4.5 works without issues. Very strange ;-( Rainer
Re: Anyone build 4.0.2 on IRIX 6.5?
Laurent GUERBY writes: > On Thu, 2005-10-13 at 07:50 +0100, Richard Sandiford wrote: > > Unless you're interested in Ada, I'd recommend trying with the GNU > > linker instead. I was getting good results with binutils 2.16 on 4.0 > > at one stage, although I no longer have access to an IRIX system. > > > > (There's no intrinsic reason why you can't use the GNU linker for Ada too. > > It's just that Rainer has reported problems in the past, and no-one has > > cared enough to iron out the creases.) > > Richard, Rainer, is there a PR for this problem? I'm not sure, I cannot currently find this in my notes. However, there was a GCC 4.0.2 build report on IRIX 6.5 with binutils 2.16 yesterday where Ada testresults were as terrible with GNU ld as I recall they were for me: http://gcc.gnu.org/ml/gcc/2005-10/msg00258.html I don't have any tree with Ada and GNU ld on IRIX anymore, so I cannot easily check what the errors were. Maybe Rainer Emrich who reported those results can help with the details from gcc/testsuite/ada/acats/acats.log? Rainer - Rainer Orth, Faculty of Technology, Bielefeld University
Re: Warning on C++ catch by value on non primitive types
Mike Stump wrote: Look at the parser (gcc/cp/parser.c:cp_parser_handler) and set a break point there, follow it down into semantic processing, pick a nice place to do the checking, and then add the code to check it. look at finish_handler_parms in semantics.c For it to be accepted, others would have to agree it is a good thing to have, for example, if it were in the Effective C++ book, you can argue that way. yeah, if it were in one of those books it could be added to the -weff-c++ option. It doesn't seem sensible to add a different option for an alternative (set of?) coding rule(s). nathan -- Nathan Sidwell:: http://www.codesourcery.com :: CodeSourcery LLC [EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk
Re: Anyone build 4.0.2 on IRIX 6.5?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Unfortunately I removed the acats.log file. But I'm going to rebuild. Rainer Rainer Orth schrieb: > Laurent GUERBY writes: > > >>On Thu, 2005-10-13 at 07:50 +0100, Richard Sandiford wrote: >> >>>Unless you're interested in Ada, I'd recommend trying with the GNU >>>linker instead. I was getting good results with binutils 2.16 on 4.0 >>>at one stage, although I no longer have access to an IRIX system. >>> >>>(There's no intrinsic reason why you can't use the GNU linker for Ada too. >>>It's just that Rainer has reported problems in the past, and no-one has >>>cared enough to iron out the creases.) >> >>Richard, Rainer, is there a PR for this problem? > > > I'm not sure, I cannot currently find this in my notes. However, there was > a GCC 4.0.2 build report on IRIX 6.5 with binutils 2.16 yesterday where Ada > testresults were as terrible with GNU ld as I recall they were for me: > > http://gcc.gnu.org/ml/gcc/2005-10/msg00258.html > > I don't have any tree with Ada and GNU ld on IRIX anymore, so I cannot > easily check what the errors were. Maybe Rainer Emrich who reported those > results can help with the details from gcc/testsuite/ada/acats/acats.log? > > Rainer > > - > Rainer Orth, Faculty of Technology, Bielefeld University - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTj0J3s6elE6CYeURAqkzAKCe8zh8Ub7WVNNglT3A8J2+h68piwCffSl2 4b11mDmOPWfjEEiuRg1Pk8s= =nNB5 -END PGP SIGNATURE-
[RFC] Don't emit REG_DEAD for clobbers if reg stays live
Hello, > Just as an FYI, Kenny and I have replaced the global liveness analyzer > with one from df.c, and removed the need for make_accurate_live_analysis > (ie df.c now does the partial avail liveness stuff). > > We are currently in the process of changing all the other users of life > analysis to use the df.c liveness, which should solve this problem > (since they will all then use the accurate life analysis). Good to hear! Unfortunately this will come too late to fix the bug in gcc 4.1. What about the following workaround? This one could be fine for the 4.1.0 release: Remember the situation after reload. r1 is used for an uninitialized variable hence it is live from the beginning to the read of the variable. The special liveness analyzer in global alloc not considering uninitialized quantities to conflict with others assigns r1 also to a local pseudo. bb 1 start: r1 dead insn 1: r1 = 0; insn 2: use r1; clobber r1; REG_DEAD (r1) !!! bb 1 end: r1 live Due to the REG_DEAD note regrename assumes it is safe to rename r1 locally to r5 resulting in: bb 1 start: r1 live !!! insn 1: r5 = 0; insn 2: use r5; clobber r5; REG_DEAD (r5) bb 1 end: r1 live Because live at start has changed due to a local change an assertion in flow is triggered. The cause of the problem is that we already enter regrename with wrong liveness info which in turn is caused by using a different liveness analyzer in global alloc than elsewhere. We have the register r1 live at the end of the basic block but the last rtx writing this value is a clobber. This situation should only occur if we had overlapping live ranges which were assigned to the same hard reg. Under normal circumstances this should be considered a bug and an assertion would be the right choice. But knowing that this could only be caused by the global alloc liveness analyzer the flow analyzer should avoid emitting a REG_DEAD note. That way the value of the uninitialized variable (which is undefined anyway) would be clobbered what should not cause any trouble. The attached patch modifies mark_set_1 to consider a CLOBBER a normal SET if the clobbered register is live afterwards. So as a rfc what do you (or anybody else) think about the attached patch for mainline gcc. Bootstrapped on i686, s390 and s390x without testsuite regressions. This patch fixes the 920501-4.c regression on s390x. Bye, -Andreas- 2005-10-13 Andreas Krebbel <[EMAIL PROTECTED]> * flow.c (mark_set_1): Handle CLOBBERs like SETs if the register is live afterwards. Index: gcc/flow.c === RCS file: /cvs/gcc/gcc/gcc/flow.c,v retrieving revision 1.635 diff -p -c -r1.635 flow.c *** gcc/flow.c 22 Aug 2005 16:58:46 - 1.635 --- gcc/flow.c 13 Oct 2005 09:25:51 - *** mark_set_1 (struct propagate_block_info *** 2819,2825 else SET_REGNO_REG_SET (pbi->local_set, i); } ! if (code != CLOBBER) SET_REGNO_REG_SET (pbi->new_set, i); some_was_live |= needed_regno; --- 2819,2825 else SET_REGNO_REG_SET (pbi->local_set, i); } ! if (code != CLOBBER || needed_regno) SET_REGNO_REG_SET (pbi->new_set, i); some_was_live |= needed_regno;
Re: RFC: IPO optimization framework for GCC
Steve Ellcey wrote: > > In the meantime I would be interested in any opinions people have on > what level we should be writing things out at. Generic? Gimple? RTL? Or just dumping plain C code? This is almost what the pretty printers are doing, and the way back to the compiler is already there ;-) Sebastian
Re: RFC: weakref GCC attribute and .weakref assembly directive
Hello, Alexandre Oliva wrote: What we need, in contrast, is some means to define an alias that doesn't, by itself, cause an external definition of the symbol to be brought in. If the symbol is referenced directly elsewhere, however, then it must be defined. This is similar to the notion of weak references in garbage collection literature, in which a strong reference stops an object from being garbage-collected, but a weak reference does not. I've decided to name this kind of alias a weakref. Could you compare your novel weak references to PECOFF's notion of "weak externals"? .weak sym1 = sym2 # Analogous to: .weakref sym1, sym2 "If a definition of sym1 is linked, then an external reference to the symbol is resolved normally. If a definition of sym1 is not linked, then all references to the weak external for sym1 refer to sym2 instead. The external symbol, sym2, must always be linked; typically it is defined in the module containing the weak reference to sym1" (PECOFF 6.0 5.5.3). Note that PECOFF weak external symbols have external linkage, but they will never be used to resolve an undefined reference in another object at link-time. I am thinking that the difference is that PECOFF weak externals can be resolved by definitions anywhere in the final link, while your new weak references can only be overriden by definitions within the same translation unit. Does this seem correct? Thanks, Aaron W. LaFramboise
Re: RFC: weakref GCC attribute and .weakref assembly directive
On Thu, Oct 13, 2005 at 08:33:01AM -0500, Aaron W. LaFramboise wrote: > Could you compare your novel weak references to PECOFF's notion of "weak > externals"? > > .weak sym1 = sym2 # Analogous to: .weakref sym1, sym2 > > "If a definition of sym1 is linked, then an external reference to the > symbol is resolved normally. > > If a definition of sym1 is not linked, then all references to the weak > external for sym1 refer to sym2 instead. > > The external symbol, sym2, must always be linked; typically it is > defined in the module containing the weak reference to sym1" (PECOFF 6.0 > 5.5.3). > > Note that PECOFF weak external symbols have external linkage, but they > will never be used to resolve an undefined reference in another object > at link-time. > > > I am thinking that the difference is that PECOFF weak externals can be > resolved by definitions anywhere in the final link, while your new weak > references can only be overriden by definitions within the same > translation unit. Does this seem correct? The difference is that ".weak sym1 = sym2" resolves to sym1 (if available) else sym2; but ".weakref sym1, sym2" resolves to sym2 (if available) else zero. Also sym1 does not become an external, only a local alias, IIRC. -- Daniel Jacobowitz CodeSourcery, LLC
Re: Warning on C++ catch by value on non primitive types
> yeah, if it were in one of those books it could be added to the -weff-c+
> + option. It doesn't seem sensible to add a different option for an
> alternative (set of?) coding rule(s).
FYI this is item 13 in MEC++.
I think this would be a good error to have. My suggestion is to file an
enhancement request in gcc bugzilla, with this code:
#include
void
foo()
{
try
{
}
catch (std::logic_error e)
{
}
}
saying that with -Weffc++, you want a warning. Include a link back to
this thread, so that who-ever works on this can read the initial
reaction and the suggestion by Nathan to hook into finish_handler_parms.
In the near past, Giovanni has done a good job of enhancing the More
Effective C++ rules. If you ask nicely, maybe he'd do the same for this.
best,
benjamin
Re: Warning on C++ catch by value on non primitive types
On 13 Oct 2005, at 7:41 AM, Benjamin Kosnik wrote:
yeah, if it were in one of those books it could be added to the -
weff-c+
+ option. It doesn't seem sensible to add a different option for an
alternative (set of?) coding rule(s).
FYI this is item 13 in MEC++.
It is on just about any decent modern C++ coding guide/list somewhere.
I think this would be a good error to have. My suggestion is to
file an
enhancement request in gcc bugzilla, with this code:
#include
void
foo()
{
try
{
}
catch (std::logic_error e)
{
}
}
saying that with -Weffc++, you want a warning. Include a link back to
this thread, so that who-ever works on this can read the initial
reaction and the suggestion by Nathan to hook into
finish_handler_parms.
Yes, thanks for all the feedback.
I will look at the code mentioned earlier.
In the near past, Giovanni has done a good job of enhancing the More
Effective C++ rules. If you ask nicely, maybe he'd do the same for
this.
That would be great and I will ask very, very nicely and offer to
help any way I can however...
I didn't want this totally tied to -Weffc++ unless there was also a
separate switch for turning it on/off because:
1.) Last time I checked g++'s own standard library headers did not
pass -Weffc++ cleanly and hence I couldn't get a clean build of my C+
+ code using -Weffc++.
2.) A lot of other 3rd party C++ headers including the last version
of Boost I was using (admittedly a relatively old version, maybe
version 1.30) didn't pass -Weffc++ cleanly.
3.) People have many times debated the validity/usefulness of some of
the warnings that -Weffc++ produces and I think it's better to have
individual switches for each warning in -Weffc++ and then -Weffc++
just becomes a batch switch that turns on the individual switches en
masse.
best,
benjamin
[gomp] objcp/objcp-decl.c:93: error: too many arguments to function 'lookup_name'
I just want to say I can't bootstrap gomp: stage1/xgcc -Bstage1/ -B/usr/local/sparc64-unknown-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition -Wmissing-format-attribute -Werror -DOBJCPLUS -I../../gcc.gomp/gcc/objc -I../../gcc.gomp/gcc/cp -fno-common -DHAVE_CONFIG_H -I. -Iobjcp -I../../gcc.gomp/gcc -I../../gcc.gomp/gcc/objcp -I../../gcc.gomp/gcc/../include -I../../gcc.gomp/gcc/../libcpp/include ../../gcc.gomp/gcc/objcp/objcp-decl.c -o objcp/objcp-decl.o ../../gcc.gomp/gcc/objcp/objcp-decl.c: In function 'objcp_lookup_name': ../../gcc.gomp/gcc/objcp/objcp-decl.c:93: error: too many arguments to function 'lookup_name' make[3]: *** [objcp/objcp-decl.o] Error 1 make[3]: Leaving directory `/usr/local/src/branch/objdir.gomp/gcc' make[2]: *** [stage2_build] Error 2 make[2]: Leaving directory `/usr/local/src/branch/objdir.gomp/gcc' make[1]: *** [bubblestrap] Error 2 make[1]: Leaving directory `/usr/local/src/branch/objdir.gomp/gcc' make: *** [bubblestrap] Error 2 That is, the obj-c++ isn't working... however, this is a new frontend/language so... Just thought I'd enlighten you guys :) -- Cheers, /ChJ
Re: Warning on C++ catch by value on non primitive types
On Thu, Oct 13, 2005 at 09:41:22AM -0500, Benjamin Kosnik wrote: > > > yeah, if it were in one of those books it could be added to the -weff-c+ > > + option. It doesn't seem sensible to add a different option for an > > alternative (set of?) coding rule(s). > > FYI this is item 13 in MEC++. -Weffc++ is broken and should just die. The coding rules they propose, and that the flag enforces, are completely incompatible with the STL: you cannot write a C++ standard library in a way that doesn't either spew tons of -Weffc++ warnings or that bloats out most of the objects by adding an unnecessary virtual function table to all kinds of objects that are now a single pointer (you're pretty much forced to put a virtual destructor in any class that is inherited from). That's two pointers instead of one in most iterators and function objects. Yes, you can tell the compiler to ignore warnings in system headers, but then users can't use the same programming techniques that are used in the STL. So please don't build anything new on top of this ill-considered warning.
Successfull build of gcc-4.0.2 on ia64-unknown-linux-gnu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Compiler version: 4.0.2 Platform: ia64-unknown-linux-gnu configure flags: - --prefix=/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install - --with-gnu-as - --with-as=/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/bin/as - --with-gnu-ld - --with-ld=/SCRATCH/gcc-build/Linux/ia64-unknown-linux-gnu/install/bin/ld - --enable-threads=posix --enable-shared --enable-__cxa_atexit - --with-gmp=/appl/shared/gnu/Linux/ia64-unknown-linux-gnu - --with-mpfr=/appl/shared/gnu/Linux/ia64-unknown-linux-gnu - --enable-languages=c,ada,c++,f95,java,objc binutils: binutils-2.16.1 Build system: Linux itanic 2.4.21-32.0.1.EL.cern #1 SMP Thu May 26 11:51:54 CEST 2005 ia64 ia64 ia64 GNU/Linux cc for building: gcc gcc (GCC) 4.0.1 Copyright (C) 2005 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. as for building: GNU assembler 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. This assembler was configured for a target of \`ia64-unknown-linux-gnu'. ld for building: GNU ld version 2.16.1 Copyright 2005 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. testresults: http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00580.html - -- Rainer Emrich TECOSIM GmbH Im Eichsfeld 3 65428 Rüsselsheim Phone: +49(0)6142/8272 12 Mobile: +49(0)163/56 949 20 Fax.: +49(0)6142/8272 49 Web: www.tecosim.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDTpTm3s6elE6CYeURAjFeAJ40HnIDlvhEwv0gQNQx72dc8giVgwCg1JJZ 9ZrrodZD3Q92roCEYmFTSMo= =aw7r -END PGP SIGNATURE-
Re: Linker error about relocation
Eric Fisher <[EMAIL PROTECTED]> writes: > Sorry, maybe it's not appropriate to put this question here. But I need help. > Porting gcc involves the relocation and BFD porting. I've added some > relocate type. > But after linked, the address is not correct. Are there any documents > about the relocation. And what should I do? This question would be more appropriate on the binutils mailing list. See http://sourceware.org/binutils/. The best I can suggest is the documentation on BFD relocation handling in bfd/doc/bfdint.texi. Unfortunately you will discover that it's a horrible mess. Ian
[RFC] Fortran ICE caused by array addressability issue
Hello,
I've been investigating the failure of namelist_14.f90 -O0,
the last s390x-ibm-linux Fortran regression.
A much reduced test case is:
program test
type :: mt
integer:: ii(4)
end type mt
type(mt) :: t
t = mt ((/1,1,1,1/))
end program test
Compiling this program without optimization fails with
test.f90:9: internal compiler error: in expand_assignment, at expr.c:3929
(Note that *with* optimization everything is fine.)
The ICE in expand_assignment results from expanding the
following line of code (from test.f90.t24.fixupcfg):
mt.0.ii[S.6] = D.557;
"mt.0" is a temporary of type "mt" generated by the gimplifier. As the
size of mt is 16, the expander uses TImode to hold the variable.
The ICE occurs because the expander tries to use a *register* to hold
that variable, and indexing a *variable* slot inside an array held in
a register is not supported by expand_assignment.
The decision whether to use a register or a stack slot is made in the
function use_register_for_decl (function.c):
bool
use_register_for_decl (tree decl)
{
/* Honor volatile. */
if (TREE_SIDE_EFFECTS (decl))
return false;
/* Honor addressability. */
if (TREE_ADDRESSABLE (decl))
return false;
/* Only register-like things go in registers. */
if (DECL_MODE (decl) == BLKmode)
return false;
/* If -ffloat-store specified, don't put explicit float variables
into registers. */
/* ??? This should be checked after DECL_ARTIFICIAL, but tree-ssa
propagates values across these stores, and it probably shouldn't. */
if (flag_float_store && FLOAT_TYPE_P (TREE_TYPE (decl)))
return false;
/* If we're not interested in tracking debugging information for
this decl, then we can certainly put it in a register. */
if (DECL_IGNORED_P (decl))
return true;
return (optimize || DECL_REGISTER (decl));
}
As the variable is a temporary generated by the gimplifier, it has
its DECL_IGNORED_P flag set, which is why use_register_for_decl
decides to put it into a register, causing the ICE. I was unable
to reproduce this in C, because I don't get such temporaries there.
Now, the interesting point is that when opimization is on, this
routine would return true anyway, so why does it work then? This
is because then the TREE_ADDRESSABLE flag is set, so it will always
be placed onto the stack.
However, the routine mark_array_ref_addressable (tree-cfg.c) which
sets the TREE_ADDRESSABLE flag is only ever called from the routine
execute_cleanup_cfg_post_optimizing (tree-optimize.c), which is never
called when not optimizing ...
Now, I'm not sure how to fix this. One fix would be to always make
sure mark_array_ref_addressable is called, even when not optimizing.
I don't know what the right call point would be.
The other fix would be to remove the special treatment of
DECL_IGNORED_P from use_register_for_decl. This may cause somewhat
worse code generation, but only in the -O0 case, which I'm not
particularly concerned about ...
Any suggestions what the proper fix should be?
Thanks,
Ulrich
--
Dr. Ulrich Weigand
Linux on zSeries Development
[EMAIL PROTECTED]
Re: Warning on C++ catch by value on non primitive types
On Oct 13, 2005, at 8:57 AM, Thomas Costa wrote: I didn't want this totally tied to -Weffc++ unless there was also a separate switch for turning it on/off because: We support fine grained warnings now. So, this isn't a problem. Just be sure to mention you want a fine grained flag, and that you like spelling "-W..." (after you review the way we spell options).
Re: Warning on C++ catch by value on non primitive types
So can the existing set of warnings that -Weffc++ enables be broken up into fine grained warnings quite easily? Has it already been done? On 13 Oct 2005, at 11:44 AM, Mike Stump wrote: On Oct 13, 2005, at 8:57 AM, Thomas Costa wrote: I didn't want this totally tied to -Weffc++ unless there was also a separate switch for turning it on/off because: We support fine grained warnings now. So, this isn't a problem. Just be sure to mention you want a fine grained flag, and that you like spelling "-W..." (after you review the way we spell options).
Re: Warning on C++ catch by value on non primitive types
On Oct 13, 2005, at 8:58 AM, Joe Buck wrote: -Weffc++ is broken and should just die. Or we can `modernize it' by removing those things we no longer agree with, and document the bits of it that we don't like anymore in the manual. Hopefully he'll release a new book with updated guidelines. If there are no useful things left, well, let's remove it (or remove the effects the option has).
Re: Warning on C++ catch by value on non primitive types
Thomas Costa wrote: > So can the existing set of warnings that -Weffc++ enables be broken > up into fine grained warnings quite easily? Has it already been done? c++/16166 Paolo.
Re: Warning on C++ catch by value on non primitive types
Mike Stump wrote: > ... Hopefully he'll release a new book with updated guidelines. The new, third, edition of Effective C++ is out. Paolo.
Re: Warning on C++ catch by value on non primitive types
On Oct 13, 2005, at 11:46 AM, Thomas Costa wrote: So can the existing set of warnings that -Weffc++ enables be broken up into fine grained warnings quite easily? Yes. M-x grep warn_ecpp in gcc/cp/*, then replace: warning (0, with warning (OPT_Weffc_12, and then arrange for an -Weffc_12 flag (or whatever name you like). If his new book removes one you don't like, just whack it instead. We can default ones that go against sane C++ to off, that way, we can restore the utility of the -Weffc++ flag. Has it already been done? No. Sound good?
Re: Warning on C++ catch by value on non primitive types
> -Weffc++ is broken and should just die.
-Weffc++ should be made more useful, and able to be switched on a per-rule
basis.
If you search bugzilla for "Weffc++" you can get an idea of what are
considered useful improvements. I don't consider dated diatribes like
your previous email especially helpful.
As you are well aware, GCC is part of the GNU project. It's all about
freedom. We're not suggesting that people always use this flag, merely
that if they are motivated, know some C++, and are willing to look
through results that may contain false positives, they will no doubt
find some useful information. I know I do. I don't use this flag all
the time, but do use it on occasion and find the results interesting.
And you know what? This isn't the only C++ language flag that has these
issues. Look at -Wabi and the inlining warnings for similar issues.
There are no doubt other issues with other warnings: every long term
user of GCC no doubt has some favorite carp about the ridiculousness of
some flag or another. Ditching diagnostics because you don't like them
or they are imperfectly implemented seems like a strange course of
action for a member of the gcc SC to advocate.
The alternatives, which include people writing their own tools or
purchasing proprietary C++ lint tools to do this for them (which still
have the problems of the current g++ warnings, if not more) are not
suggestions I consider wise.
> The coding rules they propose,
> and that the flag enforces, are completely incompatible with the STL: you
> cannot write a C++ standard library in a way that doesn't either spew tons
> of -Weffc++ warnings or that bloats out most of the objects by adding an
> unnecessary virtual function table to all kinds of objects that are now a
> single pointer (you're pretty much forced to put a virtual destructor in
> any class that is inherited from). That's two pointers instead of one
> in most iterators and function objects.
Perhaps you were burned with older implementations of this flag. While
still not perfect, a lot of improvements went into this warning for
3.4.x.
I thought this particular complaint got fixed in the last round of -
Weffc++ enhancements, where this only warns if derived classes have
virtual functions. I can't find a reference to it in the mailing list
or in bugzilla.
The simple example below doesn't warn, for instance.
struct base
{
void foo();
};
struct derived: public base
{
void bar();
};
-benjamin
Re: Warning on C++ catch by value on non primitive types
I wrote:
> > -Weffc++ is broken and should just die.
On Thu, Oct 13, 2005 at 02:31:07PM -0500, Benjamin Kosnik wrote:
> If you search bugzilla for "Weffc++" you can get an idea of what are
> considered useful improvements. I don't consider dated diatribes like
> your previous email especially helpful.
See comment #4 to PR 12854. You state, correctly, that "The remaining
bits that warn with -Weffc++ are either mandated by the standard, or
required for performance/size reasons by ABI implementations."
That is, some aspects of -Weffc++ aren't compatible with the C++ standard;
others require that classes that should not have a virtual function table
add one.
You state later in the log that the flag is now usable on mainline. But
if I understand correctly, this is because of the warning suppression in
system headers, and is true only of code that doesn't use the STL heavily
(in particular, deriving from function objects and the like).
I was never crazy about the idea of treating system headers differently
for the purpose of warnings. I understand why it is done and why it is
necessary, but if the GCC project itself cannot produce warning-free
code for system libraries, it suggests that there is something wrong with
the warning. So it's a tradeoff: we can't fix headers provided by others
(OS headers), so it's right to shut up about them. And certainly for
specialized warnings it's understandable that the system header won't
match. But at least for warnings in -Wall, I think the system headers
should pass, and some of the -Weffc++ warnings could legitimately go in
-Wall.
> The alternatives, which include people writing their own tools or
> purchasing proprietary C++ lint tools to do this for them (which still
> have the problems of the current g++ warnings, if not more) are not
> suggestions I consider wise.
I agree. Something like -Weffc++ could be a very nice idea. The problem
is that the original Effective C++ rules have bugs.
> Perhaps you were burned with older implementations of this flag. While
> still not perfect, a lot of improvements went into this warning for
> 3.4.x.
And thanks for doing them.
> The simple example below doesn't warn, for instance.
>
> struct base
> {
> void foo();
> };
>
> struct derived: public base
> {
> void bar();
> };
Right; the warnings come for certain uses of derived. When I have time,
I'll go back over the issues I've had and try to show some examples.
Re: Warning on C++ catch by value on non primitive types
> See comment #4 to PR 12854. You state, correctly, that "The remaining
> bits that warn with -Weffc++ are either mandated by the standard, or
> required for performance/size reasons by ABI implementations."
Yep.
> That is, some aspects of -Weffc++ aren't compatible with the C++ standard;
> others require that classes that should not have a virtual function table
> add one.
Yep.
> You state later in the log that the flag is now usable on mainline. But
> if I understand correctly, this is because of the warning suppression in
> system headers, and is true only of code that doesn't use the STL heavily
> (in particular, deriving from function objects and the like).
Nyet.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14172
> I was never crazy about the idea of treating system headers differently
> for the purpose of warnings. I understand why it is done and why it is
> necessary, but if the GCC project itself cannot produce warning-free
> code for system libraries, it suggests that there is something wrong with
> the warning. So it's a tradeoff: we can't fix headers provided by others
> (OS headers), so it's right to shut up about them. And certainly for
> specialized warnings it's understandable that the system header won't
> match. But at least for warnings in -Wall, I think the system headers
> should pass, and some of the -Weffc++ warnings could legitimately go in
> -Wall.
Agreed. Doing the pragma system header thing was a sad day for me.
For major releases, I try to run with highest warning flags on both GNU
and EDG compilers, and also bring out the tweaky flags like -Weffc++.
IMHO this kind of effort is only really worthwhile on rare occasions,
and is overkill for day-to-day development.
> > The alternatives, which include people writing their own tools or
> > purchasing proprietary C++ lint tools to do this for them (which still
> > have the problems of the current g++ warnings, if not more) are not
> > suggestions I consider wise.
>
> I agree. Something like -Weffc++ could be a very nice idea. The problem
> is that the original Effective C++ rules have bugs.
Agreed. However, we can fix the implementation of some of these rules
to make them more sane. If we can, we should, and we should definitely
encourage people to work on this stuff instead of shutting them down
with "kill all warnings" talk.
> > Perhaps you were burned with older implementations of this flag. While
> > still not perfect, a lot of improvements went into this warning for
> > 3.4.x.
>
> And thanks for doing them.
Thanks to Giovanni for doing the heavy lifting. All I did was complain
in the right place, with enough detail that other people could
understand my complaints.
> > The simple example below doesn't warn, for instance.
> >
> > struct base
> > {
> > void foo();
> > };
> >
> > struct derived: public base
> > {
> > void bar();
> > };
>
> Right; the warnings come for certain uses of derived. When I have time,
> I'll go back over the issues I've had and try to show some examples.
That would be nice. Make sure you put them in bugzilla with -Weffc++ in the
keyword.
I seem to dimly recall that one of the remaining issues with bogus
warnings is with the current std::allocator design. That might be a
good first place to start with this examples.
It does seem like the highest-priority item for going forward is
splitting -Weffc++ into smaller, more granular units so that it is
possible for people to use just the useful warnings, and not get what
they feel is noise. As Paolo has pointed out, there is already a
feature request for this very thing: c+ +/16166.
best,
benjamin
gcc-4.0-20051013 is now available
Snapshot gcc-4.0-20051013 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20051013/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 CVS branch with the following options: -rgcc-ss-4_0-20051013 You'll find: gcc-4.0-20051013.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20051013.tar.bz2 C front end and core compiler gcc-ada-4.0-20051013.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20051013.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20051013.tar.bz2 C++ front end and runtime gcc-java-4.0-20051013.tar.bz2 Java front end and runtime gcc-objc-4.0-20051013.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20051013.tar.bz2The GCC testsuite Diffs from 4.0-20051006 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Update on GCC moving to svn
On Oct 8, 2005, at 5:47 PM, Daniel Berlin wrote: Thus, i'm going to put an updated repo on gcc.gnu.org on Monday (i was converting it Could I request that: svn ls svn+ssh://gcc.gnu.org/export/u0/gccsvn/gccrepo/branches | grep -i apple output a line or two (or five) before in a test repo before we switch? I wanna see it live, in a test setup so I can spot anything wrong with it, as once it is live, I think it is too late to `fix' it. In cvs, I see: apple-200508-beta-branch: 1.12.0.64 apple-tiger-release-branch: 1.6.30.4.0.10 apple-local-200502-branch: 1.12.0.44 apple-gcc_os_35-branch: 1.6.30.4.0.8 apple-ppc-branch: 1.6.30.4.0.4 Thanks.
Re: Update on GCC moving to svn
On Thu, 2005-10-13 at 15:54 -0700, Mike Stump wrote: > On Oct 8, 2005, at 5:47 PM, Daniel Berlin wrote: > > Thus, i'm going to put an updated repo on gcc.gnu.org on Monday (i was > > converting it > > Could I request that: > > svn ls svn+ssh://gcc.gnu.org/export/u0/gccsvn/gccrepo/branches | grep > -i apple > > output a line or two (or five) before in a test repo before we > switch? I'm actually in the middle of building a fully merged + converted repo (IE exactyl what the final repo will look like, including the merge from old-gcc). It should be done in another 10 hours or less. I was planning to announce it and update the wiki's page so that those with access to gcc.gnu.org could have a final run through.
Need advice: x86 redudant compare to zero
Hi,
Here is a bits of code from bzip2:
#define mswap(zz1, zz2) { int zztmp = zz1; zz1 = zz2; zz2 =
zztmp; }
void foo(int unLo, int unHi, int ltLo, int *ptr, char *block, int
med, int d, int n) {
while (1) {
if (unLo > unHi) break;
n = ((int)block[ptr[unLo]+d]) - med;
if (n == 0) {
mswap(ptr[unLo], ptr[ltLo]);
ltLo++; unLo++; continue;
};
if (n > 0) break;
unLo++;
}
}
gcc produces the following code:
.text
.globl _foo
_foo:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
subl$12, %esp
movl8(%ebp), %edx
cmpl12(%ebp), %edx
jg L10
movl16(%ebp), %eax
movl20(%ebp), %ecx
leal(%ecx,%eax,4), %eax
movl%eax, -16(%ebp)
jmp L4
L12:
movl-16(%ebp), %ecx
movl(%ecx), %eax
movl%eax, (%esi)
movl-20(%ebp), %edi
movl%edi, (%ecx)
addl$4, %ecx
movl%ecx, -16(%ebp)
addl$1, %edx
cmpl%edx, 12(%ebp)
jl L10
L13:
movl20(%ebp), %ecx
L4:
leal(%ecx,%edx,4), %esi
movl(%esi), %edi
movl%edi, -20(%ebp)
movl24(%ebp), %eax
addl%edi, %eax
movl32(%ebp), %edi
movsbl (%eax,%edi),%eax
subl28(%ebp), %eax
cmpl$0, %eax < extra compare...
je L12
jg L10
addl$1, %edx
cmpl%edx, 12(%ebp)
jge L13
L10:
addl$12, %esp
popl%esi
popl%edi
popl%ebp
ret
The cmpl is not needed because subl has already set the flags.
My question is: where and how would you suggest we do this
optimization. With peephole2? Or in combine? In i386.md, I see
pattern *subsi_2 looks like what I'd like to combine these two insn
into:
(define_insn "*subsi_2"
[(set (reg FLAGS_REG)
(compare
(minus:SI (match_operand:SI 1 "nonimmediate_operand" "0,0")
(match_operand:SI 2 "general_operand" "ri,rm"))
(const_int 0)))
(set (match_operand:SI 0 "nonimmediate_operand" "=rm,r")
(minus:SI (match_dup 1) (match_dup 2)))]
"ix86_match_ccmode (insn, CCGOCmode)
&& ix86_binary_operator_ok (MINUS, SImode, operands)"
"sub{l}\t{%2, %0|%0, %2}"
[(set_attr "type" "alu")
(set_attr "mode" "SI")])
But I do not see a peephole2 that would generate this insn. Does
anyone know how this pattern is used?
Suggestions are appreciated!
Thanks,
Evan Cheng
Apple Computers, Inc.
Re: Need advice: x86 redudant compare to zero
On Friday 14 October 2005 01:41, Evan Cheng wrote:
#(insn:TI 126 125 40 (parallel [
#(set (reg:SI 0 ax [71])
#(minus:SI (reg:SI 0 ax [71])
#(reg:SI 5 di)))
#(clobber (reg:CC 17 flags))
#]) 242 {*subsi_1} (insn_list:REG_DEP_TRUE 125 (insn_list:REG_DEP_TRUE
37 (nil)))
#(expr_list:REG_DEAD (reg:SI 5 di)
#(expr_list:REG_UNUSED (reg:CC 17 flags)
#(nil
subl%edi, %eax # 126 *subsi_1/1 [length = 2]
#(insn:TI 40 126 41 (set (reg:CC 17 flags)
#(compare:CC (reg:SI 0 ax [71])
#(const_int 0 [0x0]))) 5 {*cmpsi_1_insn} (insn_list:REG_DEP_TRUE
126 (nil))
#(expr_list:REG_DEAD (reg:SI 0 ax [71])
#(nil)))
cmpl$0, %eax# 40*cmpsi_1_insn/1 [length = 3]
>
> .text
> globl _foo
> _foo:
> pushl %ebp
> movl%esp, %ebp
> pushl %edi
> pushl %esi
> subl$12, %esp
> movl8(%ebp), %edx
> cmpl12(%ebp), %edx
> jg L10
> movl16(%ebp), %eax
> movl20(%ebp), %ecx
> leal(%ecx,%eax,4), %eax
> movl%eax, -16(%ebp)
> jmp L4
> L12:
> movl-16(%ebp), %ecx
> movl(%ecx), %eax
> movl%eax, (%esi)
> movl-20(%ebp), %edi
> movl%edi, (%ecx)
> addl$4, %ecx
> movl%ecx, -16(%ebp)
> addl$1, %edx
> cmpl%edx, 12(%ebp)
> jl L10
> L13:
> movl20(%ebp), %ecx
> L4:
> leal(%ecx,%edx,4), %esi
> movl(%esi), %edi
> movl%edi, -20(%ebp)
> movl24(%ebp), %eax
> addl%edi, %eax
> movl32(%ebp), %edi
> movsbl (%eax,%edi),%eax
> subl28(%ebp), %eax
> cmpl$0, %eax < extra compare...
> je L12
> jg L10
> addl$1, %edx
> cmpl%edx, 12(%ebp)
> jge L13
> L10:
> addl$12, %esp
> popl%esi
> popl%edi
> popl%ebp
> ret
>
> The cmpl is not needed because subl has already set the flags.
>
> My question is: where and how would you suggest we do this
> optimization. With peephole2? Or in combine? In i386.md, I see
> pattern *subsi_2 looks like what I'd like to combine these two insn
> into:
>
> (define_insn "*subsi_2"
>[(set (reg FLAGS_REG)
> (compare
>(minus:SI (match_operand:SI 1 "nonimmediate_operand" "0,0")
> (match_operand:SI 2 "general_operand" "ri,rm"))
>(const_int 0)))
> (set (match_operand:SI 0 "nonimmediate_operand" "=rm,r")
> (minus:SI (match_dup 1) (match_dup 2)))]
>"ix86_match_ccmode (insn, CCGOCmode)
> && ix86_binary_operator_ok (MINUS, SImode, operands)"
>"sub{l}\t{%2, %0|%0, %2}"
>[(set_attr "type" "alu")
> (set_attr "mode" "SI")])
>
> But I do not see a peephole2 that would generate this insn. Does
> anyone know how this pattern is used?
>
> Suggestions are appreciated!
>
> Thanks,
>
> Evan Cheng
> Apple Computers, Inc.
Re: Warning on C++ catch by value on non primitive types
Thomas Costa <[EMAIL PROTECTED]> writes: | That would be great and I will ask very, very nicely and offer to | help any way I can however... | I didn't want this totally tied to -Weffc++ unless there was also a | separate switch for turning it on/off because: | | 1.) Last time I checked g++'s own standard library headers did not | pass -Weffc++ cleanly and hence I couldn't get a clean build of my C+ | + code using -Weffc++. | 2.) A lot of other 3rd party C++ headers including the last version | of Boost I was using (admittedly a relatively old version, maybe | version 1.30) didn't pass -Weffc++ cleanly. | 3.) People have many times debated the validity/usefulness of some of | the warnings that -Weffc++ produces and I think it's better to have | individual switches for each warning in -Weffc++ and then -Weffc++ | just becomes a batch switch that turns on the individual switches en | masse. What I find the most annoying with -Weffc++ is not the rules themselves; but the fact that is that it is a set of guidelines designed for a *particular style* of programming in C++ -yet- many people see it as _The Right Way_ of doing things in C++, forgetting this is a multi-paradigm language and not a Pure programming language. I do not find it surprising that major software components like libstdc++ or Boost do not slavishly follow -Weffc++ -- I would have been surprised if they did. -- Gaby
Re: Warning on C++ catch by value on non primitive types
Joe Buck <[EMAIL PROTECTED]> writes: | So please don't build anything new on top of this ill-considered warning. Amen. -- Gaby
Re: Warning on C++ catch by value on non primitive types
Mike Stump <[EMAIL PROTECTED]> writes: | On Oct 13, 2005, at 8:58 AM, Joe Buck wrote: | > -Weffc++ is broken and should just die. | | Or we can `modernize it' by removing those things we no longer agree | with, and document the bits of it that we don't like anymore in the | manual. I find that to be invitation to confusion. People who the rules or have been trained to learn the rules would be needlessly confused. And people who don't know them would be confused too. Call it something else you shall. -- Gaby
Re: Need advice: x86 redudant compare to zero
[Sorry, pressed the wrong key combination again for the other mail... ]
On Friday 14 October 2005 01:41, Evan Cheng wrote:
> gcc produces the following code:
You're not giving enough information for me to reproduce it. I used
"-O2 -march=i686 -dAP" for the follow annotated assembler output:
#(insn:TI 126 125 40 (parallel [
#(set (reg:SI 0 ax [71])
#(minus:SI (reg:SI 0 ax [71])
#(reg:SI 5 di)))
#(clobber (reg:CC 17 flags))
#]) 242 {*subsi_1} (insn_list:REG_DEP_TRUE 125 (insn_list:REG_DEP_TRUE
37 (nil)))
#(expr_list:REG_DEAD (reg:SI 5 di)
#(expr_list:REG_UNUSED (reg:CC 17 flags)
#(nil
subl%edi, %eax # 126 *subsi_1/1 [length = 2]
#(insn:TI 40 126 41 (set (reg:CC 17 flags)
#(compare:CC (reg:SI 0 ax [71])
#(const_int 0 [0x0]))) 5 {*cmpsi_1_insn} (insn_list:REG_DEP_TRUE
126 (nil))
#(expr_list:REG_DEAD (reg:SI 0 ax [71])
#(nil)))
cmpl$0, %eax# 40*cmpsi_1_insn/1 [length = 3]
> The cmpl is not needed because subl has already set the flags.
And as you already noticed, we don't actually model that in this case.
> My question is: where and how would you suggest we do this
> optimization.
combine.
> With peephole2?
You'd get an explosion of peephole patterns.
Gr.
Steven
Re: Warning on C++ catch by value on non primitive types
Benjamin Kosnik <[EMAIL PROTECTED]> writes: | As you are well aware, GCC is part of the GNU project. It's all about | freedom. I understand that. But that should not prevent us from getting perspective on -Weffc++. -- Gaby
Re: Need advice: x86 redudant compare to zero
On Oct 13, 2005, at 7:41 PM, Evan Cheng wrote:
Hi,
Here is a bits of code from bzip2:
#define mswap(zz1, zz2) { int zztmp = zz1; zz1 = zz2; zz2 =
zztmp; }
void foo(int unLo, int unHi, int ltLo, int *ptr, char *block, int med,
int d, int n) {
while (1) {
if (unLo > unHi) break;
n = ((int)block[ptr[unLo]+d]) - med;
if (n == 0) {
mswap(ptr[unLo], ptr[ltLo]);
ltLo++; unLo++; continue;
};
if (n > 0) break;
unLo++;
}
}
PowerPC describes the pattern were we don't need the result of n after a
compare as:
(define_insn ""
[(set (match_operand:CC 0 "cc_reg_operand" "=x,?y")
(compare:CC (minus:P (match_operand:P 1 "gpc_reg_operand" "r,r")
(match_operand:P 2 "gpc_reg_operand"
"r,r"))
(const_int 0)))
(clobber (match_scratch:P 3 "=r,r"))]
"TARGET_POWERPC"
"@
subf. %3,%2,%1
#"
[(set_attr "type" "fast_compare")
(set_attr "length" "4,8")])
So something like (not tested):
(define_insn ""
[(set (reg FLAGS_REG)
(compare (minus:P (match_operand:SI 1 "nonimmediate_operand"
"0,0")
(match_operand:SI 2 "general_operand"
"ri,rm"))
(const_int 0)))
(clobber (match_scratch:SI 1 "=r"))]
"ix86_match_ccmode (insn, CCGOCmode)
&& ix86_binary_operator_ok (MINUS, SImode, operands)"
"sub{l}\t{%2, %0|%0, %2}"
[(set_attr "type" "alu")
(set_attr "mode" "SI")])
Maybe adding a pattern like that, will work?
You most likely would like to "steal" other patterns like that from the
rs6000
backend.
Thanks,
Andrew Pinski
Re: Warning on C++ catch by value on non primitive types
On Fri, Oct 14, 2005 at 01:55:49AM +0200, Gabriel Dos Reis wrote: > What I find the most annoying with -Weffc++ is not the rules > themselves; but the fact that is that it is a set of guidelines > designed for a *particular style* of programming in C++ That is, traditional OO programming. > many people see it as _The Right Way_ of doing things in C++, forgetting > this is a multi-paradigm language In particular, generic programming, as represented in STL and Boost. > I do not find it surprising > that major software components like libstdc++ or Boost do not > slavishly follow -Weffc++ -- I would have been surprised if they did. It seems that the key issue with -Weffc++ is that it is overly paranoid about the possibility that someone will destroy a derived object through a base pointer or reference, resulting in the wrong destructor being called, even in cases where neither the base class nor the derived class have any virtual functions. In the case of no virtual functions, the base/derived relationship is just a means of factoring out common code; a typical STL example would be the deriving of a function object from something like std::binary_function, or in the construction of reverse iterators. Furthermore, there are many cases where calling the wrong destructor is a no-op in any real GCC implementation (e.g. both the base and derived classes have one data member, a POD, and there is no explicit destructor, or the only side effect is in the base destructor). Most of the STL-related noises -Weffc++ makes were, as I recall, related to such cases. Maybe it could be made to shut up only about particular cases known to be safe.
Re: Need advice: x86 redudant compare to zero
My question is: where and how would you suggest we do this
optimization. With peephole2? Or in combine? In i386.md, I see pattern
*subsi_2 looks like what I'd like to combine these two insn into:
(define_insn "*subsi_2"
[(set (reg FLAGS_REG)
(compare
(minus:SI (match_operand:SI 1 "nonimmediate_operand" "0,0")
(match_operand:SI 2 "general_operand" "ri,rm"))
(const_int 0)))
(set (match_operand:SI 0 "nonimmediate_operand" "=rm,r")
(minus:SI (match_dup 1) (match_dup 2)))]
"ix86_match_ccmode (insn, CCGOCmode)
&& ix86_binary_operator_ok (MINUS, SImode, operands)"
"sub{l}\t{%2, %0|%0, %2}"
[(set_attr "type" "alu")
(set_attr "mode" "SI")])
That's quite similar to several PPC patterns for andi. , and they work.
If you've got two other insns that look like the set's I'd expect
combine
to merge them, and would look to see why it doesn't.
Re: Need advice: x86 redudant compare to zero
My question is: where and how would you suggest we do this
optimization. With peephole2? Or in combine? In i386.md, I see
pattern *subsi_2 looks like what I'd like to combine these two insn
into:
(define_insn "*subsi_2"
[(set (reg FLAGS_REG)
(compare
(minus:SI (match_operand:SI 1 "nonimmediate_operand" "0,0")
(match_operand:SI 2 "general_operand" "ri,rm"))
(const_int 0)))
(set (match_operand:SI 0 "nonimmediate_operand" "=rm,r")
(minus:SI (match_dup 1) (match_dup 2)))]
"ix86_match_ccmode (insn, CCGOCmode)
&& ix86_binary_operator_ok (MINUS, SImode, operands)"
"sub{l}\t{%2, %0|%0, %2}"
[(set_attr "type" "alu")
(set_attr "mode" "SI")])
But I do not see a peephole2 that would generate this insn. Does
anyone know how this pattern is used?
This is the sort of thing you'd expect combine.c to make when it
combines an scc insn with arithmetic when the arithmetic result
is also used.
Re: Need advice: x86 redudant compare to zero
On Thu, Oct 13, 2005 at 08:10:27PM -0400, Andrew Pinski wrote: > PowerPC describes the pattern were we don't need the result of n after a > compare as: Except that we *do* need the result of N after the compare in this case. r~
Duplicating immediate predecessor of EXIT_BLOCK
I'm interested in duplicating the immediate predecessor basic block of the EXIT_BLOCK, but this makes the EXIT_BLOCK have 2 predecessors which isn't allowed. Can someone give me some guidances as to how I can insert a bogus block between the two to allow the duplication? Thanks, Chad Rosier
Re: [gfortran] Change language name from "f95" to "fortran"
FX Coudert wrote: Attached patch changes the name of the language in --enable-languages from "f95" to "fortran", and in a few other places. There are still lots of places which are refered to as f95 (such as f951 ;-), but they are all internal uses. This happened a month ago. It just occured to me today that it is a bit odd that I can do --enable-languages=fortran, but I can't do -x fortran. The -x option only accepts f77 and f95. Shouldn't -x fortran work also? -- Jim Wilson, GNU Tools Support, http://www.specifix.com
many libgcc in MacOS X 10.4 build
What exactly are all of the new libgcc versions created when building the current gcc cvs on MacOS X 10.4. I find that I have... -rw-r--r-- 1 root admin 20732 Oct 13 23:08 libgcc_s.10.4.dylib -rw-r--r-- 1 root admin 20968 Oct 13 23:08 libgcc_s.10.5.dylib -rw-r--r-- 1 root admin 240636 Oct 13 23:08 libgcc_s_ppc64.1.dylib -rw-r--r-- 1 root admin 209796 Oct 13 23:08 libgcc_s.1.dylib Particularly curious is the libgcc_s.10.5.dylib. Is there some specific feature that won't be functional in gcc until MacOS X 10.5? Jack
Re: Duplicating immediate predecessor of EXIT_BLOCK
[EMAIL PROTECTED] writes: > I'm interested in duplicating the immediate predecessor basic block of the > EXIT_BLOCK, but this makes the EXIT_BLOCK have 2 predecessors which isn't > allowed. Can someone give me some guidances as to how I can insert a > bogus block between the two to allow the duplication? Why can't EXIT_BLOCK have two predecessors? Ian
Re: Duplicating immediate predecessor of EXIT_BLOCK
> [EMAIL PROTECTED] writes: > >> I'm interested in duplicating the immediate predecessor basic block of >> the >> EXIT_BLOCK, but this makes the EXIT_BLOCK have 2 predecessors which >> isn't >> allowed. Can someone give me some guidances as to how I can insert a >> bogus block between the two to allow the duplication? > > Why can't EXIT_BLOCK have two predecessors? > > Ian > >From can_duplicate_block_p(): /* Duplicating fallthru block to exit would require adding a jump and splitting the real last BB. */ e = find_edge (bb, EXIT_BLOCK_PTR); if ( e && (e->flags & EDGE_FALLTHRU)) return false;
Re: Duplicating immediate predecessor of EXIT_BLOCK
[EMAIL PROTECTED] writes: > > [EMAIL PROTECTED] writes: > > > >> I'm interested in duplicating the immediate predecessor basic block of > >> the > >> EXIT_BLOCK, but this makes the EXIT_BLOCK have 2 predecessors which > >> isn't > >> allowed. Can someone give me some guidances as to how I can insert a > >> bogus block between the two to allow the duplication? > > > > Why can't EXIT_BLOCK have two predecessors? > > > > Ian > > > > From can_duplicate_block_p(): > /* Duplicating fallthru block to exit would require adding a jump and > splitting the real last BB. */ > e = find_edge (bb, EXIT_BLOCK_PTR); > if ( e && (e->flags & EDGE_FALLTHRU)) > return false; I don't know why that is there. I see that it has been there since the function was written. There may well be a good reason for it. Or not. I don't know. Still, it doesn't follow that EXIT_BLOCK can't have more than one predecessor. Even that code just prevents it from having more than one EDGE_FALLTHRU predecessor. Anyhow, to answer your original question, you should be able to call split_edge to introduce a new basic block between your block and EXIT_BLOCK. Ian
Re: Update on GCC moving to svn
> I'm actually in the middle of building a fully merged + converted repo > (IE exactyl what the final repo will look like, including the merge > from old-gcc). > > It should be done in another 10 hours or less. > > I was planning to announce it and update the wiki's page so that those > with access to gcc.gnu.org could have a final run through. Has any thought been put into helping the 200+ people with write access migrate? I.e. a quick how-to guide for simple cvs actions and their corresponding svn commands posted on the website? Hmm, I guess we would need to update these pages to the svn equivalents which would pretty much cover the basics of a how-to guide: http://gcc.gnu.org/cvs.html http://gcc.gnu.org/cvswrite.html Also, we have a bunch of mirrors sites. Are these updated through cvs? If so, what are we doing about that? Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Linking of object files from different compilers for ARM
Hello! I have two files: foo.c and main.c. foo.c is compiled with RVTC 2.2 compiler. main.c is compiled with gcc compiler (configured with --target=arm-elf). I cannot link them together using gcc linker. But it's possible to link files if I use CodeSourcery version of gcc. CodeSourcery guys writes that they have added full EABI support and hope to submit it to the gcc 4.1. So, the question is what's the difference between CodeSourcery's version of gcc and FSF version? And is EABI support really submitted to the gcc 4.1? -- Yaroslav
