Proposed patches for Clang 3.5.1

Hi,

I’d like to propose the following patches for inclusion in Clang 3.5.1.

Proposed clang patches:

· r213769 - Fix test/Driver/cl-x86-flags.c by providing explicit –target

· r214025 - [Driver][Mips] Check output of -dynamic-linker arguments by the Clang driver

· r214662 - [Mips] Add the mips64-linux-gnu target to the test case to check in128 type handling.

· r217147 - [mips] Zero-sized structs cannot be ignored in MipsABIInfo::classifyReturnType() for O32

Proposed llvm patches:

· r216920 - Fix left shifts of negative values in MipsDisassembler.

· r221408 - [mips64] Fix MIPS64 exception personality encoding

· r221453 - [mips] Tolerate the use of the %z inline asm operand modifier with non-immediates.

· r216262 - [mips] Don’t use odd-numbered float registers for double arguments for fastcc calling convention if FP is 64-bit and +nooddspreg is used.

· r217257 - [mips] Change Feature-related types from unsigned to uint64_t in MipsAsmParser. No functional changes.

· r218745 - [mips] Fix disassembly of [ls][wd]c[23], cache, and pref

I’d also like to propose the inclusion of the recent ABI fixes to the Mips target but I’m not sure this is a good idea. I’m having difficulty sorting out the dependencies for these at the moment since they seem to depend on some of Eric Christopher’s Subtarget/TargetMachine refactoring. It may also be a bit large for a stable release since it’s ~50 LLVM patches and ~8 Clang patches and refactors a large amount of the Mips calling convention code. What do you think?

Daniel Sanders

Leading Software Design Engineer, MIPS Processor IP

Imagination Technologies Limited

www.imgtec.com

Hi,

I'd like to propose the following patches for inclusion in Clang 3.5.1.

Proposed clang patches:

* r213769 - Fix test/Driver/cl-x86-flags.c by providing explicit -target

This one seems OK, but I would feel better if the X86 code owner approved
it too. Could you be pull this request into a separate mail and cc him.

* r214025 - [Driver][Mips] Check output of -dynamic-linker arguments by the Clang driver

* r214662 - [Mips] Add the `mips64-linux-gnu` target to the test case to check `in128` type handling.

* r217147 - [mips] Zero-sized structs cannot be ignored in MipsABIInfo::classifyReturnType() for O32

These look OK to me you you can merge them to the 3.5 branch yourself,
or if you aren't comfortable with this, I can do it. If you decide
to merge them yourself, make sure you use the merge script so we get a
consistent commit message format: utils/release/merge.sh

Note this only works with SVN. If you use git, you may need to manually paste
the svn commit log.

Proposed llvm patches:

* r216920 - Fix left shifts of negative values in MipsDisassembler.

* r221408 - [mips64] Fix MIPS64 exception personality encoding

* r221453 - [mips] Tolerate the use of the %z inline asm operand modifier with non-immediates.

* r216262 - [mips] Don't use odd-numbered float registers for double arguments for fastcc calling convention if FP is 64-bit and +nooddspreg is used.

This all look OK to me, go ahead an merge.

* r217257 - [mips] Change Feature-related types from unsigned to uint64_t in MipsAsmParser. No functional changes.

I'm a little concerned this might break the shared library ABI. We will need
to verify that it doesn't before it gets merged.

* r218745 - [mips] Fix disassembly of [ls][wd]c[23], cache, and pref

This looks OK to me.

I'd also like to propose the inclusion of the recent ABI fixes to the Mips target but I'm not sure this is a good idea. I'm having difficulty sorting out the dependencies for these at the moment since they seem to depend on some of Eric Christopher's Subtarget/TargetMachine refactoring. It may also be a bit large for a stable release since it's ~50 LLVM patches and ~8 Clang patches and refactors a large amount of the Mips calling convention code. What do you think?

Can you give me an idea of how important these fixes are? My personal
feeling is that big fixes like this can sometimes be OK as long as they
are mostly contained to a specific target and that target isn't X86
or ARM. In this case, it would help too if you could provide some release
testing for MIPS.

Are you planning on back-porting these patches to 3.5 for personal use,
even if they aren't going to be included in the official release?

