On Tue, Jan 12, 2016 at 2:22 PM, Jim Wilson wrote:
> I see a number of places in tree-vect-generic.c that add a
> VIEW_CONVERT_EXPR if useless_type_convertsion_p is false. That should
> work, except when I try this, I see that the VIEW_CONVERT_EXPR gets
> converted to a NOP_EXPR by gimplify_build
Thanks Manuel.
Is there anyway to get this information with gcc 4.x.x?
Regards,
Vanush
On Tue, Jan 12, 2016 at 5:17 AM, Manuel López-Ibáñez
wrote:
> On 11/01/16 01:08, Vanush Vaswani wrote:
>>
>> I am new to GCC internals.
>>
>> I'm trying to create a plugin to operate on pragmas. Currently hav
Snapshot gcc-5-20160112 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160112/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
I'm looking at an ICE on SPEC 2006 464.h264ref slice.c that occurs
with -O3 for both aarch64 and armhf.
palantir:2080$ ./xgcc -B./ -O3 -S slice.i
slice.c: In function ‘poc_ref_pic_reorder’:
slice.c:838:6: error: incorrect type of vector CONSTRUCTOR elements
{_48, _55, _189, _59}
vect_no_reorder_
On 11/01/16 08:20, Gerald Pfeifer wrote:
Compiling Wine with GCC trunk (to become GCC 6) I noticed four
dozen of warnings triggered by -Wmisleading-indentation.
Some are simply weird formatting, some may be indicative of
real issues -- and I have started to look into them one by
one and submitti
On Tue, Jan 12, 2016 at 03:11:29PM +0900, AKASHI Takahiro wrote:
> Will,
>
> On 01/09/2016 12:53 AM, Will Deacon wrote:
> >On Fri, Jan 08, 2016 at 02:36:32PM +0900, AKASHI Takahiro wrote:
> >>On 01/07/2016 11:56 PM, Richard Earnshaw (lists) wrote:
> >>>On 07/01/16 14:22, Will Deacon wrote:
> O
On 01/12/2016 06:44 AM, Jeff Law wrote:
I would argue that each of these does represent misleading
indentation and that the warning is warranted for each.
Perhaps they aren't as bad as prior cases, but I'd still
consider them mis-leading.
(https://gcc.gnu.org/ml/gcc-patches/2015-10/msg03242.html
On 12/01/16 17:10, Jakub Jelinek wrote:
Hi!
What is the reason for these notes?
From https://gcc.gnu.org/ml/gcc-patches/2013-03/msg01316.html:
...
Using the reg-note we are able to easily link call_insns to their
corresponding declaration, even after the calls may have been split into
an ins
Hi!
What is the reason for these notes?
I mean, for indirect calls usually the argument is NULL, so at least for
that case I'd say
(expr_list:REG_CALL_DECL (nil)
is just a waste of RTL memory, because nothing will really make use of it:
static tree
get_call_fndecl (rtx_insn *insn)
{
rtx note, d
On Mon, 11 Jan 2016 13:51:25 -0700
Tom Tromey wrote:
> > "Michael" == Michael Matz writes:
>
> Michael> Well, that's a hack. A solution is to design something that
> Michael> works generally for garbage collected languages with such
> Michael> requirements instead of arbitrarily limiting
On 01/12/2016 05:22 PM, Andrew Pinski wrote:
On Tue, Jan 12, 2016 at 12:18 AM, Eric Botcazou wrote:
-fstack-usage does not work when there are VLAs or alloca's. So there
is no way to figure that part out without analysis of the actual
assembly code.
No, -fstack-usage always works, i.e. its o
On Tue, Jan 12, 2016 at 12:18 AM, Eric Botcazou wrote:
>> -fstack-usage does not work when there are VLAs or alloca's. So there
>> is no way to figure that part out without analysis of the actual
>> assembly code.
>
> No, -fstack-usage always works, i.e. its output can always be relied upon;
> wh
> -fstack-usage does not work when there are VLAs or alloca's. So there
> is no way to figure that part out without analysis of the actual
> assembly code.
No, -fstack-usage always works, i.e. its output can always be relied upon;
when it cannot compute the maximum stack usage, it prints "unbound
13 matches
Mail list logo
