several SSH keys to access svn+ssh:gcc.gnu.org
Hello All,
I would like to svn commit to GCC (either after an OK to the trunk, or
to the GCC MELT branch) from two different machines (my work machine &
my home machine).
Up to now, my office machine was not powerful enough to compile quickly
GCC MELT (so I used to ssh from office to home, and then svn commit
from the home server). But I just got my office machine replaced by
something powerful.
The SSH keys are different (at office, I have a passphrase, not at
home).
Is it possible to access svn+ssh:gcc.gnu.org with two different keys?
What is the exact procedure?
http://gcc.gnu.org/wiki/SSH_connection_caching is suggesting
ssh gcc.gnu.org appendkey -- does it work as I understand?
Cheers.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
gcc-4.3-20101107 is now available
Snapshot gcc-4.3-20101107 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20101107/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 166420 You'll find: gcc-4.3-20101107.tar.bz2 Complete GCC (includes all of below) MD5=10a48ef09d3e0b68dc2ac21196787c1e SHA1=fd45ddaefcb1ebd66358873f35d443401d143e64 gcc-core-4.3-20101107.tar.bz2C front end and core compiler MD5=953d657d9561348c5944efb743083e19 SHA1=d7d266529ee2931b8e5e6cd062711b08e89c01fc gcc-ada-4.3-20101107.tar.bz2 Ada front end and runtime MD5=3027f2306134a674c2a0df27b204b00f SHA1=92a2979399ad072dc16005eb77b997f1931dad48 gcc-fortran-4.3-20101107.tar.bz2 Fortran front end and runtime MD5=e3897895a3cb2ff2274636cd61165d61 SHA1=da8aab8036cacedf9e9e3db5212ac33e3d0f8ea5 gcc-g++-4.3-20101107.tar.bz2 C++ front end and runtime MD5=bee8594007b6ddcdbb2728bf39820fe8 SHA1=ce2cd86cc59125a388bd85767e5512b571e6b92c gcc-java-4.3-20101107.tar.bz2Java front end and runtime MD5=a651168c1c47001a3446611583ab9276 SHA1=a558ddc42848527cedaad145b97dc247ceb37711 gcc-objc-4.3-20101107.tar.bz2Objective-C front end and runtime MD5=22b8f95dc88ce2cc5671ae05c338e25b SHA1=45af27c2fe0b180523209f73dfcde73832521829 gcc-testsuite-4.3-20101107.tar.bz2 The GCC testsuite MD5=61c016533dc7bf81e67f8b5b0275f493 SHA1=bbcf0e4edfe0a9e7a6d2126373ab8f8da7fa35ef Diffs from 4.3-20101031 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?
Jim writes: > After upgrading my Dell laptop, both OS+kernel the i8k interface was giving > nonsensical output. As it turned out it's not the kernel but compiler > upgrade which broke this. > > Guys at Archlinux have found the underlying cause (but don't seem to have > submitted a patch yet): > https://bbs.archlinux.org/viewtopic.php?pid=780692#p780692 > gcc seems to optimize the assembly statements away. > > And indeed, applying this patch makes the i8k interface work again, > i.e. replacing the asm(..) construct by asm volatile(..) The compiler really should not optimize the asm away, because it has both input and output arguments which are later used. "asm volatile" normally just means "don't move significantly" I tested it with gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292] (SUSE Linux) and the asm statement is there for both 32bit and 64bit (with an allmodconfig, with both -O2 and -Os) If gcc 4.5.1 broke that over 4.5.0 you should really file a bug report for the compiler, it seems like a serious regression in 4.5.1 -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: several SSH keys to access svn+ssh:gcc.gnu.org
On Sun, 7 Nov 2010, Basile Starynkevitch wrote: > Is it possible to access svn+ssh:gcc.gnu.org with two different keys? > What is the exact procedure? > > http://gcc.gnu.org/wiki/SSH_connection_caching is suggesting > ssh gcc.gnu.org appendkey -- does it work as I understand? That is my understanding. Alternately, you could generate a key for accessing gcc.gnu.org and use that key both on your home system and your office system, for example doing something like Host gcc.gnu.org IdentityFile=~/.ssh/id_dsa-gcc.gnu.org in .ssh/config (assuming id_dsa-gcc.gnu.org is the private key for that specific key pair). Gerald
Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?
Andi Kleen writes: > Jim writes: > >> After upgrading my Dell laptop, both OS+kernel the i8k interface was giving >> nonsensical output. As it turned out it's not the kernel but compiler >> upgrade which broke this. >> >> Guys at Archlinux have found the underlying cause (but don't seem to have >> submitted a patch yet): >> https://bbs.archlinux.org/viewtopic.php?pid=780692#p780692 >> gcc seems to optimize the assembly statements away. >> >> And indeed, applying this patch makes the i8k interface work again, >> i.e. replacing the asm(..) construct by asm volatile(..) > > The compiler really should not optimize the asm away, because > it has both input and output arguments which are later used. > "asm volatile" normally just means "don't move significantly" The asm fails to mention that it modifies *regs. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: gcc 4.5.1 / as 2.20.51.0.11 miscompiling drivers/char/i8k.c ?
Andreas Schwab writes: > > The asm fails to mention that it modifies *regs. It has a memory clobber, that should be enough, no? Besides in any case it cannot be eliminated because it has valid non dead inputs and outputs. -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: I propose Ralf Wildenhues for build machinery maintainer
On Fri, 5 Nov 2010, Ian Lance Taylor wrote: > To the steering committee: I propose Ralf Wildenhues as a new maintainer > for the build machinery. I've relayed this proposal, thanks Ian. (Ralf, I assume you are fine with this or you would speak up. ;-) Gerald
integral overflow and integral conversions
Currently, the middle end seems to use the same rules for handling
constant overflow of integer arithmetic and conversion between integer
types: set TREE_OVERFLOW on the INTEGER_CST if the type is signed and
the value doesn't fit in the target type. But this doesn't seem to
match the C/C++ standards.
C99 says,
6.3.1.3 Signed and unsigned integers
1 When a value with integer type is converted to another integer type
other than _Bool, if the value can be represented by the new type, it is
unchanged.
2 Otherwise, if the new type is unsigned, the value is converted by
repeatedly adding or subtracting one more than the maximum value that
can be represented in the new type until the value is in the range of
the new type.49)
3 Otherwise, the new type is signed and the value cannot be represented
in it; either the result is implementation-defined or an
implementation-defined signal is raised.
6.5 Expressions
5 If an exceptional condition occurs during the evaluation of an
expression (that is, if the result is not mathematically defined or not
in the range of representable values for its type), the behavior is
undefined.
Note the difference. When converting an integer value to another
integer type that it doesn't fit into, the behavior is either
well-defined or implementation-defined. When arithmetic produces a
value that doesn't fit into the type in which the arithmetic is done,
the behavior is undefined even if the type is unsigned.
So we're setting TREE_OVERFLOW inappropriately for conversion to signed
integer types (though the front ends unset it again in cast context),
and, more problematically, failing to set it for unsigned arithmetic
overflow:
#include
enum E {
A = (unsigned char)-1,// OK
B = (signed char)UCHAR_MAX, // implementation-defined
C = INT_MAX+1,// undefined (C)/ill-formed (C++)
D = UINT_MAX+1// undefined (C)/ill-formed (C++)
};
Am I missing something?
This is more of a problem for C++, which says that arithmetic overflow
in a context that requires a constant expression is ill-formed; in C
it's merely undefined.
Jason
Re: integral overflow and integral conversions
Jason Merrill writes: > So we're setting TREE_OVERFLOW inappropriately for conversion to > signed integer types (though the front ends unset it again in cast > context), and, more problematically, failing to set it for unsigned > arithmetic overflow: C99 6.2.5 paragraph 9 says "A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type." In the C++0x draft I have, 3.9.1 paragraph 4 says "Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2**N where n is number of bits in the value representation of that particular size of integer." So I don't think unsigned arithmetic can overflow in C/C++. Not sure about your point about TREE_OVERFLOW. Ian
Re: integral overflow and integral conversions
On 11/07/2010 11:11 PM, Ian Lance Taylor wrote: C99 6.2.5 paragraph 9 says "A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type." In the C++0x draft I have, 3.9.1 paragraph 4 says "Unsigned integers, declared unsigned, shall obey the laws of arithmetic modulo 2**N where n is number of bits in the value representation of that particular size of integer." So I don't think unsigned arithmetic can overflow in C/C++. Ah, so I was missing something, thanks! Jason
Re: I propose Ralf Wildenhues for build machinery maintainer
Hello, * Gerald Pfeifer wrote on Mon, Nov 08, 2010 at 01:36:47AM CET: > On Fri, 5 Nov 2010, Ian Lance Taylor wrote: > > To the steering committee: I propose Ralf Wildenhues as a new maintainer > > for the build machinery. > > I've relayed this proposal, thanks Ian. (Ralf, I assume you are fine > with this or you would speak up. ;-) Yes. Thanks for the proposal, and the support from everyone, I feel honored! Cheers, Ralf
