Re: Bootstrap failure in stage 1 on trunk for i686-pc-linux-gnu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues schrieb: |>> | On Thu, Jul 17, 2008 at 7:51 AM, Rainer Emrich <[EMAIL PROTECTED]> wrote: |>> |> /opt/gnu/src/gcc/gcc-4.4.0/gcc/reload1.c: In function 'choose_reload_regs': |>> |> /opt/gnu/src/gcc/gcc-4.4.0/gcc/reload1.c:6083: error: expected expression at end of input | | Looks like a corrupted file. Interrupted download, full disk? | | Cheers, | Ralf | Sorry for the noise, it was a corrupted file indeed. svn did not detect the difference. - -- Mit freundlichen Grüßen / Best Regards Dipl.-Ing. Rainer Emrich Dept. Manager IT/Softwareentwicklung TECOSIM Technische Simulation GmbH Ferdinand-Stuttmann-Straße 15 D-65428 Rüsselsheim Phone +49 (0) 6142 8272-330 Fax+49 (0) 6142 8272-249 Mobile +49 (0) 163 5694920 www.tecosim.com best partner for simulation _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ TECOSIM Technische Simulation GmbH, Rüsselsheim Firmensitz: Ferdinand-Stuttmann-Straße 15, 65428 Rüsselsheim Registergericht: Amtsgericht Darmstadt, HRB 83704 Geschäftsführer: Udo Jankowski, Jürgen Veith -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIgEvf3s6elE6CYeURAvmsAJ0WhkAqcW1Oxd4Ivk7wZG7AbxtsjwCgy9gK n5CjxYWe0srw1722y2m1p1w= =nYAw -END PGP SIGNATURE-
Re: Set environment variable on remote target
Andreas Schwab wrote:
Jie Zhang <[EMAIL PROTECTED]> writes:
So we have to use single quotes. The updated patch is attached.
This will break if the value can contain single quotes.
How about using double quotes but escaping ", \, $, and ` using
backslash? The patch is attached.
Jie
diff --git a/lib/rsh.exp b/lib/rsh.exp
index 1a207a8..d846887 100644
--- a/lib/rsh.exp
+++ b/lib/rsh.exp
@@ -225,6 +225,7 @@ proc rsh_upload {desthost srcfile destfile} {
#
proc rsh_exec { boardname program pargs inp outp } {
global timeout
+global remote_env
verbose "Executing $boardname:$program $pargs < $inp"
@@ -261,7 +262,14 @@ proc rsh_exec { boardname program pargs inp outp } {
set inp "/dev/null"
}
-set ret [local_exec "$RSH $rsh_useropts $hostname sh -c '$program $pargs \\; echo XYZ\\\${?}ZYX'" $inp $outp $timeout]
+set remote_envs ""
+foreach envvar [array names remote_env] {
+ set tmp_env "$remote_env($envvar)"
+ # Escape ", \, $, and `, which cannot be protected by double quotes.
+ regsub -all "(\[\"$`])" $tmp_env "\\1" tmp_env
+ set remote_envs "$remote_envs $envvar=\"$tmp_env\""
+}
+set ret [local_exec "$RSH $rsh_useropts $hostname sh -c '$remote_envs $program $pargs \\; echo XYZ\\\${?}ZYX'" $inp $outp $timeout]
set status [lindex $ret 0]
set output [lindex $ret 1]
diff --git a/lib/utils.exp b/lib/utils.exp
index 6c9ff98..6325dd8 100644
--- a/lib/utils.exp
+++ b/lib/utils.exp
@@ -414,3 +414,12 @@ proc getenv { var } {
}
}
+#
+# Set an environment variable remotely
+#
+proc remote_setenv { var val } {
+global remote_env
+
+set remote_env($var) $val
+}
+
gmp-4.2.2 t-printf test fails when compiled with trunk revision 137937 on i686-pc-linux-gnu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
gmp_vfprintf wrong
~ fmt |%08Zd|
~ got |0000|
~ want ||
~ got_len 8
~ ftell_len 8
~ fread_len 8
~ want_len 8
/bin/sh: line 4: 10698 Aborted ${dir}$tst
FAIL: t-printf
PASS: t-scanf
PASS: t-locale
==
1 of 3 tests failed
Please report to [EMAIL PROTECTED]
==
- --
Mit freundlichen Grüßen / Best Regards
Dipl.-Ing. Rainer Emrich
Dept. Manager IT/Softwareentwicklung
TECOSIM Technische Simulation GmbH
Ferdinand-Stuttmann-Straße 15
D-65428 Rüsselsheim
Phone +49 (0) 6142 8272-330
Fax+49 (0) 6142 8272-249
Mobile +49 (0) 163 5694920
www.tecosim.com
best partner for simulation
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
TECOSIM Technische Simulation GmbH, Rüsselsheim
Firmensitz: Ferdinand-Stuttmann-Straße 15, 65428 Rüsselsheim
Registergericht: Amtsgericht Darmstadt, HRB 83704
Geschäftsführer: Udo Jankowski, Jürgen Veith
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFIgHar3s6elE6CYeURAntHAJ96aYutrdQY87DRbdef8Pvp8FmMTQCgijhC
Jv6IuuibngF11XX/Xa54/DY=
=Z2k6
-END PGP SIGNATURE-
Where to get a list of warning and error messages
I'm currently building a database of gcc warnings and error messages including a example of code what triggers it and how to fix it. Is there any full database of gcc warnings and errors? Simon Toth
Re: Where to get a list of warning and error messages
Simon Toth wrote: I'm currently building a database of gcc warnings and error messages including a example of code what triggers it and how to fix it. Is there any full database of gcc warnings and errors? Simon Toth For the GNAT front end, no such list exists, however, a grep of the front end sources for the string Error_Msg would produce something good enough for this purpose.
Re: Where to get a list of warning and error messages
* Simon Toth ([EMAIL PROTECTED]) [20080718 13:16]: > Is there any full database of gcc warnings and errors? AFAIK, there isn't one. I guess your best choice is gcc.pot (i.e. the message catalog) in the po subdir. Philipp
How to determine if a decl is a class member in GCC
Hi,
In my attribute handlers that handle the new thread-safety attributes
(in c-common.c), I need to check if a decl is a class member. How do
people do that? My original code was checking if a decl is a
FIELD_DECL but that doesn't work for static members. I also tried to
use DECL_CONTEXT but it is not set (in the C++ front-end) for data
members. (I was able to use DECL_CONTEXT for member functions,
though.) Is there any other way that I should use?
BTW, as an experiment, I went ahead and made the following change in
C++ front-end to set the DECL_CONTEXT of class data members. The patch
appears to work and doesn't seem to break any g++ and gcc regression
tests. (I will be running gdb testsuite later.) I think there must be
a reason why the DECL_CONTEXT of data members wasn't set in the
front-end, but it's not clear to my why. Can someone kindly explain
why that is and whether the patch is OK?
Thanks,
Le-chun
Index: cp/decl.c
===
--- cp/decl.c (revision 137849)
+++ cp/decl.c (working copy)
@@ -9074,6 +9074,11 @@ grokdeclarator (const cp_declarator *dec
if (thread_p)
DECL_TLS_MODEL (decl) = decl_default_tls_model (decl);
+
+/* Since a static class data member is a VAR_DECL (instead of
+ a FIELD_DECL), setting the decl_context here allows us to
+ tell if it is a class member. */
+DECL_CONTEXT (decl) = ctype ? ctype : current_class_type;
}
else
{
Adapting GCC to compile code for software CPU
Folks, I have a model of a CPU with reduced set of commands and would like to use GCC to compile code for its architecture. The instruction says to notify you in case of any action that might need to be known to the community. So there is the notice. Also, anyone who wants to share the list of possible issues or recommendations - welcome. Cheers, Adel.
gimple type system
Diego has asked me to look into what would be needed in a gimple type system. This is an issue that has been brought to a head because now it is time to merge types for lto. There are a lot of questions that need to be answered before designing such a system and i would like to handle them one by one, rather than deal with a thousand threads that go off in a lot of directions. So for now, I would like to limit the discussion to a single question: "what do we want to do in the middle end of a compiler with a middle end type system?" I have a couple of positive answers and one negative answer. The point of this mail is to get a more refined list. The two positive answers are: 1) Type narrowing. In an object oriented system, it is generally a big win to be able to narrow a type as much as possible. This can be used to then be able to inline method calls, as well as remove runtime casts and type checks (this is useless for c). 2) Inter file type checking. While this is not an optimization, there are reasons why it would be useful to discover types that are mismatched across compilation units. The thing that MAY not be useful anymore is the use of a type system of alias analysis. I would have hoped that danny and richi and all of the other people hacking on the alias analysis would have subsumed anything that one could have gathered from a type based alias analysis. If I am wrong, please correct me. Anyway, there must be other uses of types in either the existing middle end or that people have dreams of adding to the middle end in the future. Now is the time to raise your hand before the design has been started. Kenny
Re: gimple type system
On Fri, Jul 18, 2008 at 11:25 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: > Diego has asked me to look into what would be needed in a gimple type > system. This is an issue that has been brought to a head because now it is > time to merge types for lto. > > There are a lot of questions that need to be answered before designing such > a system and i would like to handle them one by one, rather than deal with a > thousand threads that go off in a lot of directions. So for now, I would > like to limit the discussion to a single question: "what do we want to do > in the middle end of a compiler with a middle end type system?" > > I have a couple of positive answers and one negative answer. The point of > this mail is to get a more refined list. The two positive answers are: > > 1) Type narrowing. In an object oriented system, it is generally a big win > to be able to narrow a type as much as possible. This can be used to then > be able to inline method calls, as well as remove runtime casts and type > checks (this is useless for c). > 2) Inter file type checking. While this is not an optimization, there are > reasons why it would be useful to discover types that are mismatched across > compilation units. > > The thing that MAY not be useful anymore is the use of a type system of > alias analysis. I would have hoped that danny and richi and all of the > other people hacking on the alias analysis would have subsumed anything that > one could have gathered from a type based alias analysis. If I am wrong, > please correct me. Hah. You are definitely wrong. > Anyway, there must be other uses of types in either the existing middle end > or that people have dreams of adding to the middle end in the future. Now > is the time to raise your hand before the design has been started. We already have a middle-end type-system. It is unfortunately mostly implicitly defined by the assumptions we make and the information we extract from the types. I don't think you can just go and define a type-system - after all, what would be the result of such a definition? Instead there are some goals we want to reach: 1) reduce the amount of data related to types (and declarations) during optimization 2) canonicalize "types" if their difference does not matter for the current and further stages of compilation (like we do now say all integral types with the same precision and signedness are "the same") For both of the above a prerequesite to actually really "unify" types (not treating them the same, but actually getting rid of either in favor of another) is to handle debug information properly. The plan is to emit debug information for the source-level state of types early and refer to that from declarations via a unique identifier. One question would be if we want to gradually lower types (for example flatten structures, unify bit-precision integer types to modes, etc.) or if we just want to do one step after/during gimplification (we have a second step at RTL expansion of course). Richard.
Re: gimple type system
Richard Guenther wrote: On Fri, Jul 18, 2008 at 11:25 PM, Kenneth Zadeck <[EMAIL PROTECTED]> wrote: Diego has asked me to look into what would be needed in a gimple type system. This is an issue that has been brought to a head because now it is time to merge types for lto. There are a lot of questions that need to be answered before designing such a system and i would like to handle them one by one, rather than deal with a thousand threads that go off in a lot of directions. So for now, I would like to limit the discussion to a single question: "what do we want to do in the middle end of a compiler with a middle end type system?" I have a couple of positive answers and one negative answer. The point of this mail is to get a more refined list. The two positive answers are: 1) Type narrowing. In an object oriented system, it is generally a big win to be able to narrow a type as much as possible. This can be used to then be able to inline method calls, as well as remove runtime casts and type checks (this is useless for c). 2) Inter file type checking. While this is not an optimization, there are reasons why it would be useful to discover types that are mismatched across compilation units. The thing that MAY not be useful anymore is the use of a type system of alias analysis. I would have hoped that danny and richi and all of the other people hacking on the alias analysis would have subsumed anything that one could have gathered from a type based alias analysis. If I am wrong, please correct me. Hah. You are definitely wrong. I stand corrected. I could hope. Anyway, there must be other uses of types in either the existing middle end or that people have dreams of adding to the middle end in the future. Now is the time to raise your hand before the design has been started. We already have a middle-end type-system. It is unfortunately mostly implicitly defined by the assumptions we make and the information we extract from the types. I don't think you can just go and define a type-system - after all, what would be the result of such a definition? Here, I think that you are wrong. You can first start with a series of requirements and only keep the information that is necessary to satisfy the requirements.We currently have a type system that is defined by: here is what the c front end used to provide for use, and then we grafted on what the front ends would provide for use and now we have a mess. It is my hope to define what what we really need and then to define an api to get that information and then engineer the underlying information to make this all work and I would like to know why we want to merge and what it means to merge (except for the obvious space reason) before i go proposing some algorithms and datastructures to support this. Instead there are some goals we want to reach: 1) reduce the amount of data related to types (and declarations) during optimization 2) canonicalize "types" if their difference does not matter for the current and further stages of compilation (like we do now say all integral types with the same precision and signedness are "the same") For both of the above a prerequesite to actually really "unify" types (not treating them the same, but actually getting rid of either in favor of another) is to handle debug information properly. The plan is to emit debug information for the source-level state of types early and refer to that from declarations via a unique identifier. One question would be if we want to gradually lower types (for example flatten structures, unify bit-precision integer types to modes, etc.) or if we just want to do one step after/during gimplification (we have a second step at RTL expansion of course). I would like to settle this lowering issue after i get an inventory of the uses we want to make of the type information. kenny Richard.
gcc-4.4-20080718 is now available
Snapshot gcc-4.4-20080718 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080718/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 137968 You'll find: gcc-4.4-20080718.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20080718.tar.bz2 C front end and core compiler gcc-ada-4.4-20080718.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20080718.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20080718.tar.bz2 C++ front end and runtime gcc-java-4.4-20080718.tar.bz2 Java front end and runtime gcc-objc-4.4-20080718.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20080718.tar.bz2The GCC testsuite Diffs from 4.4-20080711 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: [tuples] Jakub is now branch maintainer
On 7/16/08 10:49 AM, Gerald Pfeifer wrote: Hear, hear. ;-) Do you guys want to update http://gcc.gnu.org/svn.html accordingly as well? (I believe you are missing there, too, Diego. ;-) Will do. It shouldn't be much longer until we merge the branch into mainline, but I'll patch svn.html anyway. Diego.