-Tom

I was involved in this, it's a very benign test-only fix that will make the
test pass when clang's default target is not x86. Please merge it.

From: Tom Stellard [mailto:tom@stellard.net]
Sent: 24 November 2014 17:15
To: Daniel Sanders
Cc: LLVM Developers Mailing List (llvmdev@cs.uiuc.edu)
Subject: Re: Proposed patches for Clang 3.5.1

> Hi,
>
> I'd like to propose the following patches for inclusion in Clang 3.5.1.
>
> Proposed clang patches:
>
> * r213769 - Fix test/Driver/cl-x86-flags.c by providing explicit -target
>

This one seems OK, but I would feel better if the X86 code owner approved
it too. Could you be pull this request into a separate mail and cc him.

Ok.

> * r214025 - [Driver][Mips] Check output of -dynamic-linker arguments
by the Clang driver
>
> * r214662 - [Mips] Add the `mips64-linux-gnu` target to the test case to
check `in128` type handling.
>
> * r217147 - [mips] Zero-sized structs cannot be ignored in
MipsABIInfo::classifyReturnType() for O32

These look OK to me you you can merge them to the 3.5 branch yourself,
or if you aren't comfortable with this, I can do it. If you decide
to merge them yourself, make sure you use the merge script so we get a
consistent commit message format: utils/release/merge.sh

Note this only works with SVN. If you use git, you may need to manually
paste
the svn commit log.

Thanks. I'm happy to merge them.

> Proposed llvm patches:
>
> * r216920 - Fix left shifts of negative values in MipsDisassembler.
>
> * r221408 - [mips64] Fix MIPS64 exception personality encoding
>
> * r221453 - [mips] Tolerate the use of the %z inline asm operand
modifier with non-immediates.
>
> * r216262 - [mips] Don't use odd-numbered float registers for double
arguments for fastcc calling convention if FP is 64-bit and +nooddspreg is
used.
>

This all look OK to me, go ahead an merge.

Thanks.

> * r217257 - [mips] Change Feature-related types from unsigned to
uint64_t in MipsAsmParser. No functional changes.
>

I'm a little concerned this might break the shared library ABI. We will need
to verify that it doesn't before it gets merged.

I don't think this will break it since the two functions that are changed are private to MipsAsmParser and our Feature* constants in MipsGenSubtargetInfo.inc are already uint64_t. However, I haven't supported a shared library ABI before so I can't be sure. How would I check?

> * r218745 - [mips] Fix disassembly of [ls][wd]c[23], cache, and pref
>

This looks OK to me.

Thanks.

> I'd also like to propose the inclusion of the recent ABI fixes to the Mips
target but I'm not sure this is a good idea. I'm having difficulty sorting out the
dependencies for these at the moment since they seem to depend on some
of Eric Christopher's Subtarget/TargetMachine refactoring. It may also be a
bit large for a stable release since it's ~50 LLVM patches and ~8 Clang patches
and refactors a large amount of the Mips calling convention code. What do
you think?

Can you give me an idea of how important these fixes are? My personal
feeling is that big fixes like this can sometimes be OK as long as they
are mostly contained to a specific target and that target isn't X86
or ARM.

Without them, the calling convention for big-endian 64-bit Mips targets is very badly broken. Clang is generally consistent with itself, but interlinking with GCC-compiled code doesn't work. When I started on this work ~4500 of 5000 tests generated by ABITestGen.py produced incorrect output when mixing GCC and Clang objects. 32-bit and little-endian Mips targets are ok except for a couple rare corner cases (e.g. 128-bit float return values).

Known problems include:
* Inreg struct arguments (and return values) of <64-bits are passed in the least significant bits of a register instead of the most significant
* Arguments of <64-bits that are passed via the stack are in the wrong portion of the stack slot.
* 128-bit floats are returned in the wrong registers. This one is actually a long-standing GCC bug that has become the de-facto standard.
* Small structures in varargs are read from the wrong part of the stack slot. This doesn't work for GCC either.
* Floating point arguments are passed correctly, but fixing some of the above bugs can easily break soft-float

