On Mon, May 24, 2010 at 4:52 AM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
Kai,
I tested your patch posted here:
http://gcc.gnu.org/ml/gcc/2010-05/msg00445.html
to address the issue
% cat x.c
int main() { }
% gccvs -flto x.c
% gccvs -fwhopr x.c
lto1: fatal error:
On Sun, 23 May 2010, Kai Wang wrote:
Based on this, it will be great if you can apply your patch to
-CURRENT, 8-STABLE and 7-STABLE.
I'll see what I can do.
Thanks!
The elf_update() failure is caused by an alignment check inside
FreeBSD elf_update(). [...]
Anyway, I attached a patch for
On Sat, 22 May 2010, Gerald Pfeifer wrote:
I'll be submitting result for that around noon your time tomorrow-
Right now I am testing vanilla GCC and patched FreeBSD libelf, my
tester is just rather slow.
Like Kai's patch to FreeBSD's libelf
On Sun, May 23, 2010 at 12:48:20AM +0200, Gerald Pfeifer wrote:
On Thu, 20 May 2010, Kai Wang wrote:
The elf_getbase() API in FreeBSD libelf can only be called using an
archive member ELF descriptor. It will return -1 (indicates an error)
when called with a regular ELF object.
The
Kai,
I tested your patch posted here:
http://gcc.gnu.org/ml/gcc/2010-05/msg00445.html
to address the issue
% cat x.c
int main() { }
% gccvs -flto x.c
% gccvs -fwhopr x.c
lto1: fatal error: elf_update() failed: Layout constraint violation
compilation terminated.
Guys,
I only read the gcc@ archive, so sorry about breaking the thread.
Testing with gfortran finds
FreeBSD's libelf with no patches.
=== gfortran Summary ===
# of expected passes34177
# of unexpected failures40
# of expected failures 33
# of
On Sat, May 22, 2010 at 10:29 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
Guys,
I only read the gcc@ archive, so sorry about breaking the thread.
Testing with gfortran finds
FreeBSD's libelf with no patches.
=== gfortran Summary ===
# of expected passes
On Sat, 22 May 2010, Richard Guenther wrote:
Hm, so you didn't test FreeBSD's libelf without Kias patch but my GCC patch
applied. (at least my patch doesn't make the situation worse for any case
it seems)
I'll be submitting result for that around noon your time tomorrow-
Right now I am
On Sat, May 22, 2010 at 11:07:44PM +0200, Richard Guenther wrote:
On Sat, May 22, 2010 at 10:29 PM, Steve Kargl
s...@troutmask.apl.washington.edu wrote:
Guys,
I only read the gcc@ archive, so sorry about breaking the thread.
Testing with gfortran finds
FreeBSD's libelf with no
On Thu, May 20, 2010 at 7:19 PM, Kai Wang k...@freebsd.org wrote:
On Sun, May 02, 2010 at 11:38:39PM +0200, Gerald Pfeifer wrote:
As http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00120.html shows,
*-unknown-freebsd* exhibits tons of failures around LTO.
I dug a bit deeper, and even the
On Sun, May 02, 2010 at 11:38:39PM +0200, Gerald Pfeifer wrote:
As http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00120.html shows,
*-unknown-freebsd* exhibits tons of failures around LTO.
I dug a bit deeper, and even the most trivial test program
int main() { }
fails with
lto1:
On Sun, May 2, 2010 at 11:38 PM, Gerald Pfeifer ger...@pfeifer.com wrote:
As http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00120.html shows,
*-unknown-freebsd* exhibits tons of failures around LTO.
I dug a bit deeper, and even the most trivial test program
int main() { }
fails with
As http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00120.html shows,
*-unknown-freebsd* exhibits tons of failures around LTO.
I dug a bit deeper, and even the most trivial test program
int main() { }
fails with
lto1: internal compiler error: compressed stream: data error
Please submit a
On 02/05/2010 22:38, Gerald Pfeifer wrote:
#0 diagnostic_action_after_output () at /usr/test/gcc/gcc/diagnostic.c:193
#1 0x08136d6e in diagnostic_report_diagnostic (context=0x8926400,
diagnostic=0xbfbfe5f4) at /usr/test/gcc/gcc/diagnostic.c:472
#2 0x0813754a in internal_error
14 matches
Mail list logo
