https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #2 from David Edelsohn ---
Created attachment 38299
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38299&action=edit
Stage2 sbitmap.s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #4 from David Edelsohn ---
sbitmap.s was one of the smaller files. All of the debugging information seems
to be present, but emitted in a different order in the stage2 versus stage3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
David Edelsohn changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #7 from David Edelsohn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #8 from David Edelsohn ---
Development branch prior to debug-early merge works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #9 from David Edelsohn ---
r224187 works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #10 from David Edelsohn ---
This is starting to look like PR60984 all over again. Testing trunk with
--enable-checking=release succeeds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #12 from David Edelsohn ---
Current trunk works. I am testing gcc-6-branch now. But the RC itself does
not work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #13 from David Edelsohn ---
A source tree checked out from r235040 (the same as the tarball) works. It
looks more likely that the problem is some difference between the repository
and the tarball.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #14 from David Edelsohn ---
The problem likely is due to gcc/gentype-lex.c distributed in the tarball. The
AIX systems currently use flex 2.5.3, which produces working gengtype-lex.c on
AIX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #15 from David Edelsohn ---
gcc-6-20160410 snapshot tarball (without gengtype-lex.c) works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #17 from David Edelsohn ---
Yes, WS1 is Flex 2.5.37. I will upload both. There are many differences.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #18 from David Edelsohn ---
Created attachment 38310
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38310&action=edit
gengtype-lex.c distributed in GCC-6.0.1-RC1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #19 from David Edelsohn ---
Created attachment 38311
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38311&action=edit
gengtype-lex.c generated on AIX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #21 from David Edelsohn ---
The recent flex adds a number of its own C int type definitions and ranges.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #23 from David Edelsohn ---
Older releases of Flex are no longer available as source code. Flex now is
distributed through sourceforge, not gnu.org. Newer releases of Flex don't
build on AIX.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #24 from David Edelsohn ---
Actually, I finally was able to convince Flex 2.6.0 to build. I'll try with
that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #26 from David Edelsohn ---
After some more tests, I don't believe that flex is the culprit. I removed
gengtype-lex.c from GCC-6.0.1-RC and allowed the flex to rebuild it, but the
build still failed with the miscompare.
The problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #27 from David Edelsohn ---
I performed a recursive diff of r235040 vs gcc-6.0.1-rc-20160415. Other than
.svn directories, the only differences are:
Only in gcc6rc/INSTALL: binaries.html
Only in gcc6rc/INSTALL: build.html
Only in gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #28 from David Edelsohn ---
I copied gcc/REVISION to the release candidate to remove one additional
difference and tried bootstrap, but it still failed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #29 from David Edelsohn ---
Flex 2.6.0 works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #31 from David Edelsohn ---
I will test, but Flex and gengtype-lex.c does not appear to be the issue. If
the change works, it will be coincidental.
I have built the RC with gengtype-lex.c removed so that it is regenerated with
the s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #33 from David Edelsohn ---
I'm completely confused as well. The bits seem to be identical. The only
other obvious difference is ordering of timestamps of the source files that
would cause Make to build files in a different order.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #34 from David Edelsohn ---
The tarball contains LAST_UPDATED, although different contents.
I previously copied gcc/REVISION from svn checkout to the RC (which is
referenced by Makefile). That showed no difference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #35 from David Edelsohn ---
Flex 2.6.0 works with --enable-checking=yes, but may not work with
--enable-checking=release. I believe that Flex may be the culprit. If the
current bootstrap confirms that, I am going to bootstrap with g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #36 from David Edelsohn ---
It definitely is Flex. gcc-6-branch r235040 and r235340 fail when built with
Flex 2.6.0. gcc-6.0.1-RC-20160415 fails using the supplied gengtype-lex.c
created with Flex 2.5.37.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #38 from David Edelsohn ---
The gt* files don't differ.
I normally use
--disable-werror --enable-languages=c,c++,fortran,objc --with-gmp=/opt/cfarm
--with-libiconv-prefix=/opt/cfarm --disable-libstdcxx-pch
--with-included-gettext --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #40 from David Edelsohn ---
I see that you did not have /opt/freeware/bin in your path on AIX. How did it
even build without GNU Make and other build requirements?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #43 from David Edelsohn ---
I tried RC2 and it again failed. I configured again with your configure
command and what appears to be your build command, and it succeeded.
One difference is my normal bootstrap script still use the cont
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #48 from David Edelsohn ---
Commenting out the fold_non_dependent_expr call seems to work for me using the
build method that regularly was failing before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70704
--- Comment #49 from David Edelsohn ---
Can we add some testcases to ensure that -fchecking and similar flags don't
accidentally affect code generation due to future changes?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69810
--- Comment #9 from David Edelsohn ---
Author: dje
Date: Fri Apr 29 17:20:36 2016
New Revision: 235646
URL: https://gcc.gnu.org/viewcvs?rev=235646&root=gcc&view=rev
Log:
PR target/69810
* config/rs6000/rs6000.md (EXTQI
||2016-05-08
CC||dje at gcc dot gnu.org,
||meissner at gcc dot gnu.org,
||segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Support C++ function overloading in C using the overloadable attribute. The
appropriate function is invoked based on the function parameters. This feature
is defined in the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199
David Edelsohn changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199
--- Comment #3 from David Edelsohn ---
How does _Generic interact with C++ if one includes the same header file in
either language?
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
/tmp/20160608/./gcc/xgcc -B/tmp/20160608/./gcc/ -xc -S -c /dev/null -fself-test
/nasfarm/edelsohn/src/src/gcc/pretty-print.c:1246: FAIL: ASSERT_STREQ
(expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71471
David Edelsohn changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71471
--- Comment #5 from David Edelsohn ---
ah, no, it must be the %p one
and that is indeed arch specific I think
c99 says:
The value of the pointer is
converted to a sequence of printing characters, in an
implementation-defined
manner.
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
The patch breaks bootstrap on AIX and probably is a hidden bug on all targets.
With the patch, libbacktrace/xcoff.c fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81638
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81638
--- Comment #2 from David Edelsohn ---
Created attachment 41877
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41877&action=edit
pre-processed xcoff.c compiled on AIX 7.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81638
--- Comment #4 from David Edelsohn ---
The test around the setting of incl is the same as the test around the use of
incl at the place of the false positive uninitialized error
for (i = 0; i < vec->count; ++i)
incl = ...
if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81638
--- Comment #8 from David Edelsohn ---
I already tested the equivalent patch. If the preferred solution is a
work-around for the false positive, I'll install that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81638
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 81638, which changed state.
Bug 81638 Summary: [8 Regression] AIX bootstrap failure due to Recover GOTO
predictor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81638
What|Removed |Added
: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
./53984.cc:31: void test01(): Assertion 'in.bad()' failed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81808
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81808
--- Comment #2 from David Edelsohn ---
Created attachment 41967
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41967&action=edit
Pre-processed source of testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81808
--- Comment #3 from David Edelsohn ---
After in >> x, x appears to contain the value 0x02ff22770.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81808
--- Comment #7 from David Edelsohn ---
I have no objection to skipping the test on AIX if the test is not correct for
AIX behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82317
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
||2017-09-25
CC||dje at gcc dot gnu.org,
||krebbel at gcc dot gnu.org,
||vogt at linux dot vnet.ibm.com
Summary|vec_ceil/vec_floor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67531
--- Comment #7 from David Edelsohn ---
What progress do you expect? IBM long double does not support non-default
rounding. This will be fixed when PPC64LE long double defaults to IEEE 128 bit
floating point.
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix*
RC1 is experiencing a bootstrap comparison failure on AIX for some object files
in libgomp. The difference is the symbol name of global initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80531
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: x86-64
// https://twitter.com/zxovq/status/861377261827629057
#include
#include
class my_stream : public std::stringstream {
public:
operator std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80662
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc-ibm-aix
/nasfarm/edelsohn/src/src/gcc/c-family/c-cppbuiltin.c: In function 'void
builtin_define_float_constants(const char*, const char*, const char*, const
char*,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80860
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80860
--- Comment #3 from David Edelsohn ---
But I had a successful bootstrap with r248295, which is after your patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80860
David Edelsohn changed:
What|Removed |Added
CC|hubicka at gcc dot gnu.org |
--- Comment #4 from David Edels
,
|sparc-sun-solaris2.12 |sparc-sun-solaris2.12,
||powerpc-ibm-aix*
CC||dje at gcc dot gnu.org
--- Comment #8 from David Edelsohn ---
Probably also a cause of AIX bootstrap hang.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
CC: rdapp at linux dot vnet.ibm.com, segher at gcc dot gnu.org,
wschmidt at gcc dot gnu.org
Target Milestone: ---
Target: powerpc*-*-*
The recent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80925
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
GCC 6 didn't add the fallthru edge and thus properly treated longjmp as
noreturn during CFG build.
void longjmp(); void __attrib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80926
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
[Reported on Stackoverflow
https://stackoverflow.com/questions/43748646/gcc-bug-with-lambda-capture-of-this-in-initialization-list-with
||2017-06-12
CC||dje at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from David Edelsohn ---
This seems to be failing on all 32 bit targets (IA-32, powerpc -m32, AIX -m32).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78481
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*
libgcc/Makefile.in defines:
libgcc.a libgcov.a libunwind.a libgcc_eh.a:
-rm -f $@
objects="$(ob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57058
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78482
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71848
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68838
--- Comment #2 from David Edelsohn ---
oss_01 is "good" with zero size until the string is emitted.
.good: 1 .fail: 0
size: 0
oss_01 << str_01;
.good: 0 .fail: 1
size: 33554432
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68838
--- Comment #3 from David Edelsohn ---
.good: 0 .fail: 1
width: 5000 size: 33554432
str_01[0]: 97
oss_01.str()[0]: 32
The string is filled with L'a' (0x97). The stringstream is filled with space
(0x32) and width is not set to 0 although size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68838
--- Comment #4 from David Edelsohn ---
On 32 bit AIX, wchar is 16 bits, two bytes. The libstdc++ code prepends
33554432 of fill, which is exactly 2*16777216 or 2^24 2 byte characters. Why is
2^24 special?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68838
--- Comment #5 from David Edelsohn ---
Sigh. The test is running out of memory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78576
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68838
--- Comment #6 from David Edelsohn ---
Author: dje
Date: Tue Nov 29 17:50:27 2016
New Revision: 242967
URL: https://gcc.gnu.org/viewcvs?rev=242967&root=gcc&view=rev
Log:
PR libstdc++/68838
* testsuite/lib/libstdc++.exp (DEFAULT_CXXFLA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68838
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78235
--- Comment #5 from David Edelsohn ---
This fails in dbxout.c:dbxout_type_fields()
/* Output the name, type, position (in bits), size (in bits) of each
field that we can support. */
for (tem = TYPE_FIELDS (type); tem; tem = DECL_CHAIN
(
file=0x11af5554 <_GLOBAL__F_final_solutions_obstack+29508>
"/home/dje/src/src/gcc/cgraph.h", line=0, function=0x2ff21880 "/�\030�")
at /home/dje/src/src/gcc/diagnostic.c:1446
#1 0x10a96f64 in symtab_node::get (decl=)
#2 0x100a3a94 in _Z17decl_section_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78235
--- Comment #6 from David Edelsohn ---
Author: dje
Date: Thu Dec 1 18:58:47 2016
New Revision: 243126
URL: https://gcc.gnu.org/viewcvs?rev=243126&root=gcc&view=rev
Log:
PR debug/66419
PR c++/78235
* dbxout.c (dbxout_type_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66419
--- Comment #6 from David Edelsohn ---
Author: dje
Date: Thu Dec 1 18:58:47 2016
New Revision: 243126
URL: https://gcc.gnu.org/viewcvs?rev=243126&root=gcc&view=rev
Log:
PR debug/66419
PR c++/78235
* dbxout.c (dbxout_type_field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78235
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66149
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77373
--- Comment #4 from David Edelsohn ---
unit size
align 256 symtab 0 alias set -1 canonical type 700fc0c0
fields
used nonlocal decl_3 BLK file
/gsa/yktgsa/home/e/d/edelsohn/src/src/gcc/testsuite/g++.dg/ext/v
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Target Milestone: ---
Target: powerpc*-*-*
c-c++-common/raw-string-6.c:5:18: error: unterminated raw string
c-c++-common/raw-string-6.c:5:1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78811
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78811
--- Comment #2 from David Edelsohn ---
Started somewhere between 243555 and 243578.
Requires -mcpu=power7 or lower. Works with -mcpu=power8.
Possibly r243578 combine.c change.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78417
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78417
--- Comment #3 from David Edelsohn ---
Bounty available!
:00 |2016-12-21
CC||dje at gcc dot gnu.org
Summary|Hard-coded C++ header paths |Hard-coded C++ header paths
|and relocation problem on |and relocation problem
|Windows
||2016-12-21
CC||dje at gcc dot gnu.org,
||wschmidt at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from David Edelsohn ---
Confirmed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71199
David Edelsohn changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
++
Assignee: unassigned at gcc dot gnu.org
Reporter: dje at gcc dot gnu.org
Blocks: 71737
Target Milestone: ---
Target: powerpc-ibm-aix*
The patch for PR 71737 introduced a new regression in libstdc++
libstdc++-v3/include/tr1/shared_ptr.h:556: internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79103
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79198
David Edelsohn changed:
What|Removed |Added
CC||dje at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664
--- Comment #16 from David Edelsohn ---
> That isn't an argument for -fno-sched-spec, it is an argument for a cost
> model which better matches the cost of the transformation, using the
> information available, without bloating the automaton.
501 - 600 of 1697 matches
Mail list logo
