Re: GCC version bikeshedding

[Andreas Schwab]

Richard Sandiford  writes:

> So if x.y.z is __GNU__.__GNU_MINOR__.__GNU_PATCHLEVEL__ then the positions
> in the number stay the same but the meanings of __GNU_MINOR__ and
> __GNU_PATCHLEVEL__ change.

There is no change in meaning.  .. stays the
same.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GCC version bikeshedding

[Richard Sandiford]

Andreas Schwab  writes:
> Richard Sandiford  writes:
>> So if x.y.z is __GNU__.__GNU_MINOR__.__GNU_PATCHLEVEL__ then the positions
>> in the number stay the same but the meanings of __GNU_MINOR__ and
>> __GNU_PATCHLEVEL__ change.
>
> There is no change in meaning.

Sure there is, in terms of the release progression.  The whole point of
the discussion is that what used to be the "patchlevel" would become
the "minor version".

Richard

Re: GCC version bikeshedding

[Andreas Schwab]

Richard Sandiford  writes:

> Andreas Schwab  writes:
>> Richard Sandiford  writes:
>>> So if x.y.z is __GNU__.__GNU_MINOR__.__GNU_PATCHLEVEL__ then the positions
>>> in the number stay the same but the meanings of __GNU_MINOR__ and
>>> __GNU_PATCHLEVEL__ change.
>>
>> There is no change in meaning.
>
> Sure there is, in terms of the release progression.  The whole point of
> the discussion is that what used to be the "patchlevel" would become
> the "minor version".

The patchlevel remains the patchlevel, which is the third part of the
version number.  It's no longer modified by the offcial releases, but
that doesn't change its meaning.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Question for ARM person re asm_fprintf

[Kyrill Tkachov]

Hi David,

On 22/07/14 02:46, David Wohlferd wrote:

I have been looking at asm_fprintf in final.c, and I think there's a
design flaw.  But since the change affects ARM and since I have no
access to an ARM system, I need a second opinion.

asm_fprintf allows platforms to add support for new format specifiers by
using the ASM_FPRINTF_EXTENSIONS macro.  ARM uses this to add support
for %@ and %r specifiers.  Pretty straight-forward.

However, it isn't enough to add these two items to the case statement in
asm_fprintf.  Over in c-format.c, there is compile-time checking that is
done against calls to asm_fprintf to validate the format string.  %@ and
%r have been added to this checking (see asm_fprintf_char_table), but
NOT in a platform-specific way.

This means that using %r or %@ will successfully pass the format
checking on all platforms, but will ICE on non-ARM platforms since there
are no case statements in asm_fprintf to support them.

Compiling the code in asm_fprintf-1.c (see the patch) with this patch
correctly reports "unknown conversion type character" for both 'r' and
'@' in  x86_64-pc-cygwin.  It would be helpful if someone could confirm
that it still compiles without error under ARM after applying this
patch.  I'm reluctant to post this to gcc-patches when it has never been
run.


I've tested the asm_fprintf-1.c test on an arm-none-eabi cross compiler 
with this patch which I think should be enough for this patch's 
purposes, I've confirmed that the assembly generated contains the:

.ascii  "%@%r\000"

string so I'd suggest you go ahead and post it to gcc-patches.
This is, of course, not a full regression suite run and I'm not sure if 
there's anything else in the testsuite that would exercise this bit of 
code, but I can kick off a run for that later if you'd like.


Kyrill

dw

Re: [gomp4] Offloading wiki page

[Bernd Schmidt]

On 07/21/2014 09:07 PM, Ilya Verbin wrote:

I've created a wiki page about offloading.  Any improvements are welcome.


It says "Immutable Page", so I can't seem to edit it. Anyway, here are 
my thoughts on the configure/make changes (should go into the TODO section):