With these patches, big-endian 64-bit Mips targets successfully interlinks with GCC for almost everything I've tried. So far I've tested the first 100,000 ABITestGen.py tests for the N32 ABI (64-bit with 32-bit pointers), 10,000 for the N64 ABI (64-bit), and various varargs tests for both ABI's. The one known failure is small structures in vararg functions and this turns out to be broken on GCC too.

In this case, it would help too if you could provide some release
testing for MIPS.

I'll be testing natively for MIPS32, and MIPS32r2 (both endians). I'll also be testing cross-compilation for MIPS64r2 (both endians) and MIPS64r6 (both endians).

Are you planning on back-porting these patches to 3.5 for personal use,
even if they aren't going to be included in the official release?

If one of our customers requires it, yes. Otherwise, I'll stick to official releases. Sorry for the vague answer on this one.

From: Tom Stellard [mailto:tom@stellard.net]
Sent: 24 November 2014 17:15
To: Daniel Sanders
Cc: LLVM Developers Mailing List (llvmdev@cs.uiuc.edu)
Subject: Re: Proposed patches for Clang 3.5.1

Hi,

I’d like to propose the following patches for inclusion in Clang 3.5.1.

Proposed clang patches:

  • r213769 - Fix test/Driver/cl-x86-flags.c by providing explicit -target

This one seems OK, but I would feel better if the X86 code owner approved
it too. Could you be pull this request into a separate mail and cc him.

Ok.

  • r214025 - [Driver][Mips] Check output of -dynamic-linker arguments
    by the Clang driver

  • r214662 - [Mips] Add the mips64-linux-gnu target to the test case to
    check in128 type handling.

  • r217147 - [mips] Zero-sized structs cannot be ignored in
    MipsABIInfo::classifyReturnType() for O32

These look OK to me you you can merge them to the 3.5 branch yourself,
or if you aren’t comfortable with this, I can do it. If you decide
to merge them yourself, make sure you use the merge script so we get a
consistent commit message format: utils/release/merge.sh

Note this only works with SVN. If you use git, you may need to manually
paste
the svn commit log.

Thanks. I’m happy to merge them.

Proposed llvm patches:

  • r216920 - Fix left shifts of negative values in MipsDisassembler.

  • r221408 - [mips64] Fix MIPS64 exception personality encoding

  • r221453 - [mips] Tolerate the use of the %z inline asm operand
    modifier with non-immediates.

  • r216262 - [mips] Don’t use odd-numbered float registers for double
    arguments for fastcc calling convention if FP is 64-bit and +nooddspreg is
    used.

This all look OK to me, go ahead an merge.

Thanks.

  • r217257 - [mips] Change Feature-related types from unsigned to
    uint64_t in MipsAsmParser. No functional changes.

I’m a little concerned this might break the shared library ABI. We will need
to verify that it doesn’t before it gets merged.

I don’t think this will break it since the two functions that are changed are private to MipsAsmParser and our Feature* constants in MipsGenSubtargetInfo.inc are already uint64_t. However, I haven’t supported a shared library ABI before so I can’t be sure. How would I check?

  • r218745 - [mips] Fix disassembly of [ls][wd]c[23], cache, and pref

This looks OK to me.

Thanks.

I’d also like to propose the inclusion of the recent ABI fixes to the Mips
target but I’m not sure this is a good idea. I’m having difficulty sorting out the
dependencies for these at the moment since they seem to depend on some
of Eric Christopher’s Subtarget/TargetMachine refactoring. It may also be a
bit large for a stable release since it’s ~50 LLVM patches and ~8 Clang patches
and refactors a large amount of the Mips calling convention code. What do
you think?

Can you give me an idea of how important these fixes are? My personal
feeling is that big fixes like this can sometimes be OK as long as they
are mostly contained to a specific target and that target isn’t X86
or ARM.

Without them, the calling convention for big-endian 64-bit Mips targets is very badly broken. Clang is generally consistent with itself, but interlinking with GCC-compiled code doesn’t work. When I started on this work ~4500 of 5000 tests generated by ABITestGen.py produced incorrect output when mixing GCC and Clang objects. 32-bit and little-endian Mips targets are ok except for a couple rare corner cases (e.g. 128-bit float return values).

