https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443
--- Comment #11 from Joshua Kinard ---
(In reply to Joshua Kinard from comment #10)
> Created attachment 43166 [details]
> genrecog.ii temp data from failing build command
Forgot to add, this is generated from a checkout of commit id 1998c023a3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443
--- Comment #10 from Joshua Kinard ---
Created attachment 43166
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43166&action=edit
genrecog.ii temp data from failing build command
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443
--- Comment #9 from Joshua Kinard ---
(In reply to Eric Botcazou from comment #8)
> > FWIW, reversing PR59461 (some manual edits required) on gcc-7_1_0-release
> > compiles cleanly, which is the first time that's happened on this machine
> > unde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443
--- Comment #7 from Joshua Kinard ---
(In reply to Eric Botcazou from comment #6)
> Please retry with the current 7 branch, it contains additional fixes.
I did about a week ago. Tried building gcc-7-branch HEAD with both gcc-6.4.0
and gcc-5.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443
Joshua Kinard changed:
What|Removed |Added
Version|7.1.0 |7.2.0
Version|7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443
Joshua Kinard changed:
What|Removed |Added
Version|7.1.0 |7.2.0
Version|7.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443
--- Comment #3 from Joshua Kinard ---
It's just build/genrecog.c. I had a stale build environment file that was
still sending "-j3" to 'make'. I fixed that and restarted from where it last
left off, and it gets to genrecog.c and spent about ~20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81443
--- Comment #2 from Joshua Kinard ---
(In reply to Richard Biener from comment #1)
> What file is it compiling?
As far as I can tell, it looks somewhat random. I initially thought that
'build/genrecog.o' was a single file, but after several re-
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: kumba at gentoo dot org
Target Milestone: ---
I am attempting to compile gcc-7.1.0 on a 64-bit MIPS platform, targeting the
MIPS-III ISA, glibc-userland, N32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #41 from Joshua Kinard ---
(In reply to Andrew Pinski from comment #38)
> Does this work now?
Whatever the issue on MIPS/N32 was, it's resolved by dropping -Wl,-z,now. So
no longer an issue AFAICT.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #36 from Joshua Kinard ---
(In reply to Joshua Kinard from comment #35)
>
> It looks like it's my LDFLAGS, specifically with -Wl,-z,now.
It looks like this might be a problem with my toolchain, possibly in binutils,
and possibly onl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #35 from Joshua Kinard ---
(In reply to rguent...@suse.de from comment #34)
> On Thu, 14 Jan 2016, kumba at gentoo dot org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
> >
> > --- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #33 from Joshua Kinard ---
The problem may be tied to a particular CFLAG on glibc-n32 MIPS. I ran our
(Gentoo's) stage-building script, and forgot to block gcc-5.3.0 from building,
and it ended up completing. Difference between that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #32 from Joshua Kinard ---
(In reply to Richard Biener from comment #30)
> Any status update? Does bootstrap work on trunk (with --disable-checking)?
Okay, here's updates from the MIPS angle on a few configurations:
MIPS-IV, Big-en
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #27 from Joshua Kinard ---
(In reply to Richard Biener from comment #26)
> Don't hold your breath. Basically somebody who can reproduce it has to find
> the root-cause and a fix.
4.9.3 works, and the problem appears specific to genm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
--- Comment #25 from Joshua Kinard ---
Still present in gcc-5.2. Reverting commit r218976 also didn't help.
Reproduced on a second MIPS machine running N32 ABI as well. any idea if this
is being looked at for 5.3?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66038
Joshua Kinard changed:
What|Removed |Added
CC||kumba at gentoo dot org
--- Comment #23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #24 from Joshua Kinard ---
This might have been inadvertently fixed by this patch:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02282.html
Which is commit 0d18e650 in the master branch. Can't pin down when that was
merged into the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
Joshua Kinard changed:
What|Removed |Added
Version|4.8.0 |4.9.3
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #22 from Joshua Kinard ---
(In reply to Andrew Pinski from comment #21)
> (In reply to Joshua Kinard from comment #20)
> > Created attachment 33166 [details]
> > Disassembly of the ASM from 'sln' compiled by a non-working gcc-4.8.0.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #20 from Joshua Kinard ---
Created attachment 33166
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33166&action=edit
Disassembly of the ASM from 'sln' compiled by a non-working gcc-4.8.0.
This is the objdump disassembly of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #19 from Joshua Kinard ---
Created attachment 33165
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33165&action=edit
Disassembly of the ASM from 'sln' compiled by a known working gcc-4.8.0.
This is the objdump disassembly of th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
Joshua Kinard changed:
What|Removed |Added
Component|c++ |regression
Version|4.9.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #17 from Joshua Kinard ---
(In reply to Joshua Kinard from comment #16)
> In 'all-stage2-gcc'. That's right around the commit you're referencing, so
> I went ahead and reversed these four commits:
>
> 1. 39a8c5eaded1e5771a941c56a49c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #16 from Joshua Kinard ---
(In reply to Andrew Pinski from comment #15)
> (In reply to Joshua Kinard from comment #14)
> > (In reply to Andrew Pinski from comment #13)
> > > What is the kernel version? There has been some recent (thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #14 from Joshua Kinard ---
(In reply to Andrew Pinski from comment #13)
> What is the kernel version? There has been some recent (this year) fixes
> inside the kernel for futex.
>
> Though I admit I have seen this just recently when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #12 from Joshua Kinard ---
So I discovered the presence of the --disable-linux-futex configure flag,
rebuilt gcc-4.9.0 with it, and tested my conftest.c testcase, and can confirm
that the resulting binary no longer hangs on a futex sy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #11 from Joshua Kinard ---
I also have another test case from glibc itself, where when compiling
glibc-2.19 w/ gcc-4.8.x or greater, at the end, it creates a statically-linked
version of 'ln' as 'sln', and tries to run that. That bin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #10 from Joshua Kinard ---
I rebuilt both glibc-2.19 and gcc-4.8.3 w/ debugging, though gcc's build system
managed to strip out or optimize away some of the debugging code. That said,
it's enough to see that the hang is being trigger
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #9 from Joshua Kinard ---
Rebuilt/upgraded to gcc-4.8.3 against the patched glibc-2.19, and I am still
getting the hang.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #8 from Joshua Kinard ---
(In reply to Joshua Kinard from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > This is the patch which I used for glibc to fix some libstdc++ issues:
>
> Okay, so it's in glibc. Is your patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #7 from Joshua Kinard ---
(In reply to Andrew Pinski from comment #6)
> This is the patch which I used for glibc to fix some libstdc++ issues:
Okay, so it's in glibc. Is your patch in glibc yet? It applies cleanly to
2.19, but carr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #4 from Joshua Kinard ---
It looks like the bug might be somewhere in __cxa_guard_acquire() in
libstdc++-v3/lubsupc++/guard.cc, as that references glibc and futexes. strace
indicates that the same syscall was invoked twice in a row -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #3 from Joshua Kinard ---
(In reply to Jonathan Wakely from comment #2)
> Can you provide a stack trace to show which constructor/destructor it's
> hanging in?
Hopefully you mean a backtrace from gdb. Not finding a lot of info on do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #1 from Joshua Kinard ---
Forgot the gcc -v info:
gcc -v
Using built-in specs.
COLLECT_GCC=/usr/mips-unknown-linux-gnu/gcc-bin/4.9.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/mips-unknown-linux-gnu/4.9.0/lto-wrapper
Target: mips-unknow
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kumba at gentoo dot org
CC: toolchain at gentoo dot org
Host: mips-unknown-linux-gnu
Target: mips-unknown-linux-gnu
--- Comment #2 from kumba at gentoo dot org 2008-11-12 01:01 ---
I ran into this too. The problem flag is -foptimize-sibling-calls. You can
pass that with -O1 to trigger the bug, but not with -O0. Some other
optimization in -O1 seems to be mixing with this one and causing the flaw
--- Comment #3 from kumba at gentoo dot org 2008-10-25 16:58 ---
The patch did work, but I've since moved onto using 4.3.2, which has no
problems. Closing as WORKSFORME
--
kumba at gentoo dot org changed:
What|Removed |
--- Comment #2 from kumba at gentoo dot org 2008-07-31 01:21 ---
My apologies! I searched in several areas (google, gcc ML, gcc-bugs, etc..),
and nothing turned up at first, so I thought I'd log a bug. Bit behind and
playing catch up on a number of things.
I'll test the li
sion: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kumba at gentoo dot org
GCC build triplet: mips-linux-gnu
GCC host triplet: mips-linux-gnu
GCC target triplet: mips-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36969
--- Comment #4 from kumba at gentoo dot org 2008-04-21 02:13 ---
Just ran into this myself, with the following error on glibc-2.7, building with
gcc-4.3.0, but on a different file:
plural-exp.c: In function '__gettext_extract_plural':
plural-exp.c:157: error: unable to find
--- Comment #2 from kumba at gentoo dot org 2006-01-20 06:54 ---
Created an attachment (id=10684)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10684&action=view)
Use dmove/move where appropriate
Typo in original, this is the correct version.
--
kumba at gentoo
--- Comment #1 from kumba at gentoo dot org 2006-01-20 06:48 ---
Created an attachment (id=10683)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10683&action=view)
Use dmove/move where appropriate
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25871
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kumba at gentoo dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25871
--- Comment #7 from kumba at gentoo dot org 2005-12-16 01:55 ---
Got a confirmation the issue exists on Linux/Sparc as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437
--- Comment #6 from kumba at gentoo dot org 2005-12-16 00:51 ---
Created an attachment (id=10510)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10510&action=view)
Preprocessed Output of testcase at -O1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437
--- Comment #5 from kumba at gentoo dot org 2005-12-16 00:50 ---
Created an attachment (id=10509)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10509&action=view)
Preprocessed Output of testcase at -O0
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437
--- Comment #4 from kumba at gentoo dot org 2005-12-16 00:47 ---
Forgot to add, the failure itself was traceable to the RC5_32_set_key()
function in rc5_skey.c in the original files. In the attached testcase, the
function in question begins on Line #554.
--
http://gcc.gnu.org
--- Comment #3 from kumba at gentoo dot org 2005-12-16 00:44 ---
Created an attachment (id=10508)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10508&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437
--- Comment #2 from kumba at gentoo dot org 2005-12-16 00:42 ---
Created an attachment (id=10507)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10507&action=view)
What Really Happens
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437
--- Comment #1 from kumba at gentoo dot org 2005-12-16 00:42 ---
Created an attachment (id=10506)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10506&action=view)
Expected Results
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437
iority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kumba at gentoo dot org
GCC build triplet: mips-unknown-linux-gnu
GCC host triplet: mips-unknown-linux-gnu
GCC target triplet: mips-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25437
52 matches
Mail list logo