The host and offload compilers need to be able to find each other. This 
is achieved by installing the offload compiler into special locations, 
and informing each about the presence of the other. All available 
offload compilers must first be configured with 
"--enable-as-accelerator-for=host-triplet", and installed into the same 
prefix as the host compiler. Then the host compiler is built with 
"--enable-offload-targets=target1,target2,..." which identifies the 
offload compilers that have already been built and installed.


The install locations for the offload compilers differ from those of a 
normal cross toolchain, by the following mapping:


bin/$target-gcc   -> bin/$host-accel-$target-gcc
lib/gcc/$target/$ver/ -> lib/gcc/$host/$ver/accel/$target

It may be necessary to compile offload compilers with a sysroot, since 
otherwise install locations for libgomp could clash (maybe that library 
needs to move into lib/gcc/..?)


A target needs to provide a mkoffload tool if it wishes to be usable as 
an accelerator. It is installed as one of EXTRA_PROGRAMS, and the host 
lto-wrapper knows how to find it from the paths described above. 
mkoffload will invoke the offload compiler in LTO mode to produce an 
offload binary from the host object files, then post-process this to 
produce a new object file that can be linked in with the host 
executable. It can find the host compiler by examining $COLLECT_GCC, and 
it must take care to clear this and certain other environment variables 
when executing the offload compiler so as to not confuse it.


The object file produced with mkoffload should contain a constructor 
that calls GOMP_offload_register to identify itself at run-time. 
Arguments to that function are a symbol called __OPENMP_TARGET__, 
provided by libgcc and unique per shared object, a table with 
information about mappings between host and offload functions and 
variables, and a target identifier.


[ Note: on gomp-4_0-branch, all the Makefile bits aren't entirely 
working at the moment since we were intending to use a slightly 
different scheme for nvptx. However, this is how it should work after I 
get some patches installed. ]


For reference, I'm attaching my current version of ptx mkoffload.


Bernd

/* Offload image generation tool for ptx

   Nathan Sidwell 
   Bernd Schmidt 

   Munges PTX assembly into a C source file defining the PTX code as a
   string.

   This is not a complete assembler.  We presume the source is well
   formed from the compiler and can die horribly if it is not.  */

#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "intl.h"
#include 
#include "obstack.h"
#include "diagnostic-core.h"
#include "collect-utils.h"

const char tool_name[] = "nvptx mkoffload";

#define COMMENT_PREFIX "#"

typedef enum Kind
{
  /* 0-ff used for single char tokens */
  K_symbol = 0x100, /* a symbol */
  K_label,  /* a label defn (i.e. symbol:) */
  K_ident,  /* other ident */
  K_dotted, /* dotted identifier */
  K_number,
  K_string,
  K_comment
} Kind;

typedef struct Token
{
  unsigned short kind : 12;
  unsigned short space : 1; /* preceded by space */
  unsigned short end : 1;   /* succeeded by end of line */
  /* Length of token */
  unsigned short len;

  /* Token itself */
  char const *ptr;
} Token;

/* statement info */
typedef enum Vis
{
  V_dot = 0,  /* random pseudo */
  V_var = 1,  /* var decl/defn */
  V_func = 2, /* func decl/defn */
  V_insn = 3, /* random insn */
  V_label = 4, /* label defn */
  V_comment = 5,
  V_pred = 6,  /* predicate */
  V_mask = 0x7,
  V_global = 0x08, /* globalize */
  V_weak = 0x10,   /* weakly globalize */
  V_no_eol = 0x20, /* no end of line */
  V_prefix_comment = 0x40 /* prefixed comment */
} Vis;

typedef struct Stmt
{
  struct Stmt *next;
  Token *tokens;
  unsigned char vis;
  unsigned len : 12;
  unsigned sym : 12;
} Stmt;

struct id_map
{
  id_map *next;
  char *ptx_name;
};

static const char *read_file (FILE *);
static Token *tokenize (const char *);

static void write_token (FILE *, const Token *);
static void write_tokens (FILE *, const Token *, unsigned, int);

