Basile Starynkevitch | 29 Aug 17:29 2014
Picon

GCC plugins & GGC & explicit gcc_free

Hello All,

[[I know that this is a sensitive issue, and I also know that I am in
the minority believing that a garbage collection is useful inside the
GCC compiler]]

How should plugins deal with data that is explicitly gcc_free-d outside
of ggc_collect?

In particular, plugins are apparently allowed to have their own GTY-ed
data (which is very good, I certainly don't want that feature to
disappear). I'm particularly thinking of "static analysis" (or
"observing") plugins, which would take advantage of the GCC compiler to
add some extra measures and analysis but which won't change anything
observable in the GCC internal representations (e.g. plugins that won't
add or remove any Gimple inside existing functions, for instance).

I believe that such "observing" plugins should certainly be allowed to
register a pass which would put some data (e.g. tree-s or basic_block-s)
inside some GTY-ed variable and examine it much later, perhaps even at
PLUGIN_FINISH time (and certainly at PLUGIN_FINISH_UNIT time). This
would make sense if such a plugin would like to make some detailed
statistics, serialize *some* of the Gimple or Tree-s in a database, etc.

However, such a plugin could crash, because at several occasions
ggc_free is *forcibly* called *outside* of the garbage collector - and
there is no mechanism (finalization, plugin hooks) to communicate that
deletion to the plugin. So such a plugin will keep a *stale* data
referenced by its GTY-ed roots.

(Continue reading)

lin zuojian | 29 Aug 11:50 2014
Picon

record_component_aliases will not record the bases with no field declaration

Hi,
    record_component_aliases only handle fields of a record type, and
    would ignore the base of this record if the base has no field
    declaration.
    Is this a bug or on purpose?
    Thanks.
--
Lin Zuojian

DJ Delorie | 29 Aug 06:27 2014
Picon

push_rounding vs memcpy vs stack_pointer_delta


The m32c-elf with -mcpu=m32c has a word-aligned stack and uses pushes
for arguments (i.e. not accumulate_outgoing_args).  In this test case,
one of the arguments is memcpy'd into place, and an assert fails:

typedef struct {
  int a, b, c, d, e, f, g, h;
} foo;
int x;
void
dj (int a, int b, foo c)
{
  dj2 (x, a, b, c);
}

      if (pass == 0)
	{
	  . . .
	}
      else
	{
	  normal_call_insns = insns;

	  /* Verify that we've deallocated all the stack we used.  */
	  gcc_assert ((flags & ECF_NORETURN)
		      || (old_stack_allocated
			  == stack_pointer_delta - pending_stack_adjust));
	}

After much debugging, it turns out that the argument that's memcpy'd
(Continue reading)

gccadmin | 29 Aug 00:36 2014
Picon

gcc-4.8-20140828 is now available

Snapshot gcc-4.8-20140828 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140828/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 214699

You'll find:

 gcc-4.8-20140828.tar.bz2             Complete GCC

  MD5=b7500b4927a15060390231fa28ad591e
  SHA1=197a41099174ce18b6cef876631ad8c62c91b027

Diffs from 4.8-20140821 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

gccadmin | 28 Aug 00:45 2014
Picon

gcc-4.9-20140827 is now available

Snapshot gcc-4.9-20140827 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140827/
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/gcc-4_9-branch revision 214609

You'll find:

 gcc-4.9-20140827.tar.bz2             Complete GCC

  MD5=a04385e042728145006bda74b6bd4572
  SHA1=29ee60c2b9030e97274be00f56929cd1a591ec00

Diffs from 4.9-20140820 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Basile Starynkevitch | 27 Aug 20:29 2014
Picon

consistent naming of passes....

Hello all,

When I compile some file (precisely, the gcc/melt-runtime.cc from the latest melt branch) with -O1
-fdump-passes (using GCC 4.9) I'm getting
notably

   ipa-cp                                              :  OFF
   ipa-cdtor                                           :  OFF
   ipa-inline                                          :  ON
   ipa-pure-const                                      :  ON
   ipa-static-var                                      :  ON
   ipa-pta                                             :  OFF
   ipa-simdclone                                       :  OFF
   *free_cfg_annotations                               :  ON

However, in file gcc/ipa-inline.c there is

