On 2016-Feb-21, at 1:02 AM, Roman Divacky wrote:
>
> On Sat, Feb 20, 2016 at 03:26:58PM +0100, Dimitry Andric wrote:
>> On 20 Feb 2016, at 09:34, Roman Divacky wrote:
>>> Fwiw, I've just committed the patch to clang in r261422. You might want
>>> to keep using a local modification or ask dim@ t
On Sat, Feb 20, 2016 at 03:26:58PM +0100, Dimitry Andric wrote:
> On 20 Feb 2016, at 09:34, Roman Divacky wrote:
> > Fwiw, I've just committed the patch to clang in r261422. You might want
> > to keep using a local modification or ask dim@ to import that patch
> > to our copy of 3.8.
>
> I've ask
On 20 Feb 2016, at 09:34, Roman Divacky wrote:
> Fwiw, I've just committed the patch to clang in r261422. You might want
> to keep using a local modification or ask dim@ to import that patch
> to our copy of 3.8.
I've asked the LLVM release manager to consider merging this into the
3.8 branch. T
Thanks!
llvm bugzilla's 26605 did not having anything yet for this so I've copied over
your note. But I've left the status alone.
The next thing that I ran into looks nastier: c++'s exception handling is
broken.
#include
int main(void)
{
try { throw std::exception(); }
catch (std::e
Fwiw, I've just committed the patch to clang in r261422. You might want
to keep using a local modification or ask dim@ to import that patch
to our copy of 3.8.
Thanks for your diagnosis and testing!
Roman
On Thu, Feb 18, 2016 at 02:29:29PM -0800, Mark Millard wrote:
> On 2016-Feb-17, at 9:23 PM,
On 2016-Feb-17, at 9:23 PM, Mark Millard wrote:
>
> My fpr related notes/worries about the fix were wrong.
>
> I finally got some time to look at this again and I see that I somehow missed
> the following code when I looked before:
>
> // The calling convention either uses 1-2 GPRs or 1 FPR.
My fpr related notes/worries about the fix were wrong.
I finally got some time to look at this again and I see that I somehow missed
the following code when I looked before:
// The calling convention either uses 1-2 GPRs or 1 FPR.
Address NumRegsAddr = Address::invalid();
if (isInt || IsSo
By the way: Nothing tested or seen so far checks DOUBLE_OR_FLOAT handling.
That involves fr (fpr in va_list in clang terms) instead of gr/gpr. fr/fpr has
its own independent count and bound for using floating point registers vs.
using the overflow area. There is also condition register bit 6 tha
I used:
> Index: /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp
> ===
> --- /usr/src/contrib/llvm/tools/clang/lib/CodeGen/TargetInfo.cpp
> (revision 295601)
> +++ /usr/src/contrib/llvm/tools/clang/lib/CodeGen/Targe
On 2016-Feb-15, at 1:20 PM, Mark Millard wrote:
>
> On 2016-Feb-15, at 12:18 PM, Roman Divacky wrote:
>>
>> 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
On 2016-Feb-15, at 12:18 PM, Roman Divacky wrote:
>
> 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/lib/CodeGen/TargetInfo.c
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/lib/CodeGen/TargetInfo.cpp
> > ==
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/lib/CodeGen/TargetInfo.cpp
> ===
> --- tools/clang/lib/CodeGen/TargetInfo.cpp(revisio
Mark, I believe you're right. What do you think about this patch?
Index: tools/clang/lib/CodeGen/TargetInfo.cpp
===
--- tools/clang/lib/CodeGen/TargetInfo.cpp (revision 260852)
+++ tools/clang/lib/CodeGen/TargetInfo.cpp (wor
I'm top posting as the following can stand on its own fairly well.
On Sun Feb 14 23:46:14 UTC 2016 Nathan Whitehorn wrote:
> On 02/14/16 14:34, Mark Millard wrote:
> > clang's code base is not familiar material for me nor do I have solid
> > reference material for the FreeBSD TARGET_ARCH=powerp
On 02/14/16 14:34, Mark Millard wrote:
clang's code base is not familiar material for me nor do I have solid
reference material for the FreeBSD TARGET_ARCH=powerpc ABI rules so
the below has my guess work involved. The following code appears to
have hard wired a global, unvarying constant (8)
On 2016-Feb-14, at 11:29 AM, Roman Divacky wrote:
>
> 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
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
>
I've isolated another clang 3.8.0 TARGET_ARCH=powerpc SEGV problem that shows
up for using clang 3.8.0 to buildworld/installworld for powerpc.
> ls -l -n /
gets a SEGV. As listed in
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207175 ( and
https://llvm.org/bugs/show_bug.cgi?id=26605 ) th
19 matches
Mail list logo