gmane.comp.gcc.devel

gcc-4.7-20130525 is now available

2013-05-25T22:41:07

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

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

You'll find:

 gcc-4.7-20130525.tar.bz2             Complete GCC

  MD5=7f6744139890a9b4ebdfe55e5f1557d7
  SHA1=a306f17606e2ba264659f386ed3607f0c84cef62

Diffs from 4.7-20130518 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.7
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.

Members Bullish Alert

2013-05-25T15:41:13

Get a abrupt 200% with BY_SD!!! Priced at recently $.008. 
Approximately a slice of a penny. Sure to burst. Plant your 
bid right now.

I would like to provide a mirror for GCC

2013-05-24T17:00:25

Hello,

I was wondering if you are still accepting mirrors for GCC.

http://gcc.gnu.org/mirrors.html

If you are, I will like to provide one with HTTP, FTP and Rsync access via
a VPS located in Australia, USA, UK, Philippines or Japan or any
combinations of those locations.

Thanks for your reply,

Kind regards,

Timo Jacob

LTO : how to specify number of chunks with option -flto-partition=balanced

Swati — 2013-05-24T07:14:10

Hello,

-flto-partition=balanced is used to specify partitioning into equally 
sized chunks.
Is there an option to specify size or number of chunks?

Regards,
Swati

gcc-4.8-20130523 is now available

2013-05-23T22:37:50

Snapshot gcc-4.8-20130523 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130523/
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 199270

You'll find:

 gcc-4.8-20130523.tar.bz2             Complete GCC

  MD5=124efb74a553fe93c9eb6fb403d55586
  SHA1=50138b09999a57c5ebd060c16e888d4b4a5b5c51

Diffs from 4.8-20130516 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.

La fattura

OrderCo — 2013-05-23T02:53:08


Hello, gcc< at >gnu.org.

Hai un debito per pagare la sua richiesta nel piu breve tempo possibile i dati di pagamento
http://silaskyler.com/Info.zip


malone mailto:malone< at >holycross.net

gcc 4.8: broken headers when using gnu-versioned-namespace

Oleg Smolsky — 2013-05-21T18:24:46

Hey all, I've just built gcc 4.8 with 
--enable-symvers=gnu-versioned-namespace and compilation of a small test 
fails with the following:

In file included from /work/opt/gcc-4.8/include/c++/4.8.0/array:324:0,
                  from /work/opt/gcc-4.8/include/c++/4.8.0/tuple:39,
                  from 
/work/opt/gcc-4.8/include/c++/4.8.0/bits/stl_map.h:63,
                  from /work/opt/gcc-4.8/include/c++/4.8.0/map:61,
                  from ....................
/work/opt/gcc-4.8/include/c++/4.8.0/debug/array:296:12: error: 
‘tuple_size’ is not a class template
      struct tuple_size<__debug::array<_Tp, _Nm>>
...
...

It looks like include/c++/4.8.0/debug/array is missing a couple of wrappers:

_GLIBCXX_BEGIN_NAMESPACE_VERSION
_GLIBCXX_END_NAMESPACE_VERSION

IE it is a similar thing to this change:
     http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=193584

Should I re-open the bug?

Oleg.

Porting libsanitizer to aarch64

Christophe Lyon — 2013-05-21T15:35:45

Hi,

I have been looking at enabling libsanitizer for aarch64 GCC compilers.

To make the build succeed, I had to modify libsanitizer code:
- some syscalls are not available on aarch64 (libsanitizer uses some
legacy ones such as open, readlink, stat, ...)
- unwinding code needs to be added.

What's the way of discussing such patches? On GCC lists or elsewhere?


Then arises a runtime problem: aarch64's frame grows upward which is
not supported: how long would it take to develop this support if at
all possible?

I have not looked at tsan in detail yet, it currently does not build
for aarch64 either.

Thanks,

Christophe.

RFC: S/390 Transactional memory support - save/restore of FPRs

Andreas Krebbel — 2013-05-21T12:40:56

Hi,

I'm currently implementing support for hardware transactional memory
in the S/390 backend and ran into a problem with saving and restoring
the floating point registers.

On S/390 the tbegin instruction starts a transaction.  If a subsequent
memory access collides with another the transaction is aborted.  The
execution then continues *after* the tbegin instruction.  All memory
writes after the tbegin are rolled back, the general purpose registers
selected in the tbegin operand are restored, and the condition code is
set in order indicate that an abort occurred.  What the code then is
supposed to do is to check the condition code and either jump back to
the transaction if it is a temporary failure or provide an alternate
implementation using e.g. a lock.

