Hi,
In a followup to
https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html
I attempted to fix gnu ld in base to fix the wrongly set bit.
The following patch http://www.vlakno.cz/~rdivacky/ppc64.exceptions.fix.patch
switches a few computations to happen in 64bits instead of
Hi,
Currently C++ exceptions don't work on PowerPC64 when compiled with clang. I
looked at why and discovered the following.
With the default gcc unwinder and libstdc++ this simple test program:
#include
int main()
{
try {
std::cout << "Before\n";
pe = 50
> Type = 64
> Type = 50
> Type = 64
> Type = 10
> Type = 10
> Type = 50
> Type = 64
> Type = 50
> Type = 48
> Type = 10
> Type = 50
> Type = 50
> Type = 64
> Type = 64
> Type = 50
> Type = 64
> Type = 50
> Type = 50
> Type =
Go with Out.
On Tue, Jan 17, 2017 at 01:53:14PM -0800, Mark Millard wrote:
> On 2017-Jan-17, at 11:54 AM, Roman Divacky wrote:
>
> . . .
> > I wonder if it doesnt work because of my first patch (the one to turn GOT
> > reloc into PLT one).
> >
> > LLD understa
041a is .dynstr
> 0x1420 - 0x1468 is .rela.plt <<<<<= note
> 0x1468 - 0x1474 is .eh_frame_hdr
> 0x10010000 - 0x100104f8 is .text
> 0x10010500 - 0x1001052c is
===
> Mark Millard
> markmi at dsl-only.net
>
> On 2017-Jan-12, at 5:58 PM, Mark Millard wrote:
>
> On 2017-Jan-12, at 11:22 AM, Roman Divacky wrote:
>
> > Can you check if the TOC is correct? LLD assumes this:
> >
> > static uint64_t PPC64TocOffset = 0x8000;
&
Can you try this patch?
Index: tools/lld/ELF/Target.cpp
===
--- tools/lld/ELF/Target.cpp(revision 291691)
+++ tools/lld/ELF/Target.cpp(working copy)
@@ -1062,7 +1062,8 @@
}
PPC64TargetInfo::PPC64TargetInfo() {
- PltRel =
t;
> > On 2017-Jan-8, at 1:03 AM, Roman Divacky wrote:
> >
> >> I think we should add the @toc notations to all the places where it's
> >> needed.
> >> Can you submit such a patch (perhaps with the one for adding 0 to the cmp
> >> instruction) so the
n should
> > make clang 3.9.1 targeting powerpc64 do the right thing for
> > this issue.]
> >
> > On 2017-Jan-7, at 2:07 PM, Mark Millard wrote:
> >
> >> On 2017-Jan-7, at 12:51 AM, Roman Divacky wrote:
> >>
> >>> That's a great pro
ain using
> R_PPC64_TOC16_DS
> with .toc in locore.o (that does work).]
>
> On 2016-Dec-12, at 1:09 PM, Roman Divacky wrote:
>
> > Ping Can you take a look Nathan?
> >
> > Thanks! Roman
> >
> > On Thu, Dec 08, 2016 at 11:14:52PM +0100, Roman Divacky wro
Ping Can you take a look Nathan?
Thanks! Roman
On Thu, Dec 08, 2016 at 11:14:52PM +0100, Roman Divacky wrote:
> I believe the code comes from sys/powerpc/aim/locore64.S and if you compare
> the different values from the disssembly with the .S code you can see
> it's __tocbase an
elated information here.]
>
> On 2016-Dec-8, at 10:55 AM, Roman Divacky wrote:
>
> > Can you try to investigate why it dies? I am not convinced -mminimal-toc
> > would result in a boot failure. I think the kernel would fail to link.
>
> I give information for bo
===
> Mark Millard
> markmi at dsl-only.net
>
> On 2016-Dec-7, at 4:11 PM, Mark Millard <mar...@dsl-only.net> wrote:
>
> On 2016-Dec-7, at 11:00 AM, Roman Divacky wrote:
>
> > Can the compiler you built with the patch process this file:
> >
> &g
Can you try this patch?
Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
===
--- llvm/lib/Target/PowerPC/PPCInstrInfo.td (revision 288675)
+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td (working copy)
@@ -2373,6 +2373,12 @@
def
Mark,
__builtin_dwarf_cfa() is lowered in clang to llvm intrinsic eh_dwarf_cfa.
There's a depth argument (which defaults to 0, saying it's correct for most
targets).
Then the intrinsic gets lowered in SelectionDAG using
PPCTargetLowering::LowerFRAMEADDR()
Can you check that 1) the depth
On Mon, Feb 15, 2016 at 12:17:50PM -0800, Mark Millard wrote:
> On 2016-Feb-15, at 11:11 AM, Roman Divacky wrote:
> >
> > Mark, I believe you're right. What do you think about this patch?
> >
> > Index: tools/clang
gt; above is DUAL_GP.) But for what I'm dealing with here it has the following
> extra wording at the very end of its OTHER section:
>
> > If gr>9 and the type is DUAL_GP ,or . . ., or . . ., then set gr = 11 (to
> > prevent subsequent SINGLE_GPs from being placed
Fwiw, the code to handle the vaarg is in
tools/clang/lib/CodeGen/TargetInfo.cpp:PPC32_SVR4_ABIInfo::EmitVAArg()
You can take a look to see whats wrong.
On Sat, Feb 13, 2016 at 07:03:29PM -0800, Mark Millard wrote:
> I've isolated another clang 3.8.0 TARGET_ARCH=powerpc SEGV problem that shows
Fwiw, LLVM expect 16B aligned stack on PowerPC.
On Sun, Jan 31, 2016 at 05:55:20AM -0800, Mark Millard wrote:
> 3 quick FreeBSD for powerpc (32-bit) questions:
>
>
> A) For PowerPC (32-bit) what is the stack alignment requirement by the ABI(s)
> that FreeBSD targets?
>
> B) Are signal
Can you file a bug in llvm bugzilla?
On Sat, Jan 30, 2016 at 03:00:26AM -0800, Mark Millard wrote:
> I got around to trying some more use of the 3.8.0 clang based world on
> powerpc (32 bit) (now -r294962 based) and ran into:
>
> A) Segmentation faults during signal handlers in syslogd, nfsd,
clang 3.8 support soft-float on PPC natively, no need for the
-mllvm -disable-ppc-float-in-variadic=true hack anymore.
Roman
On Fri, Jan 15, 2016 at 11:07:59PM -0800, Mark Millard wrote:
> At least for amd64 clang 3.8.0 -> powerpc via TARGET_ARCH=powerpc buildkernel
> I get the following
On Thu, Jan 14, 2016 at 01:54:06AM -0800, Mark Millard wrote:
> Context: projects/clang380-import based amd64 FreeBSD used to try building
> for powerpc64
>
> In csu/powerpc64/Makefile I replaced:
>
> > CFLAGS+=-I${.CURDIR}/../common \
> > -I${.CURDIR}/../../libc/include
On Thu, Dec 10, 2015 at 11:56:55AM -0800, Mark Millard wrote:
> I have submitted bug 205183 for powerpc64's 11.0-CURRENT r291745 system clang
> 3.7 crashing when compiling contrib/atf/atf-sh/atf-check.cpp during
> buildworld. The backtrace and a .zip of the atf-check-a96a93.cpp and
>
I used this script to build with gcc 4.9:
https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh
Buildling sys/i386/boot2 failed:
...
output: fmt=bin size=21ef text=200 data=1fef org=0 entry=0
-1007 bytes available
*** Error code 1
Oof, this is going
On Thu, Sep 11, 2014 at 05:04:06PM -0700, Steve Kargl wrote:
What's the current status for running clang on sparc64?
Last time we played with this (february?) it was able to compile
a seemingly working world. So I guess it's not that terribly broken.
We didnt test that much stuff though.
In
On Sat, Sep 13, 2014 at 09:51:35AM -0700, Steve Kargl wrote:
On Sat, Sep 13, 2014 at 10:23:22AM +0200, Roman Divacky wrote:
On Thu, Sep 11, 2014 at 05:04:06PM -0700, Steve Kargl wrote:
What's the current status for running clang on sparc64?
Last time we played with this (february
Fwiw, I fixed this upstream. The version 3.5 will hae this. Thanks
again for the report!
On Wed, Jul 17, 2013 at 04:13:41PM -0400, Kurt Lidl wrote:
I noticed this issue this morning, while looking at a unrelated
compilation failure. I was using clang on an amd64 machine,
running a system
Yes, this is because the FreeBSD driver toolchain shares the same
infrastructure with Linux. So we stat ~200 linux dirs :(
This rys.vlakno.cz/~rdivacky/freebsd-driver.patch proof of concept
patch fixes it by unsharing FreeBSD from Linux but I am not
convinced it's worth it.
It should also be
On Fri, Jan 25, 2013 at 02:47:19AM -0600, Mark Linimon wrote:
On Fri, Jan 25, 2013 at 08:41:11AM +, David Chisnall wrote:
I think all of the ports that don't build with clang are now explicitly
depending on gcc.
Nope. We switched some of the most notorious failures, but hundreds
more
LLVM by default turns these:
case LibFunc::copysign: case LibFunc::copysignf: case LibFunc::copysignl:
case LibFunc::fabs: case LibFunc::fabsf: case LibFunc::fabsl:
case LibFunc::sin: case LibFunc::sinf: case LibFunc::sinl:
case LibFunc::cos: case
Fwiw, this seems to have been fixed as of a few minutes ago.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120910/150720.html
Steve, can you please test llvm/clang from (their) svn and report
back? We can import a newer snapshot if all is ok.
Thank you.
On Fri, Sep 14, 2012 at
Is this correct?
lev ~$ ./cos 1.23456789e20
6.031937e-01
-9.629173e-02
2.814722e-01
If so I believe the issue is fixed.
On Sat, Sep 15, 2012 at 03:48:38PM +0200, Tijl Coosemans wrote:
On 15-09-2012 14:48, Roman Divacky wrote:
Fwiw, this seems to have been fixed as of a few minutes ago
tl;dr: Clang will become the default compiler for x86 architectures on
2012-11-04
There was a chorus of voices talking about ports already. My POV
is that suggesting to 'fix remaining ports to work with clang' is
just a nonsense. You are proposing to fork the development of all the
On Tue, Sep 11, 2012 at 03:21:22PM +0300, Konstantin Belousov wrote:
On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote:
tl;dr: Clang will become the default compiler for x86 architectures on
2012-11-04
There was a chorus of voices talking about ports already. My POV
On Tue, Sep 11, 2012 at 08:12:30AM -0700, Steve Kargl wrote:
On Tue, Sep 11, 2012 at 04:27:55PM +0200, Tijl Coosemans wrote:
On 11-09-2012 16:10, Dimitry Andric wrote:
On 2012-09-11 15:24, Steve Kargl wrote:
What is important is whether software built with clang functions
correctly.
On Tue, Nov 08, 2011 at 08:55:39AM +0100, Dimitry Andric wrote:
On 2011-11-08 01:25, Alexander Best wrote:
i've seen dozens of issues, where people set CPUTYPE=native. although this
works in a lot of cases, it doesn't in others. why don't we simply add
something like
. if ${CPUTYPE} ==
On Mon, Aug 29, 2011 at 05:50:26PM -0700, Pedro F. Giffuni wrote:
Hi;
This new CLang + Valgrind-like feature announced is very cool:
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-August/016671.html
Homepage: http://sva.cs.illinois.edu/index.html
It doesn't look difficult to package
On Fri, Jun 10, 2011 at 09:53:38AM -0600, Warner Losh wrote:
Hey Marcel,
I don't mean to throw cold water at your enthusiasm, but I thought I heard
that upstream llvm was in the process of decommissioning ia64 support. Did I
hear wrong?
Quite :) LLVM removed their IA64 backend a long
fwiw, this is what I have:
http://lev.vlakno.cz/~rdivacky/boot2-diet.patch
with some llvm changed (-mrtd implementation + earlycse at the
end of -O2) I am still at -113 bytes short on UFS1+UFS2 boot2
this is with latest llvm, with the one in fbsd it was at roughly -80
(stack alignment changes)
On Sat, Feb 19, 2011 at 01:01:36AM +, Alexander Best wrote:
hi everybody,
r218745 triggered quite a discussion about dead code in boot2.c. i talked to
roman (rdivacky@) and we were trying to improve the situation so that boot2
would build with clang 2.8 (base) and the latest development
On Mon, Jan 31, 2011 at 04:27:55PM +, Alexander Best wrote:
On Sat Jan 1 11, Alexander Best wrote:
On Sat Jan 1 11, Roman Divacky wrote:
clang -O2 -pipe -march=native -fpic -fvisibility=hidden
-DVISIBILITY_HIDDEN -g -std=gnu99 -fstack-protector -Wsystem-headers
-Wall -Wno
On Thu, Jan 20, 2011 at 01:45:03PM -0800, Steve Kargl wrote:
On Thu, Jan 20, 2011 at 07:54:49PM +0100, Roman Divacky wrote:
ok, I sat down and implemented what Hans Ottevanger told me to do :)
http://lev.vlakno.cz/~rdivacky/clang-gprof.patch
Wow. Thanks.
I tried
On Mon, Jan 17, 2011 at 10:44:11AM -0800, Steve Kargl wrote:
How does one build an executable for profiling with clang?
LLVM (and thus clang) does not support GPROF profiling.
clang -o testf -O2 -march=native -pipe -static -pg -I/usr/local/include
-I../mp testf.c -L/usr/local/lib -L../mp
On Thu, Dec 30, 2010 at 06:46:16PM +, Alexander Best wrote:
On Thu Dec 30 10, Roman Divacky wrote:
On Thu, Dec 30, 2010 at 06:40:48PM +, Alexander Best wrote:
On Thu Dec 30 10, Roman Divacky wrote:
On Thu, Dec 30, 2010 at 12:20:33AM +, Alexander Best wrote:
On Tue Dec 28
-march=native in clang works by detecting CPU name
and passing it (if found) to llvm. if the CPU is not
detected nothing is passed.
nocona is supported
ie. leaving the CPUNAME empty or specifying it to nocona should
be equivalent to setting it to native.
can you apply this patch:
Index:
45 matches
Mail list logo