static Stmt *alloc_stmt (unsigned, Token *, Token *, const Token *);
#define alloc_comment(S,E) alloc_stmt (V_comment, S, E, 0)
#define append_stmt(V, S) ((S)->next = *(V), *(V) = (S))
static Stmt *rev_stmts (Stmt *);
static void write_stmt (FILE *, const Stmt *);
static void write_stmts (FILE *, const Stmt *);

static Token *parse_insn (Token *);
static Token *parse_list_nosemi (Token *);
static Token *parse_init (Token *);
static Token *parse_file (Token *);

static Stmt *decls;
static Stmt *vars;
static Stmt *fns;

static id_map *func_ids, **funcs_tail = &func_ids;
static id_map *var_ids

Notes from GNU Cauldron 2014

[Alex Bradbury]

First of all, thanks to the organisers and the speakers for a very
enjoyable and informative event. I took notes during many of the talks
and someone suggested I share these notes to the list in case anyone
is interested. I'm afraid I missed the steering committee Q+A and
didn't take notes on the release management Q+A.

You can find a markdown version of my notes pasted below, or else in
HTML at the end of http://llvmweekly.org/issue/29. Details on the
speakers can be found at https://gcc.gnu.org/wiki/cauldron2014

### Glibc BoF
* 2.20 is in "slushy" freeze mode. What else is left? fmemopen, fd locking,
some `-Wundef` work
* Anyone planning to check in something big for 2.21?
* Mentor Graphics planning to check in a NIOS II port. They won't be
accepted until Linux kernel patches are in a kernel release.
* A desire for AArch64 ILP32 ABI to get in. Kernel patches currently in
review, compiler work is ready.
* OpenRISC
* NaCl (nptl)
* Benchmarking glibc? Does anyone have a good approach. There is a preload
library approach (see notes from Ondrej's talk).
* Glibc has been built with AddressSanitizer, help needed to get it integrated
into the build system. There was a comment this would be nice to get in to
distributions.
* Red Hat are working on supporting alternate libm implementations, including
a low-precision and high-precision implementation. Intel are looking to add
math functions that work on small vectors.

### Abigail: toward ABI taming
* Want to determine if changes to your shared library break apps for users,
and users want to know whether an updated library remains compatible with
their code. The bidiff tool will tell you the differences in terms of ABI
given two object files as its input.
* libabi consists of modules such as a DWARF reader, the comparison engine.
Tools such as bidiff are built on this API
* What's next for libabigail?
* bicompat will help application authors determine whether their
application A is still compatibile with an updated version of a given
library L by examining the undefined symbols of A that are resolved by L.
* More amenable to automation (such as integration into build systems)
* Support for un-instantiated templates. This would require declarations
of uninstantiated templates to be represented in DWARF.
* A first official release (though source is available at
)

### Writing VMs in Java and debugging them with GDB
* Oracle Labs have been working on various dynamic language implementations in
Java (e.g. Ruby, Python, R, JS, ...).
* FastR is a reimplementation of R in Java featuring an interpreter (Truffle)
and dynamic compiler (Graal).
* Truffle and Graal starts with an AST interpreter. The first time a node is
evaluated it is specialised to the type that was seen at runtime. Later the
tree is compiled using partial evaluation.
* It may be deployed on standard HotSpot (no compilation), GraalVM, or the
SubstrateVM (SVM) which uses Graal to ahead-of-time compile the language
implementation. Debugging the SVM is difficult as Java debugging tools are not
available. The solution is to generate DWARF information in the SVM's output.
* Truffle and Graal are open source, the SubstrateVM is not (yet?).

### GCC and LLVM collaboration
* Good news: license issues, personal grudges and performance are off-topic.
* Users should be protected from whatever disagreements take place. In the
future we should have more pro-active discussions on various issues as opposed
to reactive discussions regarding e.g. compiler flags that have been noticed
to be arbitrarily different after the fact.
* Renato lists common projects that we may collaborate on: binutils, glibc,
sanitizers. Sanitizers are a collaboration success story.
* Can we agree on a (new?) common user interface?
* There's a surprising amount of confusion about `-march`, `-mtune`, and
`-mcpu` considering we're in a room of compiler developers. It sounds like
there's not much support for re-engineering the set of compiler flags as the
potential gain is not seen as being great enough.
* Can we agree to standardise on attributes, C/C++ extensions, builtins, ASM,
the linker API?
* GCC docs have just been rewritten, so some criticisms about how difficult it
is to dig in are no longer valid.

### Machine Guided Energy Efficient Compilation
* Initial investigations in 2012 found that compiler flags can have a
meaningful effect on energy consumption. This raises the question of how to
determine which flags to use.
* MAGEEC will target both GCC and LLVM initially. It is implemented as a
compiler plugin which performs feature extraction and allows the output of the
machine learning algorithm to change the sequence of passes which are run.
Fractional Factorial Design is used to reduce the optimisation space to
explore.
* Turning passes on/off arbitrarily can often result in internal compiler
errors. Should the machine learning algorithm learn this, or should GCC b

Re: [gomp4] Offloading wiki page

[Thomas Schwinge]

Hi!

On Tue, 22 Jul 2014 13:06:19 +0200, Bernd Schmidt  
wrote:
> On 07/21/2014 09:07 PM, Ilya Verbin wrote:
> > I've created a wiki page about offloading.  Any improvements are welcome.

Guys, thanks for setting this up so quickly!

> It says "Immutable Page", so I can't seem to edit it.

Probably applies for your write access to any wiki page, and that's
because you've not been added to thw whitelist,
?  I can add your ID, as can
everyone else who already has access.


Grüße,
 Thomas


pgpFzpSR7gaxy.pgp
Description: PGP signature

Re: [gomp4] Offloading wiki page

[Bernd Schmidt]

On 07/22/2014 01:24 PM, Thomas Schwinge wrote:
> On Tue, 22 Jul 2014 13:06:19 +0200, Bernd Schmidt 
 wrote:

>> It says "Immutable Page", so I can't seem to edit it.
>
> Probably applies for your write access to any wiki page, and that's
> because you've not been added to thw whitelist,
> ?  I can add your ID, as can
> everyone else who already has access.

Sounds plausible. I couldn't remember enough account details to login or 
reset the password, so I made a new account, BerndSchmidt - if you could 
add that...



Bernd

Re: [gomp4] Offloading wiki page

[Thomas Schwinge]

Hi!

On Tue, 22 Jul 2014 13:30:55 +0200, Bernd Schmidt  
wrote:
> On 07/22/2014 01:24 PM, Thomas Schwinge wrote:
>  > On Tue, 22 Jul 2014 13:06:19 +0200, Bernd Schmidt 
>  wrote:
>  >> It says "Immutable Page", so I can't seem to edit it.
>  >
>  > Probably applies for your write access to any wiki page, and that's
>  > because you've not been added to thw whitelist,
>  > ?  I can add your ID, as can
>  > everyone else who already has access.
> 
> Sounds plausible. I couldn't remember enough account details to login or 
> reset the password, so I made a new account, BerndSchmidt - if you could 
> add that...

Maybe that has actually been your wiki handle before, but at one point
got pruned due to inactivity -- I added it to the page, and noticed that
it points to your 2008 page, .
;-) Happy editing!


