On Wed, Mar 20, 2013 at 12:24 PM, Jakub Jelinek wrote:
> On Wed, Mar 20, 2013 at 12:20:27PM +0100, Richard Biener wrote:
>> Walking the SSA def chain would also be possible - preferably from
>> cfgexpand.c when we process the stmt. But you'll eventually lose
>> debug info like for
>>
>> int i =
On Wed, Mar 20, 2013 at 12:20:27PM +0100, Richard Biener wrote:
> Walking the SSA def chain would also be possible - preferably from
> cfgexpand.c when we process the stmt. But you'll eventually lose
> debug info like for
>
> int i = 1;
> __builtin_foo (i);
>
> when we then never expand the
On Wed, Mar 20, 2013 at 11:46 AM, Jakub Jelinek wrote:
> On Wed, Mar 20, 2013 at 11:38:03AM +0100, Richard Biener wrote:
>> Not without using information created by TER which is disabled for this
>> case because of different line information. If TER would not be disabled
>> for this reason it wou
On Wed, Mar 20, 2013 at 11:38:03AM +0100, Richard Biener wrote:
> Not without using information created by TER which is disabled for this
> case because of different line information. If TER would not be disabled
> for this reason it would already work automagically.
Would relaxing that in TER fo
On Tue, Mar 19, 2013 at 6:30 PM, Andi Kleen wrote:
> On Tue, Mar 19, 2013 at 05:10:22PM +0100, Jakub Jelinek wrote:
>> On Tue, Mar 19, 2013 at 08:51:21AM -0700, Andi Kleen wrote:
>> > > Using __always_inline as the name of the macro is a bad idea, glibc
>> > > headers use that macro already. Just
On Tue, Mar 19, 2013 at 05:10:22PM +0100, Jakub Jelinek wrote:
> On Tue, Mar 19, 2013 at 08:51:21AM -0700, Andi Kleen wrote:
> > > Using __always_inline as the name of the macro is a bad idea, glibc
> > > headers use that macro already. Just use something else in public headers
> > > that aren't p
On Tue, Mar 19, 2013 at 08:51:21AM -0700, Andi Kleen wrote:
> > Using __always_inline as the name of the macro is a bad idea, glibc
> > headers use that macro already. Just use something else in public headers
> > that aren't part of glibc.
>
> That's why I had the ifdef, but ok. I'll use __forc
> Using __always_inline as the name of the macro is a bad idea, glibc
> headers use that macro already. Just use something else in public headers
> that aren't part of glibc.
That's why I had the ifdef, but ok. I'll use __force_inline then.
-Andi
On Mon, Mar 18, 2013 at 04:28:13PM +, Jonathan Wakely wrote:
> On 16 March 2013 13:29, Andi Kleen wrote:
> >
> > With inline __attribute__((always_inline)) these functions
> > get inlined even with -O0.
> >
> > I hardcoded the attribute in the header for now, assuming
> > that all compilers tha
On 16 March 2013 13:29, Andi Kleen wrote:
>
> With inline __attribute__((always_inline)) these functions
> get inlined even with -O0.
>
> I hardcoded the attribute in the header for now, assuming
> that all compilers that support libstdc++ have attribute
> always_inline too. If not it would need to
On 18 March 2013 16:28, Jonathan Wakely wrote:
> On 16 March 2013 13:29, Andi Kleen wrote:
>>
>> With inline __attribute__((always_inline)) these functions
>> get inlined even with -O0.
>>
>> I hardcoded the attribute in the header for now, assuming
>> that all compilers that support libstdc++ have
On Mon, Mar 18, 2013 at 04:28:13PM +, Jonathan Wakely wrote:
> On 16 March 2013 13:29, Andi Kleen wrote:
> >
> > With inline __attribute__((always_inline)) these functions
> > get inlined even with -O0.
> >
> > I hardcoded the attribute in the header for now, assuming
> > that all compilers tha
From: Andi Kleen
When a non constant memory model is passed to __atomic_*
gcc falls back to seq_cst. This drops any HLE acquire or release bits.
This can happen when is used with -O0
as the member functions are not always inlined then and the memory
argument passed in ends up being non-constant
13 matches
Mail list logo