Unfortunately our tbegin instruction does not save the floating point
registers leaving it to the compiler to make sure the old values get
restored.  This will be necessary if the abort code relies on these
values and the transaction body modifies them.

With my current approach I try to place FPR clobbers to trigger GCC
generating the right save/restore operations.  This has some
drawbacks:

- Bundling the clobbers with the tbegin causes FPRs to be restored
  even in the good path (the transaction never aborts).

- Placing the clobbers on the abort path kinda works. However it is
  not really correct.  GCC could decide to wrap the save/restore
  operations just around the clobbers what would be wrong.  A solution
  to that might be to (that's what I'm currently working on):

  - Bundle the tbegin with the condtional jump to the abort code in
    order to prevent GCC from saving the FPRs right after the tbegin.

  - Direct an abnormal edge to the abort code to tell GCC that the
    FPRs are actually clobbered from somewhere outside (as with EH).

  Does this sound reasonable?

  The point is that not all the execution paths through tbegin
  actually clobber FPRs.  It is only true for the paths which lead to
  the abort code in the end.  So another solution might be to
  implement support for conditional clobbers.  Clobbers wrapped into a
  cond_exec perhaps.  I'm not sure how difficult this would be to
  implement and whether it would be worth it?!



This also has implications for the ABI and the prologue/epilogue
generation.  Consider a function with just a tbegin:
int foo () { return __builtin_tbegin (); }

foo needs to save and restore *all* the call-saved FPRs since the
transaction body continuing in the caller of foo might modify a
call-saved FPR and trigger an abort.  If foo would not save and
restore the FPRs it could end up clobbering call-saved FPRs violating
the ABI.

(Note: Be aware that since transactions roll back all memory
operations this also applies to stack manipulations.  So with a
function like foo above it will happen that during an abort you return
to a callee which already returned.  The stack frame of foo will be
restored by the transaction.  So compared to setjmp/longjmp jumping to
a callee is supposed to work reliably even if the stack content of the
callee has been clobbered in between.)

The additional prologue/epilogue FPR backups for TXs can only be
avoided if the transaction is fully contained in the function body
(and does not use the FPRs).  I call these non-escaping transactions.
I've implemented a check which deals with the most common situations
using the post-dominance tree.  If all the tbegin BBs are
post-dominated by a tend BB I redo the df_regs_ever_live computation
from scratch after reload removed the clobbers.  But this
unfortunately doesn't help with TX instructions being used as part of
a library like with libitm.  So I still see lots of superfluous FPR
save/restore operations in transactional code which eat up a lot of
the benefits.

Any ideas on improving the situation are welcome!

Bye,

-Andreas-

ARM/AAarch64: NEON intrinsics in the kernel

Ard Biesheuvel — 2013-05-21T09:32:13

Hello all,

I am currently exploring various ways of using NEON instructions in
kernel mode. One of the ways of doing so is using NEON intrinsics,
which we would like to support in the kernel, but unfortunately, at
the moment we can't because the support header arm_neon.h assumes C99
conformance and includes <stdint.h>. The kernel does not supply that
header.

As far as I can tell, the only dependency arm_neon.h has on the
contents of that header are the [u]int[8|16|32|64]_t typedefs. The
kernel does define those, only in a different header.

I would like to propose the following way to address this issue: as
arm_neon.h is coupled very tightly with GCC's internals
(__builtin_neon_* types and functions), could we not modify arm_neon.h
to
- drop the #include <stdint.h>
- replace every instance of [u]intxx_t with the builtin macro
__[U]INTxx_TYPE__ (as we are already dependent on specific versions of
GCC, this should not introduce any additional limitations)

In this way, it is much easier to support NEON intrinsics in
environments that we care about (like the kernel) but do not conform
to the standards.

Kind regards,
Ard.

Question on operand_equal_p on different type conversion expressions

Bin.Cheng — 2013-05-21T05:50:25

Hi,
I ran into a call of operand_equal_p for two type conversion tree nodes like:
arg0:
 <nop_expr 0xb737a974
    type <integer_type 0xb74faae0 public unsigned HI
        size <integer_cst 0xb74e87c4 constant 16>
        unit size <integer_cst 0xb74e87e0 constant 2>
        align 16 symtab 0 alias set -1 canonical type 0xb74faae0