Grüße,
 Thomas


pgptFn4mrRLEd.pgp
Description: PGP signature

SC: New MIPS maintainers needed

[Richard Sandiford]

I'll need to step down as MIPS maintainer this weekend in order to avoid
a possible conflict of interest with a new job.  SC: please could you
appoint some new maintainers to take over?

Matthew and Catherine (cc:ed) have been among the biggest contributors
to the MIPS port recently and they said they'd be willing to act as
co-maintainers.  Obviously it doesn't need to be just 2 people though
and I'm certainly not trying to exclude anyone.  If someone else would
like to put their name forward, please do.

Thanks,
Richard

[ARM] Is TARGET_UNIFIED_ASM still needed?

[Kyrill Tkachov]

Hi all,

In the arm backend we've got this TARGET_UNIFIED_ASM macro that is 
currently on for TARGET_THUMB2 with a comment that says:

/* We could use unified syntax for arm mode, but for now we just use it
   for Thumb-2.  */

I've been doing some work converting the pre-UAL floating point 
mnemonics to unified syntax and it seems if we were to strictly adhere 
to this TARGET_UNIFIED_ASM I would have to guard those changes, which 
would be somewhat ugly.


Is it perhaps time to just drop this and assume unified asm everywhere?


Kyrill

Re: GCC version bikeshedding