const pass_data pass_data_ipa_inline =
{
  IPA_PASS, /* type */
  "inline", /* name */
  OPTGROUP_INLINE, /* optinfo_flags */
  false, /* has_gate */
  true, /* has_execute */
  TV_IPA_INLINING, /* tv_id */

I find strange that the two names (the one given by -fdump-passes and the one in the pass_data_ipa_inline
object) are different.

When I try to insert a plugin pass (actually in MELT, file gcc/melt/xtramelt-ana-simple.melt) named
(Continue reading)

Wilco Dijkstra | 27 Aug 18:24 2014

Register allocation: caller-save vs spilling

Hi,

I'm investigating various register allocation inefficiencies. The first thing that stands out is
that GCC both supports caller-saves as well as spilling. Spilling seems to spill all definitions and
all uses of a liverange. This means you often end up with multiple reloads close together, while it
would be more efficient to do a single load and then reuse the loaded value several times.
Caller-save does better in that case, but it is inefficient in that it repeatedly stores registers
across every call even if unchanged. If both were fixed to minimise the number of loads/stores I
can't see how one could beat the other, so you'd no longer need both.

Anyway due to the current implementation there are clearly cases where caller-save is best and cases
where spilling is best. However I do not see it making the correct decision despite trying to
account for the costs - some code is significantly faster with -fno-caller-saves, other code wins
with -fcaller-saves. As an example, I see code like this on AArch64:

        ldr     s4, .LC20
        fmul    s0, s0, s4
        str     s4, [x29, 104]
        bl      f
        ldr     s4, [x29, 104]
        fmul    s0, s0, s4

With -fno-caller-saves it spills and rematerializes the constant as you'd expect:

        ldr     s1, .LC20
        fmul    s0, s0, s1
        bl      f
        ldr     s5, .LC20
        fmul    s0, s0, s5

(Continue reading)

Daniel Gutson | 27 Aug 16:27 2014

Possible LRA issue?

Hi,

   I have a large codebase where at some point, there's a structure
that takes an unsigned integer template argument, and uses as the size
of an array, something like

template <class T, size_t S>
struct Struct
{
    typedef std::array<T, S> Chunk;
    typedef std::list<Chunk> Content;

   Content c;
};

Changing the values of S alters significantly the compile time and
memory that the compiler takes. We use some large numbers there.
At some point, the compiler runs out of memory (xmalloc fails). I
wondered why, and did some analysis by debugging the 4.8.2 (same with
4.8.3), and did the following experiment turning off all the
optimizations (-fno-* and -O0):
  I generated a report of xmalloc usage of two programs: one having
S=10u, and another with S=11u, just to see the difference of 1.
The report was generated as follows: I set a breakpoint at xmalloc,
appending a bt to a file. Then I found common stack traces and counted
how many xmallocs were called in one and another versions of the
program (S=10u and S=11u as mentioned above).
The difference were:

a) Stack trace:
(Continue reading)

Dominik Vogt | 27 Aug 11:59 2014
Picon

Turning a single warning into an error in dejagnu test

I'm writing a dejagnu test and encounter this warning at one place:

  warning: passing argument 1 of '...' makes integer from pointer
  without a cast [enabled by default]

Now, I have a "{ dg-error ... }" comment in that line.  The line
is generated from a script among hundreds of others that are all
expected to produce errors, not warnings.  It would be very
inconvenient (= lots of work) to change the script to make an
exception just for that single line (because there's no easy way
to identify lines that produce the warning instead of an error).

So the question is:  Is it possible to turn only this one warning
into an error inside a dejagnu test?  As I understand it, there
are no -W... switches for "enabled by default" options, and I
cannot use -Werror because that would break other tests in the
file.

Ciao

Dominik ^_^  ^_^

--

-- 

Dominik Vogt
IBM Germany

Mike Stump | 27 Aug 07:06 2014
Picon
Picon

The C++ link on the main web page seems old

Gosh, https://gcc.gnu.org/projects/cxx0x.html and
https://gcc.gnu.org/gcc-4.8/cxx0x_status.html seem to old and dated now.  First, the standard before
last has been published.  Second, at some point, it can’t be experimental anymore.  Would be nice if
someone could update the content.  The part about the concepts branch being dead is now wrong, it is alive again.
Sebastian Pop | 26 Aug 15:56 2014
Picon

[AArch64] Using QEMU to run Ubuntu ARM 64-bit

Hi,

my colleague Brian has posted the instructions to set up
an AArch64 virtual machine running ubuntu on top of qemu:

http://rzycki.blogspot.com/2014/08/using-qemu-to-run-ubuntu-arm-64-bit.html

We are using this setup to bootstrap gcc on aarch64.

Sebastian


Gmane