--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
: 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |fortran
Ever
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
: 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
--- 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
: 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
: 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
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
--- 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
--- 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
501 - 566 of 566 matches
Mail list logo