It’s likely possible to rewrite the patches so that they don’t depend on my other work. If you have any questions there or need me to stamp the rewrites as “what should happen if you don’t take my patches into account” I’m happy to do so.

Thanks.

-eric

We'd very much like to see those in 3.5.1, if it wouldn't be too invasive...

David

Actually, clang is pretty inconsistent with itself on bit-endian 64-bit MIPS prior to this work. Any arguments that end up on the stack are corrupted when calling from clang-compiled code to clang-compiled code. This is most obvious in variadic calls, but breaks in a load of other places too.

David

> > > I'd also like to propose the inclusion of the recent ABI fixes to the Mips
> > > target but I'm not sure this is a good idea. I'm having difficulty sorting out the
> > > dependencies for these at the moment since they seem to depend on some
> > > of Eric Christopher's Subtarget/TargetMachine refactoring. It may also be a
> > > bit large for a stable release since it's ~50 LLVM patches and ~8 Clang patches
> > > and refactors a large amount of the Mips calling convention code. What do
> > > you think?
> >
> > Can you give me an idea of how important these fixes are? My personal
> > feeling is that big fixes like this can sometimes be OK as long as they
> > are mostly contained to a specific target and that target isn't X86
> > or ARM.
>
> Without them, the calling convention for big-endian 64-bit Mips targets is very badly broken. Clang is generally consistent with itself,
> but interlinking with GCC-compiled code doesn't work. When I started on this work ~4500 of 5000 tests generated by ABITestGen.py
> produced incorrect output when mixing > GCC and Clang objects. 32-bit and little-endian Mips targets are ok except for a couple rare
> corner cases (e.g. 128-bit float return values).

It's likely possible to rewrite the patches so that they don't depend on my other work. If you have any questions there or need me to stamp the rewrites as "what should happen if you don't take my patches into account" I'm happy to do so.

Thanks.

-eric

I believe I've managed to backport them to the release_35 branch but I haven't re-tested them beyond running 'ninja check-all' yet. The patches are currently at https://github.com/dsandersimgtec/clang/commits/release_35, and https://github.com/dsandersimgtec/llvm/commits/release_35_proposed.
I'm going to run as much ABI testing as possible on it this evening.

It would be nice to also backport

r219998 - [libcxx] Fix SFINAE in . Patch from K-Ballo.

for the 3.5.1 release to unbreak the build of octave with the clang compilers.

http://savannah.gnu.org/bugs/?43298

Jack

It would be nice to also backport

r219998 - [libcxx] Fix SFINAE in . Patch from K-Ballo.

for the 3.5.1 release to unbreak the build of octave with the clang compilers.

http://savannah.gnu.org/bugs/?43298

Jack

CC’ing mclow.

From: Daniel Sanders
Sent: 25 November 2014 17:39
To: Eric Christopher; Tom Stellard
Cc: LLVM Developers Mailing List (llvmdev@cs.uiuc.edu)
Subject: RE: [LLVMdev] Proposed patches for Clang 3.5.1

> > > > I'd also like to propose the inclusion of the recent ABI fixes to the Mips
> > > > target but I'm not sure this is a good idea. I'm having difficulty sorting out the
> > > > dependencies for these at the moment since they seem to depend on some
> > > > of Eric Christopher's Subtarget/TargetMachine refactoring. It may also be a
> > > > bit large for a stable release since it's ~50 LLVM patches and ~8 Clang patches
> > > > and refactors a large amount of the Mips calling convention code. What do
> > > > you think?
> > >
> > > Can you give me an idea of how important these fixes are? My personal
> > > feeling is that big fixes like this can sometimes be OK as long as they
> > > are mostly contained to a specific target and that target isn't X86
> > > or ARM.
> >
> > Without them, the calling convention for big-endian 64-bit Mips targets is very badly broken. Clang is generally consistent with itself,
> > but interlinking with GCC-compiled code doesn't work. When I started on this work ~4500 of 5000 tests generated by ABITestGen.py
> > produced incorrect output when mixing > GCC and Clang objects. 32-bit and little-endian Mips targets are ok except for a couple rare
> > corner cases (e.g. 128-bit float return values).
>
> It's likely possible to rewrite the patches so that they don't depend on my other work. If you have any questions
> there or need me to stamp the rewrites as "what should happen if you don't take my patches into account" I'm
> happy to do so.
>
> Thanks.
>
> -eric