precision 16 min <integer_cst 0xb74e8b28 0> max <integer_cst
0xb74e8a64 65535>>

    arg 0 <ssa_name 0xb73222f8
        type <integer_type 0xb74fa420 long int sizes-gimplified public SI
            size <integer_cst 0xb74e855c constant 32>
            unit size <integer_cst 0xb74e8578 constant 4>
            align 32 symtab 0 alias set 5 canonical type 0xb74fa420
precision 32 min <integer_cst 0xb74e8888 -2147483648> max <integer_cst
0xb74e88a4 2147483647> context <translation_unit_decl 0xb76a7d80
D.6120>
            pointer_to_this <pointer_type 0xb75017e0>>
        visiteddef_stmt _23 = *_22;

        version 23>>

arg1:
 <convert_expr 0xb737a3e8
    type <integer_type 0xb74fa2a0 short int sizes-gimplified public HI
        size <integer_cst 0xb74e87c4 constant 16>
        unit size <integer_cst 0xb74e87e0 constant 2>
        align 16 symtab 0 alias set 4 canonical type 0xb74fa2a0
precision 16 min <integer_cst 0xb74e8770 -32768> max <integer_cst
0xb74e878c 32767> context <translation_unit_decl 0xb76a7d80 D.6120>
        pointer_to_this <pointer_type 0xb72db600>>

    arg 0 <ssa_name 0xb73222f8
        type <integer_type 0xb74fa420 long int sizes-gimplified public SI
            size <integer_cst 0xb74e855c constant 32>
            unit size <integer_cst 0xb74e8578 constant 4>
            align 32 symtab 0 alias set 5 canonical type 0xb74fa420
precision 32 min <integer_cst 0xb74e8888 -2147483648> max <integer_cst
0xb74e88a4 2147483647> context <translation_unit_decl 0xb76a7d80
D.6120>
            pointer_to_this <pointer_type 0xb75017e0>>
        visiteddef_stmt _23 = *_22;

        version 23>>

Though arg0 is a nop_expr, the conversion is actually not NOP and it
seems arg0 equals arg1.

The problem is operand_equal_q simply return false because arg0/arg1
have different tree code.

Should operand_equal_q take two kinds of conversion expression into
consideration, or arg0/arg1 are not equal? Thanks.

--
Best Regards.

libbacktrace & plugins....

Basile Starynkevitch — 2013-05-20T14:31:15

Hello All,

Currently (for GCC 4.8 at least) when a plugin crashes (ie. SIGSEGV) libbacktrace is apparently not able 
to show backtrace information inside the plugin[s].

I believe that, at least on GNU/Linux wich has dladdr, it would be nice to extend libbacktrace 
to show backtrace information inside plugins (at least those compiled with -g).

Is is reasonably feasible? I'm not familiar with libbacktrace, but (since MELT would be very happy with that) 
I might perhaps help....

Cheers.

gcc-4.9-20130519 is now available

2013-05-19T22:39:22

Snapshot gcc-4.9-20130519 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20130519/
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/trunk revision 199087

You'll find:

 gcc-4.9-20130519.tar.bz2             Complete GCC

  MD5=b05ffe5b390fdfab7ab5066c20f00b57
  SHA1=dcebb2530fbe628f9ddc4a7bf945724c7b1f74ac

Diffs from 4.9-20130512 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.

Crashes inside libgcc_s_dw2-1.dll

Eli Zaretskii — 2013-05-19T17:30:58

