https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #30 from David Edelsohn ---
.../src/src/configure --disable-werror --with-gmp=/opt/cfarm
--with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch
--with-included-gettext
By the way, it's a lot faster if the src and build directories
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #32 from David Edelsohn ---
How far are you going back in the bisection effort? You may be earlier than
the point at which GCC on AIX generated stab strings continuation lines. At
worst you manually can apply the continuation code f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #36 from David Edelsohn ---
The DBX_CONTIN patch should be in gcc/xcoffout.h, not in rs6000.h.
The patch originally was added 2015-02-06.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #42 from David Edelsohn ---
The situation of GDB on AIX is not good.
I placed an older version of gdb-7.6 in my bin directory. You can try that. I
will see if I can get a copy of the AIX Toolbox GDB which contains some
additional pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #43 from David Edelsohn ---
I upgraded GDB on gcc119 with GDB 7.9.1 + IBM patches. It may work a little
better.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #48 from David Edelsohn ---
Based on Comment #45, is this a problem in the Stage 1 compilers? Note that
Alan and Segher adjusted the doloop patterns in this release cycle. Does
backporting that patch or bootstrapping with current tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081
--- Comment #51 from David Edelsohn ---
If you use /scratch for source, build and TMPDIR, as well as
SHELL=/usr/bin/bash CONFIG_SHELL=/usr/bin/bash
it should build faster on AIX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79439
--- Comment #5 from David Edelsohn ---
current_file_function_operand probably needs to add a test for
flag_semantic_interposition when the ABI mandates interpolation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78379
--- Comment #28 from David Edelsohn ---
Because PPC64LE Linux reset the base ISA level, VSX now is enabled by default,
so a function clone for VSX probably isn't necessary. While special versions
might help AIX and PPC64BE, with lower ISA defaul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80376
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, segher at gcc dot gnu.org,
seurer at gcc dot gnu.org, uros at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82553
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
|NEW
Last reconfirmed||2017-11-15
CC||dje at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from David Edelsohn ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83005
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82997
--- Comment #2 from David Edelsohn ---
*** Bug 83005 has been marked as a duplicate of this bug. ***
||2017-11-15
CC||dje at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #3 from David Edelsohn ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82997
--- Comment #4 from David Edelsohn ---
Andrey reports that this starts with r254707
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: power*-*-aix*
$ ./check_value.exe
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/ext/special_functions/hyperg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83120
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc*-*-*
New testcase failure on PowerPC (Linux and AIX)
FAIL: c-c++-common/attr-nonstring-3.c -std=gnu++98
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83131
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||2017-12-01
CC||dje at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from David Edelsohn ---
confirmed.
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
PowerPC port xmmintrin.h _mm_min_ps invokes Power vec_min instrinsic and
_mm_max_ps invokes Power vec_max instrinsic. vec_min
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83315
David Edelsohn changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83120
--- Comment #5 from David Edelsohn ---
Author: dje
Date: Thu Dec 7 20:05:59 2017
New Revision: 255483
URL: https://gcc.gnu.org/viewcvs?rev=255483&root=gcc&view=rev
Log:
PR libstdc++/83120
* testsuite/ext/special_f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83120
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67197
--- Comment #3 from David Edelsohn ---
The patch was reverted, but we don't know why it caused problems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #15 from David Edelsohn ---
The AIX Subroutine Linkage Convention states:
"The address value in the stack pointer must be quadword-aligned. (The address
value must be a multiple of 16.)" - Stack Layout, Note 2.
https://www.ibm.com/s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68663
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77349
--- Comment #3 from David Edelsohn ---
Author: dje
Date: Fri Sep 16 14:42:54 2016
New Revision: 240188
URL: https://gcc.gnu.org/viewcvs?rev=240188&root=gcc&view=rev
Log:
2016-09-16 David Edelsohn
Backported from
Priority: P3
Component: go
Assignee: ian at airs dot com
Reporter: dje at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
go-system.h includes C++ headers before system.h to work-around poisoned
declarations
// These must be included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77715
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77780
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Assignee: ian at airs dot com
Reporter: dje at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
Target: powerpc-ibm-aix*
The Go front-end uses '$' as a joiner and creates symbols such as
internal_race.Acquire$descriptor. This is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68703
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77780
David Edelsohn changed:
What|Removed |Added
Keywords||assemble-failure
--- Comment #2 from Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78056
David Edelsohn changed:
What|Removed |Added
Target|powerpc64-unknown-linux-gnu |powerpc*-*-*
Status|UNCONFI
,
||powerpc-ibm-aix*
CC||dje at gcc dot gnu.org
Host|sparc-sun-solaris2.12 |sparc-sun-solaris2.12,
||powerpc-ibm-aix*
Build|sparc-sun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78056
--- Comment #9 from David Edelsohn ---
Any *one* of the BU_P9V_AV_P builtins will cause the failure. If those
builtins are commented out of rs6000-builtins.def (with the appropriate changes
to rs6000-c.c), bootstrap will succeed.
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
GCC now warns for -fprofile-update=atomic + -pthread on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78069
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78055
--- Comment #15 from David Edelsohn ---
The AIX failures are fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #17 from David Edelsohn ---
Created attachment 39891
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39891&action=edit
Experimental patch
If this patch is correct, then there is a general problem for Linux also.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #18 from David Edelsohn ---
As long as GCC claims that it can make a distinction between the various
alignments and macros, the GCC code generation must continue to honor it.
On AIX, at least, the ABI claims a different stack alignme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #20 from David Edelsohn ---
If STACK_DYNAMIC_OFFSET has to be increased to 16, it has to be increased.
info->parm_size probably was adjusted for VMX parameters.
Note that GCC has gone through contortions with STACK_BOUNDARY,
PREFERR
: ian at airs dot com
Reporter: dje at gcc dot gnu.org
CC: cmang at google dot com
Target Milestone: ---
Target: powerpc-ibm-aix*
Linux has a fairly simple ucred, but AIX has a large, complicated one
with multiple variations that appears to be too much for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172
--- Comment #2 from David Edelsohn ---
The error message is the complete line -- or at least the entire line that was
communicated to me.
priv_t is a type defined in AIX /usr/include/priv.h, which is included by
cred.h. uid_t, gid_t and pid_t a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78172
--- Comment #4 from David Edelsohn ---
Created attachment 39944
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39944&action=edit
sysinfo.go
Generated sysinfo.go file attached.
Priority: P3
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
With the tree-vrp.c change of r241774, I encounter the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
--- Comment #2 from David Edelsohn ---
I built the GCC stage1 with and without the tree-vrp.c patch. Same sources,
same revision, same directory. cc1plus.good and cc1plus.bad.
Then I used both versions of cc1plus to compile tree-ssa-sccvn.c wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
--- Comment #5 from David Edelsohn ---
Created attachment 39953
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39953&action=edit
Pre-processed tree-ssa-sccvn.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
--- Comment #8 from David Edelsohn ---
Reading specs from /edelsohn/RICHI/./prev-gcc/specs
COLLECT_GCC=/edelsohn/RICHI/./prev-gcc/xg++
Target: powerpc-ibm-aix7.2.0.0
Configured with: /nasfarm/edelsohn/src/sandbox/configure --disable-werror
--enab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
--- Comment #9 from David Edelsohn ---
Any difference if you force more GC? AIX has a different process address space
layout and has much more aggressive memory reclamation in malloc/free.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
--- Comment #10 from David Edelsohn ---
The get_create() change does change the section_type_conflict on AIX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78056
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
--- Comment #14 from David Edelsohn ---
Honza suggested
Index: varasm.c
===
--- varasm.c(revision 241793)
+++ varasm.c(working copy)
@@ -6036,7 +6036,8 @@
#ifdef MAKE_DECL_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
--- Comment #15 from David Edelsohn ---
Another option is to force the COMDAT group to NULL in set_comdat_group() if
!HAVE_COMDAT_GROUP. That would allow the rest of the COMDAT functionality to
continue to work. Does that make any sense to try?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
--- Comment #17 from David Edelsohn ---
ld: 0711-317 ERROR: Undefined symbol: .std::allocator::allocator()
ld: 0711-317 ERROR: Undefined symbol: .std::__cxx11::basic_string, std::allocator >::basic_string(char const*,
std::allocator const&)
ld: 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
--- Comment #18 from David Edelsohn ---
Changing pass_ipa_comdats::gate to
return HAVE_COMDAT_GROUP && optimize;
does not experience the tree-vrp.c bootstrap failure and does not generate the
numerous additional testsuite failures.
There is on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
--- Comment #19 from David Edelsohn ---
I will try
if (HAVE_COMDAT_GROUP)
symbol->set_comdat_group (comdat_group);
else
symbol->set_comdat_group (NULL);
in varasm.c:make_decl_one_only().
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
--- Comment #20 from David Edelsohn ---
Using set_comdat_group(NULL) in varasm.c did not correct the testsuite
failures. The only option that has worked so far is to disable ipa-comdat at
gate function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
--- Comment #22 from David Edelsohn ---
There are two levels of set_comdat_group(). I am going to move the assert to
cgraph.h and try to find what else is setting comdat groups.
Do you want me to gate IPA comdat in the interim?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77349
David Edelsohn changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
--- Comment #24 from David Edelsohn ---
Author: dje
Date: Fri Nov 4 23:20:50 2016
New Revision: 241863
URL: https://gcc.gnu.org/viewcvs?rev=241863&root=gcc&view=rev
Log:
PR bootstrap/78188
PR c++/71848
* ipa-comdats.c (pass_ipa_comda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71848
--- Comment #3 from David Edelsohn ---
Author: dje
Date: Fri Nov 4 23:20:50 2016
New Revision: 241863
URL: https://gcc.gnu.org/viewcvs?rev=241863&root=gcc&view=rev
Log:
PR bootstrap/78188
PR c++/71848
* ipa-comdats.c (pass_ipa_comda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78188
--- Comment #25 from David Edelsohn ---
Author: dje
Date: Sat Nov 5 13:06:08 2016
New Revision: 241871
URL: https://gcc.gnu.org/viewcvs?rev=241871&root=gcc&view=rev
Log:
2016-11-05 Richard Biener
PR bootstrap/78188
-code
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
Created attachment 39981
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78235
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78235
--- Comment #2 from David Edelsohn ---
20_util/variant/compile.cc produces a similar error:
In file included from
/nasfarm/edelsohn/src/src/libstdc++-v3/testsuite/20_util/variant/compile.cc:21:
/tmp/GCC/powerpc-ibm-aix7.2.0.0/libstdc++-v3/includ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78336
--- Comment #1 from David Edelsohn ---
I thought that Darwin specifically picked up the definition from
config/darwin.h.
I don't understand the failure because the rs6000.h logic did not change and
rs6000_asm_weaken_decl is declared in rs6000-pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78336
--- Comment #3 from David Edelsohn ---
So the problem is the reference to ASM_OUTPUT_DEF in rs6000_asm_weaken_decl,
despite the fact that the function never will be called on Darwin. Previously
the ASM_WEAKEN_DECL macro was protected by RS6000_W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78336
--- Comment #6 from David Edelsohn ---
Author: dje
Date: Sun Nov 13 14:28:49 2016
New Revision: 242353
URL: https://gcc.gnu.org/viewcvs?rev=242353&root=gcc&view=rev
Log:
PR target/78336
* config/rs6000/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78336
--- Comment #5 from David Edelsohn ---
I committed option 3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78336
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78336
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78386
--- Comment #10 from David Edelsohn ---
-std=gnuXX affects IEEE 754 conformance, but that is not mentioned in the
documentation, only in source code comments (c-family/c-cppbuiltin.c)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=378
--- Comment #11 from David Edelsohn ---
Recent releases of GCC are built with linker options to allow larger data
section. Are the user process limits (ulimit) set large enough? One could
rebuild GCC cc1 and cc1plus with even larger -bmaxdata value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=378
--- Comment #13 from David Edelsohn ---
I mis-remembered the bug. This is a problem with branch distance. The GNU
Assembler, GNU Linker and GOLD allow instruction relaxation that creates long
branch stubs for far branches. The AIX toolchain does not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763
--- Comment #5 from David Edelsohn ---
I can see why the proposed patch will work, but it seems a little heavy-handed.
This case isn't something that simplify_gen_subreg() should handle?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763
--- Comment #10 from David Edelsohn ---
I'm not questioning the analysis, I'm questioning the solution. Directly
generating a register and jamming in the REGNO in this pattern seems sort of
crude.
gen_rtx_REG (DImode, REGNO (op0));
I don't doubt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763
--- Comment #13 from David Edelsohn ---
Gentlemen, I really do not understand this discussion.
I used the term "crude" and receive a response that it is not crude, but it is
dangerous. WTF? Why is anyone trying to "sell" the patch when I repeated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60763
--- Comment #16 from David Edelsohn ---
Comment on attachment 32568
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32568
Patch with changelog and comment.
Okay. Thanks for the clarification.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50689
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
|UNCONFIRMED |NEW
Known to work||4.9.0
Keywords||wrong-code
Last reconfirmed||2014-04-26
CC||dje at gcc dot gnu.org
Ever confirmed|0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60143
--- Comment #2 from David Edelsohn ---
This already is fixed in 4.9.0. I am unsure which patch actually fixed the bug.
|UNCONFIRMED |NEW
Last reconfirmed||2014-04-26
CC||dje at gcc dot gnu.org
Ever confirmed|0 |1
Known to fail||4.8.0, 4.8.1, 4.8.2
--- Comment #3
||2014-04-26
CC||dje at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #10 from David Edelsohn ---
Apparently confirmed.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42465
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984
--- Comment #1 from David Edelsohn ---
I have been bootstrapping GCC trunk and 4.9 on AIX 7.1 without any failures.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984
David Edelsohn changed:
What|Removed |Added
Target|powerpc-ibm-aix6.1 |powerpc-ibm-aix*
Priority|P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984
--- Comment #3 from David Edelsohn ---
731 template
732 inline T &
733 vec::operator[] (unsigned ix)
734 {
735 gcc_checking_assert (ix < m_vecpfx.m_num);
736 return m_vecdata[ix];
737 }
3153 gcc_checking_asser
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984
David Edelsohn changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984
David Edelsohn changed:
What|Removed |Added
Keywords||ice-on-valid-code
Last reconfirmed|201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984
--- Comment #8 from David Edelsohn ---
I reproduced the failure starting with both GCC 4.6.3 and GCC 4.8.1.
However, I am seeing some very strange results:
r209278 built in /tmp/20140412 SUCCESS
r209300 (trunk before branch) built in /tmp/20930
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984
--- Comment #9 from David Edelsohn ---
Torbjorn: could you try building in a different directory, e.g.,
/builds/MMDD for the date or some random number?
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
The rs6000 port should use divde to implement GCC named pattern divmodtidi4 and
divdeu to for udivmodtidi4. Similarly, divwe and divweu can implement
divmoddisi4 and udivmoddisi4.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61030
David Edelsohn changed:
What|Removed |Added
Target||powerpc*-*-*
Status|UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60984
--- Comment #12 from David Edelsohn ---
Are you using GNU Bash as your SHELL (recommended in the target-specific
installation instructions). It should not take that long to bootstrap GCC on a
recent system. AIX /bin/sh runs configure very slowly.
601 - 700 of 1697 matches
Mail list logo
