svn update: checksum's don't match
Getting this today on updates: %svn update stty: standard input: Invalid argument stty: standard input: Invalid argument svn: Checksum mismatch for '.svn/text-base/tree-vrp.c.svn-base'; expected: '284237c8119d7910c47b9bbee2161731', actual: '99646b12bbb393c78836b9c1097a6cf8' I tried a couple (distinct) check outs, all have this issue. What's up? This has happened before, looks like hardware/repo issues from: http://gcc.gnu.org/ml/gcc/2006-05/msg00488.html I'm using svn, version 1.4.4 (r25188) fc8 on x86 and x86_64 -benjamin
ABI compatibility regression: Return values on x86
gcc (x86) recently changed its behaviour when returning values shorter
than int. It used to sign extend, and now it doesn't.
short func2( short *size) { return *size; }
trunk:
func2:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
movzwl (%eax), %eax
popl%ebp
ret
gcc, all previous versions:
func2:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
movswl (%eax),%eax
leave
ret
This applies to both 32- and 64-bit gcc versions.
This ABI change was caused by
svn diff -r126479:126480 svn+ssh://gcc.gnu.org/svn/gcc/trunk
2007-07-09 Richard Guenther <[EMAIL PROTECTED]>
* c-decl.c (start_function): Do not promote return type.
Index: gcc/c-decl.c
===
--- gcc/c-decl.c(revision 126479)
+++ gcc/c-decl.c(revision 126480)
@@ -6270,18 +6270,6 @@
declare_parm_level ();
restype = TREE_TYPE (TREE_TYPE (current_function_decl));
- /* Promote the value to int before returning it. */
- if (c_promoting_integer_type_p (restype))
-{
- /* It retains unsignedness if not really getting wider. */
- if (TYPE_UNSIGNED (restype)
- && (TYPE_PRECISION (restype)
- == TYPE_PRECISION (integer_type_node)))
- restype = unsigned_type_node;
- else
- restype = integer_type_node;
-}
-
resdecl = build_decl (RESULT_DECL, NULL_TREE, restype);
DECL_ARTIFICIAL (resdecl) = 1;
DECL_IGNORED_P (resdecl) = 1;
This is generic code; I don't think there was any intention to change
the x86 ABI.
The 32-bit psABI says
"A function that returns an integral or pointer value places its
result in register %eax.
"[ ... ] Functions pass all integer-valued arguments as words,
expanding or padding signed or unsigned bytes and halfwords as
needed."
It is not explicit that return values are handled in the same way as
incoming args, but IMO it is reasonable to assume so. In any case,
we'd have to have a very good reason to change the ABI at this stage.
Ian Taylor pointed out that any change to this wouldn't be visible to
gcc-generated code, which is true. This is why, I suppose. no-one
noticed it, despite the fact that it's an ABI change. However, it may
well break other languages that link to gcc. It certainly caused
libffi test failures, which is how we noticed it.
So, what now? Can we even agree about what the psABI actually says
about sign-extending result values? Was what we did before correct,
or what we do now? I don't believe that it doesn't matter.
Andrew.
--
Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4
1TE, UK
Registered in England and Wales No. 3798903
Re: svn update: checksum's don't match
> What's up? Well, I just checked out the whole trunk again and everything is fine. So, probably some screw-up on my end. Sorry for the noise. -benjamin
Re: XML dump for GCC
Hello Brian, How does this compare to GCC-XML? http://www.gccxml.org/HTML/Index.html - Doug On Jan 4, 2008 10:42 AM, Brian M. Ames <[EMAIL PROTECTED]> wrote: > Hello, > > I have substantially completed an extension that would allow dumps to be > emitted as XML. I would like to contribute it to the FSF for inclusion in > the GCC distribution. Please let me know if there is interest in this. > > Thanks, > > Brian M. Ames > >
Re: ABI compatibility regression: Return values on x86
On Mon, Jan 07, 2008 at 06:32:08PM +, Andrew Haley wrote: > > So, what now? Can we even agree about what the psABI actually says > about sign-extending result values? Was what we did before correct, > or what we do now? I don't believe that it doesn't matter. You can follow up with this thread in ia32 psABI discussion group: http://groups.google.com/group/ia32-abi/browse_thread/thread/f47e0106b21d9269 H.J.
Re: __builtin_expect for indirect function calls
The frontends here would prefer to just implement __builtin_expect_call (fp,foo), and leave __builtin_expect as it is now. We don't see a need for a polymorphic __builtin_expect, as we are worried about backwards compatibility. A question was raised: Are side effects in the second parameter guaranteed to be executed? Is it valid for a compiler to ignore any side effects? Mark Mendell TOBEY Team Lead IBM Toronto Laboratory, 8200 Warden Ave, Markham, Ontario, Canada, L6G 1C7 Tel: 905-413-3485Tie: 313-3485Internet: [EMAIL PROTECTED] From: Mark Mitchell <[EMAIL PROTECTED]> To: Richard Guenther <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], Hans-Peter Nilsson <[EMAIL PROTECTED]>, gcc , [EMAIL PROTECTED], [EMAIL PROTECTED], Mark Mendell/Toronto/[EMAIL PROTECTED] Date: 06/01/2008 02:42 PM Subject:Re: __builtin_expect for indirect function calls Richard Guenther wrote: >> What do people think? Do we have the leeway to change this? Or should >> we add __builtin_expect2? Or add an -fno-polymorphic-builtin-expect? >> Or...? > > I think we should simply make __builtin_expect polymorphic, but make sure > to promote integral arguments with rank less than long to long. I thought of that, but I hadn't suggested this idea because it seemed so weird. Promoting to int would not be odd, but promoting to long is weird. Anyhow, you're right; that's another option, and, despite weirdness, plausible. I can't think of a way in which it changes current behavior, unless you call __builtin_expect with a long long, and that's probably not going to do what you expect right now anyhow. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
gcc-4.1-20080107 is now available
Snapshot gcc-4.1-20080107 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20080107/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 131387 You'll find: gcc-4.1-20080107.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20080107.tar.bz2 C front end and core compiler gcc-ada-4.1-20080107.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20080107.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20080107.tar.bz2 C++ front end and runtime gcc-java-4.1-20080107.tar.bz2 Java front end and runtime gcc-objc-4.1-20080107.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20080107.tar.bz2The GCC testsuite Diffs from 4.1-20071231 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 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.
