[snip]
how about replacing the existing
text ("It does not make sense to use this feature with a non-static
local variable since such variables do not have assembler names.") with
"Do not use this feature with a non-static local variable." or maybe "It
is not supported to use this feature with a
Snapshot gcc-4.9-20150819 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20150819/
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
(It appears I accidentally dropped the mailing list)
Hi,
> On 08/19/2015 02:38 PM, DJ Delorie wrote:
> > I've seen this on other targets too, sometimes so bad I write a quick
> > target-specific "stupid move optimizer" pass to clean it up.
> >
> > A generic pass would be much harder, but very use
On Wed, Aug 19, 2015 at 02:08:16PM -0700, David Wohlferd wrote:
> >>My intent here is to break this clearly into two @subsubheadings:
> >>'Assembler names for data' and 'Assembler names for functions'. Since
> >>data is the first section, I removed the word 'function' here.
> >I missed that, sorry.
(Resending due to email glitch)
Thanks again for your comments.
On 8/18/2015 2:23 AM, Segher Boessenkool wrote:
On Mon, Aug 17, 2015 at 09:55:48PM -0700, David Wohlferd wrote:
On systems where an underscore is normally prepended to the name
of a C
-function or variable, this feature allows
On 08/19/2015 02:38 PM, DJ Delorie wrote:
I've seen this on other targets too, sometimes so bad I write a quick
target-specific "stupid move optimizer" pass to clean it up.
A generic pass would be much harder, but very useful.
More important is to determine *why* we're getting these patterns. I
DJ Delorie writes:
> I've seen this on other targets too, sometimes so bad I write a quick
> target-specific "stupid move optimizer" pass to clean it up.
>
> A generic pass would be much harder, but very useful.
Robert (on cc) is currently attempting some improvements to the regrename
pass to tr
I've seen this on other targets too, sometimes so bad I write a quick
target-specific "stupid move optimizer" pass to clean it up.
A generic pass would be much harder, but very useful.
When compiling ARM/thumb with -Os for size, I've seen some cases where GCC
generates unnecessary move instructions.
It seems sometimes that there are some possibility to improve the use from
2-operand into 3-operand instructions.
Some patterns I see is:
Generated code Case 1:
On Wed, 2015-08-19 at 13:40 -0400, David Malcolm wrote:
> Is your pass of the correct type? (presumably IPA_PASS). I've run into
> this a few times with custom passes (which seems to be a "gotcha");
> position_pass can fail here:
>
> /* Check if the current pass is of the same type as the
On Wed, 2015-08-19 at 10:27 -0700, Steve Ellcey wrote:
> I am trying to create a new IPA pass to scan the routines being compiled
> by GCC and I thought I would put it in after the last IPA pass (comdats)
> so I tried to register it with:
>
> opt_pass *p = make_pass_ipa_frame_header_opt (g);
>
I am trying to create a new IPA pass to scan the routines being compiled
by GCC and I thought I would put it in after the last IPA pass (comdats)
so I tried to register it with:
opt_pass *p = make_pass_ipa_frame_header_opt (g);
static struct register_pass_info f =
{p, "comdats", 1, P
If a new option is added, of course it needs documenting in the ld manual
(ld.texinfo).
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, Aug 19, 2015 at 2:10 PM, Uday P. Khedker wrote:
>
>
> Andrew Pinski wrote on Wednesday 19 August 2015 04:44 PM:
>>
>> On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker
>> wrote:
>>>
>>> We are working on an analysis for identifying the class of an object flow
>>> sensitively for
>>> flow s
Andrew Pinski wrote on Wednesday 19 August 2015 04:44 PM:
On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker wrote:
We are working on an analysis for identifying the class of an object flow
sensitively for
flow sensitive de-virtualization (i.e. replacing a virtual function call by
a call to the
Hi all,
This simple patch will tighten the conditions when matching movw and
arm_movt rtx pattern.
Those two patterns will generate the following assembly:
movw w1, #:lower16: dummy + addend
movt w1, #:upper16: dummy + addend
The addend here is optional. However, it should be an 16-bit signed
On Wed, Aug 19, 2015 at 7:16 PM, Uday P. Khedker wrote:
>
> We are working on an analysis for identifying the class of an object flow
> sensitively for
> flow sensitive de-virtualization (i.e. replacing a virtual function call by
> a call to the
> function of a known class in the hierarchy). This
We are working on an analysis for identifying the class of an object flow
sensitively for
flow sensitive de-virtualization (i.e. replacing a virtual function call by a
call to the
function of a known class in the hierarchy). This is a regular ipa pass. It
find outs the
class of an object at po
On 19 August 2015 at 03:16, Martin Sebor wrote:
> On 08/03/2015 12:35 PM, Joel Sherrill wrote:
>>
>> Hi
>>
>> Just noticed this building the head for arm-rtems4.11. Should
>> the first comparison be eliminated and, maybe, a comment added?
>>
>> ctype_members.cc:216:14: warning: comparison of unsign
-Original Message-
From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Ajit
Kumar Agarwal
Sent: Monday, August 17, 2015 4:03 PM
To: Richard Biener
Cc: Jeff Law; gcc@gcc.gnu.org; Vinod Kathail; Shail Aditya Gupta; Vidhumouli
Hunsigida; Nagaraju Mekala
Subject: RE: vec
20 matches
Mail list logo
