On Sun, Jun 19, 2016 at 11:43 PM, David Wohlferd
wrote:
> Perhaps this post should be directed toward port maintainers?
>
> Since several global maintainers have now suggested it, I have created a
> patch that deprecates basic asm when used in a function (attached). It
> excludes (ie does not de
On 20/06/16 08:00, Andrew Pinski wrote:
> + /* Acceptable. */
> + asm (" "); /* { dg-warning "Deprecated: asm in function without
> extended syntax" } */
This is incorrect English. It should be
"Deprecated: asm without extended syntax in function"
because it's the asm that is missing the e
On Mon, 20 Jun 2016, Andrew Haley wrote:
> On 20/06/16 08:00, Andrew Pinski wrote:
> > + /* Acceptable. */
> > + asm (" "); /* { dg-warning "Deprecated: asm in function without
> > extended syntax" } */
>
> This is incorrect English. It should be
>
> "Deprecated: asm without extended synta
On Mon, Jun 20, 2016 at 12:00:16AM -0700, Andrew Pinski wrote:
> Also I think the other place where we should accept basic asm is for
> "nop" instructions. I have seen people use that heavily.
And anything else that means the same as basic asm and as extended asm.
> Note really I don't like the
On 20/06/16 14:50, Segher Boessenkool wrote:
> If basic asm is deprecated, that means some time later it will be
> removed, at which time an asm without : can be used as extended asm
Not exactly: it'd be an asm with no inputs, no outputs, and no
clobbers i.e. no effects.
Andrew.
On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote:
> On 20/06/16 14:50, Segher Boessenkool wrote:
> > If basic asm is deprecated, that means some time later it will be
> > removed, at which time an asm without : can be used as extended asm
>
> Not exactly: it'd be an asm with no inputs,
On 20/06/16 15:42, Segher Boessenkool wrote:
> On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote:
>> On 20/06/16 14:50, Segher Boessenkool wrote:
>>> If basic asm is deprecated, that means some time later it will be
>>> removed, at which time an asm without : can be used as extended asm
On Mon, Jun 20, 2016 at 03:49:19PM +0100, Andrew Haley wrote:
> On 20/06/16 15:42, Segher Boessenkool wrote:
> > On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote:
> >> On 20/06/16 14:50, Segher Boessenkool wrote:
> >>> If basic asm is deprecated, that means some time later it will be
>
On 20/06/16 15:52, Segher Boessenkool wrote:
> On Mon, Jun 20, 2016 at 03:49:19PM +0100, Andrew Haley wrote:
>> On 20/06/16 15:42, Segher Boessenkool wrote:
>>> On Mon, Jun 20, 2016 at 02:55:58PM +0100, Andrew Haley wrote:
On 20/06/16 14:50, Segher Boessenkool wrote:
> If basic asm is depr
Given how many embedded ports have #defines in external packages for
basic asms for instructions such as nop, enable/disable interrupts,
other system-level opcodes, etc... I think this is a bad idea. Even
glibc would break.
#define enable() asm("eint")
__asm__ __volatile__ ("fwait");
Hi,
On Sun, 19 Jun 2016, David Wohlferd wrote:
> All basic asm in trunk: 1,105 instances.
> - Exclude 273 instances with empty strings leaving 832.
> - Exclude 271 instances for boehm-gc project leaving 561.
> - Exclude 202 instances for testsuite project leaving 359.
> - Exclude 282 instances th
On 20/06/16 18:36, Michael Matz wrote:
> I see zero gain by deprecating them and only churn. What would be the
> advantage again?
Correctness. It is very likely that many of these basic asms are not
robust in the face of compiler changes because they don't declare
their dependencies and therefo
Hi,
On Mon, 20 Jun 2016, Andrew Haley wrote:
> On 20/06/16 18:36, Michael Matz wrote:
> > I see zero gain by deprecating them and only churn. What would be the
> > advantage again?
>
> Correctness.
As said in the various threads about basic asms, all correctness
problems can be solved by mak
On 06/17/2016 02:19 PM, Alexander Cherepanov wrote:
On 2016-06-15 17:15, Martin Sebor wrote:
There has been quite a bit of discussion among the committee on
this subject lately (the last part is the subject of DR #451,
though it's discussed in the context of uninitialized objects
with indetermin
Thank you.
On Mon, Jun 13, 2016 at 6:19 PM, Matthew Fortune
wrote:
> Heiher writes:
>> Looks the return value of TestNewA is passed on $f0/$f2 from disassembly
>> code. I don't known why the return value of TestNewB is passed on
>> $v0/$v1? a bug?
>
> I believe this is an area where GNU strays
15 matches
Mail list logo