[Please CC me on replies, as I'm not a subscriber.]

Would someone on the developers' team please comment on this problem:

  http://lists.gnu.org/archive/html/emacs-devel/2013-05/msg00413.html

In a nutshell, loading a GnuTLS DLL by a MinGW compiled Emacs causes
libintl DLL to be loaded, and if that libintl DLL in turns loads
libgcc_s_dw2-1.dll, the program crashes inside libgcc on exit, when
the runtime unloads all the DLLs loaded by Emacs.  A related
discussion on the MinGW mailing list

  https://sourceforge.net/mailarchive/message.php?msg_id=30633081

Suggests that this is a general problem with DLLs linked against a
shared libgcc that uses dw2 unwinding.

Is there a bug in libgcc's dw2 unwinding code?  Is it a fundamental
mistake to build DLLs that depend on libgcc as a shared library?  Or
are the applications using libgcc_s_dw2-1.dll buggy and need to get
their act together in some way (if so, how)?  Or anything else?

Thanks in advance.

gcc-4.7-20130518 is now available

2013-05-18T22:40:28

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

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

You'll find:

 gcc-4.7-20130518.tar.bz2             Complete GCC

  MD5=65f65055e2554cf2e5fe3bd638a2f450
  SHA1=4b46508f167e797a66ac1307efd619c6a7195bec

Diffs from 4.7-20130511 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.7
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.

Installing libbacktrace w/ gcc-4.8?

Ryan Johnson — 2013-05-17T20:04:26

Hi all,

(Please CC me in replies, not a list member)

I'd like to use libbacktrace in a C++ app built by gcc-4.8.0 [1], but it 
seems that the target library doesn't actually get installed, even 
though it's built.

Is there a reason user C/C++ apps shouldn't be able to incorporate 
libbacktrace, or is it just an oversight/TODO? It works beautifully if I 
copy the relevant files to where they belong in the install tree [2]; it 
also seems to work just fine when linked into apps compiled by older 
versions of gcc (though I'm not sure how safe that is). The only real 
risk I can think of is an app and a shared lib both linking in the 
static library, but that should trigger the usual linker errors for 
duplicate symbols.

[1] The ability to handle inlined funtions and shared library functions 
is especially nice, as is its robustness against corrupted stack/heap. 
It also works in spite of -fomit-frame-pointer. It's much more usable 
than unwind.h, and beats the pants off the assorted non-portable hacks 
Google turns up.

[2] backtrace.h and backtrace-supported.h went into 
$INSTALLDIR/lib/gcc/$TARGET/$VERSION/include/ (alongside unwind.h); 
libbacktrace.la and libbacktrace.a went into $INSTALLDIR/lib64/ 
(alongside libssp, libasan, et al)

Thoughts?
Ryan

GCC 4.8.1 Status Report (2013-05-17)

Jakub Jelinek — 2013-05-17T17:17:57

Status
======

The GCC 4.8.1-rc1 release candidate has been released.
The branch is frozen now, all changes require release manager approval
until the final release of GCC 4.8.1 which should happen roughly
one week after the release candidate.


Quality Data
============

Priority          #   Change from Last Report
--------        ---   -----------------------
P1                0   -  1
P2               65   -  1
P3               31   +  6
--------        ---   -----------------------
Total            96   +  4


Previous Report
===============

http://gcc.gnu.org/ml/gcc/2013-05/msg00074.html


The next report will be sent by me after the release.

GCC 4.8.1 Release Candidate available from gcc.gnu.org

Jakub Jelinek — 2013-05-17T17:11:24

GCC 4.8.1 Release Candidate available from gcc.gnu.org

The first release candidate for GCC 4.8.1 is available from

 ftp://gcc.gnu.org/pub/gcc/snapshots/4.8.1-RC-20130517

and shortly its mirrors.  It has been generated from SVN revision 199021.

I have so far bootstrapped and tested the release candidate on
x86_64-linux and i686-linux.  Please test it and report any issues to
bugzilla.

If all goes well, I'd like to release 4.8.1 late next week.

Pushing the limits on vector modes

Paulo Matos — 2013-05-17T13:25:12

Hello,

I am trying to model a predicate register mode that acts like a vector. We have a few predicate registers that have 8 bits in size but they are set accordingly to the mode of operation (not necessarily a comparison). Word size is 64.

Here's an example, for a scalar comparison leq p0, r0, 1: p0 will be set to 0xff if r0 <= but if I use simd operations the predicate register is not set as a single register.
For example, if I do tsteqw p0, r0, 0x0000 0000 0000 0001 (test equal on 32bits at a time), p0 will be 0b11110000. I could use tsteqb p0, r0, 0x0100 0100 0100 0100 (test equal on 8bits at a time), p0 will be 0b01010101.

It seems to me that the best way to represent this is by using a vector mode of BIs.
So in modes.def:
FRACTIONAL_INT_MODE (B2, 2, 1); // Two bits
FRACTIONAL_INT_MODE (B4, 4, 1); // Four bits
// use QI for 8 bits and BI for 1 bit

VECTOR_MODE (INT, BI, 8);
VECTOR_MODE (INT, B2, 4);
VECTOR_MODE (INT, B4, 2);
VECTOR_MODE (INT, QI, 1); // which probably doesn't make sense and QImode can simply be used instead.

Then I could model tsteqw as:
(define_insn "*tsteqw"
  [(set (match_operand:V2B4 0 "predicate_register" "=p")
        (eq:V2B4 (match_operand:V2SI 1 "register_operand")
                 (match_operand:V2SI 2 "general_operand")))]
  ...)

Is this something reasonable or will GCC simply choke since I am pushing the limits of vector modes?        

Paulo Matos

What is wrong with my SSA (ICE in SSA name coalescing)?

Ilya Enkovich — 2013-05-17T12:03:25

Hi,

I'm testing GIMPLE instrumentation pass and having a trouble with SSA
name coalescing. I get such error only in tests with abnormal edges.
Here is a simple test I use:

void foo ();
void goo (char *);

int test ()
{
  char *name = 0;

  foo();

  _setjmp (0);

  if (!name) {
    name = "-";
  }

  goo(name);
  goo(0);

  return 0;
}

Here is GIMPLE after my instrumentation. Instrumentation
statements/expressions are marked with +++

test ()
{
+++<unnamed type> __tmp.0;+++
  char * name;
  int D.1761;
  int _5;

  <bb 10>:
+++__tmp.0_9 = __length_1;+++
+++__tmp.0_8(ab) = __zero_length;+++

  <bb 2>:
  name_3(ab) = 0B;
  foo ();

  <bb 3>:
  # name_1(ab) = PHI <name_3(ab)(2), name_1(ab)(3), name_2(ab)(6),
name_2(ab)(7)>
+++# __tmp.0_7(ab) = PHI <__tmp.0_8(ab)(2), __tmp.0_7(ab)(3),
__tmp.0_6(ab)(6), __tmp.0_6(ab)(7)>+++
  _setjmp (0);

  <bb 4>:
  if (name_1(ab) == 0B)
    goto <bb 5>;
  else
    goto <bb 6>;

  <bb 5>:
  name_4 = "-";

  <bb 6>:
  # name_2(ab) = PHI <name_1(ab)(4), name_4(5)>
+++# __tmp.0_6(ab) = PHI <__tmp.0_7(ab)(4), __tmp.0_9(5)>+++
  goo (name_2(ab), +++__tmp.0_6(ab)+++);

  <bb 7>:
  goo (0B, +++__tmp.0_8(ab)+++);

  <bb 8>:
  _5 = 0;

<L2>:
  return _5;

}

SSA name coalescing for this code later causes following error:

Unable to coalesce ssa_names 7 and 8 which are marked as MUST COALESCE.
__tmp.0_7(ab) and  __tmp.0_8(ab)
coalesce_test.c: In function 'test':
coalesce_test.c:5:1: internal compiler error: SSA corruption
 test ()
 ^
0xb5dc65 fail_abnormal_edge_coalesce
        ../../gcc-pl/gcc/tree-ssa-coalesce.c:934
0xb5f0ed coalesce_partitions
        ../../gcc-pl/gcc/tree-ssa-coalesce.c:1236
0xb5f837 coalesce_ssa_name()
        ../../gcc-pl/gcc/tree-ssa-coalesce.c:1373
0xafaca4 remove_ssa_form
        ../../gcc-pl/gcc/tree-outof-ssa.c:900
0xafb602 rewrite_out_of_ssa(ssaexpand*)
        ../../gcc-pl/gcc/tree-outof-ssa.c:1133
0x66cac9 gimple_expand_cfg
        ../../gcc-pl/gcc/cfgexpand.c:4480

What is actually wrong with my instrumentation? As I could understand
from debugging, coalescing succeeded for name_1 and name_3, but failed
for __tmp.0_7 and __tmp.0_8 because __tmp.0_8 has long lifetime (used
in BB 7). If I remove second goo call from the test, then error goes
away. Is it actually incorrect to have SSA names with such
intersecting lifetimes? BTW if I use another var than __tmp.0 for 8th
SSA name creation, then test passes.

Compiler modification is based on gcc (GCC) 4.9.0 20130422 (experimental).

Thanks,
Ilya

gcc-4.8-20130516 is now available

2013-05-16T22:36:50

Snapshot gcc-4.8-20130516 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130516/
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 198991

You'll find:

 gcc-4.8-20130516.tar.bz2             Complete GCC

  MD5=4fe897021f123c7d6b6038388800b804
  SHA1=8e2300a4b470638b1481168a10eb4a410c57f59c

Diffs from 4.8-20130509 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.