On 06/05/2016 06:02 PM, Bernd Edlinger wrote:
I think we all agreed on the general direction of this patch.
The patch is basically unchanged from previous version,
except one line in doc/extend.texi has been updated.
So I would like to ask if it is OK for trunk.
Are there any users of extrac
On Sun, 5 Jun 2016, Bernd Edlinger wrote:
> Ping...
>
> I think we all agreed on the general direction of this patch.
>
> The patch is basically unchanged from previous version,
> except one line in doc/extend.texi has been updated.
>
> So I would like to ask if it is OK for trunk.
The gimple_
Ping...
I think we all agreed on the general direction of this patch.
The patch is basically unchanged from previous version,
except one line in doc/extend.texi has been updated.
So I would like to ask if it is OK for trunk.
Thanks
Bernd.gcc/
2016-05-05 Bernd Edlinger
PR c/24414
On 05/23/16 23:46, David Wohlferd wrote:
> On 5/23/2016 12:46 AM, Richard Biener wrote:
> > On Sun, 22 May 2016, Andrew Haley wrote:
> >> On 05/20/2016 07:50 AM, David Wohlferd wrote:
> >>> I realize deprecation/removal is drastic. Especially since basic
> >>> asm (mostly) works as is. But fi
On 5/23/2016 12:46 AM, Richard Biener wrote:
> On Sun, 22 May 2016, Andrew Haley wrote:
>> On 05/20/2016 07:50 AM, David Wohlferd wrote:
>>> I realize deprecation/removal is drastic. Especially since basic
>>> asm (mostly) works as is. But fixing memory clobbers while leaving
>>> the rest broken
On 05/22/2016 04:33 AM, Andrew Haley wrote:
On 05/20/2016 07:50 AM, David Wohlferd wrote:
At a minimum, suddenly forcing an unexpected/unneeded memory clobber
can adversely impact the optimization of surrounding code. This can
be particularly annoying if the reason for the asm was to improve
p
On Sun, 22 May 2016, Andrew Haley wrote:
> On 05/20/2016 07:50 AM, David Wohlferd wrote:
>
> > At a minimum, suddenly forcing an unexpected/unneeded memory clobber
> > can adversely impact the optimization of surrounding code. This can
> > be particularly annoying if the reason for the asm was t
On 05/20/2016 07:50 AM, David Wohlferd wrote:
> At a minimum, suddenly forcing an unexpected/unneeded memory clobber
> can adversely impact the optimization of surrounding code. This can
> be particularly annoying if the reason for the asm was to improve
> performance. And adding a memory clobbe
On 5/18/2016 3:07 PM, Jeff Law wrote:
On 05/07/2016 11:38 AM, Andrew Haley wrote:
My argument in support of Bernd's proposal is that it makes sense from
a *practical* software reliability point of view. It wouldn't hurt,
and might fix some significant bugs. It's similar to the targets
which al
On 05/07/2016 11:38 AM, Andrew Haley wrote:
On 06/05/16 07:35, David Wohlferd wrote:
1) I'm not clear precisely what problem this patch fixes. It's true
that some people have incorrectly assumed that basic asm clobbers
memory and this change would fix their code. But some people also
incorrec
On 05/09/16 15:46, Bernd Schmidt wrote:
> On 05/09/2016 03:37 PM, Bernd Edlinger wrote:
>> On 05/09/16 09:56, Richard Biener wrote:
>>>
>>> At least it sounds to me that its semantics can be fully expressed
>>> with generic asms? (Maybe apart from the only-if-ASM_STRING-is-empty
>>> part)
>>>
>>
>
On 05/09/2016 03:37 PM, Bernd Edlinger wrote:
On 05/09/16 09:56, Richard Biener wrote:
At least it sounds to me that its semantics can be fully expressed
with generic asms? (Maybe apart from the only-if-ASM_STRING-is-empty
part)
That was also my first idea too.
In simple cases an asm ("wha
On 05/09/16 09:56, Richard Biener wrote:
> On Thu, 5 May 2016, Bernd Edlinger wrote:
>
>> Hi!
>>
>> this patch is inspired by recent discussion about basic asm:
>>
>> Currently a basic asm is an instruction scheduling barrier,
>> but not a memory barrier, and most surprising, basic asm
>> does _not
On Thu, 5 May 2016, Bernd Edlinger wrote:
> Hi!
>
> this patch is inspired by recent discussion about basic asm:
>
> Currently a basic asm is an instruction scheduling barrier,
> but not a memory barrier, and most surprising, basic asm
> does _not_ implicitly clobber CC on targets where
> extend
On 06/05/16 07:35, David Wohlferd wrote:
> 1) I'm not clear precisely what problem this patch fixes. It's true
> that some people have incorrectly assumed that basic asm clobbers
> memory and this change would fix their code. But some people also
> incorrectly assume it clobbers registers. I as
On 05/07/16 01:33, David Wohlferd wrote:
>
>>> A few questions:
>>>
>>> 1) I'm not clear precisely what problem this patch fixes. It's true
>>> that some people have incorrectly assumed that basic asm clobbers memory
>>> and this change would fix their code. But some people also incorrectly
>>> a
A few questions:
1) I'm not clear precisely what problem this patch fixes. It's true
that some people have incorrectly assumed that basic asm clobbers memory
and this change would fix their code. But some people also incorrectly
assume it clobbers registers. I assume that's why Jeff Law prop
On 05/06/16 08:35, David Wohlferd wrote:
> On 5/5/2016 10:29 AM, Bernd Edlinger wrote:
>> Hi!
>>
>> this patch is inspired by recent discussion about basic asm:
>>
>> Currently a basic asm is an instruction scheduling barrier,
>> but not a memory barrier, and most surprising, basic asm
>> does _not
On 5/5/2016 10:29 AM, Bernd Edlinger wrote:
Hi!
this patch is inspired by recent discussion about basic asm:
Currently a basic asm is an instruction scheduling barrier,
but not a memory barrier, and most surprising, basic asm
does _not_ implicitly clobber CC on targets where
extended asm always
Hi!
this patch is inspired by recent discussion about basic asm:
Currently a basic asm is an instruction scheduling barrier,
but not a memory barrier, and most surprising, basic asm
does _not_ implicitly clobber CC on targets where
extended asm always implicitly clobbers CC, even if
nothing is in
Hi,
On 09.12.2015 16:48 Bernd Schmidt wrote:
> On 12/09/2015 04:09 PM, Bernd Edlinger wrote:
>
>> So would you agree on the general direction of the patch,
>> if I drop the hunk in sched-deps.c ?
>
> I'm not sure there was any consensus in that other thread, but I think
> assuming that basic asms
On 12/09/2015 04:09 PM, Bernd Edlinger wrote:
So would you agree on the general direction of the patch,
if I drop the hunk in sched-deps.c ?
I'm not sure there was any consensus in that other thread, but I think
assuming that basic asms clobber memory and CC, can be justified. That
certainly
Hi,
On 09.12.2015 12:06 Bernd Schmidt wrote:
> On 12/09/2015 03:18 AM, Bernd Edlinger wrote:
>> Furthermore there is a documented use for asm(""): The empty
>> assembler string is used to make a function
>> volatile, thus calls can not be optimized away. But I think it is
>> not necessary to ma
On 12/09/2015 03:18 AM, Bernd Edlinger wrote:
Furthermore there is a documented use for asm(""): The empty assembler string
is used to make a function
volatile, thus calls can not be optimized away. But I think it is not
necessary to make this clobber anything,
nor should it be an instruction
Hi,
from the recent discussion on g...@gcc.gnu.org I became aware that the so
called "basic asm"
which is an asm without colon, has no way to specify the clobber list. That
makes it rather
useless, because everyone would expect it to be able to use at least global
memory.
Furthermore there i
25 matches
Mail list logo