I believe I've managed to backport them to the release_35 branch but I haven't re-tested them beyond running
'ninja check-all' yet. The patches are currently at https://github.com/dsandersimgtec/clang/commits/release_35,
and https://github.com/dsandersimgtec/llvm/commits/release_35_proposed.
I'm going to run as much ABI testing as possible on it this evening.

I've successfully run the simple vararg test (passing 10 int's in varargs, passing them in a va_list, then printing each one) for all ABI's/endians and mixtures of GCC/Clang.

I've also run the first 5,000 ABITestGen.py generated tests for all ABI's/Endians. Big-endian O32 shows a single failure involving small structures (this is not a regression). Big-endian N32 shows about a dozen failures that do not fail on the trunk but aren't regressions either. All other ABI's and Endians are passing successfully. Even with those big-endian N32 failures (which fail without the patches too), this status is a big improvement on the status without the patches so I'm inclined to think we should merge and fix the remaining issues in 3.5.2 (assuming we do one).
Tom: Is that ok with you?
David: Are you using big-endian N32 or N64?

I'm running an event with some students for most of today. I'll check my emails when I can and I'll have my laptop but I probably won't be able to merge anything until after 5pm GMT (9am PST). I'll leave more ABI tests running in the meantime.

Apart from the ABI fixes mentioned above, the only patch I'm awaiting approval for is:
* r217257 - [mips] Change Feature-related types from unsigned to uint64_t in MipsAsmParser. No functional changes.

> From: Daniel Sanders
> Sent: 25 November 2014 17:39
> To: Eric Christopher; Tom Stellard
> Cc: LLVM Developers Mailing List (llvmdev@cs.uiuc.edu)
> Subject: RE: [LLVMdev] Proposed patches for Clang 3.5.1
>
> > > > > I'd also like to propose the inclusion of the recent ABI fixes to the Mips
> > > > > target but I'm not sure this is a good idea. I'm having difficulty sorting out the
> > > > > dependencies for these at the moment since they seem to depend on some
> > > > > of Eric Christopher's Subtarget/TargetMachine refactoring. It may also be a
> > > > > bit large for a stable release since it's ~50 LLVM patches and ~8 Clang patches
> > > > > and refactors a large amount of the Mips calling convention code. What do
> > > > > you think?
> > > >
> > > > Can you give me an idea of how important these fixes are? My personal
> > > > feeling is that big fixes like this can sometimes be OK as long as they
> > > > are mostly contained to a specific target and that target isn't X86
> > > > or ARM.
> > >
> > > Without them, the calling convention for big-endian 64-bit Mips targets is very badly broken. Clang is generally consistent with itself,
> > > but interlinking with GCC-compiled code doesn't work. When I started on this work ~4500 of 5000 tests generated by ABITestGen.py
> > > produced incorrect output when mixing > GCC and Clang objects. 32-bit and little-endian Mips targets are ok except for a couple rare
> > > corner cases (e.g. 128-bit float return values).
> >
> > It's likely possible to rewrite the patches so that they don't depend on my other work. If you have any questions
> > there or need me to stamp the rewrites as "what should happen if you don't take my patches into account" I'm
> > happy to do so.
> >
> > Thanks.
> >
> > -eric
>
> I believe I've managed to backport them to the release_35 branch but I haven't re-tested them beyond running
> 'ninja check-all' yet. The patches are currently at Commits · dsandersllvm/clang · GitHub,
> and https://github.com/dsandersimgtec/llvm/commits/release_35_proposed.
> I'm going to run as much ABI testing as possible on it this evening.

I've successfully run the simple vararg test (passing 10 int's in varargs, passing them in a va_list, then printing each one) for all ABI's/endians and mixtures of GCC/Clang.

I've also run the first 5,000 ABITestGen.py generated tests for all ABI's/Endians. Big-endian O32 shows a single failure involving small structures (this is not a regression). Big-endian N32 shows about a dozen failures that do not fail on the trunk but aren't regressions either. All other ABI's and Endians are passing successfully. Even with those big-endian N32 failures (which fail without the patches too), this status is a big improvement on the status without the patches so I'm inclined to think we should merge and fix the remaining issues in 3.5.2 (assuming we do one).
Tom: Is that ok with you?
David: Are you using big-endian N32 or N64?

