--- Comment #1 from dje at google dot com 2007-11-09 00:57 ---
I looked into what's going on here.
This is a problem in the i386.md lshr+zext combiner patterns (or a problem in
the combine pass, depending on one's point of view). There are patterns in
i386.md that are s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71375
--- Comment #3 from David Edelsohn ---
Author: dje
Date: Mon Jun 20 02:25:50 2016
New Revision: 237587
URL: https://gcc.gnu.org/viewcvs?rev=237587&root=gcc&view=rev
Log:
PR target/71375
* config/rs6000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71375
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69810
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71816
--- Comment #6 from David Edelsohn ---
Bootstrap is proceeding with r238077.
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
Recent C++ front-end changes appear to have elicited new failures on AIX for
insert4_neg.cc in libstdc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71848
--- Comment #1 from David Edelsohn ---
Created attachment 38880
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38880&action=edit
insert4_neg.ii pre-processed source code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71848
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||2016-07-15
CC||dje at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #4 from David Edelsohn ---
New.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71614
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72855
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
The AIX assembler implicitly inserts the length information at the beginning of
DWARF debugging sections. In 64 bit mode, it also implicitly
|UNCONFIRMED |ASSIGNED
Last reconfirmed||2016-08-23
Assignee|unassigned at gcc dot gnu.org |dje at gcc dot gnu.org
Target Milestone|--- |5.5
Ever confirmed|0 |1
--- Comment #1 from David
Severity: normal
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
The patch causes bootstrap failure on AIX. Stage 1 GCC is miscompiled and
gencfn-macros fails with numerous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
David Edelsohn changed:
What|Removed |Added
Target||powerpc-ibm-aix*
Status|UNC
++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Depends on: 68703
Target Milestone: ---
Target: powerpc-ibm-aix*
vector32.C and vector32a.C fail on AIX
internal compiler error: in get, at cgraph.h:395
Referenced Bugs:
https
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77373
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Keywords: link-failure
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc*-*-*
The "Various GCOV/PGO improvement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378
--- Comment #3 from David Edelsohn ---
-ftree-profile and gcov don't link against libatomic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378
--- Comment #5 from David Edelsohn ---
Configure might work for multilib libgcov. It's mode dependent (-m32/-m64) in
GCC, so a single configure check is not sufficient.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77349
--- Comment #2 from David Edelsohn ---
Author: dje
Date: Fri Aug 26 23:51:27 2016
New Revision: 239790
URL: https://gcc.gnu.org/viewcvs?rev=239790&root=gcc&view=rev
Log:
PR target/77349
* config/rs6000/xcoff.h (DWARF_OFFSET_SIZE): D
||2016-08-30
CC||dje at gcc dot gnu.org,
||segher at gcc dot gnu.org
Target Milestone|--- |7.0
Ever confirmed|0 |1
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #4 from David Edelsohn ---
Altivec works on AIX, which requires 128 bit alignment. So GCC and AIX are able
to cooperate to generate the necessary alignment. The stack pointer is
supposed to maintain quadword alignment on AIX.
Presum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #7 from David Edelsohn ---
It looks like STACK_DYNAMIC_OFFSET will behave correctly on AIX if Altivec or
VSX is enabled. AIX increased the alignment when Altivec support was added.
It appears that STACK_DYNAMIC_OFFSET should add a t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #10 from David Edelsohn ---
I was thinking more of
#define STACK_DYNAMIC_OFFSET(FUNDECL) \
(RS6000_ALIGN (crtl->outgoing_args_size, \
(TARGET_ALTIVEC |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
David Edelsohn changed:
What|Removed |Added
Target|powerpc-ibm-aix*|powerpc*-*-*
--- Comment #12 from David
--- Comment #1 from dje at transmeta dot com 2006-10-25 02:23 ---
Re: "We think may be what wanted is:" ...
That's just off the cuff speculation. The curious things are:
- op1 is shifted outside the mode of the operation (0x3c << 31) (HOST_WIDE_INT
is 64 bits)
--- Comment #2 from dje at transmeta dot com 2006-10-25 02:41 ---
Thinking about it some more, disregard this (I think):
- nonzero_bits returns bits that may be one, not bits that are one, so it's not
clear this optimization is valid regardless of anything else
I _think_ this i
--- Comment #7 from dje at gcc dot gnu dot org 2006-04-13 15:37 ---
Paolo, I'm not sure why you think that two splats and two adds is too
expensive. Memory is moving farther and farther away from the processor.
--
dje at gcc dot gnu dot org changed:
What|Re
--- Comment #12 from dje at watson dot ibm dot com 2006-04-14 14:32 ---
Subject: Re: [4.1/4.2 Regression] Invalid altivec constant loading code
One can produce a few more values fairly easily, but having GCC
know the optimal sequence for all constants could be rather bulky
--- Comment #3 from dje at gcc dot gnu dot org 2006-04-14 17:39 ---
I don't know how you got to this point at all. GNU Java currently is not
supported on AIX.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26275
--- Comment #4 from dje at gcc dot gnu dot org 2006-04-14 17:52 ---
The testcase works for me. I am a little confused about what you actually have
installed if you have "gcc" and "g++" installed with different names (with and
without -4.0.2). Do you have a consist
--- Comment #4 from dje at gcc dot gnu dot org 2006-04-25 04:24 ---
This optimization occurred in 4.1 between life2 and lreg:
life2:
(insn 24 23 25 2 (set (reg:SI 126)
(const_int -503316480 [0xe200])) 279 {*movsi_internal1}
(nil)
(nil))
(insn 30 29 31 2
--- Comment #7 from dje at watson dot ibm dot com 2006-04-25 15:21 ---
Subject: Re: [4.2 regression] ICE in final_scan_insn, at final.c:2448 - could
not split insn
The patch may be necessary, but does not fix the testcase. The testcase
needs the patch that Andrew originally tested
--- Comment #9 from dje at gcc dot gnu dot org 2006-04-25 16:09 ---
By the way, while Andrew and my patch does produce correct code, it reverts to
the original behavior of the constant propagating into the AND between life2
and lreg, not between life1 and combine. Somehow combine is
--- Comment #12 from dje at gcc dot gnu dot org 2006-04-26 14:33 ---
Subject: Bug 27282
Author: dje
Date: Wed Apr 26 14:33:49 2006
New Revision: 113275
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113275
Log:
2006-04-26 David Edelsohn <[EMAIL PROTECTED]>
--- Comment #14 from dje at gcc dot gnu dot org 2006-04-26 17:57 ---
Subject: Bug 27282
Author: dje
Date: Wed Apr 26 17:57:03 2006
New Revision: 113278
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113278
Log:
PR middle-end/27282
* gcc.c-torture/compile
--- Comment #12 from dje at gcc dot gnu dot org 2006-05-04 13:52 ---
Subject: Bug 26481
Author: dje
Date: Thu May 4 13:52:45 2006
New Revision: 113525
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113525
Log:
PR target/26481
* config/rs6000/r
--- Comment #13 from dje at gcc dot gnu dot org 2006-05-04 13:55 ---
I was waiting for feedback from the original reporter, which never was
supplied. I have committed the patch on mainline to the 4.1 branch. I do not
have access to an AIX 5.1 system and without more details, it is
--- Comment #15 from dje at gcc dot gnu dot org 2006-05-04 20:41 ---
Subject: Bug 26481
Author: dje
Date: Thu May 4 20:40:52 2006
New Revision: 113539
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113539
Log:
PR target/26481
* config/rs6000/r
--- Comment #16 from dje at gcc dot gnu dot org 2006-05-04 20:44 ---
Subject: Bug 26481
Author: dje
Date: Thu May 4 20:43:57 2006
New Revision: 113540
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113540
Log:
PR target/26481
* config/rs6000/r
--- Comment #4 from dje at gcc dot gnu dot org 2006-05-09 17:09 ---
Subject: Bug 26545
Author: dje
Date: Tue May 9 17:09:06 2006
New Revision: 113659
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113659
Log:
PR target/26545
* config/rs6000
--- Comment #4 from dje at gcc dot gnu dot org 2006-05-09 17:12 ---
AIX 4.2 does not have enough support for weak symbols to compile C++ shared
library correctly. You must use --disable-shared on AIX 4.2.
--
dje at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from dje at gcc dot gnu dot org 2006-05-09 17:15 ---
Subject: Bug 26545
Author: dje
Date: Tue May 9 17:14:56 2006
New Revision: 113660
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113660
Log:
PR target/26545
* config/rs6000
--- Comment #6 from dje at gcc dot gnu dot org 2006-05-09 17:15 ---
patch applied.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from dje at gcc dot gnu dot org 2006-05-09 17:20 ---
You might be able to combine the address generation with the load in
legitimize_reload_address. See the existing code for SYMBOL_REF.
--
dje at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from dje at gcc dot gnu dot org 2006-05-10 14:56 ---
The section anchors feature does not like "__FUNCTION__" or "__func__" as an
inlined asm argument.
Also, "some rs6000 work" is not very informative or useful.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27528
--- Comment #1 from dje at gcc dot gnu dot org 2006-05-10 21:33 ---
I can disable section anchors for Ada, similar to Objective C and Objective
C++, but this failure likely means that there is a bug in the Trees generated
by GNU Ada.
--
dje at gcc dot gnu dot org changed
--- Comment #4 from dje at gcc dot gnu dot org 2006-05-11 15:13 ---
It looks like something in exception handling is creating a new object very
late, after reload, and the new address is not validized before being handed to
replace_equiv_address().
Should explow.c:use_anchored_address
--- Comment #8 from dje at gcc dot gnu dot org 2006-05-15 15:30 ---
Andreas or AJ,:
Can you test with gcc/except.c:output_ttype() changed from expand_normal() to
expand_expr (..., EXPAND_INITIALIZER, ...) ?
--
dje at gcc dot gnu dot org changed:
What|Removed
--- Comment #12 from dje at gcc dot gnu dot org 2006-05-18 15:56 ---
Users are suppose to control the architecture and code generation through
-mcpu=XXX, which sets the architecture options in self-consistent ways for the
target. On Darwin, -mcpu=G5 sets -mpowerpc64; on Linux
--- Comment #3 from dje at gcc dot gnu dot org 2006-05-25 17:27 ---
If the failures are associated with enabling section anchors by default, then
this has uncovered another problem with the section anchor support. Do you
have any more information about what is failing? Could this be
--- Comment #11 from dje at gcc dot gnu dot org 2006-05-25 17:34 ---
What is happening with this patch? Are these test results considered good?
Will this patch be submitted?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27536
--- Comment #20 from dje at gcc dot gnu dot org 2006-05-26 14:07 ---
The patch you reference enables section anchors by default. Neither AIX nor
PPC Linux show new Gfortran testsuite failures from the use of section anchors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27683
--- Comment #3 from dje at gcc dot gnu dot org 2006-06-01 14:20 ---
dup
*** This bug has been marked as a duplicate of 27536 ***
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from dje at gcc dot gnu dot org 2006-06-01 14:20 ---
*** Bug 27862 has been marked as a duplicate of this bug. ***
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dje at gcc dot gnu dot org 2006-06-05 21:25 ---
I still think this looks like an alignment problem. Without section anchors
GCC generates:
.lcomm domain_array,13916,16
.type domain_array, @object
.lcomm N_domains,4,4
.type
--- Comment #10 from dje at gcc dot gnu dot org 2006-06-06 15:10 ---
The auto-vectorizer is a Tree-SSA pass. The section anchors are an RTL pass.
I do not understand why the alignment of the vectorized variables is not known
at section anchor creation time.
--
http://gcc.gnu.org
--- Comment #13 from dje at gcc dot gnu dot org 2006-06-06 15:22 ---
We're performing the auto-vectorization in unit-at-a-time-mode, so maybe we
need to recompile the other functions. It seems that we're going to encounter
more problems along these lines with LTO.
--- Comment #2 from dje at gcc dot gnu dot org 2006-06-07 02:31 ---
Can you provide any information about what initially produces the
(subreg:DF (reg:DI)) ?
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from dje at gcc dot gnu dot org 2006-06-07 21:39 ---
I checked with the IBM XLC team and they speculatively increase the alignment
of variables that could be auto-vectorized, so that gives another vote for that
method. They did mention that whole-program IPA allows them
--- Comment #9 from dje at gcc dot gnu dot org 2006-06-17 01:37 ---
The bug is in flow.c and fixed by the new df.c rewrite of dataflow. Ken and I
tripped over the same problem.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from dje at gcc dot gnu dot org 2006-06-26 18:51 ---
This appears to be a problem in the insvdi_internal2 and insvdi_internal3
combiner patterns.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dje at gcc dot gnu dot org 2006-06-27 01:34 ---
rs6000.c:insvdi_rshift_rlwimi_p() is wrong, specifically the lines checking the
shift count.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28170
--- Comment #7 from dje at gcc dot gnu dot org 2006-06-27 01:40 ---
I think the correct test is something like
Index: rs6000.c
===
--- rs6000.c(revision 115003)
+++ rs6000.c(working copy)
@@ -9794,8 +9794,8
--- Comment #6 from dje at gcc dot gnu dot org 2006-06-30 13:39 ---
This may be due to spe_build_register_parallel() called from
rs6000_function_value().
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from dje at gcc dot gnu dot org 2006-07-05 20:03 ---
I think this simply is a case of not allowing TFmode in PRE_INC addresses:
Index: rs6000.c
===
--- rs6000.c(revision 115196)
+++ rs6000.c(working
--- Comment #11 from dje at gcc dot gnu dot org 2006-07-06 14:37 ---
The original code could not be "totally broken" unless Alan's code also is
totally broken because he computes many of the same tests. Also, Alan does not
include an important test from the original co
--- Comment #13 from dje at gcc dot gnu dot org 2006-07-06 19:00 ---
Subject: Bug 28170
Author: dje
Date: Thu Jul 6 18:59:58 2006
New Revision: 115229
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115229
Log:
2006-07-06 David Edelsohn <[EMAIL PROTECTED]>
--- Comment #8 from dje at gcc dot gnu dot org 2006-07-06 19:00 ---
Subject: Bug 28150
Author: dje
Date: Thu Jul 6 18:59:58 2006
New Revision: 115229
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115229
Log:
2006-07-06 David Edelsohn <[EMAIL PROTECTED]>
--- Comment #8 from dje at gcc dot gnu dot org 2006-07-08 03:13 ---
The patch looks consistent with the rest of the e500 design, although I am not
familiar enough with the e500 ISA to determine if the code will be correct
under all circumstances. I'm willing to approve the pat
--- Comment #10 from dje at gcc dot gnu dot org 2006-07-11 13:28 ---
This now causes bootstrap failure on primary platforms.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dje at gcc dot gnu dot org 2006-07-11 16:59 ---
Switching actually causes problems on AIX due to AIX math.h header enabling
additional macros with types that conflict with GCC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19115
--- Comment #10 from dje at watson dot ibm dot com 2006-07-13 16:31 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
>>>>> edmar at freescale dot com writes:
edmar> I tried the patch on comment 7 on gcc main line from yesterday. It did
not
--- Comment #12 from dje at watson dot ibm dot com 2006-07-13 19:58 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
>>>>> edmar at freescale dot com writes:
edmar> And to kill the last shread of doubt, here I am using the xgcc present
on the
edma
--- Comment #14 from dje at watson dot ibm dot com 2006-07-13 20:36 ---
Subject: Re: [4.1/4.2 Regression] returning constant double
What, exactly, is your testcase foo.c? The example at the top of
PR 28287?
$ cat foo.c
double f (void) { return 0; }
$ ./xgcc -B./ -O2 -S
--- Comment #17 from dje at gcc dot gnu dot org 2006-07-14 17:44 ---
Subject: Bug 27287
Author: dje
Date: Fri Jul 14 17:44:27 2006
New Revision: 115451
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115451
Log:
2006-07-14 Eliot Dresselhaus <[EMAIL PROTECTED]&g
--- Comment #18 from dje at gcc dot gnu dot org 2006-07-14 17:47 ---
Remove 4.2 regression designation.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from dje at gcc dot gnu dot org 2006-07-14 19:11 ---
This is because the E500 DOUBLE support wasn't prepared for complex doubles.
Index: rs6000.c
===
--- rs6000.c(revision 115431)
+++ rs6
--- Comment #4 from dje at gcc dot gnu dot org 2006-07-14 19:21 ---
rs6000_legitimate_offset_address_p() accepts constant offsets:
case V4HImode:
case V2SImode:
case V1DImode:
case V2SFmode:
/* SPE vector modes. */
return SPE_CONST_OFFSET_OK (offset);
It
--- Comment #4 from dje at gcc dot gnu dot org 2006-07-17 01:43 ---
Double Complex on e500 with double GPRs fundamentally does not interact well
with GCC's current design. GCC does not want to have a double placed in the
same register that can contain an int if the width o
--- Comment #5 from dje at gcc dot gnu dot org 2006-07-17 02:05 ---
Created an attachment (id=11902)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11902&action=view)
consistently calculate nregs for FLOAT_MODES
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24036
--- Comment #1 from dje at gcc dot gnu dot org 2008-11-24 21:57 ---
Yep. confirmed.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
Status
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dje at gcc dot gnu dot org
GCC build triplet: powerpc*-*-*
GCC host triplet: powerpc*-*-*
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38731
--- Comment #2 from dje at gcc dot gnu dot org 2009-01-05 19:54 ---
For example, the following, when declared locally:
typedef char Str_30 [31];
Str_30 Str_1_Par_Ref;
Str_30 Str_2_Par_Ref;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38731
--- Comment #5 from dje dot gcc at gmail dot com 2009-05-20 17:51 ---
Subject: Re: Inefficient loop unrolling
> I implemented a tree-level loop-unrolling pass in our private porting, which
> takes advantage of later tree ivopt pass. It produces much better code than
> rtl-l
--- Comment #1 from dje at gcc dot gnu dot org 2009-05-21 12:40 ---
Confirmed
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #4 from dje at gcc dot gnu dot org 2009-06-01 21:49 ---
Local variable debugging is broken for AIX stabs as well.
On AIX, the DECL and the insn contain different offsets from virtual-stack-vars
for the same variable:
(mem/c/i:SI (plus:SI (reg/f:SI 115 virtual-stack-vars
--- Comment #5 from dje at gcc dot gnu dot org 2009-06-02 12:51 ---
cfgexpand.c:expand_used_vars() expands and instantiates virtual-stack-vars for
INSNs when it walks the partion map:
for (i = 0; i < SA.map->num_partitions; i++)
{
tree var = partition_to_var (SA.
--- Comment #2 from dje at gcc dot gnu dot org 2009-06-04 16:18 ---
AIX started miscomparing in libgcc as well.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from dje at gcc dot gnu dot org 2009-06-04 17:11 ---
Jakub mentioned that Alexandre patch added comparison of libgcc, which may not
have been compared before. But I successfully bootstrapped with Alexandre's
patch the previous day.
--
http://gcc.gnu.org/bug
--- Comment #6 from dje at gcc dot gnu dot org 2009-06-04 17:17 ---
Alexandre committed the change in revision 148080 and I successfully
bootstrapped AIX yesterday with revision 148105.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40338
--- Comment #7 from dje at gcc dot gnu dot org 2009-06-04 19:25 ---
Okay, I think these are separate bugs. The HP-PA error may be due to
Alexandre's change.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40338
ormal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dje at gcc dot gnu dot org
GCC build triplet: powerpc-ibm-aix5.3.0.0
GCC host triplet: powerpc-ibm-aix5.3.0.0
GCC target triplet: powerpc-ibm-aix5.3.0.0
http://gcc.gn
--- Comment #1 from dje at gcc dot gnu dot org 2009-06-04 19:27 ---
confirmed.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #3 from dje dot gcc at gmail dot com 2009-06-04 19:41 ---
Subject: Re: AIX PPC64 libgcc bootstrap miscompare
Only the rs6000 changes: r148138. I am trying to narrow it down to
the rs6000.c change or the asm changes.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #14 from dje at gcc dot gnu dot org 2009-06-15 23:06 ---
This patch also fixes the gcc.c-torture/compile/pr34688.c failures. RTL-PRE
finds RTL with deep LABEL_REFs. When it creates a move, the emit_use and the
REG_NOTE on the move itself share RTL.
I suspect we need to
--- Comment #8 from dje at gcc dot gnu dot org 2009-06-30 14:50 ---
Now I see failures when building libgcc:
../../.././gcc/dp-bit.c: In function '__pack_d':
../../.././gcc/dp-bit.c:268:39: internal compiler error: in simplify_subreg, at
simplify-rtx.c:4966
--
http://g
--- Comment #9 from dje at gcc dot gnu dot org 2009-06-30 15:07 ---
The traceback leads to the store flag change.
(gdb) print op
$3 = (rtx) 0x30153558
(gdb) pr
(reg:SI 234)
(gdb) print innermode
$4 = DImode
(gdb) print outermode
$5 = SImode
#0 fancy_abort (file=0x10e8a5b8 "/far
1001 - 1100 of 1800 matches
Mail list logo