[Richard Biener]

On Tue, Jul 22, 2014 at 10:07 AM, Andreas Schwab  wrote:
> Richard Sandiford  writes:
>
>> Andreas Schwab  writes:
>>> Richard Sandiford  writes:
 So if x.y.z is __GNU__.__GNU_MINOR__.__GNU_PATCHLEVEL__ then the positions
 in the number stay the same but the meanings of __GNU_MINOR__ and
 __GNU_PATCHLEVEL__ change.
>>>
>>> There is no change in meaning.
>>
>> Sure there is, in terms of the release progression.  The whole point of
>> the discussion is that what used to be the "patchlevel" would become
>> the "minor version".
>
> The patchlevel remains the patchlevel, which is the third part of the
> version number.  It's no longer modified by the offcial releases, but
> that doesn't change its meaning.

Btw, we'd have the opportunity to fix one long-standing issue with our
versioning.  Once we release 4.9.1 the branch becomes 4.9.2 (prerelease)
but any version checking using __GNU_PATCHLEVEL__ checking for a
fix that went into the 4.9.2 release will not work for snapshots between
the 4.9.1 and the 4.9.2 releases.  Now we'd have the opportunity to
encode "prerelease" vs. "" vs. "experimental" with the patchlevel.
Say the first release from the branch will be 5.1.0 and immediately after
it we bump to 5.1.1 (_not_ 5.2.0 as we do now).  For the next release
(and a single SVN revision) we bump to 5.2.0 and then immediately
to 5.2.1.  And we don't have to call it "prerelease" then (which sounds
bad, worse than "postrelease" and not changing the version).

Richard.


> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

Re: GCC version bikeshedding

[Marek Polacek]

On Sun, Jul 20, 2014 at 07:01:46PM +0200, Jakub Jelinek wrote:
> Ian/Jason, is that your understanding too?  In any case, we should mention
> it on gcc.gnu.org/index.html, in develop.html and perhaps a few other spots.

Also it'd be nice to create htdocs/gcc-5.0/changes.html, so we can
start adding new features there.  Gerald?

Marek

Re: [ARM] Is TARGET_UNIFIED_ASM still needed?

[Ramana Radhakrishnan]

On 22/07/14 14:14, Kyrill Tkachov wrote:

Hi all,

In the arm backend we've got this TARGET_UNIFIED_ASM macro that is
currently on for TARGET_THUMB2 with a comment that says:
/* We could use unified syntax for arm mode, but for now we just use it
 for Thumb-2.  */

I've been doing some work converting the pre-UAL floating point
mnemonics to unified syntax and it seems if we were to strictly adhere
to this TARGET_UNIFIED_ASM I would have to guard those changes, which
would be somewhat ugly.


I would just change vfp.md to UAL and expect it to work because GAS 
accepts unified syntax for the floating point instructions even without 
.syntax unified.


We need T_U_A until the point of time that the Thumb1 port is converted 
to UAL, GAS validated against Thumb1 and the rest of the "arm" port is 
converted to UAL and verified with GAS.


Additionally if someone were to do the full transition, remember that 
users need to have a way of mixing non-unified syntax in inline 
assembler with unified syntax in the rest of the C code.



regards
Ramana



Is it perhaps time to just drop this and assume unified asm everywhere?


Kyrill

Re: [GSoC] generation of Gimple code from isl_ast_node_block

[Roman Gareev]