I'm running an event with some students for most of today. I'll check my emails when I can and I'll have my laptop but I probably won't be able to merge anything until after 5pm GMT (9am PST). I'll leave more ABI tests running in the meantime.

I will try to look at the patches today. I'm going to delay the release a week
or so, because of all the merge requests I've received, so there is no rush.

-Tom

...

I will try to look at the patches today. I'm going to delay the release a week
or so, because of all the merge requests I've received, so there is no rush.

Hi Tom,

I would like to propose the following additional patches for 3.5.1. These will already be part of the upcoming clang 3.5.0 import into the FreeBSD 11.0 base system. Apologies in advance for the long list. :slight_smile:

Enabling TLS support for PowerPC32:

  http://llvm.org/viewvc/llvm-project?rev=213960&view=rev

    [PowerPC] Support TLS on PPC32/ELF

    Patch by Justin Hibbits!

Two changes needed for being able to link lldb 3.5.x against llvm 3.5.x:

  http://llvm.org/viewvc/llvm-project?rev=215352&view=rev

    AArch64: add support for dynamic-loader relocations

    LLD needs them, and it's good to be able to print them properly when
    our object dumpers encounter them.

    Patch by Daniel Stewart.

  http://llvm.org/viewvc/llvm-project?rev=216571&view=rev

    Fix some semantic usability issues with DynamicLibrary.

    This patch allows invalid DynamicLibrary instances to be
    constructed, and fixes the const-correctness of the isValid()
    method.

Fixing a possible SIGILL problem on ARMv6 and lower, plus test:

  http://llvm.org/viewvc/llvm-project?rev=216989&view=rev

    Only emit movw on ARMv6T2+

    Fix PR18364.

    Patch by Dimitry Andric.

  http://llvm.org/viewvc/llvm-project?rev=216990&view=rev

    Missing test from r216989

Fix assigning garbage to floats in some cases:

  http://llvm.org/viewvc/llvm-project?rev=217410&view=rev

    Set trunc store action to Expand for all X86 targets.

    When compiling without SSE2, isTruncStoreLegal(F64, F32) would return Legal, whereas with SSE2 it would return Expand. And since the Target doesn't seem to actually handle a truncstore for double -> float, it would just output a store of a full double in the space for a float hence overwriting other bits on the stack.

    Patch by Luqman Aden!

Enabling armv6k for FreeBSD/ARM:

  http://llvm.org/viewvc/llvm-project?rev=217454&view=rev

    Use armv6k default for FreeBSD/ARM

    Patch by Andrew Turner.

Downgrading a DWARF2 section error when .note sections are added to a .S file while debug info is on:

  http://llvm.org/viewvc/llvm-project?rev=218241&view=rev

    Downgrade DWARF2 section limit error to a warning

    We currently emit an error when trying to assemble a file with more
    than one section using DWARF2 debug info. This should be a warning
    instead, as the resulting file will still be usable, but with a
    degraded debug illusion.

Fixing a very bad OOM condition when compiling certain programs with debug info on, plus test:

  http://llvm.org/viewvc/llvm-project?rev=221709&view=rev

    Totally forget deallocated SDNodes in SDDbgInfo.

    What would happen before that commit is that the SDDbgValues associated with
    a deallocated SDNode would be marked Invalidated, but SDDbgInfo would keep
    a map entry keyed by the SDNode pointer pointing to this list of invalidated
    SDDbgNodes. As the memory gets reused, the list might get wrongly associated
    with another new SDNode. As the SDDbgValues are cloned when they are transfered,
    this can lead to an exponential number of SDDbgValues being produced during
    DAGCombine like in http://llvm.org/bugs/show_bug.cgi?id=20893

    Note that the previous behavior wasn't really buggy as the invalidation made
    sure that the SDDbgValues won't be used. This commit can be considered a
    memory optimization and as such is really hard to validate in a unit-test.

  http://llvm.org/viewvc/llvm-project?rev=221854&view=rev

    Add an assert and a test that verify r221709's fix.

