[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #17 from sje at cup dot hp dot com 2010-09-23 16:27 --- It looks like GCC on IA64 HP-UX has a problem when a routine in .text.unlikely calls a function in .text. If I define UNLIKELY_EXECUTED_TEXT_SECTION_NAME and HOT_TEXT_SECTION_NAME to just be '.text' then I can bootstrap with partial inlining enabled. I think the bug that is causing the abort is probably in the GNU assembler or the HP linker or some combination of the two. There is still a GCC bug here because the partial inlining change shouldn't have triggered the use of .text.unlikely. Particularly since it appears that it is the caller of the partially inlined function that is getting put into .text.unlikely, not the 'remainder' of the partially inlined function. On IA64 Linux, we do not appear to be using .text.unlikely, and that is probably why I see this bug on HP-UX but not Linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #16 from sje at cup dot hp dot com 2010-09-20 22:12 --- Honza, have you had a chance to look at this failure recently? It is still happening and I can only build GCC on ia64-hp-hpux11.23 using workarounds to stop some of the inlining. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug middle-end/43760] [4.6 regression] New test failures
--- Comment #7 from sje at cup dot hp dot com 2010-09-02 18:26 --- I wonder if we should attack this from a different angle. We have been trying to make the .pred.mutex.rel info more accurate to avoid this warning. If we can't do that I wonder if we should make GCC more conservative about doing two predicated writes in a single instruction group. This would make the code slower but it might be an infrequent enough occurance that it doesn't matter. Also, I currently see gfortran.dg/maxlocval_3.f90 failing with this message and when I look at the assembly code, there are two predicated writes that are using two consecutive pr registers (p12 and p13) but they are not set in a single cmp instructions. They are set seperately and I believe that both could be true which would mean that we are generating invalid code. I am going to test a patch that changes rws_access_regno to not allow two predicated register write in the same instruction group. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
[Bug bootstrap/44970] [4.6 regression] Revision 162270 failed to bootstrap
--- Comment #75 from sje at cup dot hp dot com 2010-08-23 20:49 --- Paolo, are you looking at this? The hppa64-*-* bootstrap is still broken. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44970
[Bug plugins/45346] New: hard-reg-set.h needs to be in the plugin include directory
I am trying to build a plugin that uses cgraph.h, which is in the plugin directory. But cgraph.h needs function.h and function.h needs hard-reg-set.h. hard-reg-set.h is not in the plugin include directory. The test case is to build a plugin where the plugin uses the header file cgraph.h or function.h. I believe this started failing at r159776 when Paul Brook added the include of hard-reg-set.h into function.h -- Summary: hard-reg-set.h needs to be in the plugin include directory Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45346
[Bug plugins/45348] New: cp/cp-tree.h in plugin header does not work.
If you include the header file cp/cp-tree.h in a plugin it will not compile because cp/cp-tree.h includes c-family/c-common.h which cannot be found. c-common.h is in the plugin directory but not under the c-family directory. It looks like the makefile tries to flatten the directory structure when putting headers in the plugin directory which is why c-common.h is in plugin/include and not plugin/include/c-family. I don't know if cp/cp-tree.h should be changed or if the Makefile should be changed. Test case ia a plugin that includes cp/cp-tree.h. -- Summary: cp/cp-tree.h in plugin header does not work. Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45348
[Bug testsuite/45266] [4.6 regression] FAIL: gfortran.dg/array_memcpy_3.f90
--- Comment #8 from sje at cup dot hp dot com 2010-08-16 17:11 ---
! { dg-final { scan-tree-dump-times memcpy|ref-all.*ref-all 2 original } }
worked for me on IA64 where we have 2 memcpys' in the output. Neither of my
suggestions from comment #7 worked. I don't know if this will work on a
platform
which generates the 'ref-all' strings instead of memcpy's. All my platforms;
IA64, PA, x86 seem to generate memcpy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45266
[Bug testsuite/45266] [4.6 regression] FAIL: gfortran.dg/array_memcpy_3.f90
--- Comment #7 from sje at cup dot hp dot com 2010-08-13 22:39 --- Does memcpy|(ref-all.*ref-all) need to be (memcpy|(ref-all.*ref-all)) or perhaps (memcpy|ref-all.*ref-all). Everyplace else I see a | in a scan statement there are parentheses around the options. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45266
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #12 from sje at cup dot hp dot com 2010-08-11 17:20 ---
I have a slightly smaller test case for this, but it still needs to bootstrap
to fail. If I bootstrap just the C part of the compiler I get a successful
build (with partial inlining enabled) but when I use that compiler to compile
this test case (with -O2) I get a segfault in the compiler:
char *s4;
test2_sub (int i, ...)
{
__builtin_va_list ap;
__builtin___vsprintf_chk (s4, 0, __builtin_object_size (s4, 0), %s %d, ap);
}
If I modify the gimple_rewrite_call_expr call in builtins.c and replace the
call to gimple_call_num_args with a new function that I don't inline (or that I
inline completely) the segfault goes away.
Looking at some of the dump files, builtins.c.041t.fnsplit shows
gimple_call_num_args getting split but I don't see any indication of inlining
in builtins.c.015/025/043. fnsplit creates gimple_call_num_args.part.22 and
changes gimple_call_num_args to call that routine the dump doesn't show
imple_rewrite_call_expr calling part.22 but later dumps do show this. I will
attach builtins.c.041t.fnsplit.
Any help on this bug would be appreciated, IA64 HP-UX has not bootstrapped with
ToT sources in some time now.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-08-11 17:20:41
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #13 from sje at cup dot hp dot com 2010-08-11 17:23 --- Created an attachment (id=21455) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21455action=view) compressed builtins.c.041t.fnsplit dump file I believe that the splitting and inlining of gimple_call_num_args into gimple_rewrite_call_expr is causing the failure but I do not know why. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug middle-end/41551] [4.4 Regression] ia64: ICE: in instantiate_virtual_regs_in_insn, at function.c:1630
--- Comment #8 from sje at cup dot hp dot com 2010-08-10 15:58 --- Backported to the 4.4 branch. -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41551
[Bug target/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c fails for signed zeros
--- Comment #12 from sje at cup dot hp dot com 2010-08-04 19:25 --- Fixed on ToT. -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583
[Bug fortran/45151] [4.6 regression] New Fortran failuires
--- Comment #14 from sje at cup dot hp dot com 2010-08-03 15:42 --- The assembler warning messages (shown in comment #13) that are causing the failure of gfortran.dg/maxlocval_3.f90 are due to PR 15445 and is not a new problem. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45151
[Bug target/45063] [4.6 Regression] ICE: Segmentation fault (cc1) compiling matmul_i1.c
--- Comment #16 from sje at cup dot hp dot com 2010-07-30 18:33 --- I just tried the patch in comment #15 and successfully bootstrapped GCC on my 32 bit PA system (including building matmul_i1.c). This was on ToT (r162716). -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45063
[Bug target/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c fails for signed zeros
--- Comment #10 from sje at cup dot hp dot com 2010-07-29 21:32 --- I have posted a patch for this bug to gcc-patches. http://gcc.gnu.org/ml/gcc-patches/2010-07/msg02302.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583
[Bug target/43941] Impossible to build any version beyond 4.2.4
--- Comment #6 from sje at cup dot hp dot com 2010-07-29 21:50 --- Because the ia64-hp-hpux11.31 compiler generates 32 bit code by default you cannot do a bootstrap build in 64 bit mode. From install.texi: Note that the bootstrap compiler and the resulting GCC must be link compatible, else the bootstrap will fail with linker errors about incompatible object file formats. Since the resulting GCC generates 32 bit code and the bootstrap compiler you are using generates 64 bit code they are not link compatible. Note that you can build GCC in 32 bit mode and still use the resulting compiler to compile programs in 64 bit mode by using the -mlp64 option. -- sje at cup dot hp dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43941
[Bug target/45026] Empty function compiles to many loads and stores
--- Comment #1 from sje at cup dot hp dot com 2010-07-26 20:07 --- It doesn't result in any loads, just stores. This code is storing the first part of the structure argument which was passed (partially) in registers into memory. Obviously it doesn't need to do this since the argument isn't used. I think this is an unfortunate side-effect of passing a large structure as an argument. If the structure were smaller and fit entirely into registers you would see an empty function. Large structures are split on IA64 with the first part going into registers and the last part going into memory and it looks like GCC 'reconstructs' the structure in memory before determining if it is needed or not. Ideally, you should pass a pointer here instead of passing (and copying) the structure, but it would be nice if GCC realised the argument wasn't needed and didn't do the stores so this could be considered a missed optimization. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45026
[Bug middle-end/44878] [4.6 Regression] Build fails when compiling libstdc++
--- Comment #4 from sje at cup dot hp dot com 2010-07-22 22:29 --- Fixed, I can now bootstrap GCC *with partial inlining turned off*. Partial inlining still doesn't work on IA64 HP-UX, that problem is PR 44716. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44878
[Bug libgomp/45025] Memory ordering issues with libgomp critical sections and __sync
--- Comment #1 from sje at cup dot hp dot com 2010-07-21 22:39 --- I backported the patch for PR 42869 to the 4.4 branch to fix Itanium. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45025
[Bug middle-end/44878] [4.6 Regression] Build fails when compiling libstdc++
--- Comment #2 from sje at cup dot hp dot com 2010-07-09 16:10 ---
Here is a smaller test case:
class e
{
public:
e(void* __e);
e(const e);
};
void * v() { }
e foo() { return e(v()); }
It only fails on IA64 in 32 bit mode and the problem seems to be related to
the change in needs_to_live_in_memory. If I undo the one line change in that
function then the example will compile.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44878
[Bug middle-end/44813] [4.6 Regression] ipa-split causes ice in ptr_deref_may_alias_decl_p, at tree-ssa-alias.c:173
--- Comment #5 from sje at cup dot hp dot com 2010-07-08 20:39 --- The patch for this fix broke the ia64-hp-hpux11.23 build. I will attach a new test case, if I compile the test case with cc1plus I get an ICE. This is probably some issue with Pmode vs. ptr_mode. I do not need to build bootstrap to reproduce the problem and I do not need any options when compiling the test case. $ obj_gcc/gcc/cc1plus -quiet x.cc x.cc: In function 'std::__exception_ptr::exception_ptr std::current_exception()': x.cc:19:1: internal compiler error: in emit_move_insn, at expr.c:3397 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44813
[Bug middle-end/44813] [4.6 Regression] ipa-split causes ice in ptr_deref_may_alias_decl_p, at tree-ssa-alias.c:173
--- Comment #6 from sje at cup dot hp dot com 2010-07-08 20:40 --- Created an attachment (id=21151) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21151action=view) Test case that fails on ia64-hp-hpux11.23 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44813
[Bug c++/44878] New: Build fails when compiling libstdc++
The patch to PR 44813 broke the build on ia64-hp-hpux11.23. The patch went in at r161898. Attached is a test case which causes an ICE when compiled with GCC on ia64-hp-hpux11.23. No options are needed during the compile. The failure is: x.cc: In function 'std::__exception_ptr::exception_ptr std::current_exception()': x.cc:19:1: internal compiler error: in emit_move_insn, at expr.c:3397 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. In the debugger I see: (gdb) p mode $1 = DImode (gdb) p debug_rtx(x) (reg/f:DI 341 [ retval+-4 ]) $2 = void (gdb) p debug_rtx(y) (subreg/s/v:SI (reg/f:DI 341 [ retval+-4 ]) 4) so the problem is the mismatch in the modes. IA64 generates 32 bit pointers by default but they need to be extended to 64 bits before being dereferenced. -- Summary: Build fails when compiling libstdc++ Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com GCC build triplet: ia64-hp-hpux11.23 GCC host triplet: ia64-hp-hpux11.23 GCC target triplet: ia64-hp-hpux11.23 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44878
[Bug c++/44878] Build fails when compiling libstdc++
--- Comment #1 from sje at cup dot hp dot com 2010-07-08 21:53 --- Created an attachment (id=21152) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21152action=view) Test case that fails on ia64-hp-hpux11.23 This test case generates an ICE on ia64-hp-hpux11.23. No options are required during compile. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44878
[Bug middle-end/44813] [4.6 Regression] ipa-split causes ice in ptr_deref_may_alias_decl_p, at tree-ssa-alias.c:173
--- Comment #8 from sje at cup dot hp dot com 2010-07-08 21:53 --- I have created PR 44878 for the IA64 problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44813
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #3 from sje at cup dot hp dot com 2010-07-07 15:30 --- I haven't been able to come up with a test case other then bootstrapping. If I build a non-bootstrap compiler and run the testsuite I don't get any unexpected failures due to this problem. It is only when, during bootstrap, I run the cc1plus executable that was built by the stage1 cc1 that I get a failure. At that point trying to compile any C++ program with cc1plus results in cc1plus aborting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #4 from sje at cup dot hp dot com 2010-07-07 17:22 --- The problem seems to happen when compiling cp/decl.c. If I compile this file at -O1 instead of -O2 the resulting C++ compiler will work. I am trying to see if I can track it down to one function within cp/decl.c. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #5 from sje at cup dot hp dot com 2010-07-07 22:48 --- If I put __attribute__ ((noinline)) on check_class_member_definition_namespace in cp/decl.c, I don't see the bug. I don't see anything special about this function so I don't know why it is having problems being (partially) inlined when nothing else seems to cause problems. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #7 from sje at cup dot hp dot com 2010-07-07 23:43 --- Created an attachment (id=21129) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21129action=view) Compressed preprocessed cp/decl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #8 from sje at cup dot hp dot com 2010-07-07 23:44 --- Created an attachment (id=21130) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21130action=view) Compressed decl.c.015t.inline_param1 file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #9 from sje at cup dot hp dot com 2010-07-07 23:44 --- Created an attachment (id=21131) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21131action=view) Compressed decl.c.025t.einline2 file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #10 from sje at cup dot hp dot com 2010-07-07 23:45 --- Created an attachment (id=21132) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21132action=view) Compressed decl.c.041t.fnsplit file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug middle-end/44716] [4.6 Regression] Bootstrap fails with partial inlining (r161382)
--- Comment #11 from sje at cup dot hp dot com 2010-07-07 23:45 --- Created an attachment (id=21133) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21133action=view) Compressed decl.c.043t.inline_param3 file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug middle-end/44790] [4.6 Regression] Bootstrap fails after MEM-REF merge
--- Comment #3 from sje at cup dot hp dot com 2010-07-06 16:44 ---
The neccessary UNSPEC seems to be there if you trace the instructions back
far enough. I tried it on my test case and it worked. I am now testing the
patch on ToT to see if I can bootstrap. I also have to turn off partial
inlining to get bootstrap to work on ia64-hp-hpux11.23. I tweaked the patch
for ToT there are a bunch of changes to expr.c including setting base so the
patch I am currently testing with r161861 looks like this:
Index: expr.c
===
--- expr.c (revision 161861)
+++ expr.c (working copy)
@@ -8777,13 +8777,11 @@ expand_expr_real_1 (tree exp, rtx target
base = build2 (BIT_AND_EXPR, TREE_TYPE (base),
gimple_assign_rhs1 (def_stmt),
gimple_assign_rhs2 (def_stmt));
- op0 = expand_expr (base, NULL_RTX, address_mode, EXPAND_NORMAL);
if (!integer_zerop (TREE_OPERAND (exp, 1)))
- {
- rtx off;
- off = immed_double_int_const (mem_ref_offset (exp), address_mode);
- op0 = simplify_gen_binary (PLUS, address_mode, op0, off);
- }
+ base = build2 (POINTER_PLUS_EXPR, TREE_TYPE (base),
+base, double_int_to_tree (sizetype,
+ mem_ref_offset (exp)));
+ op0 = expand_expr (base, NULL_RTX, address_mode, EXPAND_SUM);
op0 = memory_address_addr_space (mode, op0, as);
temp = gen_rtx_MEM (mode, op0);
set_mem_attributes (temp, exp, 0);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44790
[Bug middle-end/44790] [4.6 Regression] Bootstrap fails after MEM-REF merge
--- Comment #4 from sje at cup dot hp dot com 2010-07-06 22:56 --- I successfully bootstrapped ToT (after setting flag_partial_inlining to 0 to work around pr44716) using the patch. Testing also looked good, there are some new failures but they are all either new tests that may have never worked on this platform or tests that are also failing on other platforms. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44790
[Bug middle-end/44790] New: Bootstrap fails after MEM-REF merge
GCC fails to bootstrap on ia64-hp-hpux11.23 after r161655. Building without
bootstrap and running the testsuite shows that tests are failing in 32 bit mode
but not 64 bit mode so the problem is probably ia64's unique method of
extending pointers in 32 bit mode Most of the failing tests involve va_args.
Here is a cutdown test that fails:
f (int n, ...)
{
long x;
int i;
__builtin_va_list ap;
__builtin_va_start(ap,n);
x = __builtin_va_arg(ap,long);
if (x != 123)
abort();
__builtin_va_end(ap);
}
main ()
{
f (3, (long) 123);
exit(0);
}
--
Summary: Bootstrap fails after MEM-REF merge
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC build triplet: ia64-hp-hpux11.23
GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44790
[Bug middle-end/44790] Bootstrap fails after MEM-REF merge
--- Comment #1 from sje at cup dot hp dot com 2010-07-02 19:49 --- This may be related to x + CST folding. The bug only happens at -O1 or above. I think I forgot to mention that in the original bug report. When I look at the expand dump and the comparision to 123 I see: (insn 17 16 18 3 x.c:8 (set (reg:DI 348) (zero_extend:DI (subreg/s/v:SI (reg/v/f:DI 339 [ ap+-4 ]) 4))) -1 (nil)) (insn 18 17 19 3 x.c:8 (set (reg/f:DI 347) (plus:DI (reg:DI 348) (const_int 4 [0x4]))) -1 (nil)) (insn 19 18 20 3 x.c:9 (set (reg:SI 349) (mem:SI (reg/f:DI 347) [0 MEM[(int *)ap_1 + 4B]+0 S4 A32])) -1 (nil)) (insn 20 19 21 3 x.c:9 (set (reg:BI 350) (eq:BI (reg:SI 349) (const_int 123 [0x7b]))) -1 (nil)) Instruction 17, where we set r348 to zero_extend of r339 looks wrong. We need to do a pointer extend here, I.e. (unspec 24) go generate an addp4. r349 is not a valid pointer after instruction 17 and this generates the fault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44790
[Bug middle-end/44716] New: Bootstrap fails with partial inlining (r161382)
The ia64-hp-hpux11.23 platform fails when building the C++ library during a bootstrap build with r161382. r161381 works. r161521, which has some bug fixes, still fails. The failure only occurs with bootstrap, the compiler faults when building the libstdc++ library. /proj/opensrc_nobackup/sje/reg3/build-ia64-hp-hpux11.23-trunk/obj_gcc/ia64-hp-hpux11.23/libstdc++-v3/include/bits/postypes.h:123:12: internal compiler error: Illegal instruction Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [ia64-hp-hpux11.23/bits/stdc++.h.gch/O2ggnu++0x.gch] Error Running under gdb didn't give me a complete backtrace but did show: #0 0x42c88b0:2 in cplus_expand_constant (cst=0x6432d880) at /proj/opensrc_nobackup/sje/reg3/src/trunk/gcc/cp/expr.c:70 I will try turning off partial inlining and see if that fixes the problem using the r161382 sources. This bug doesn't appear to be the same as PR44671 (fixed in r161521) or PR44687 (an ICE error in tree_nrv). -- Summary: Bootstrap fails with partial inlining (r161382) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sje at cup dot hp dot com GCC build triplet: ia64-hp-hpux11.23 GCC host triplet: ia64-hp-hpux11.23 GCC target triplet: ia64-hp-hpux11.23 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug middle-end/44716] Bootstrap fails with partial inlining (r161382)
--- Comment #1 from sje at cup dot hp dot com 2010-06-29 20:32 --- I have verified that the bootstrap works if I set flag_partial_inlining to 0. I also did a build with --disable-libstdcxx-pch to see if the build failed when I didn't build pre-compiled C++ headers and it does. It dies while compiling libstdc++-v3/libsupc++/array_type_info.cc with the same error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
[Bug testsuite/43283] ld: Unsatisfied symbol start in file c_lto_20091216-1_0.o
--- Comment #8 from sje at cup dot hp dot com 2010-06-25 16:10 --- Resolved with code change to test case. -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43283
[Bug middle-end/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c
--- Comment #3 from sje at cup dot hp dot com 2010-06-25 20:21 ---
I see this failure on ia64 linux and hp-ux. The interesting thing is that it
fails when compiled with C++ but not when compiled with C. Here is a smaller
test case that shows that the imaginary part of c1 is +0 in the good case
(compiled with C) and -0 in the bad case (compiled with C++). This only shows
up when not doing any optimization (-O0) because with optimization everything
seems to get correctly folded.
#ifdef __cplusplus
extern C {
#endif
extern void exit(int);
int printf(const char *format, ...);
#ifdef __cplusplus
}
#endif
int main (void) {
_Complex float a1, b1, c1;
a1 = 0.0f + 0.0if;
b1 = 0.0f - 0.0if;
c1 = a1 + b1;
if (__builtin_copysignf (1.0, __imag__ (a1)) != + 1.0) printf(one\n);
if (__builtin_copysignf (1.0, __imag__ (b1)) != - 1.0) printf(two\n);
if (__builtin_copysignf (1.0, __imag__ (c1)) != + 1.0) printf(three\n);
printf(%f\n,__imag__ (c1));
exit (0);
}
--
sje at cup dot hp dot com changed:
What|Removed |Added
CC||sje at cup dot hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583
[Bug middle-end/44583] [4.6 Regression] c-c++-common/torture/complex-sign-add.c
--- Comment #5 from sje at cup dot hp dot com 2010-06-25 22:47 --- I verified that this works in r160902 and fails in 160903. In 160902 I get this (partial) psuedo-code: IMAGPART_EXPR a1 = 0.0; D.1749_4 = -0.0; IMAGPART_EXPR b1 = D.1749_4; D.1760_12 = IMAGPART_EXPR a1; D.1762_14 = IMAGPART_EXPR b1; D.1764_16 = D.1760_12 + D.1762_14; IMAGPART_EXPR c1 = D.1764_16; D.1754_9 = IMAGPART_EXPR c1; D.1755_10 = (double) D.1754_9; printf (%f\n[0], D.1755_10); In 160903 I get: b1$imag_4 = -0.0; c1$imag_10 = b1$imag_4 + 0.0; D.1749_7 = c1$imag_10; D.1750_8 = (double) D.1749_7; printf (%f\n[0], D.1750_8); I am not sure if it is significant that in the first one I have: D.1764_16 = 0.0 + (- 0.0) and in the second one I have: c1$imag_10 = (- 0.0) + 0.0 I.e. the order of the -0.0 is different. Looking at the assembly code in 160902 I see (paraphrasing): fmov f8 = f0 fneg f6 = f0 fadd.s f6 = f8, f6 and in 160903 I see: fneg f6 = f0 fadd.s f6 = f6, f0 Changing the new code by hand to swap the arguments to fadd around does seem to fix things in the new code. But, oddly enough, if I swap the arguments around in the old (good) code it doesn't break, I am not sure why. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44583
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
--- Comment #13 from sje at cup dot hp dot com 2010-06-11 20:19 --- On hppa2.0w-hp-hpux11.11, I don't see the testsuite failure after 158397. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug debug/42648] [4.5/4.6 Regression] gcc.dg/guality/pr41353-1.c FAILs at -On, n 0
--- Comment #8 from sje at cup dot hp dot com 2010-06-10 19:27 --- I see pr41353-1.c failures with -O2 -flto and -O2 -fwhopr as well as with -O3. I also see other guality tests fail with non -O3 flags. See http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00991.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42648
[Bug target/43941] Impossible to build any version beyond 4.2.4
--- Comment #4 from sje at cup dot hp dot com 2010-05-05 20:54 --- I have reproduced this failure, and the problem seems to be in GMP. You mention that you set ABI to 64. I noticed that if I built GMP with the HP compiler ABI is set to 32 and then when I built GCC with that GMP it failed in the manner you show in your report. When I built GMP with GCC, ABI was set to 64 and the compiler I built with that GMP worked fine. You might want to try rebuilding GMP with GCC. Also, you mentioned that the HP Porting Center only has GCC 4.2.3, you can get newer pre-built GCC versions for HP-UX at http://www.hp.com/go/gcc (though these are all built in 32 bit mode). I was able to build GCC using HP C (in 32 bit mode) with no problems and no changes needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43941
[Bug target/43941] Impossible to build any version beyond 4.2.4
--- Comment #3 from sje at cup dot hp dot com 2010-04-30 22:55 --- I've built GCC on IA64 HP-UX 11.31, but never in 64 bit mode. I build in 32 bit mode (the default for GCC and HP C) and I haven't seen this problem. I'll try building in 64 bit mode to see if I can reproduce the problem but it may take a while since all the libraries in my BE (gmp, mpfr, etc) are in 32 bit mode and I'll need to create 64 bit ones. I haven't tried building GCC with the HP compiler in some time. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43941
[Bug debug/42648] [4.5/4.6 Regression] gcc.dg/guality/pr41353-1.c FAILs at -On, n 0
--- Comment #6 from sje at cup dot hp dot com 2010-04-21 16:27 --- This looks like what I see on ia64-debian-linux-gnu as well. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42648
[Bug middle-end/43760] [4.6 regression] New test failures
--- Comment #1 from sje at cup dot hp dot com 2010-04-19 21:30 --- /var/tmp//ccGMk41W.s: Assembler messages: /var/tmp//ccGMk41W.s:201: Warning: Use of 'mov' may violate WAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 18 /var/tmp//ccGMk41W.s:201: Warning: Only the first path encountering the conflict is reported /var/tmp//ccGMk41W.s:200: Warning: This is the location of the conflicting usage It looks like this is PR 36898. The warning is bogus in the sense that there is no real WAW dependency conflict but the assembler isn't able to figure that out on it's own without some help with better .pred.rel.mutex lines from the compiler. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-19 21:30:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
[Bug middle-end/43760] [4.6 regression] New test failures
--- Comment #3 from sje at cup dot hp dot com 2010-04-20 00:01 --- Any ideas on how to fix the compiler? The best idea I could come up with was to check each basic block to see if there are any conditional sets of predicate registers in it and add pred.rel.mutex lines for those registers. If we add pred.rel.mutex lines for all used predicate registers we wind up adding a lot of unneeded pred.rel.mutex statements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43760
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
--- Comment #8 from sje at cup dot hp dot com 2010-04-16 19:54 --- I think the problem is related to the fact that IRA is trying to figure out if the store of lx1 can be eliminated and lx1 may be uninitialized. The only place lx1 is set is in an if statement in a loop. If we don't execute the if statement then lx1 is never set and this may be what IRA is complaining about. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug middle-end/31490] Compile error section type conflict
--- Comment #17 from sje at cup dot hp dot com 2010-04-16 22:29 --- Is there any reason none of the patches created for this bug have been checked in? I still get a 'section type conflict' on IA64 with the test case from Comment #2. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31490
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
--- Comment #6 from sje at cup dot hp dot com 2010-04-15 17:10 --- I tried comparing the tree's between hppa2.0w-hp-hpux11.11, where I get the bug and ia64-hp-hpux11.23, where I do not see the bug and I didn't see any real differences in the trees, just differences in the names of generated variables (D.1056 vs. D.1077, etc). I used my cutdown test case, testcase.f90, which is the smallest test case I was able to create. The unnamed-unsigned variables I see are 32 bits and not 64 bits, but the odd thing that I see (on both pa and ia64) is: $ grep D.762 x*.f90.* x.f90.003t.original: unnamed-unsigned:32 D.762; x.f90.003t.original:D.762 = (unnamed-unsigned:32) size.6 * 8; The variable is given a value but never used. These 'unnamed-unsigned' variables seem to disappear during the copyrename1 phase. I think this value is the size of the array, in this case the size of ncoset. I guess the Fortran front-end generates it in case it is needed but in this case it is never needed and so gets optimized away. I don't know if it is related to the problem at all but I do wonder why it is 'unnamed-unsigned' and not given a real type name. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
--- Comment #7 from sje at cup dot hp dot com 2010-04-15 23:47 --- Since the failure requires -O1 as well as -fbounds-check I tried turning off various -O1 optimizations. I could turn off everything (and still get the bug) except if I use -fno-tree-dominator-opts or -fno-guess-branch-probability. If I use either of these flags the bug does not happen. I think something is happening related to the fact that _gfortran_runtime_error_at is marked as 'NORETURN' that is causing a bad optimization. It may be related to making registers as REG_DEAD but I haven't found a place where I think this marking is actually wrong yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug testsuite/43739] [4.5 Regression] FAIL: gcc.dg/pr43643.c (test for excess errors)
--- Comment #2 from sje at cup dot hp dot com 2010-04-14 16:49 --- Fixed by adding -static to link like other tests already do. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43739
[Bug testsuite/43283] ld: Unsatisfied symbol start in file c_lto_20091216-1_0.o
--- Comment #3 from sje at cup dot hp dot com 2010-04-14 16:59 --- Dave, do you have a patch for this? I see it on ia64 hpux too. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43283
[Bug testsuite/43283] ld: Unsatisfied symbol start in file c_lto_20091216-1_0.o
--- Comment #5 from sje at cup dot hp dot com 2010-04-14 19:34 --- I wonder if using asm (.globl start); asm (start: nop); Would work for everyone? I am going to try that on my nightly HP-UX and Linux runs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43283
[Bug middle-end/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
--- Comment #3 from sje at cup dot hp dot com 2010-04-14 21:56 --- Created an attachment (id=20380) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20380action=view) Shorter version of pr41928.f90 Here is a cutdown version of the failing test. Note that in this version coset is a function call instead of an array. If I make coset an array like in the original pr41928.f90, the test passes. Also if I make ax and ay integers the test passes. Since ax and ay are used as do loop variables if you don't compile with -w (like the test case does) then you get messages like these with this test case and with the original one. Warning: Deleted feature: Loop variable at (1) must be integer Warning: Deleted feature: End expression in DO loop at (1) must be integer If you modify the test (original or my cutdown version) to fix these warnings the failure goes away. I am not sure if a ICE in a testcase that uses deleted features is a bug or not but since I think the problem is that the fortran front-end is sending bad gimple to the middle end I am going to change this from a middle-end bug to a fortran bug. I have no idea why I only see this on hppa[12]*-hp-hpux11* and not on any other platforms. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug fortran/42169] [4.4/4.5/4.6 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
-- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|middle-end |fortran Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-04-14 21:56:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug libffi/40385] new testcases bought in by Revision 148285 fail on ia64
--- Comment #11 from sje at cup dot hp dot com 2010-04-14 22:29 --- I am going to close out this bug report since there are currently no failures on IA64, only expected failures for libffi.call/err_bad_abi.c and libffi.call/err_bad_typedef.c which are XFAIL'ed for all platforms. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40385
[Bug c/43633] New: sizeof returns wrong size for large long long values when using -std=c99
If I compile a program with -std=c99 and do a sizeof of a constant that is
larger then LONG_LONG_MAX but smaller then ULONG_LONG_MAX I get 16 instead of
8. For values larger then ULONG_LONG_MAX I get 8. I can reproduce this on x86
Linux and IA64 HP-UX (and probably other systems).Here is a test case that
should show the problem on any systems where LONG LONG is 8 bytes. Compiled
without -std=c99 all the prints will print '8', with '-std=c99' the middle two
prints will print out 16 instead of 8. Reproducable with ToT and going back to
at least 4.1.0.
#include stdio.h
main()
{
/* LONG_LONG_MAX */
printf(%ld\n, sizeof(9223372036854775807LL));
/* LONG_LONG_MAX + 1 */
printf(%ld\n, sizeof(9223372036854775808LL));
/* ULONG_LONG_MAX as a long long type */
printf(%ld\n, sizeof(18446744073709551615LL));
/* ULONG_LONG_MAX + 1 as a long long type */
printf(%ld\n, sizeof(18446744073709551616LL));
}
--
Summary: sizeof returns wrong size for large long long values
when using -std=c99
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43633
[Bug target/42040] [ia64] Inappropriate address spills
--- Comment #14 from sje at cup dot hp dot com 2010-03-24 21:34 --- Well it looks like the big SPEC slowdowns were a glitch. The generated code is only slightly different and when I tried to reproduce the results I saw a slight speed up in mcf instead of a slowdown. I still got an overall slowdown in SPEC, but it was only 0.25%. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42040
[Bug target/42040] [ia64] Inappropriate address spills
--- Comment #12 from sje at cup dot hp dot com 2010-03-22 20:48 --- Since the proposed patch to meant to address non-optimimal code generation I decided to try the patch with SPEC2006 and see if it helped the performance. On SPECint, I got a 3% slowdown, mostly due to 429.mcf slowing down a lot (20%). 471.omnetap also slowed down (7%) and nothing else changed much. With SPECfp, we got a 0.36% speedup, with 434.zeusmp (4.4%) and 459.GemsFTDT (3.39%) speeding up the most and no significant slowdowns. I will try to see what happened with 429.mcf and see why that slowed down so much. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42040
[Bug target/42040] [ia64] Inappropriate address spills
--- Comment #8 from sje at cup dot hp dot com 2010-03-17 22:09 ---
I tried the patch and didn't have any problem bootstrapping and I didn't see
any regressions. It also fixed my small test case, but when I went back and
tried some of the other tests from PR 28490 I still saw some of the bad gprel
usages. Here is a slightly more cutdown testcase from 28490 that still fails
with the patch applied and when compiling with -O2.
extern const char basesyntax[];
extern const char arisyntax[];
typedef struct __jmp_buf_tag { }
jmp_buf[1];
struct jmploc { jmp_buf loc; };
readtoken1 (int firstc, char const *syntax, char *eofmark, int striptabs)
{
int c = firstc;
for (;;)
{
switch (syntax[c])
{
case 1:
if (syntax == (basesyntax + 130))
goto endword;
syntax = (basesyntax + 130);
parsebackq_oldreturn:;
}
}
endword:
if (syntax == (arisyntax + 130)) {
struct jmploc jmploc;
if (_setjmp (jmploc.loc))
goto parsebackq_oldreturn;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42040
[Bug target/42040] [ia64] Inappropriate address spills
--- Comment #10 from sje at cup dot hp dot com 2010-03-17 23:47 --- Reading Richard's initial comment I thought the problem was that the code was (or could be) illegal because the relocation may be out of range and we shouldn't use the gprel relocation for any of these constant pool references. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42040
[Bug middle-end/43391] [4.5 Regression] make_decl_rtl failure for C++ on AIX and HPUX
--- Comment #1 from sje at cup dot hp dot com 2010-03-16 18:09 --- If I remove the assert and look at all the times this is triggered in my small test case they all seem to involve builtin typeinfos created by emit_support_tinfos. If you look at this routine there are some comments about forcing things to be comdat. I think this is be base of the problem. It may be that HPPA and AIX need to create a target specific library_rtti_comdat function but I haven't looked into that in detail yet to see if it will fix the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43391
[Bug middle-end/43391] [4.5 Regression] make_decl_rtl failure for C++ on AIX and HPUX
--- Comment #2 from sje at cup dot hp dot com 2010-03-16 21:23 --- Using: #define TARGET_CXX_LIBRARY_RTTI_COMDAT hook_bool_void_false like DARWIN has, doesn't completely fix the problem. I still get the same failure but now only with 2 typeinfo's instead of with all the typeinfos created by emit_support_tinfos. _ZTSN10__cxxabiv117__array_type_infoE typeinfo name for __cxxabiv1::__array_type_info _ZTIN10__cxxabiv117__array_type_infoE typeinfo for __cxxabiv1::__array_type_info I wonder if tinfo_base_init should be checking targetm.cxx.library_rtti_comdat when creating these typeinfo's (via create_pseudo_type_info). Lots of ramifications here that I don't understand. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43391
[Bug target/42869] GOMP_critical_start wrong on Itanium due to __sync miscompilation
--- Comment #6 from sje at cup dot hp dot com 2010-03-12 18:22 --- Fixed by moving the mf after the cmpxch.rel. The cmpxchg.rel will keep memory operations from moving down and the mf will keep them from moving up. Changing cmpxchg.rel to cmpxchg.acq would have achieved the same result. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42869
[Bug target/42040] [ia64] Inappropriate address spills
--- Comment #1 from sje at cup dot hp dot com 2010-03-12 19:22 ---
I once asked Jim Wilson about this but didn't get an answer. Here is a pointer
to that email. Also included here is a short example that generates the gprel
load.
My earlier example and question can be seen in:
http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00170.html
Short test case:
typedef struct table { int a; int b; int c; } table;
extern table mv_tables[2];
void foo()
{
init_mv_table(mv_tables[1]);
}
--
sje at cup dot hp dot com changed:
What|Removed |Added
CC||sje at cup dot hp dot com,
||wilson at codesourcery dot
||com
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-03-12 19:22:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42040
[Bug target/42869] GOMP_critical_start wrong on Itanium due to __sync miscompilation
--- Comment #2 from sje at cup dot hp dot com 2010-03-09 23:25 --- I think the code is wrong. Looking at ToT, config/ia64/sync.md will generate the code shown where the memory fence is in front of the cmpxchg4.rel instruction. cmpxchg4.rel has release semantics which are defined in the Itanium manual as: Release instructions guarentee that all previous orderable instructions are made visible prior to being made visible themselves. This would imply to me that the memory fence before the cmpxchg4.rel is not needed but we do need one after it in order to prevent things being moved up ahead of the cmpxchg4.rel. Alternatively, we could change to code to use cmpxchg4.acq instead of cmpxchg4.rel and keep the memory fence where it is. cmpxchg4.acq has acquire semantics instead of release semantics. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42869
[Bug target/42869] GOMP_critical_start wrong on Itanium due to __sync miscompilation
--- Comment #4 from sje at cup dot hp dot com 2010-03-09 23:49 --- Yes, I think this is clearly a bug in the IA64 definition of sync_compare_and_swap. I think the fix is swapping the two instructions being generated by the IA64 sync_compare_and_swap instruction. (cmpxchg4.rel followed by a memory fence instead of a memory fence followed by cmpxchg4.rel). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42869
[Bug middle-end/41250] hppa has DECL_VALUE_EXPR decls appearing in the function
--- Comment #4 from sje at cup dot hp dot com 2010-02-26 19:05 --- Was the patch from comment #3 ever sent to gcc-patches? I couldn't find it. I did see earlier discussions about some other patches but the patch in comment #3 seems to have been put here after those discussions. I tested it on my hppa2.0w-hp-hpux11.11 system and it fixed g++.dg/torture/pr34099.C and did not cause any regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41250
[Bug middle-end/42837] [4.5 Regression] FAIL: g++.dg/abi/packed1.C execution test
--- Comment #6 from sje at cup dot hp dot com 2010-02-17 18:03 --- I tried the test with GCC 4.4.0 and 4.3.3 on IA64, in those cases the test failed because we didn't actually pack anything and then the if test failed and we called abort. $ /opt/hp-gcc-4.3.3/bin/g++ -Wpacked packed1.C -o x;./x packed1.C:7: warning: packed attribute causes inefficient alignment for 'INNER' packed1.C:13: warning: ignoring packed attribute because of unpacked non-POD field 'INNER OUTER::inner' Abort(coredump) With the latest compiler on IA64, we try to pack the structure. This results in no warning messages but we then generate a Bus error, probably due to illegal alignment. So the test never worked but this still seems like a regression in behaviour. The HP compiler seems to handle this, it compiles and runs without calling abort. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42837
[Bug middle-end/42837] [4.5 Regression] FAIL: g++.dg/abi/packed1.C execution test
--- Comment #3 from sje at cup dot hp dot com 2010-02-16 18:48 --- I would guess this failure started with r156088 when the test was added. I think the test is OK but that ia64 can't handle packing OUTER when one of the fields in OUTER is a struct with a virtual function. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-16 18:48:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42837
[Bug middle-end/42837] [4.5 Regression] FAIL: g++.dg/abi/packed1.C execution test
--- Comment #4 from sje at cup dot hp dot com 2010-02-16 18:50 --- Forgot to mention that the test was added along with a fix for PR c++/41788. I don't think the fix or the test are bad though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42837
[Bug target/42924] [4.5 Regression] pex-unix.c:589:1: internal compiler error: output_operand
--- Comment #13 from sje at cup dot hp dot com 2010-02-05 18:23 --- Fixed with the definition of TARGET_DELEGITIMIZE_ADDRESS. -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42924
[Bug target/42924] [4.5 Regression] pex-unix.c:589:1: internal compiler error: output_operand
--- Comment #10 from sje at cup dot hp dot com 2010-02-03 19:31 --- return XVECEXP (XEXP (x, 1), 0, 0); The return is wrong. The UNSPEC_DLTIND14R operation returns the address of XVECEXP (XEXP (x, 1), 0, 0). Is it as simple as wrapping this in a MEM rtx? I am testing return gen_rtx_MEM (GET_MODE (x), XVECEXP (XEXP (x, 1), 0, 0)); So far, so good. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42924
[Bug target/42924] [4.5 Regression] pex-unix.c:589:1: internal compiler error: output_operand
--- Comment #6 from sje at cup dot hp dot com 2010-02-02 17:25 ---
Jakub Jelinek suggested this patch to pa.c which fixes the compilation failure
but causes bad code generation.
static rtx pa_delegitimize_address (rtx);
#undef TARGET_DELEGITIMIZE_ADDRESS
#define TARGET_DELEGITIMIZE_ADDRESS pa_delegitimize_address
static rtx
pa_delegitimize_address (rtx orig_x)
{
rtx x = delegitimize_mem_from_attrs (orig_x);
if (GET_CODE (x) == LO_SUM
GET_CODE (XEXP (x, 1)) == UNSPEC
XINT (XEXP (x, 1), 1) == UNSPEC_DLTIND14R)
return XVECEXP (XEXP (x, 1), 0, 0);
return x;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42924
[Bug target/42924] [4.5 Regression] pex-unix.c:589:1: internal compiler error: output_operand
--- Comment #7 from sje at cup dot hp dot com 2010-02-02 17:29 ---
If you apply the patch from comment #6 the following test case generates bad
code at -O1 or higher optimization. Instead of loading 0 to initialize v it is
loading the contents of memory location 0 to do the initialization.
f(int n) {
int i;
double v[n];
for(i=0;in;i++)
v[i]=0;
}
main() {
f(100);
exit(0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42924
[Bug target/42924] [4.5 Regression] pex-unix.c:589:1: internal compiler error: output_operand
--- Comment #8 from sje at cup dot hp dot com 2010-02-02 17:49 ---
Using test case from comment #7, I compared r156291 and r156292 (plus the patch
from comment #6). I compiled with -O1 and it looks like we go wrong during
common sub expression elimination.
r156291 has x.c.150r.cse1 with:
(insn 81 80 82 4 y.c:5 (set (reg:DI 156)
(plus:DI (reg:DI 27 %r27)
(high:DI (symbol_ref/u:DI (*L$C) [flags 0x2] 84
{*pa.md:2561} (nil))
(insn 82 81 83 4 y.c:5 (set (reg/f:DI 155)
(mem/u/c:DI (lo_sum:DI (reg:DI 156)
(unspec:DI [
(symbol_ref/u:DI (*L$C) [flags 0x2])
] 2)) [0 S8 A64])) 120 {*pa.md:4100} (expr_list:REG_EQUAL
(symbol_ref/u:DI (*L$C) [flags 0x2])
(nil)))
(insn 83 82 84 4 y.c:5 (set (reg:DF 157)
(mem/u/c/i:DF (reg/f:DI 155) [0 S8 A64])) 118 {*pa.md:3933} (nil))
Where as r156292 (plus patch) has:
(insn 81 80 82 4 y.c:5 (set (reg:DI 156)
(plus:DI (reg:DI 27 %r27)
(high:DI (symbol_ref/u:DI (*L$C) [flags 0x2] 84
{*pa.md:2561} (nil))
(insn 82 81 83 4 y.c:5 (set (reg/f:DI 155)
(const_int 0 [0x0])) 120 {*pa.md:4100} (expr_list:REG_EQUAL
(symbol_ref/u:DI (*L$C) [flags 0x2])
(nil)))
(insn 83 82 84 4 y.c:5 (set (reg:DF 157)
(mem/u/c/i:DF (reg/f:DI 155) [0 S8 A64])) 118 {*pa.md:3933} (nil))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42924
[Bug target/42542] Vectorizer produces incorrect results on max/min of unsigned intergers
--- Comment #21 from sje at cup dot hp dot com 2010-01-11 23:32 --- Created an attachment (id=19544) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19544action=view) ia64 patch (fixes int, not short or char) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
[Bug target/42542] Vectorizer produces incorrect results on max/min of unsigned intergers
--- Comment #22 from sje at cup dot hp dot com 2010-01-11 23:33 --- I am looking at this on IA64 and fixing it for V2SI seems simple enough. I will attach a patch. But I am not sure what to do for V4HI and V8QI. The current code uses an 'unsigned saturating subtraction' and that seems to be what x86 is using for V16QI and V8HI. But when I run pr42542-2.c and pr42542-3.c (short and char) on IA64 they fail. My patch does make pr42542-1.c (int) work. I tried handling V4HI and V8QI in the same way as V2SI but that didn't seem to work either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
[Bug target/42542] Vectorizer produces incorrect results on max/min of unsigned intergers
--- Comment #24 from sje at cup dot hp dot com 2010-01-12 00:58 --- Never mind, when I copied (and modified) the x86 tests for ia64 I forgot to put a 'return 0' at the end of the main program so I was getting a non-zero exit. I will test my patch tonight and if all looks good submit it tomorrow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
[Bug debug/41700] g++.dg/debug/dwarf2/icf.C
--- Comment #10 from sje at cup dot hp dot com 2009-12-02 17:20 --- This bug appears to be fixed on all my PA and IPF targets. Closing out as fixed. -- sje at cup dot hp dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41700
[Bug middle-end/41551] ia64: ICE: in instantiate_virtual_regs_in_insn, at function.c:1630
--- Comment #3 from sje at cup dot hp dot com 2009-11-30 22:10 --- Fixed in r154843, test case added in gcc.dg/pr41551.c. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41551
[Bug testsuite/42086] FAIL: gcc.target/ia64/fptr-1.c execution test
--- Comment #3 from sje at cup dot hp dot com 2009-11-30 22:41 --- Fixed. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42086
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #13 from sje at cup dot hp dot com 2009-11-23 15:43 --- I think you will need to create a fde-freebsd.c file in gcc/config/ia64 to define Unwind_FindTableEntry. See fde-glibc.c and fde-vms.c for examples. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #10 from sje at cup dot hp dot com 2009-11-20 16:59 --- Does freebsd use glibc? Does freebsd have a system libunwind? I am going to guess yes to the first question and no to the second in which case you need to edit gcc/config.gcc and modify the 'ia64*-*-freebsd*' entry to include the t-libunwind-elf and ia64/t-glibc-libunwind makefile fragments to the tm_file list. That is what 'ia64*-*-linux* does when 'with_system_libunwind' is set to no. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug target/40959] build fails - No rule to make target `/usr/ports/lang/gcc43/work/build/ia64-portbld-freebsd8.0/libgcc/crtfastmath.o', needed by `T_TARGET'. Stop.
--- Comment #7 from sje at cup dot hp dot com 2009-11-16 18:14 --- The patch worked for me after changing some leading spaces to tabs If you grabbed it with a cut-n-paste the patch may have had spaces in it instead of tabs (or perhaps it was put in the report that way). You can either change the spaces to tabs by hand and use patch or you could just apply the patch by hand, there is only one instance of ia64*freebsd in the libgcc/config.host file and all you need to do is add the two new lines to the file at that location. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40959
[Bug middle-end/40505] hppa: ICE: in expand_expr_addr_expr_1, at expr.c:6830
--- Comment #8 from sje at cup dot hp dot com 2009-11-02 19:29 --- Dave, did you get any comments on your proposed patch? I just got a bug report from a GCC user that appears to be this same problem. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40505
[Bug c/41567] Too small .bss stack
--- Comment #7 from sje at cup dot hp dot com 2009-10-30 20:15 --- I tried (and failed) to reproduce this using msmpeg4.i and compiling with: gcc -shared -pthread -std=c99 -fomit-frame-pointer -g -O3 -fno-math-errno -fno-signed-zeros -fPIC -fno-tree-vectorize msmpeg4.i -o x.so I tried ToT, 4.4 and 4.3 GCC compilers and was unable to reproduce the bug. I wonder if it only happens when linking in all the objects together. I also wonder what linker you were using, I was using the latest 2.20 linker. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41567
[Bug target/41279] [4.5 Regression] 252.eon performance regression
--- Comment #8 from sje at cup dot hp dot com 2009-10-30 20:42 --- It looks like a patch has been checked in to fix this bug, is there any reason we can't close this defect? -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41279
[Bug rtl-optimization/41171] register allocator undoing optimal schedule
--- Comment #7 from sje at cup dot hp dot com 2009-10-30 21:00 --- Has a patch to move update_equiv_regs into its own pass been submitted? I don't see one and IA64 is still producing the 'wrong' scheduling. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171
[Bug c/41567] Too small .bss stack
--- Comment #9 from sje at cup dot hp dot com 2009-10-30 21:34 --- I thought the report and log was clear enough on the fact that this is indeed a problem that only arises during the final link. If not, then now it is ;) I guess the point I was trying to make is that I don't think it is possible to reproduce this by just compiling and linking msmpeg4.i. I think it is necessary to have all the objects that are being linked into the final library in order to get the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41567
[Bug c/41567] Too small .bss stack
--- Comment #10 from sje at cup dot hp dot com 2009-10-30 21:54 --- I am not sure if this would help or not but it might be interesting to try the -mno-sdata flag on the compilation to see if that helps. By default GCC on IA64 will use .sbss (short bss) and .bss (normal bss) sections. -mno-sdata will turn off the use of .sbss. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41567
[Bug middle-end/37565] __optimize__ attribute doesn't work correctly
--- Comment #10 from sje at cup dot hp dot com 2009-10-29 17:03 --- The patch I checked in provides the infrastructure to fix this problem and I have fixed the IA64 instance of it but other targets (like x86) will need to define TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE as well to completely resolve this defect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
[Bug debug/41700] g++.dg/debug/dwarf2/icf.C
--- Comment #7 from sje at cup dot hp dot com 2009-10-23 18:52 --- I haven't had a chance to test it on PA yet but it fixes the problem on Itanium. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41700
[Bug debug/41801] New: VTA: ICE in loc_cmp.
The included test case is cut down from
libstdc++-v3/testsuite/29_atomics/atomic_flag/clear/1.cc and ICE's when
compiled with '-milp32 -O1 -g -std=gnu++0x' on IA64 HP-UX. It works in 64 bit
mode and it works with -O0. The ICE is:
x.C: In function 'int main()':
x.C:16:1: internal compiler error: in loc_cmp, at var-tracking.c:2461
The C++ test case is:
typedef enum memory_order {
memory_order_acquire,
memory_order_acq_rel,
memory_order_seq_cst } memory_order;
typedef struct __atomic_flag_base { bool _M_i; } __atomic_flag_base;
struct atomic_flag : public __atomic_flag_base {
atomic_flag(bool __i) : __atomic_flag_base({ __i }) { }
void clear(memory_order __m = memory_order_seq_cst) volatile {
__sync_lock_release(_M_i);
if (__m != memory_order_acquire __m != memory_order_acq_rel)
__sync
_synchronize();
}
};
int main() {
atomic_flag f = { false };
f.clear();
}
--
Summary: VTA: ICE in loc_cmp.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sje at cup dot hp dot com
GCC build triplet: ia46-hp-hpux11.23
GCC host triplet: ia64-hp-hpux11.23
GCC target triplet: ia64-hp-hpux11.23
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41801
[Bug rtl-optimization/41697] ICE on gcc.c-torture/compile/20090917-1.c
--- Comment #2 from sje at cup dot hp dot com 2009-10-15 21:53 --- Fixed with checkin. -- sje at cup dot hp dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41697
[Bug testsuite/41700] g++.dg/debug/dwarf2/icf.C
--- Comment #2 from sje at cup dot hp dot com 2009-10-14 21:03 --- I see failures for this test on IA64 HP-UX and Linux as well. FAIL: g++.dg/debug/dwarf2/icf.C scan-assembler 0x0.*Vtable slot FAIL: g++.dg/debug/dwarf2/icf.C scan-assembler 0x1.*Vtable slot FAIL: g++.dg/debug/dwarf2/icf.C scan-assembler \\.section.*.debug_vcall -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-14 21:03:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41700
[Bug middle-end/41394] [4.5 Regression] pr34668-2.c:5:15: error: type mismatch in array reference
--- Comment #2 from sje at cup dot hp dot com 2009-10-14 21:14 --- This looks like a duplicate of 41086. I see it on IA64 HP-UX and Linux as well. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41394
