[trans-mem] _ITM_abortTransaction not considered as noreturn function
Dear Richard,
When I was looking at this problem of tail call optimization, I have
found that _ITM_abortTransaction was not considered as a 'noreturn'
function. Do you have any reason not doing this? If not, I propose to
add ECF_NORETURN in calls.c:special_function_p().
Also I just want to point out that BUILT_IN_TM_START is missing in this
switch/case but I think I figure out why it is ok to not have it (except
in the case of nested transactions).
Thanks in advance for your time,
Patrick Marlier.
Index: calls.c
===
--- calls.c (revision 170149)
+++ calls.c (working copy)
@@ -473,9 +473,10 @@
{
switch (DECL_FUNCTION_CODE (fndecl))
{
+ case BUILT_IN_TM_ABORT:
+ flags |= ECF_NORETURN;
case BUILT_IN_TM_COMMIT:
case BUILT_IN_TM_COMMIT_EH:
- case BUILT_IN_TM_ABORT:
case BUILT_IN_TM_IRREVOCABLE:
case BUILT_IN_TM_GETTMCLONE_IRR:
case BUILT_IN_TM_MEMCPY:
Hello world from x32 glibc
On Sat, Feb 12, 2011 at 11:41 AM, H.J. Lu wrote:
> Hi,
>
> We made lots of progresses on x32 pABI:
>
> https://sites.google.com/site/x32abi/
>
> 1. Kernel interface with syscall is close to be finalized.
> 2. GCC x32 branch is stabilizing.
> 3. The Bionic C library works with the syscall kernel interface.
>
> The next major milestone will be x32 glibc port.
>
[hjl@gnu-6 gcc]$ cat x.c
#include
int
main ()
{
printf ("hello world\n");
return 0;
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -mx32 -O x.c
[hjl@gnu-6 gcc]$ ./a.out
hello world
[hjl@gnu-6 gcc]$ readelf -h a.out
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI:UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x4002b0
Start of program headers: 52 (bytes into file)
Start of section headers: 3684 (bytes into file)
Flags: 0x0
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 8
Size of section headers: 40 (bytes)
Number of section headers: 36
Section header string table index: 33
[hjl@gnu-6 gcc]$ /lib32/ld-linux-x32.so.2 --list ./a.out
linux-gate.so.1 => (0x0012e000)
libc.so.6 => /lib32/libc.so.6 (0xf7c74000)
/lib32/ld-linux-x32.so.2 (0x0011)
[hjl@gnu-6 gcc]$
--
H.J.
Re: [trans-mem] _ITM_abortTransaction not considered as noreturn function
On 02/15/2011 12:35 AM, Patrick Marlier wrote: > When I was looking at this problem of tail call optimization, I have > found that _ITM_abortTransaction was not considered as a 'noreturn' > function. Do you have any reason not doing this? If not, I propose to > add ECF_NORETURN in calls.c:special_function_p(). DEF_TM_BUILTIN (BUILT_IN_TM_ABORT, "_ITM_abortTransaction", BT_FN_INT, ATTR_TM_NORETURN_NOTHROW_LIST) It's already marked noreturn. The big switch in special_function_p is only there to add ECF_TM_OPS, for which we do not have an attribute. Do you have a test case for the lack of noreturn? A trivial test here says that it's present: # BLOCK 6 freq:2 # PRED: 5 [0.0%] (true,exec) Invalid sum of outgoing probabilities 0.0% __builtin__ITM_abortTransaction (1); # SUCC: 3 (ab,abcall) Notice there's no fallthru edge. r~
Re: RFC: A new MIPS64 ABI
On Mon, 14 Feb 2011, Joe Buck wrote: > On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote: > > It seems that this proposal would benefit programs that need more than 2 GB > > but less than 4 GB, and for some reason really don't want 64 bit pointers. > > > > This seems like a microscopically small market segment. I can't see any > > sense in such an effort. > > I remember the RHEL hugemem patch being a big deal for lots of their > customers, so a process could address the full 4GB instead of only 3GB > on a 32-bit machine. If I recall correctly, upstream didn't want it > (get a 64-bit machine!) but lots of paying customers clamored for it. > > (I personally don't have an opinion on whether it's worth bothering with). As I've been warning recently in the context of the "operator new[]" overflow checks discussion, even if your process is addressing 4GB in such circumstances it can't safely use single objects of 2GB or more and it's a security problem when malloc/calloc/etc. allow such objects to be created. See PR 45779. (There could well be issues with pointer comparisons as well as pointer differences, although there at least it's possible to be consistent if you don't allow objects to wrap around both in the middle and at the end of the address space.) -- Joseph S. Myers jos...@codesourcery.com
Re: RFC: A new MIPS64 ABI
On 02/14/2011 07:00 PM, Matt Thomas wrote: On Feb 14, 2011, at 6:50 PM, David Daney wrote: On 02/14/2011 06:33 PM, Matt Thomas wrote: On Feb 14, 2011, at 6:22 PM, David Daney wrote: On 02/14/2011 04:15 PM, Matt Thomas wrote: I have to wonder if it's worth the effort. The primary problem I see is that this new ABI requires a 64bit kernel since faults through the upper 2G will go through the XTLB miss exception vector. Yes, that is correct. It is a 64-bit ABI, and like the existing n32 ABI requires a 64-bit kernel. N32 doesn't require a LP64 kernel, just a 64-bit register aware kernel. Your N32-big does require a LP64 kernel. But using 'official' kernel sources the only way to get a 64-bit register aware kernel is for it to also be LP64. So effectively, you do in fact need a 64-bit kernel to run n32 userspace code. Not all the world is Linux. :) NetBSD supports N32 kernels. Use of LP32 in the kernel is only really appropiate in systems with a small amount of memory. The proposed n32-big would run on such systems, but would probably *not* have an advantage over standard n32. My proposed ABI would need trivial kernel changes: o Fix a couple of places where pointers are sign extended instead of zero extended. I think you'll find there are more of these than you'd expect. You could be right, but to date in auditing the Linux kernel, sigaction() is the only place I have found. o Change the stack address and address ranges returned by mmap(). My biggest concern is that many many mips opcodes expect properly sign-extended value for registers. Thusly N32-big will require using daddu/dadd/dsub/dsubu for addresses. So that's yet another departure from N32 which can use addu/add/sub/subu. That's right. Which is why I said... The main work would be in the compiler toolchain and runtime libraries. You'd also need to update gas for la and dla expansion. I am counting gas, ld and libc as part of the 'compiler toolchain' David Daney
Re: Target deprecations for 4.6
On Mon, 14 Feb 2011, Douglas B Rupp wrote: > Joseph S. Myers wrote: > > > * Interix (i[34567]86-*-interix3*) (see PR 47096). > > I would appreciate it if you could leave Interix. I'll take the responsibility > to get it working. The deprecation patch has gone in. That means that your patch to get it working should include the undeprecation patch to config.gcc (as well as the associated changes to the 4.6 release notes); there's no point undeprecating before then since the target doesn't actually build at all. Hopefully the SC can consider you as a potential Interix target maintainer based on your message. If your patch isn't in by the time 4.6 branches but is expected soon afterwards we can always leave the target present but deprecated in trunk when the other deprecated targets are removed. Getting it working means not just making it possible to build a cross compiler to Interix target but getting it to build cleanly with -Werror: either making native bootstrap work, or making building a cross compiler with --enable-werror-always work, starting from a native build of current trunk as the native compiler used to build the cross compiler. There are four different target configuration headers used for Interix (i386/i386-interix.h i386/i386-interix3.h interix.h interix3.h). Since there's only one Interix target present in GCC, the abstraction implied by four headers - some of which override macros defined in each other, meaning some macro definitions are effectively dead - is rather bogus. I advise combining these four headers into one so that it is more readily possible to see what target configuration actually ends up being in effect for this target. -- Joseph S. Myers jos...@codesourcery.com
Re: RFC: A new MIPS64 ABI
On Feb 15, 2011, at 12:41 PM, David Daney wrote: > ... >> >>> The main work would be in the compiler toolchain and runtime libraries. >> >> You'd also need to update gas for la and dla expansion. >> > > I am counting gas, ld and libc as part of the 'compiler toolchain' Don't forget GDB. paul
Re: RFC: A new MIPS64 ABI
On Feb 14, 2011, David Daney wrote: > Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of > user virtual memory space. This is due the way MIPS32 memory space is > segmented. Only the range from 0..2^31-1 is available. Pointer > values are always sign extended. > The proposed new ABI would only be available on MIPS64 platforms. It > would be identical to the current MIPS n32 ABI *except* that pointers > would be zero-extended rather than sign-extended when resident in > registers. FTR, I don't really know why my Yeeloong is limited to 31-bit addresses, and I kind of hoped an n32 userland would improve that WRT o32, without wasting memory with longer pointers like n64 would. So, sorry if this is a dumb question, but wouldn't it be much easier to keep on using sign-extended addresses, and just make sure the kernel never allocates a virtual memory range that crosses a sign-bit change, or whatever other reason there is for addresses to be limited to the positive 2GB range in n32? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: RFC: A new MIPS64 ABI
On 02/15/2011 09:56 AM, Alexandre Oliva wrote: On Feb 14, 2011, David Daney wrote: Current MIPS 32-bit ABIs (both o32 and n32) are restricted to 2GB of user virtual memory space. This is due the way MIPS32 memory space is segmented. Only the range from 0..2^31-1 is available. Pointer values are always sign extended. The proposed new ABI would only be available on MIPS64 platforms. It would be identical to the current MIPS n32 ABI *except* that pointers would be zero-extended rather than sign-extended when resident in registers. FTR, I don't really know why my Yeeloong is limited to 31-bit addresses, and I kind of hoped an n32 userland would improve that WRT o32, without wasting memory with longer pointers like n64 would. So, sorry if this is a dumb question, but wouldn't it be much easier to keep on using sign-extended addresses, and just make sure the kernel never allocates a virtual memory range that crosses a sign-bit change, or whatever other reason there is for addresses to be limited to the positive 2GB range in n32? No, it is not possible. The MIPS (and MIPS64) hardware architecture does not allow userspace access to addresses with the high bit (two bits for mips64) set. Your complaint is a good summary of why I am thinking about n32-big. David Daney
Re: RFC: A new MIPS64 ABI
On 02/15/2011 09:32 AM, Joseph S. Myers wrote: On Mon, 14 Feb 2011, Joe Buck wrote: On Mon, Feb 14, 2011 at 05:57:13PM -0800, Paul Koning wrote: It seems that this proposal would benefit programs that need more than 2 GB but less than 4 GB, and for some reason really don't want 64 bit pointers. This seems like a microscopically small market segment. I can't see any sense in such an effort. I remember the RHEL hugemem patch being a big deal for lots of their customers, so a process could address the full 4GB instead of only 3GB on a 32-bit machine. If I recall correctly, upstream didn't want it (get a 64-bit machine!) but lots of paying customers clamored for it. (I personally don't have an opinion on whether it's worth bothering with). As I've been warning recently in the context of the "operator new[]" overflow checks discussion, even if your process is addressing 4GB in such circumstances it can't safely use single objects of 2GB or more and it's a security problem when malloc/calloc/etc. allow such objects to be created. See PR 45779. (There could well be issues with pointer comparisons as well as pointer differences, although there at least it's possible to be consistent if you don't allow objects to wrap around both in the middle and at the end of the address space.) Thanks Joseph, My idea for n32-big is that there would never be wraparound issues in the middle. The address space is contiguous from 0 to 4GB. Typically the area around the 4GB limit would be occupied by the stack and perhaps a several other regions reserved by the OS (vdso, etc. ). At the ends there could be wraparound/truncation issues, but this is no different than with the ABIs of most 32-bit targets. I don't know how hard it would be to make ptrdiff_t a signed 64-bit type. That would certainly complicate things somewhat. David Daney
Re: Target deprecations for 4.6
Joseph S. Myers wrote: On Mon, 14 Feb 2011, Douglas B Rupp wrote: Joseph S. Myers wrote: * Interix (i[34567]86-*-interix3*) (see PR 47096). I would appreciate it if you could leave Interix. I'll take the responsibility to get it working. The deprecation patch has gone in. That means that your patch to get it working should include the undeprecation patch to config.gcc (as well as the associated changes to the 4.6 release notes); there's no point undeprecating before then since the target doesn't actually build at all. Hopefully the SC can consider you as a potential Interix target maintainer based on your message. If your patch isn't in by the time 4.6 branches but is expected soon afterwards we can always leave the target present but deprecated in trunk when the other deprecated targets are removed. I'll accept appointment as maintainer, if the SC so decides. Getting it working means not just making it possible to build a cross compiler to Interix target but getting it to build cleanly with -Werror: either making native bootstrap work, or making building a cross compiler with --enable-werror-always work, starting from a native build of current trunk as the native compiler used to build the cross compiler. Thanks for clearing up that procedure. The binutils bits have rotted badly, so it will take some work to get native bootstrap working again. I'll try the latter procedure. There are four different target configuration headers used for Interix (i386/i386-interix.h i386/i386-interix3.h interix.h interix3.h). Since there's only one Interix target present in GCC, the abstraction implied by four headers - some of which override macros defined in each other, meaning some macro definitions are effectively dead - is rather bogus. I advise combining these four headers into one so that it is more readily possible to see what target configuration actually ends up being in effect for this target. Agreed. Fyi the subsystem variants supported by MS are 32bit and 64bit x86 and 64bit ia64. I don't the see much point in putting work into an ia64 Interix compiler at this time. But maybe two headers for x86: 32 and 64bit, if it makes sense to have them split out.
Re: Target deprecations for 4.6
On Tue, 15 Feb 2011, Douglas B Rupp wrote: > > There are four different target configuration headers used for Interix > > (i386/i386-interix.h i386/i386-interix3.h interix.h interix3.h). Since > > there's only one Interix target present in GCC, the abstraction implied by > > four headers - some of which override macros defined in each other, meaning > > some macro definitions are effectively dead - is rather bogus. I advise > > combining these four headers into one so that it is more readily possible to > > see what target configuration actually ends up being in effect for this > > target. > > Agreed. Fyi the subsystem variants supported by MS are 32bit and 64bit x86 and > 64bit ia64. I don't the see much point in putting work into an ia64 Interix > compiler at this time. But maybe two headers for x86: 32 and 64bit, if it > makes sense to have them split out. I'd think that ideally you'd want one configuration that works with both -m32 and -m64 (so the only difference between i686-interix and x86_64-interix is which is the default), though I don't know how practical that is. Anyway, as long as only one Interix version is supported by GCC the distinction between "Interix" and "Interix 3" headers is meaningless. -- Joseph S. Myers jos...@codesourcery.com
Announcing two testsuite maintainers
I am happy to announce that the steering committee has appointed Rainer Orth and Mike Stump testsuite maintainers. This has been an area lacking maintainership for a while and the two of them volunteering is very much appreciated. As usual, please adjust the MAINTAINERS file accordingly, and Happy Hacking^WTesting guys! Gerald
gcc-4.4-20110215 is now available
Snapshot gcc-4.4-20110215 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110215/ 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/branches/gcc-4_4-branch revision 170200 You'll find: gcc-4.4-20110215.tar.bz2 Complete GCC (includes all of below) MD5=b73f56e27c3e14cbaddbd1c477aae398 SHA1=fdd4935a1ccca9df6a56eb39a0c72eb56ead46d1 gcc-core-4.4-20110215.tar.bz2C front end and core compiler MD5=678c68a313b8e5d3a7fbfce18158f47e SHA1=b8be3a4ac95f8f95c6d2d8890c29dbe443e720e2 gcc-ada-4.4-20110215.tar.bz2 Ada front end and runtime MD5=3cd9320d9d12ec1f42e9eccdae62b1c5 SHA1=5d01adace824e0e73677a6a0c891d243c058a1fe gcc-fortran-4.4-20110215.tar.bz2 Fortran front end and runtime MD5=9e0fc0f943701e637d490fb091be665f SHA1=7894cbe099cc1a83a3756e23ca5aaf373bbd76bb gcc-g++-4.4-20110215.tar.bz2 C++ front end and runtime MD5=3b4428af80780d4f1c1634ed8e3d2bad SHA1=fb20b9f5f91854f2361c6a3689aa8b976686078b gcc-go-4.4-20110215.tar.bz2 Go front end and runtime MD5=e647748772b43e68bd212360fe1d7616 SHA1=f9e040f3b07b3b5b93fc44fc10c2cda8abd07d88 gcc-java-4.4-20110215.tar.bz2Java front end and runtime MD5=66fcdfc891637a67495ff366421f3f0c SHA1=30dc4ecbdf4a71d5780a35634844fed18ab52bee gcc-objc-4.4-20110215.tar.bz2Objective-C front end and runtime MD5=ad0522c4e106e84cab5f4614268dc618 SHA1=d066886808eaf53e33d70fefb9c29fb2dc3488f9 gcc-testsuite-4.4-20110215.tar.bz2 The GCC testsuite MD5=00f0b4427627f1d917794048850399ad SHA1=2f02d4b8e5d3bb34b3eb1b25ec5946c2eac0bf68 Diffs from 4.4-20110208 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: Announcing two testsuite maintainers
On Feb 15, 2011, at 2:47 PM, Gerald Pfeifer wrote: > I am happy to announce that the steering committee has appointed > Rainer Orth and Mike Stump testsuite maintainers. Since I'm sure I can't figure out which patches are outstanding, could anyone waiting on testsuite approvals or reviews (or design direction requests, etc...) mail me a pointer, or ping them I know there should be at least two...
pr45055 on non-scheduling targets...
pr45055 tests a scheduling fix, but on targets that don't support scheduling (like m32c-elf), gcc emits a warning that scheduling is not supported. This warning causes the test to fail. How do we bypass these types of test cases? I don't see a suitable effective_target for scheduling. spawn -ignore SIGHUP /greed/dj/m32c/gcc/m32c-elf/gcc/xgcc -B/greed/dj/m32c/gcc/m32c-elf/gcc/ /greed/dj/m32c/gcc/gcc/gcc/testsuite/gcc.dg/pr45055.c -O2 -ftracer -fsched-pressure -funroll-loops -fschedule-insns -fcompare-debug -DSTACK_SIZE=4096 -DNO_TRAMPOLINES -S -msim -mcpu=m16c -o pr45055.s /greed/dj/m32c/gcc/gcc/gcc/testsuite/gcc.dg/pr45055.c:1:0: warning: instruction scheduling not supported on this target machine [enabled by default] FAIL: gcc.dg/pr45055.c (test for excess errors)
