bob.wilson accepted this revision.
bob.wilson added a reviewer: bob.wilson.
bob.wilson added a comment.
This revision is now accepted and ready to land.
I applied a Darwin-specific change for this to clang in r256026.
http://reviews.llvm.org/D15455
On Fri, Dec 18, 2015 at 12:45:47PM -0800, Bob Wilson via cfe-commits wrote:
>
> > On Dec 17, 2015, at 10:59 AM, Bob Wilson via cfe-commits
> > wrote:
> >
> >
> >> On Dec 17, 2015, at 10:16 AM, Joerg Sonnenberger via cfe-commits
> >> wrote:
> >>
> >> On Wed, Dec 16, 2015 at 11:59:10PM +,
> On Dec 17, 2015, at 10:59 AM, Bob Wilson via cfe-commits
> wrote:
>
>
>> On Dec 17, 2015, at 10:16 AM, Joerg Sonnenberger via cfe-commits
>> wrote:
>>
>> On Wed, Dec 16, 2015 at 11:59:10PM +, Bob Wilson via cfe-commits wrote:
>>> We can change this to be Darwin-specific if you prefer,
> On Dec 17, 2015, at 10:16 AM, Joerg Sonnenberger via cfe-commits
> wrote:
>
> On Wed, Dec 16, 2015 at 11:59:10PM +, Bob Wilson via cfe-commits wrote:
>> We can change this to be Darwin-specific if you prefer, but we should
>> maintain compatibility with GCC and previous Clang releases in
On Wed, Dec 16, 2015 at 11:59:10PM +, Bob Wilson via cfe-commits wrote:
> We can change this to be Darwin-specific if you prefer, but we should
> maintain compatibility with GCC and previous Clang releases in this behavior.
Who is really affected by this? I don't care too much about obscure
Da
jyknight added a comment.
> #define CC1_SPEC "%{!mkernel:%{!static:%{!mdynamic-no-pic:-fPIC}}}
That's sad.
> We can change this to be Darwin-specific if you prefer, but we should
> maintain compatibility with GCC and previous Clang releases in this behavior.
Yes, the broken behavior should b
bob.wilson added a subscriber: bob.wilson.
bob.wilson added a comment.
There has been a long-standing convention in both gcc and clang for Darwin that
-static changes the default for PIC. Changing that convention is breaking stuff
for us. The commit message for r245667 says "This new behavior al
probinson added a comment.
PS4 rejects -static unconditionally, so in that sense changing what it means
doesn't matter to us. (But I really appreciate being asked!)
Still, abstractly it seems like -static doesn't really imply noPIC.
http://reviews.llvm.org/D15455
__
On Fri, Dec 11, 2015 at 07:49:25PM +, Frederic Riss wrote:
> friss added a comment.
>
> Just because it makes the behavior more intuitive? If you toolchain
> does PIC by default, it's because you are mostly building shared
> objects. When you are building a static object, it's highly likely
>
jyknight added a comment.
In http://reviews.llvm.org/D15455#308532, @joerg wrote:
> As before, I don't see why a linker flag should change code generation. That
> seems to be a gross violation of layering and quite surprising.
I agree.
http://reviews.llvm.org/D15455
__
friss added reviewers: silvas, probinson.
friss added a comment.
Adding some SCE people, as their platform would be impacted by that change.
http://reviews.llvm.org/D15455
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org
friss added a comment.
Just because it makes the behavior more intuitive? If you toolchain does PIC by
default, it's because you are mostly building shared objects. When you are
building a static object, it's highly likely that you don't need PIC. There
should be a way to enable it, but I find
joerg added a comment.
As before, I don't see why a linker flag should change code generation. That
seems to be a gross violation of layering and quite surprising.
http://reviews.llvm.org/D15455
___
cfe-commits mailing list
cfe-commits@lists.llvm.o
friss created this revision.
friss added reviewers: jyknight, rnk, joerg.
friss added a subscriber: cfe-commits.
In r245667 -static was changed not to disable -fPIC as they control
2 different concepts. On toolchains that enable -fPIC by default,
this means that now you have to pass "-static -fno-
14 matches
Mail list logo
