On 02/13/2014 04:48 PM, Jan Hubicka wrote:
all bases are also fields of within the type, so the second loop should notice
all the types seen by first loop if I am correct?
Yes, except that empty bases don't get fields because they have no data.
But since they have no data they aren't interest
On Fri, 14 Feb 2014, Jan Hubicka wrote:
> Hi,
> I have noticed that record_component_aliases is called during LTO time and it
> examines contents of BINFO:
> 0x5cd7a5 record_component_aliases(tree_node*)
> ../../gcc/alias.c:1005
> 0x5cd4a9 get_alias_set(tree_node*)
> ../../gcc/alia
Given a specific VAR_DECL tree node, I need to find out whether
its type is built in or not. Up to now I have
tree tn = TYPE_NAME (TREE_TYPE (var_decl));
if (tn != NULL_TREE && TREE_CODE (tn) == TYPE_DECL && DECL_NAME (tn))
{
...
}
This if-condition is true for both,
int x;
On Thu, Feb 13, 2014 at 09:07:55PM -0800, Torvald Riegel wrote:
> That depends on what your goal is.
A compiler that we don't need to fight in order to generate sane code
would be nice. But as Linus said; we can continue to ignore you lot and
go on as we've done.
I have built a crosscompiler for the MSP430, using a gcc4.9 snapshot
(gcc-4.9-20140112) and the compiler seems OK and builds a simple
"blinky" LED flashing example.
But my slightly larger example, originally built using Peter Bigot's
mspgcc backend, no longer compiles ...
mspgcc had a number of
MIPS is currently evaluating the benefit of using SIMD registers to pass vector
data by value. It is currently unclear how important it is for vector data to
be passed in SIMD registers. I.e. the need for passing vector data by value in
real world code is not immediately obvious. The performance
On Fri, Feb 14, 2014 at 2:17 AM, Matthew Fortune
wrote:
> MIPS is currently evaluating the benefit of using SIMD registers to pass
> vector data by value. It is currently unclear how important it is for vector
> data to be passed in SIMD registers. I.e. the need for passing vector data by
> val
Luke A. Guest archeia.com> writes:
>
> Hi,
>
> I've been over this before and have got nowhere with it.
> Say you want to build an Ada compiler for embedded work, ...
> You can build it with "make all-gcc" and install with "make install-gcc"
> ...
> But what about the gnattools? Not buildable
Hello gcc
I have been looking at optimizations of pixel-format conversion recently and
have noticed that gcc does take advantage of SSE4a extrq, BMI1 bextr TBM
bextri or BMI2 pext instructions when it could be useful.
As far as I can tell it should not be that hard. A bextr expression can
typi
On Fri, Feb 14, 2014 at 9:59 AM, Dominik Vogt wrote:
> Given a specific VAR_DECL tree node, I need to find out whether
> its type is built in or not. Up to now I have
>
> tree tn = TYPE_NAME (TREE_TYPE (var_decl));
> if (tn != NULL_TREE && TREE_CODE (tn) == TYPE_DECL && DECL_NAME (tn))
>
On Fri, Feb 14, 2014 at 2:23 PM, Allan Sandfeld Jensen
wrote:
> Hello gcc
>
> I have been looking at optimizations of pixel-format conversion recently and
> have noticed that gcc does take advantage of SSE4a extrq, BMI1 bextr TBM
> bextri or BMI2 pext instructions when it could be useful.
>
> As f
On Fri, 2014-02-14 at 12:11 +, Brian Drummond wrote:
> Revisiting the MSP430 as it's now an official gcc target, this is still a
> problem here too, so there are at least 3 targets for which it's a problem.
It's a problem for all targets.
> Looking at http://gcc.gnu.org/bugzilla/show_bug.cgi
2014-01-31 22:03 GMT+04:00 Jakub Jelinek :
> Implicit map(tofrom: a) on #pragma omp target is what the standard
> requires, so I don't see a bug on the compiler side.
> Jakub
There is an exception in the standard (page 177, lines 17-21):
> If a corresponding list item of the original list
On Fri, Feb 14, 2014 at 07:24:16PM +0400, Ilya Verbin wrote:
> 2014-01-31 22:03 GMT+04:00 Jakub Jelinek :
> > Implicit map(tofrom: a) on #pragma omp target is what the standard
> > requires, so I don't see a bug on the compiler side.
> > Jakub
>
> There is an exception in the standard (pag
On Fri, 2014-02-14 at 15:32 +, Brian Drummond wrote:
> OK I'll take a look.
> Too many make and install targets; I have no idea how this process
> interacts with the process specified here:
> https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Install:redhat
> for the msp430, using (
I created a CRTP (Curiously recurring template pattern)
and added non-static member variables to my base class and that works without
issue. But when I add non-static
variables to the subclass instance the initialization and values for the
variables in this class don't get initialized properly and
On 14 February 2014 07:46, Andrew Stern wrote:
> I created a CRTP (Curiously recurring template pattern)
> and added non-static member variables to my base class and that works without
> issue.
This mailing list is for development of GCC, not for bug reports or
help using it.
I would suggest the
> > This smells bad, since it is given a canonical type that is after the
> > structural equivalency merging that ignores BINFOs, so it may be completely
> > different class with completely different bases than the original. Bases
> > are
> > structuraly merged, too and may be exchanged for norma
On Thu, Feb 13, 2014 at 08:43:01PM -0800, Torvald Riegel wrote:
> On Thu, 2014-02-13 at 18:01 -0800, Paul E. McKenney wrote:
[ . . . ]
> > Another option would be to flag the conditional expression, prohibiting
> > the compiler from optimizing out any conditional branches. Perhaps
> > something
On 02/14/2014 07:43 AM, Jakub Jelinek wrote:
> So, perhaps we should just stop for now oring the copyfrom in and just use
> the copyfrom from the very first mapping only, and wait for what the committee
> actually agrees on.
>
> Richard, your thoughts on this?
I think stopping the or'ing until th
The constructs in the *.md files are for the compiler's internal use
(i.e. there are function attributes that trigger those). You don't
need compiler support for these opcodes at the user level; the right
way is to implement those builtins as inline assembler in a common
header file:
static inli
On Fri, 2014-02-14 at 10:50 +0100, Peter Zijlstra wrote:
> On Thu, Feb 13, 2014 at 09:07:55PM -0800, Torvald Riegel wrote:
> > That depends on what your goal is.
First, I don't know why you quoted that, but without the context,
quoting it doesn't make sense. Let me repeat the point. The standard
On Fri, 2014-02-14 at 09:29 -0800, Paul E. McKenney wrote:
> On Thu, Feb 13, 2014 at 08:43:01PM -0800, Torvald Riegel wrote:
> > On Thu, 2014-02-13 at 18:01 -0800, Paul E. McKenney wrote:
>
> [ . . . ]
>
> > > Another option would be to flag the conditional expression, prohibiting
> > > the compi
On Fri, Feb 14, 2014 at 9:29 AM, Paul E. McKenney
wrote:
>
> Linus, Peter, any objections to marking places where we are relying on
> ordering from control dependencies against later stores? This approach
> seems to me to have significant documentation benefits.
Quite frankly, I think it's stupi
On Fri, Feb 14, 2014 at 11:50 AM, Linus Torvalds
wrote:
>
> Why are we still discussing this idiocy? It's irrelevant. If the
> standard really allows random store speculation, the standard doesn't
> matter, and sane people shouldn't waste their time arguing about it.
Btw, the other part of this c
On Fri, 2014-02-14 at 14:17 -0500, DJ Delorie wrote:
> The constructs in the *.md files are for the compiler's internal use
> (i.e. there are function attributes that trigger those). You don't
> need compiler support for these opcodes at the user level; the right
> way is to implement those builti
> > > This smells bad, since it is given a canonical type that is after the
> > > structural equivalency merging that ignores BINFOs, so it may be
> > > completely
> > > different class with completely different bases than the original. Bases
> > > are
> > > structuraly merged, too and may be ex
On Fri, Feb 14, 2014 at 12:02:23PM -0800, Linus Torvalds wrote:
> On Fri, Feb 14, 2014 at 11:50 AM, Linus Torvalds
> wrote:
> >
> > Why are we still discussing this idiocy? It's irrelevant. If the
> > standard really allows random store speculation, the standard doesn't
> > matter, and sane people
On 02/12/2014 11:51 AM, Roman Gareev wrote:
Hi Roman,
thanks for the quick feedback!
I've found out that this bug appeared in revision 189156
(svn://gcc.gnu.org/svn/gcc/trunk)
and similar error message appeared in revision 191757
(svn://gcc.gnu.org/svn/gcc/trunk)
(maybe it's because of chang
On Fri, Feb 14, 2014 at 6:08 PM, Paul E. McKenney
wrote:
>
> One way of looking at the discussion between Torvald and myself would be
> as a seller (Torvald) and a buyer (me) haggling over the fine print in
> a proposed contract (the standard). Whether that makes you feel better
> or worse about
On Fri, Feb 14, 2014 at 6:44 PM, Linus Torvalds
wrote:
>
> And conversely, the C11 people can walk away from us too. But if they
> can't make us happy (and by "make us happy", I really mean no stupid
> games on our part) I personally think they'll have a stronger
> standard, and a real use case, a
On Fri, Feb 14, 2014 at 06:48:02PM -0800, Linus Torvalds wrote:
> On Fri, Feb 14, 2014 at 6:44 PM, Linus Torvalds
> wrote:
> >
> > And conversely, the C11 people can walk away from us too. But if they
> > can't make us happy (and by "make us happy", I really mean no stupid
> > games on our part) I
On Fri, Feb 14, 2014 at 10:35:44PM -0800, Paul E. McKenney wrote:
> On Fri, Feb 14, 2014 at 06:48:02PM -0800, Linus Torvalds wrote:
> > On Fri, Feb 14, 2014 at 6:44 PM, Linus Torvalds
> > wrote:
> > >
> > > And conversely, the C11 people can walk away from us too. But if they
> > > can't make us h
33 matches
Mail list logo