Enable AArch64 support for FreeBSD:

  http://llvm.org/viewvc/llvm-project?rev=221900&view=rev

    Hook up FreeBSD AArch64 support

    Patch from Andrew Turner.

Partially fix FreeBSD boot2 size optimization regressions:

  http://llvm.org/viewvc/llvm-project?rev=222562&view=rev

    Disable header duplication at -Oz in loop-rotate pass.

-Dimitry

This one is OK, I didn't realize those were private functions, so there
shouldn't be an API impact.

-Tom

...

I will try to look at the patches today. I'm going to delay the release a week
or so, because of all the merge requests I've received, so there is no rush.

Hi Tom,

Here is another rather important one, fresh off the commit list.

Fix libapr apr_stat() miscompilation:

  http://llvm.org/viewvc/llvm-project?rev=222856&view=rev

    Revert "Added inst combine transforms for single bit tests from Chris's note"

    This reverts commit r210006, it miscompiled libapr which is used in who
    knows how many projects.

    A test has been added to ensure that we don't regress again.

    I'll work on a rewrite of what the optimization was trying to do later.

-Dimitry

Ah yes, that's right. I thought it was at least consistent enough to pass the LLVM test-suite but I'm mistaken. At the time this was first reported (June/July), it turned out that there was no big-endian MIPS64 builder in our internal buildbot. The one we set up when we noticed this had 12 test-suite failures.

From: Tom Stellard [mailto:tom@stellard.net]
Sent: 26 November 2014 15:50
To: Daniel Sanders
Cc: Eric Christopher; Dr D. Chisnall; LLVM Developers Mailing List
(llvmdev@cs.uiuc.edu)
Subject: Re: [LLVMdev] Proposed patches for Clang 3.5.1

> > From: Daniel Sanders
> > Sent: 25 November 2014 17:39
> > To: Eric Christopher; Tom Stellard
> > Cc: LLVM Developers Mailing List (llvmdev@cs.uiuc.edu)
> > Subject: RE: [LLVMdev] Proposed patches for Clang 3.5.1
> >
> > > > > > I'd also like to propose the inclusion of the recent ABI fixes to the
Mips
> > > > > > target but I'm not sure this is a good idea. I'm having difficulty
sorting out the
> > > > > > dependencies for these at the moment since they seem to
depend on some
> > > > > > of Eric Christopher's Subtarget/TargetMachine refactoring. It may
also be a
> > > > > > bit large for a stable release since it's ~50 LLVM patches and ~8
Clang patches
> > > > > > and refactors a large amount of the Mips calling convention code.
What do
> > > > > > you think?
> > > > >
> > > > > Can you give me an idea of how important these fixes are? My
personal
> > > > > feeling is that big fixes like this can sometimes be OK as long as they
> > > > > are mostly contained to a specific target and that target isn't X86
> > > > > or ARM.
> > > >
> > > > Without them, the calling convention for big-endian 64-bit Mips
targets is very badly broken. Clang is generally consistent with itself,
> > > > but interlinking with GCC-compiled code doesn't work. When I started
on this work ~4500 of 5000 tests generated by ABITestGen.py
> > > > produced incorrect output when mixing > GCC and Clang objects. 32-
bit and little-endian Mips targets are ok except for a couple rare
> > > > corner cases (e.g. 128-bit float return values).
> > >
> > > It's likely possible to rewrite the patches so that they don't depend on
my other work. If you have any questions
> > > there or need me to stamp the rewrites as "what should happen if you
don't take my patches into account" I'm
> > > happy to do so.
> > >
> > > Thanks.
> > >
> > > -eric
> >
> > I believe I've managed to backport them to the release_35 branch but I
haven't re-tested them beyond running
> > 'ninja check-all' yet. The patches are currently at
https://github.com/dsandersimgtec/clang/commits/release_35,
> > and
https://github.com/dsandersimgtec/llvm/commits/release_35_proposed.
> > I'm going to run as much ABI testing as possible on it this evening.
>
> I've successfully run the simple vararg test (passing 10 int's in varargs,
passing them in a va_list, then printing each one) for all ABI's/endians and
mixtures of GCC/Clang.
>
> I've also run the first 5,000 ABITestGen.py generated tests for all
ABI's/Endians. Big-endian O32 shows a single failure involving small structures
(this is not a regression). Big-endian N32 shows about a dozen failures that
do not fail on the trunk but aren't regressions either. All other ABI's and
Endians are passing successfully. Even with those big-endian N32 failures
(which fail without the patches too), this status is a big improvement on the
status without the patches so I'm inclined to think we should merge and fix
the remaining issues in 3.5.2 (assuming we do one).
> Tom: Is that ok with you?
> David: Are you using big-endian N32 or N64?
>
> I'm running an event with some students for most of today. I'll check my
emails when I can and I'll have my laptop but I probably won't be able to
merge anything until after 5pm GMT (9am PST). I'll leave more ABI tests
running in the meantime.

