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 patc
On Mon, May 24, 2010 at 4:52 AM, Steve Kargl
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: elf_update() failed:
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.
lto-wrapper
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.
> >
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
http://gcc.gnu.org/ml/gcc-testresults/2010-05/ms
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 lto_obj_build_section_table() function in lto-elf.c calls
> elf_ge
On Sat, May 22, 2010 at 11:07:44PM +0200, Richard Guenther wrote:
> On Sat, May 22, 2010 at 10:29 PM, Steve Kargl
> wrote:
> > Guys,
> >
> > I only read the gcc@ archive, so sorry about breaking the thread.
> > Testing with gfortran finds
> >
> > FreeBSD's libelf with no patches.
> >
> > # of unex
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 test
On Sat, May 22, 2010 at 10:29 PM, Steve Kargl
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 34177
> # of unexpe
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 unreso
On Thu, May 20, 2010 at 7:19 PM, Kai Wang 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 most trivia
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 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: internal
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_err
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 ful
15 matches
Mail list logo
