--- 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'
--- 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 #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 conserv
--- 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
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
: 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
--- 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.
--- 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 aro
--- 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=21455&action=view)
compressed builtins.c.041t.fnsplit dump file
I believe that the splitting and inlining of gimple_call_n
--- 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
--- 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-04 19:25 ---
Fixed on ToT.
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|NEW
--- 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 #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 #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 #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 #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 th
--- 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|Re
--- 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 #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 rel
--- 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 #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=21152&action=view)
Test case that fails on ia64-hp-hpux11.23
This test case generates an ICE on ia64-hp-hpux11.23. No opti
s 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
--- 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=21151&action=view)
Test case that fails on ia64-hp-hpux11.23
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44813
--- 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
--- 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=21133&action=view)
Compressed decl.c.043t.inline_param3 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=21132&action=view)
Compressed decl.c.041t.fnsplit 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=21131&action=view)
Compressed decl.c.025t.einline2 file
--
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=21130&action=view)
Compressed decl.c.015t.inline_param1 file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
--- 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=21129&action=view)
Compressed preprocessed cp/decl.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44716
--- 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
--- 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 #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 wh
--- 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-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 #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 1
mmary: 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
--- 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
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
--- 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 = 0.0;
D.1749_4 = -0.0;
IMAGPART_EXPR = D.1749_4;
D.1760_12 = IMAGPART_EXPR ;
D.1762_14
--- 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
--- 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 #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-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 #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
--- 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 ca
--- 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-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 #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.
--- 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 c
--- 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&#
--- 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 #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 th
--- 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 plat
--
sje at cup dot hp dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |fortran
Ever
--- 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=20380&action=view)
Shorter version of pr41928.f90
Here is a cutdown version of the failing test. Note that in this version cos
--- 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 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 #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
on: 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
--- 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
--- 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 #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 con
--- 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 s
--- 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
--- 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 #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:
--- 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
--- 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
--- 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
--- 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 discussion
--- 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 pack
--- 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
--- 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.
--
s
--- 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
--- 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
--- 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
--- 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
--- 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
--- Comment #5 from sje at cup dot hp dot com 2010-02-02 17:18 ---
Here is a cutdown version of pex-unix.i that fails to compile with -O2 -g.
extern char **environ;
pex_unix_exec_child ()
{
int pid;
volatile int sleep_interval;
volatile int retries;
char **save_environ
--- 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
--- 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'
--- 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=19544&action=view)
ia64 patch (fixes int, not short or char)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42542
--- 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
--- 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
--- 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
--- 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
--- 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*'
--- 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
--- 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
--- 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
--- 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 tha
--- 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:
W
--- 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 |
--- 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
--- 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
--- 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
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
--- 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
--- 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
1 - 100 of 571 matches
Mail list logo
