On 06/20/2016 07:40 PM, 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. It is very likely that many of these basic asms are not
> robust in the face of compiler changes bec
On 06/21/2016 06:53 PM, Andrew Haley wrote:
> Me too. I wonder if there's anything else we can do to make basic asm
> in a function a bit less of a time bomb.
GCC could parse the assembly instructions and figure out the clobbers.
Florian
On Thursday 16 June 2016 09:44 PM, Vineet Gupta wrote:
> Hi,
>
> ARC Linux has an in-kernel dwarf unwinder which has historically consumed
> .debug_frame. The kernel is built with -gdwarf-2 and
> -fasynchronous-unwind-tables
> toggles which until recently used to generate both .debug_frame and .e
In the end, my problems with basic-asm-in-functions (BAIF) come down to
reliably generating correct code.
Optimizations are based on the idea of "you can safely modify x if you
can prove y." But given that basic asm are opaque blocks, there is no
way to prove, well, much of anything. Adding
On 6/21/2016 9:43 AM, Jeff Law wrote:
> I think there's enough resistance to deprecating basic asms within a
function that we should probably punt that idea.
I don't disagree that there has been pushback. I just wish less of it
was of the form "Because I don't wanna." A few examples of "Here
On Wed, Jun 22, 2016 at 02:23:46AM -0700, David Wohlferd wrote:
> I don't have a sample of people accessing local variables, but I do have one
> where someone was using 'scratch' registers in BAIF assuming the compiler
> would just "handle it." And before you call that guy a dummy, let me point
>
On 22/06/16 09:59, Florian Weimer wrote:
> On 06/20/2016 07:40 PM, 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. It is very likely that many of these basic asms are n
On Mon, Jun 20, 2016 at 08:01:24PM +0200, Michael Matz wrote:
> You see, the experiment shows that there's a gazillion uses of basic asms
> out there.
I applied the proposed patch and built myself an allyesconfig AArch64 linux
kernel, the results were not pretty...
make | grep "warning: Depre
On 06/22/2016 09:23 AM, James Greenhalgh wrote:
On the other hand, some of the the x86_64 examples in lib/raid6/sse2.c are
super scary and have back-to-back instructions with hard-coded registers...
asm volatile("pcmpgtb %xmm4,%xmm5");
asm volatile("paddb %xmm4,%xmm4");
On 22/06/16 10:02, Florian Weimer wrote:
On 06/21/2016 06:53 PM, Andrew Haley wrote:
Me too. I wonder if there's anything else we can do to make basic asm
in a function a bit less of a time bomb.
GCC could parse the assembly instructions and figure out the clobbers.
Which is also needed for
On Wed, Jun 22, 2016 at 10:59 AM, Manuel López-Ibáñez
wrote:
> On 22/06/16 10:02, Florian Weimer wrote:
>>
>> On 06/21/2016 06:53 PM, Andrew Haley wrote:
>>>
>>> Me too. I wonder if there's anything else we can do to make basic asm
>>> in a function a bit less of a time bomb.
>>
>>
>> GCC could p
Hi,
I am working on importing gnulib library inside the gcc tree. Should the
library be imported in the top level directory along with other libraries (like
libiberty, libatomic, liboffloadmic etc), or should it be imported inside gcc/
like it is done in the binutils-gdb tree. There they have a
On 22 June 2016 at 19:05, Andrew Pinski wrote:
> On Wed, Jun 22, 2016 at 10:59 AM, Manuel López-Ibáñez
> wrote:
>> On 22/06/16 10:02, Florian Weimer wrote:
>>> GCC could parse the assembly instructions and figure out the clobbers.
>>
>>
>> Which is also needed for various things, such as providin
On Wed, Jun 22, 2016 at 12:26 PM, Manuel López-Ibáñez
wrote:
> On 22 June 2016 at 19:05, Andrew Pinski wrote:
>> On Wed, Jun 22, 2016 at 10:59 AM, Manuel López-Ibáñez
>> wrote:
>>> On 22/06/16 10:02, Florian Weimer wrote:
GCC could parse the assembly instructions and figure out the clobbers
On 22 June 2016 at 20:28, Andrew Pinski wrote:
> On Wed, Jun 22, 2016 at 12:26 PM, Manuel López-Ibáñez
> wrote:
>> On 22 June 2016 at 19:05, Andrew Pinski wrote:
>>> Note each target in gas has its own way of parsing assembly code which
>>> is one of the reason why it is so hard todo the above a
On Wed, 22 Jun 2016, ayush goel wrote:
> I am working on importing gnulib library inside the gcc tree. Should the
> library be imported in the top level directory along with other
> libraries (like libiberty, libatomic, liboffloadmic etc), or should it
> be imported inside gcc/ like it is done
Snapshot gcc-4.9-20160622 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160622/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi there-
quick question,
does deque as defined in libstdc++ allocate upon initialisation or upon
first insertion?
Trying to dig through the code but can't figure it out.
Reason being, it's insertion graphs seem to show a surprisingly linear
progression from small amounts of N to large amounts.
18 matches
Mail list logo