I will try to look at the patches today. I'm going to delay the release a week
or so, because of all the merge requests I've received, so there is no rush.

That's a relief :-). I'll see if I can fix the N32 issues that remain on this branch.

So far, I've run the first 90,000 tests for each ABI/endian with only the failures explained above.

-Tom
>
> Apart from the ABI fixes mentioned above, the only patch I'm awaiting
approval for is:
> * r217257 - [mips] Change Feature-related types from unsigned to uint64_t
in MipsAsmParser. No functional changes.

This one is OK, I didn't realize those were private functions, so there
shouldn't be an API impact.

Thanks. Merged in r222875.

> > I've successfully run the simple vararg test (passing 10 int's in varargs,
> passing them in a va_list, then printing each one) for all ABI's/endians and
> mixtures of GCC/Clang.
> >
> > I've also run the first 5,000 ABITestGen.py generated tests for all
> ABI's/Endians. Big-endian O32 shows a single failure involving small
structures
> (this is not a regression). Big-endian N32 shows about a dozen failures that
> do not fail on the trunk but aren't regressions either. All other ABI's and
> Endians are passing successfully. Even with those big-endian N32 failures
> (which fail without the patches too), this status is a big improvement on the
> status without the patches so I'm inclined to think we should merge and fix
> the remaining issues in 3.5.2 (assuming we do one).
> > Tom: Is that ok with you?
> > David: Are you using big-endian N32 or N64?
> >
> > I'm running an event with some students for most of today. I'll check my
> emails when I can and I'll have my laptop but I probably won't be able to
> merge anything until after 5pm GMT (9am PST). I'll leave more ABI tests
> running in the meantime.
>
> I will try to look at the patches today. I'm going to delay the release a week
> or so, because of all the merge requests I've received, so there is no rush.

That's a relief :-). I'll see if I can fix the N32 issues that remain on this branch.

So far, I've run the first 90,000 tests for each ABI/endian with only the failures
explained above.

Just a quick update. The big-endian N32 failures have turned out to be false-positives. According to the logs, a shell script was briefly unavailable when it tried to run these tests. I've re-run them and they pass now. The only failure I know of is the single big-endian O32 failure.

From: Jack Howarth <howarth.mailing.lists@gmail.com>
Date: Mon, Nov 24, 2014 at 5:01 PM
Subject: Re: [LLVMdev] Proposed patches for Clang 3.5.1
To: Daniel Sanders <Daniel.Sanders@imgtec.com>

     It would be nice to also backport

r219998 - [libcxx] Fix SFINAE in <cmath>. Patch from K-Ballo.

for the 3.5.1 release to unbreak the build of octave with the clang
compilers.

GNU Octave - Bugs: bug #43298, llvm libc++ 3.5 fails to resolve... [Savannah]

Hi Jack,

Can you cc the code owner to get his/her approval.

Thanks,
Tom

>
...
> I will try to look at the patches today. I'm going to delay the release a week
> or so, because of all the merge requests I've received, so there is no rush.

Hi Tom,

I would like to propose the following additional patches for 3.5.1. These will already be part of the upcoming clang 3.5.0 import into the FreeBSD 11.0 base system. Apologies in advance for the long list. :slight_smile:

Hi Dimitry,

Can you cc the appropriate code owners to get their approval. It might
help to send a separate email per code owner.

Thanks,
Tom