specifying insn costs from attributes
In the .md-file of my port, I have set an attribute "size" of every insn, giving its size (obviously), in bytes. Is there any way I can use the value of this attribute to determine the cost (in e.g. TARGET_RTX_COSTS) when optimizing for size? Or is there some other smart way of achieving the same thing? Is it better to use the "length" attribute for this?
i386-linux bootstrap failure
> Bootstrap on i386-linux has been broken for a week now, from what I > can see. I have reported it as PR33679 > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33679), but AFAIK noone > has reproduced it, as most people now build for i686-linux. Could > someone please spare a cycle to confirm this problem? I configure with > --enable-languages=c,fortran --build=i386-pc-linux-gnu > --enable-checking=release > > Thanks, > FX Getting libgfortran failure on i586-suse-linux while bootstrapping: ../../../gcc/libgfortran/intrinsics/selected_int_kind.f90:22: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Razya
Re: specifying insn costs from attributes
On 10/11/07, Tomas Svensson <[EMAIL PROTECTED]> wrote: > In the .md-file of my port, I have set an attribute "size" of every > insn, giving its size (obviously), in bytes. Is there any way I can use the > value of this attribute to determine the cost (in e.g. TARGET_RTX_COSTS) > when optimizing for size? Or is there some other smart way of achieving > the same thing? Is it better to use the "length" attribute for this? > At the time of rtx_costs you have no way of estimating which exact instruction is going to get generated / matched with the backend. So in TARGET_RTX_COSTS you estimate the number of instructions or the size of each instruction. Look at how these are defined in other backends. It is also important that you set up the length attribute correctly so that you can use that for other features like branch shortening and reordering basic blocks. However this is useful in passes in the backend only after RTL insns have finished up with matching with actual insns in the md file. You can set this attribute based on types of the insns if you have these based on the types of instructions probably for scheduling descriptions or manually set this for every define_insn pattern in your backend. HTH cheers Ramana -- Ramana Radhakrishnan
gcc-4.2-20071011 is now available
Snapshot gcc-4.2-20071011 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071011/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 129232 You'll find: gcc-4.2-20071011.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20071011.tar.bz2 C front end and core compiler gcc-ada-4.2-20071011.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20071011.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20071011.tar.bz2 C++ front end and runtime gcc-java-4.2-20071011.tar.bz2 Java front end and runtime gcc-objc-4.2-20071011.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20071011.tar.bz2The GCC testsuite Diffs from 4.2-20070905 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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: Preparsing sprintf format strings
On 2007-10-10, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
> The only features in the printf-family of functions that depends on the
> locale are the conversion with thousand grouping ("%'d"), and glibc
> extension of using locale's alternative output digits ("%Id").
And those dealing with floating point values ("%f", "%g", etc) - for
example, this program:
#include
#include
int main() {
printf("%f\n", 3.14);
setlocale(LC_NUMERIC, "fr_FR");
printf("%f\n", 3.14);
return 0;
}
produces this output:
3.14
3,14
> We can easily just fall back to glibc sprintf in those cases.
And for these others too, of course.
Cheers,
Olly
Warning: `z' is used uninitialized in this function
Just to make sure before I submit a bug report: when GCC says that
a certain variable _is_ (as opposed to _may be_) used uninitialized
in this function, it means that it has proved that the variable
is indeed used uninitialized, right?
I am asking because I have a testcase where g++ gives this warning for
`z' in the statement marked with (***) below. However, `z' is indeed
initialized by the mul() function template, which takes the first
argument by (non-const) reference:
template
inline Result
add_mul_int(Type& to, const Type x, const Type y, Rounding_Dir dir) {
Type z;
Result r = mul(z, x, y, dir);
switch (r) {
case V_NEG_OVERFLOW:
case V_LT:
if (to <= 0) {
to = z; (***)
return r;
}
All the best,
Roberto
--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]
Re: Warning: `z' is used uninitialized in this function
On 11/10/2007, Roberto Bagnara <[EMAIL PROTECTED]> wrote: > > Just to make sure before I submit a bug report: when GCC says that > a certain variable _is_ (as opposed to _may be_) used uninitialized > in this function, it means that it has proved that the variable > is indeed used uninitialized, right? When GCC says that a certain variable "is used" uninitialized, it just means that it has found a SSA name with an empty definition in a particular BB. That proves nothing about a variable being used uninitialized, since, that BB may be conditional or it may not even be executed at all. Nonetheless, this is not the desirable behaviour so, please submit a bug report and if possible, attach the smallest self-contained testcase and the *.ssa file obtained by adding the option -fdump-tree-all-all. Please add manu at gcc dot gnu dot org to the CC list. > I am asking because I have a testcase where g++ gives this warning for > `z' in the statement marked with (***) below. However, `z' is indeed > initialized by the mul() function template, which takes the first > argument by (non-const) reference: The current Wuninitialized mechanism does not handle memory references well (it does not handle virtual operands at all), so it gets easily confused by pointers, references, arrays, etc. I am almost sure that the wrong warning is a consequence of the combination of this and the previously mentioned issues. Thanks, Manuel.
Re: gcc-4.2-20071011 is now available
On Thu, 11 Oct 2007, [EMAIL PROTECTED] wrote: > Snapshot gcc-4.2-20071011 is now available on > ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071011/ > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. I ran this script manually and reenabled the generation of snapshots off the GCC 4.2 branch. I assume we just missed the latter because we hadn't documented this step in our release documentation. Mark, what do you think of the patch below? It adds this piece of documentation and removes the step to remove RC sources from our server since we are now treating these pretty similar to regular snapshots which we do not remove either and we have users (including the FreeBSD Ports Collection who refer to these RC tarballs). (Also, it's less work for the release manager. ;-) Gerald Index: releasing.html === RCS file: /cvs/gcc/wwwdocs/htdocs/releasing.html,v retrieving revision 1.29 diff -u -3 -p -r1.29 releasing.html --- releasing.html 21 Sep 2006 14:17:36 - 1.29 +++ releasing.html 11 Oct 2007 19:12:35 - @@ -47,8 +47,6 @@ also files such as /some/where/gcc Upload the release to ftp.gnu.org. -Remove pre-release sources from gcc.gnu.org:~ftp/pub/gcc/. - If you are making a release of GCC 4.1 or later: Increment the version number in gcc/BASE-VER. Restore the word "prerelease" (without the quotation marks) to gcc/DEV-PHASE. @@ -60,6 +58,9 @@ stamp and (prerelease) annotation. Incr Notify developers that checkins to the branch are once again allowed. + +Reenable the generation of snapshots off the respective release +branch in the crontab of gccadmin on gcc.gnu.org. Web Site Updates
[tuples] mainline merge (@ 129233)
Hi folks. I have merged mainline (rev 129233) into the tuples branch. All compile.exp tests succeed. No regressions. Nothing of interest. Aldy
Re: gcc-4.2-20071011 is now available
Gerald Pfeifer wrote: > On Thu, 11 Oct 2007, [EMAIL PROTECTED] wrote: >> Snapshot gcc-4.2-20071011 is now available on >> ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071011/ >> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. > > I ran this script manually and reenabled the generation of snapshots off > the GCC 4.2 branch. I assume we just missed the latter because we hadn't > documented this step in our release documentation. Correct, sorry! > Mark, what do you think of the patch below? It adds this piece of > documentation and removes the step to remove RC sources from our server > since we are now treating these pretty similar to regular snapshots which > we do not remove either and we have users (including the FreeBSD Ports > Collection who refer to these RC tarballs). That's fine with me. I was just checking off items on the checklist. :-) I hope this didn't inconvenience the FreeBSD folks. I remembered that you'd asked me to leave the previous 4.2.1 RCs around, but I hadn't realized that was a general request, as opposed to something specific to 4.2.1. This patch is OK, thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Should build-sysroot be considered for setting inhibit_libc?
I'm working on a patch to the top level configure to detect if inhibit_libc will set for gcc and to avoid trying to build certain libraries in that case. I started to just clone the inhibit_libc logic from the gcc/configure, but as Ian commented, it is a bit strange. Then I realized that build-sysroot is not checked at all. Under what conditions should inhibit_libc really be set? Extending the current logic would result in this, is it what is really wanted? 1. Cross compiling with no build-sysroot, sysroot, or headers specified 2. Newlib is explicitly specified regardless of build-sysroot or sysroot but without headers specified. Should specifiying newlib in the absence of the newlib source continue to be treated as meaning "force inhibit_libc" in some cases, or should inhibit_libc just be exposed if that is desirable? Steve Kenton
Re: Preparsing sprintf format strings
Heikki Linnakangas writes:
>The only features in the printf-family of functions that depends on the
>locale are the conversion with thousand grouping ("%'d"), and glibc
>extension of using locale's alternative output digits ("%Id").
The entire parsing of the format string is affected by the multi-byte
character encoding. I don't know how GCC would be able tell that a byte
with the same value as '%' in the middle of string would actually be
interpreted as '%' character rather than a part of an extended multibyte
character. This can easily happen with the ISO 2022-JP encoding.
Ross Ridge