It seems that the problem is solved now. Thank you! I've sent
corresponding patches to gcc-patches.

--
   Cheers, Roman Gareev.

Re: [GSoC] Question about the implementation of vec.h

[Roman Gareev]

> Yes, you need to use .create() to initialize vec instances.

Thank you for the answer!

--
   Cheers, Roman Gareev.

PSU left at GNU Tools Cauldron

[Jeremy Bennett]

Hi all,

We have a Dell Laptop PSU which was left at the GNU Tools Cauldron. If
it is yours and you would like it back, please email me off list.


Jeremy

-- 
Tel:  +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Twitter: @jeremypbennett
Email:   jeremy.benn...@embecosm.com
Web: www.embecosm.com

Fw: Results for 4.9.1 (GCC) testsuite on i686-pc-linux-gnu

[Raghu L]

Dear GCC Team,

As there are no test results listed in buildstats page for GCC (4.9.1) for 
i686-pc-linux-gnu, I am herewith sending the testsuite results. You can list 
them in buildstats page.


Regards,
Raghunath Lolur.




On Tuesday, 22 July 2014 11:17 PM, Raghu L  wrote:
I would like to inform successful native bootstrap build of GCC 4.9.1 on 
i686-pc-linux-gnu.

My Linux distribution info: Ubuntu 12.04.3 LTS

$ ../combined/config.guess
i686-pc-linux-gnu

$ ~/localbuild-gcc-4-9-1/build$ /usr/local/gcc-4-9-1/bin/i686-
pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc-4-9-1/bin/i686-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc-4-9-1/libexec/gcc/i686-pc-linux-gnu/4.9.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../combined/configure --host=i686-pc-linux-gnu 
--build=i686-pc-linux-gnu --target=i686-pc-linux-gnu 
--prefix=/usr/local/gcc-4-9-1 --disable-nls --disable-werror --disable-multilib 
--enable-__cxa_atexit --enable-c99 --enable-long-long --enable-threads=posix 
--enable-checking=release --enable-libstdcxx-time --enable-languages=c,c++
Thread model: posix
gcc version 4.9.1 (GCC)


Version of the Linux Kernel :

$ uname -a
Linux linux 3.8.0-29-generic #42~precise1-Ubuntu SMP Wed Aug 14 15:31:16 UTC 
2013 i686 i686 i386 GNU/Linux

Version of glibc on my system:

$ dpkg -l libc6

Name   Version    Description
==-==-
 libc6  2.15-0ubuntu10 Embedded GNU C Library: Shared libraries

Test Results:
=

cat <<'EOF' |
LAST_UPDATED: Obtained from SVN: tags/gcc_4_9_1_release revision 212636

Native configuration is i686-pc-linux-gnu

    === binutils tests ===


Running target unix

    === binutils Summary ===

# of expected passes    94
# of unsupported tests    3
    === gas tests ===


Running target unix

    === gas Summary ===

# of expected passes    412
    === gcc tests ===


Running target unix

    === gcc Summary ===

# of expected passes    105255
# of expected failures    252
# of unsupported tests    1206
/home/user1/localbuild-gcc-4-9-1/build/gcc/xgcc  version 4.9.1 (GCC)

    === g++ tests ===


Running target unix
FAIL: g++.dg/asan/asan_test.C  -O2  AddressSanitizer_HugeMallocTest 
Ident((char*)malloc(size))[-1] = 0 output pattern test
FAIL: g++.dg/ipa/pr61160-3.C -std=gnu++98 execution test
FAIL: g++.dg/ipa/pr61160-3.C -std=gnu++11 execution test
FAIL: g++.dg/ipa/pr61160-3.C -std=gnu++1y execution test

    === g++ Summary ===

# of expected passes    86452
# of unexpected failures    4
# of expected failures    445
# of unsupported tests    2774
/home/user1/localbuild-gcc-4-9-1/build/gcc/testsuite/g++/../../xg++  version 
4.9.1 (GCC)

    === libatomic tests ===


