[Bug middle-end/21111] IA-64 NaT consumption faults due to uninitialized register reads
--- Additional Comments From wilson at specifixinc dot com 2005-04-19
23:05 ---
Subject: Re: IA-64 NaT consumption faults due to uninitialized
register reads
pinskia at gcc dot gnu dot org wrote:
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-04-19
20:47 ---
To me, the target specific code should be the one to fix this problem up and
not the middle-end or at
least have a hook for it so you don't mess around with other targets getting
the speed up. Anyways
seems like someone thought it would be cool if they did this, oh well.
The change I am suggesting should not hurt performance, and I expect
that it would actually help performance in many cases.
Currently, the first assignment to a structure is a bitfield insert.
If we zero the structure before the first assignment, then combine will
give us a simple assignment instead, which will be faster than a
bitfield insert for most targets. This may also allow other assignments
to be combined in, giving further benefits. (There can be multiple
first assignments if there are multiple blocks where the structure
becomes live.)
I agree that the optimizations being performed by tree-ssa are useful
here, but one must not be confused by the big picture issues here into
ignoring the details. Emitting a bit-field insert when only a simple
assignment is needed is wrong. It may cause performance loss on many
targets, and it causes core dumps on IA-64.
Take a look at this example.
struct s { unsigned long i : 32; unsigned long j : 32;};
int i;
struct s
sub (void)
{
struct s foo;
foo.i = i;
return foo;
}
Compiling this for x86-64 on mainline, I get 10 instructions, which
perform two bit-field insertions. Compiling this with gcc-3.3, I get 7
instructions which perform one bit-field insertion.
I think the optimal code is two instructions, one to load i into the low
part of the return register, and one to return. The upper bits of the
structure are don't care bits, so we can set them to anything we want.
There is no need for any bitfield insertion here at all.
Mainline does even worse than gcc-3 here because in order to decompose
the structure it creates a fake j assignment, and then we end up
emitting bitfield insertion code for the fake j assignment, even though
this code is completely useless. Furthermore, the RTL optimizer is not
able to delete this fake j assignment, because it is a bitfield insert.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2
[Bug target/20717] [4.1 Regression] Many C++ testsuite failures on ia64-hpux
--- Additional Comments From wilson at specifixinc dot com 2005-04-05 19:44 --- Subject: Re: [4.1 Regression] Many C++ testsuite failures on ia64-hpux jh at suse dot cz wrote: This sounds like reason for the failure. What precisely is the behaviour of FDESC_ADDR? (ie should I behave same way as if I see ADDR_EXPR - assume that address of the function has been taken and thus it is neccesary?). On IA-64, the address of a function is a two-word function descriptor, one word is the function entry point, and one word is the function's gp value. FDESC_EXPR is used to represent this. FDESC_EXPR must be used in places where the difference matters, e.g. in initializers for vtables. According to the docs in tree.def, operand0 of FDESC_EXPR is always a function, so it should be possible to handle FDESC_EXPR exactly the same as ADDR_EXPR if you don't care about the difference. That is what the untested patch I added to the PR does. It seems to work for the testcase. There is also the question of whether there are other places that need the same fix. I haven't looked. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20717
[Bug target/16871] missing vector support
--- Additional Comments From wilson at specifixinc dot com 2005-03-30 22:49 --- Subject: Re: missing vector support steven at gcc dot gnu dot org wrote: --- Additional Comments From steven at gcc dot gnu dot org 2005-03-30 11:21 --- Is anyone going to work on these intrinsics? Is there a list somewhere of what intrinsics we are talking about here? See comment #1, which points at patch written by HJ, which needs some more work, and probably also a formal review. As far as I know, the intrinsics are only defined in the Intel compiler documentation. That is the list HJ is working from. As I understand it, there is an intrinsic defined for every IA-64 instruction. Thus any gcc extended asm can be converted into intrinsic calls. If you know the naming scheme, you can probably generate your own list from IA-64 architecture documentation. There was also two threads in the gcc list started by Jan Beulich here http://gcc.gnu.org/ml/gcc/2005-01/msg00204.html http://gcc.gnu.org/ml/gcc/2005-01/msg00276.html I don't think he was volunteering to do the work, but he did point out some issues that need to be considered, such as how vectors should be treated as arguments and parameters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16871
[Bug target/20094] gcc.dg/transparent-union-* fail on ia64-hpux
--- Additional Comments From wilson at specifixinc dot com 2005-02-21 23:11 --- Subject: Re: gcc.dg/transparent-union-* fail on ia64-hpux giovannibajo at libero dot it wrote: --- Additional Comments From giovannibajo at libero dot it 2005-02-20 13:03 --- Jim, these are transparent unions, I thought that they were passed using the convention of the first element in the union. Yes, they are. And yes, MEMBER_TYPE_FORCES_BLK is causing the problem. Look at handle_transparent_union_attribute, and note the mode checks it is performing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20094
[Bug target/20094] gcc.dg/transparent-union-* fail on ia64-hpux
--- Additional Comments From wilson at specifixinc dot com 2005-02-21 23:19 --- Subject: Re: gcc.dg/transparent-union-* fail on ia64-hpux giovannibajo at libero dot it wrote: --- Additional Comments From giovannibajo at libero dot it 2005-02-20 13:03 --- Jim, these are transparent unions, I thought that they were passed using the convention of the first element in the union. By the way, I probably wasn't clear about this, but I haven't made any attempt to debug or analyze the problem. I'm just trying to point people at the cause of the first error, which was obvious to me just from reading the bug report. And that is MEMBER_TYPE_FORCES_BLK. There may also be other problems here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20094
[Bug target/20094] gcc.dg/transparent-union-* fail on ia64-hpux
--- Additional Comments From wilson at specifixinc dot com 2005-02-19 23:15 --- Subject: Re: gcc.dg/transparent-union-* fail on ia64-hpux pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-19 21:24 --- Hmm, Does anyone know how these union are supposed to be passed on ia64-*-hpux, if by referrence then the warning is correct and the testcase should not be tested on this target. This is an ABI Issue. unions get passed right-aligned little-endian and left-aligned big-endian. Since linux is little-endian, and HPUX is big-endian, only HPUX has a problem here. HPUX defines MEMBER_TYPE_FORCES_BLK to make this work. There are other ways to solve this problem used by other targets, for instance, defining BLOCK_REG_PADDING for HPUX. Getting BLOCK_REG_PADDING to work can be tricky though. It looks like the ia64/hpux.h is the only one that defines MEMBER_TYPE_FORCES_BLK that can trigger this problem, since the others don't trigger on pointer or integer types. It appears that MEMBER_TYPE_FORCES_BLK should not be used for a transparent union, or should be used differently. This check could perhaps be done unconditionally in stor-layout.c. This might be a simple solution. Or maybe we can pass the union/structure type to MEMBER_TYPE_FORCES_BLK and modify the ia64/hpux.h version of the macro to check for the transparent_union attribute. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20094
[Bug target/20045] gcc.dg/ia64-fptr-1.c fails on ia64-hpux
--- Additional Comments From wilson at specifixinc dot com 2005-02-19 23:31 --- Subject: Re: New: gcc.dg/ia64-fptr-1.c fails on ia64-hpux jsm28 at gcc dot gnu dot org wrote: ld: Unsatisfied symbol _GLOBAL_OFFSET_TABLE_ in file /var/tmp//ccU3vrUt.o DT_PLTGOT will hold the gp value if the program was dynamically linked, but it might be too inconvenient to get to this value. I am not sure how to get it other than by running objdump and grepping the output. Otherwise, I don't believe the ABI provides a way to get at the value. Another solution is to use an asm to grab the value from r1. This should work fine as the functions are in the same module, and hence will use the same gp value. Or we could just make this a linux specific testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20045
[Bug c++/10611] operations on vector mode not recognized in C++
--- Additional Comments From wilson at specifixinc dot com 2005-01-13 22:36 --- Subject: Re: operations on vector mode not recognized in C++ On Wed, 2005-01-12 at 01:44, rguenth at tat dot physik dot uni-tuebingen dot de wrote: --- Additional Comments From rguenth at tat dot physik dot uni-tuebingen dot de 2005-01-12 09:44 --- What is the status on this issue? It is waiting for someone who works on the C++ FE to look at it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10611
[Bug target/18987] [3.3/3.4/4.0 regression] [ia64] Extra '.restore sp' in tail call
--- Additional Comments From wilson at specifixinc dot com 2005-01-11 04:06 --- Subject: Re: [3.3/3.4/4.0 regression] [ia64] Extra '.restore sp' in tail call On Fri, 2005-01-07 at 20:47, gdr at integrable-solutions dot net wrote: I must have missed that patch then. On second thought, I think I forgot to ask about it. The patches aren't in gcc-3.4 yet, but I just asked Mark for permission, and if he OKs it I will add to both gcc-3.4 and gcc-3.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987
[Bug target/18987] [3.3/3.4/4.0 regression] [ia64] Extra '.restore sp' in tail call
--- Additional Comments From wilson at specifixinc dot com 2005-01-08 03:51 --- Subject: Re: [4.0 regression] [ia64] Extra '.restore sp' in tail call On Wed, 2004-12-22 at 14:47, debian-gcc at lists dot debian dot org wrote: --- Additional Comments From debian-gcc at lists dot debian dot org 2004-12-22 22:47 --- according to http://bugs.debian.org/286840 (if that's the same thing), this is broken in gcc-3.3 CVS and gcc-3.4 CVS as well. Latest known working version is gcc-3.3.5. The patch in question is PR 13158. I added it to mainline, but did not add it to gcc-3.4 CVS because technically it is not a regression, and hence the rules do not seem to permit me to add it there without special permission. For gcc-3.3 CVS, I need the branch maintainer's permission, and I did not get it, though I did not try very hard, so it isn't on the gcc-3.3 CVS branch either. Red Hat did add it to gcc-3_4-rhl-branch. Someone probably added it to the debian gcc sources as a patch on top of the FSF tree, so for gcc-3.3 and gcc-3.4 this will have to be fixed on the debian side by adding the patch in this PR also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18987
[Bug libstdc++/16371] [3.4/4.0 Regression] libstdc++ fails for crosses
--- Additional Comments From wilson at specifixinc dot com 2004-11-11 00:40 --- Subject: Re: [3.4/4.0 Regression] libstdc++ fails for crosses On Wed, 2004-11-10 at 13:11, mg_gentoo at yahoo dot com wrote: --- Additional Comments From mg_gentoo at yahoo dot com 2004-11-10 21:11 --- Jim, you expressed an interest in this bug a while back Maybe on the gcc list? I don't recall this PR, and don't see any comments from me in the the PR. I think the key detail here is that you have to have a target C library before you can build a target libstdc++. Of course, if you are bootstrapping a build environment, then you need the target gcc before you can build the target C library. This gets tricky when glibc is involved. You need to first install the glibc headers so you can build libgcc. Then you do a partial gcc build. You build only the compiler and libgcc without the libraries like libstdc++. Then you use gcc to build a provisional glibc. Then you can build a full gcc including libstdc++. Then you build a full glibc. Then See Dan Kegel's crosstool that automatically does this for you. http://kegel.com/crosstool/ If you don't want to go through all of the trouble of bootstrapping an entire build environment, there is a much simpler way to do this. Use a sys-root. The sys-root must include header files and libraries for the target. Gcc will then be able to find them, and link tests will work, and libstdc++ will configure OK. If libstdc++ won't configure, then something is missing from your sys-root. There is another way to solve this problem which is to hand-code in answers to all of the questions that the libstdc++ configure script asks. This is what crossconfig.m4 tries to do. However, I doubt that this is kept up to date. Every time the configure script changes, the answers in crossconfig.m4 need to change to keep up to date. For most targets, no one bothers to do that, and hence this is likely always out of date. Since there are other better ways to get a cross compiler built, this is probably not worth the trouble. One of the problems with providing hand-coded answers is that the answers can be wrong if someone has a system with non-standard packages on it. So this is usually a solution of last resort. It may be worthwhile for some targets though. Note that we use this same trick in libiberty, but there we don't have a choice because libiberty has to be buildable without a C library. This is must simpler to do though, as there are fewer questions asked by the libiberty configure script, and the list of questions rarely changes, and the answers to those questions also rarely change. I would guess that the gentoo configure problem is because the host OS does not have a multilibbed C library. If the x86_64 gentoo system does not have both the 32-bit and 64-bit C libraries in /lib, then one of the multilibbed libstdc++ builds will fail to link, and you end up with the same cross-compiler problem. This has to be fixed as above, e.g. you must provide a multilibbed glibc before you can do a multilibbed gcc build, or else you have to build gcc/glibc together as per Dan Kegel's crosstool. Incidentally, the error message referring to GCC_NO_EXECUTABLES is a misnomer. This gets printed if gcc_no_link is true, and GCC_NO_EXECUTABLES does set gcc_no_link. However, gcc_no_link also gets set by AC_PROG_CC which is the standard autoconf test for determining whether the C compiler works. If autoconf determines that the C compiler can not link, then it sets gcc_no_link. This explains why a native build can see this cross-compiler problem. AC_PROG_CC fails to link if there is something missing from your compiler environment, which as I explained above, is most likely a missing C library. I am not convinced that there is any bug here. I think the only problem is people not understanding how to do cross compiler builds, which can be much more complicated than native builds. My company has recently done cross compiler builds for linux from gcc-3.4 and we didn't have any problem. Many inexperienced gcc developers have been able to build linux cross compilers by using Dan Kegel's scripts. Hence I don't believe there is any real bug here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371
[Bug target/18010] bad unwind info due to multiple returns (missing epilogue)
--- Additional Comments From wilson at specifixinc dot com 2004-10-19 01:07 --- Subject: Re: New: bad unwind info due to multiple returns (missing epilogue) On Fri, 2004-10-15 at 04:14, davidm at hpl dot hp dot com wrote: To fix this bug, GCC should be emitting a .restore sp directive in front of every instruction which pops the stack-pointer. I'm still sick, four weeks and counting, but this looks like a pretty easy one. We just need to copy RTX_FRAME_RELATED_P when we copy instructions. The following patch gives the right result for the testcase. I have as yet done no other testing of the patch. --- Additional Comments From wilson at specifixinc dot com 2004-10-19 01:07 --- Created an attachment (id=7373) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7373action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18010