Running target unix

    === libatomic Summary ===

# of expected passes    44
# of unsupported tests    5
    === libgomp tests ===


Running target unix

    === libgomp Summary ===

# of expected passes    726
    === libitm tests ===


Running target unix

    === libitm Summary ===

# of expected passes    26
# of expected failures    3
# of unsupported tests    1
    === libstdc++ tests ===


Running target unix

    === libstdc++ Summary ===

# of expected passes    9327
# of expected failures    41
# of unsupported tests    536
    === ld tests ===


Running target unix
FAIL: PR ld/12758
FAIL: PR ld/12760
FAIL: LTO 3 symbol
FAIL: PR ld/13183
FAIL: LTO 3a
FAIL: LTO 11

    === ld Summary ===

# of expected passes    918
# of unexpected failures    6
# of expected failures    4
# of untested testcases    1

Compiler version: 4.9.1 (GCC)
Platform: i686-pc-linux-gnu
configure flags: --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu 
--target=i686-pc-linux-gnu --prefix=/usr/local/gcc-4-9-1 --disable-nls 
--disable-werror --disable-multilib --enable-__cxa_atexit --enable-c99 
--enable-long-long --enable-threads=posix --enable-checking=release 
--enable-libstdcxx-time --enable-languages=c,c++
EOF

Regards,
Raghunath Lolur.

Re: What would it take to always force indirect inlining?

[Martin Jambor]

Hi,

On Fri, Jul 18, 2014 at 03:31:23PM -0500, Daniel Santos wrote:
> 
> On 07/18/2014 04:55 AM, Martin Jambor wrote:
> >Hi,
> >
> >On Thu, Jul 17, 2014 at 12:26:43PM -0500, Daniel Santos wrote:
> >>I've recently discovered that a function marked always_inline but
> >>called by pointer won't always be inlined. What would it take to
> >>assure that this either always happens or generates an error?
> >Generally, that is the case.  Direct non-inlined calls of
> >always_inline functions thus indicate that the destination become
> >known only after inlining in the optimization pipeline.  Without more
> >context, especially without knowing how exactly you call my_quicksort
> >function, it is impossible to say why.  If you cannot povide us with
> >the source code (I would be interested if you can), you can try
> >compiling with -fdump-tree-all -fdump-ipa-all-details and go through
> >the generated dump files to find out at what point it becomes known.
> >ipa-cp and ipa-inline dumps also contain information about what
> >inlining context of your function.
> >
> >Martin
> 
> Hello. I've given it a new home:
> https://github.com/daniel-santos/cmeta. I'm using cmake for the
> first time and I'm not sure that I like it. For now, you have to
> *manually* specify your CFLAGS. This is what I'm using:
> 
> CFLAGS="-std=gnu11 -march=native -g3 -pipe -Wall -Wextra
> -Wcast-align -Wno-unused-parameter -O2 -DNDEBUG"
> 
> My -march=native is a Phenom 9850 and I did this on gcc 4.8.3. I
> have 4.9.0 installed, but I haven't examined that one just yet, but
> I will shortly. Also please note that this is currently not the
> worlds prettiest code! (sorry, I guess I'm vain)
> 

I have had a look and it indeed seems to reveal that we miss an
important opportunity for indirect inlining and will work to fix it,
hopefully in the next major version of gcc.  Meanwhile, if you want to
continue your experiments with current releases, you can replace your
ror function pointer with a macro (or its expansion, this is just an
illustration) like in the patch below and I believe it will just work,
at least on 4.9 (I have tried myself with trunk only).

If you want to continue discuss this path more, please take it off the
gcc development mailing list (you can also ask at gcc-help but I am
not subscribed there).

Thank you for the testcase,

Martin

Re: SC: New MIPS maintainers needed

[Jeff Law]

On 07/22/14 06:56, Richard Sandiford wrote:

I'll need to step down as MIPS maintainer this weekend in order to avoid
a possible conflict of interest with a new job.  SC: please could you
appoint some new maintainers to take over?

We'll get the process started.

Stepping down doesn't require you do do anything further than removing 
yourself as the listed maintainer for the MIPS port


jeff

Re: [Copyright transfer] What to do for copyright transfer to FSF for contracted changes?

[Jeff Law]

On 07/21/14 10:19, Andre Vehreschild wrote:

Hi,

I am a freelancer contracted to fix some bugs in the fortran compiler. I
understand that I need to transfer the copyright of that effort to the FSF. My
client and me are willing to sign any paperwork needed for that. Unfortunately
my client will be on holiday from Thursday on.

What do I need to do transfer the copyright of the changes I am contracted to -
which partially are already done and in discussion (see for example "PR 60414:
Patch proposal" on the fortran and gcc-patches list) and for some to come - to
FSF?

Sorry, for the bother. I did not find anything on the web besides
https://gcc.gnu.org/contribute.html#legal which is somewhat unclear to me being
none-native English speaker.
I've forwarded your message to ass...@gnu.org.  Hopefully someone from 
the FSF will be in contact shortly.


jeff

successfully built and installed GCC 4.9.1 armv7l-unknown-linux-gnueabihf

[Stefan Fleischmann]

$ ../gcc-4.9.1/config.guess 
 armv7l-unknown-linux-gnueabihf

$ /opt/gcc/4.9.1/bin/gcc -v
 Using built-in specs.
 COLLECT_GCC=/opt/gcc/4.9.1/bin/gcc
 
COLLECT_LTO_WRAPPER=/opt/gcc/4.9.1/libexec/gcc/arm-linux-gnueabihf/4.9.1/lto-wrapper
 Target: arm-linux-gnueabihf
 Configured with: ../gcc-4.9.1/configure --prefix=/opt/gcc/4.9.1 
--enable-languages=c,c++ --enable-shared --enable-linker-build-id 
--without-included-gettext --enable-threads=posix 
--with-gxx-include-dir=/opt/include/c++/4.9.1 --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--enable-gnu-unique-object --disable-libitm --disable-libquadmath 
--enable-plugin --with-system-zlib --enable-multiarch --enable-multilib 
--disable-sjlj-exceptions --with-arch=armv7-a --with-tune=cortex-a9 
--with-fpu=neon --with-float=hard --with-mode=thumb --disable-werror 
--enable-checking=release --build=arm-linux-gnueabihf 
--host=arm-linux-gnueabihf --target=arm-linux-gnueabihf
 Thread model: posix
 gcc version 4.9.1 (GCC) 

$ cat /etc/issue
 Ubuntu 12.04.4 LTS
$ uname -a
 Linux seco-gpu-devkit 3.1.10-carma #2 SMP PREEMPT Fri Apr 19 15:53:43 CEST 
2013 armv7l armv7l armv7l GNU/Linux
$ dpkg -l libc6
 libc62.15-0ubuntu10.5


=== gcc Summary ===
# of expected passes97329
# of unexpected failures22
# of expected failures  251
# of unresolved testcases   13
# of unsupported tests  1670

=== g++ Summary ===
# of expected passes81773
# of expected failures  447
# of unsupported tests  3208

=== libstdc++ Summary ===
# of expected passes9060
# of expected failures  41
# of unsupported tests  563

=== libgomp Summary ===
# of expected passes723
# of unexpected failures1
# of unsupported tests  1

=== libatomic Summary ===
# of expected passes44
# of unsupported tests  5

Re: GCC version bikeshedding

[Segher Boessenkool]

On Tue, Jul 22, 2014 at 08:44:41AM +0100, Richard Sandiford wrote:
> So why
> not just stick to the current scheme and have 5.0.0, 5.0.1, 5.0.2 etc.?

Yes, why would we use a different numbering scheme now?  There is no change
in development / release planning, unless I missed something.  Is this just
to have bigger number than the "competition"?  Or is it change for change's
sake?  Are there no more important things to be done?


Segher