gmane.comp.gcc.devel

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.

Re: pure/const function attribute and memoization

Florian Weimer — 2013-05-18T20:22:41

<http://sourceware.org/ml/libc-alpha/2013-05/msg00389.html>

The function is in glibc's math/atest-exp2.c file.


Uhm, okay.


Oh.


Well, with a bit of cheating, that's actually easy:

int f1(void) __attribute__((const));
void f2(int);
void lock(void);
void unlock(void);

void
g()
{
   for (int i = 0; i < 10; ++i) {
     lock();
     f2(f1());
     unlock();
   }
}

As expected, the loop turns into:

.L2:
calllock
movl%ebp, %edi
callf2
callunlock
subl$1, %ebx
jne.L2

If g() is called from multiple threads, this is no longer thread-safe 
unless f1() performs its own locking.

I think we should warn about memoization and thread safety issues. 
Trying to come up with more general semantics for const/pure appears to 
be difficult to impossible, and as you say, does not match what the 
compiler does today.

Re: pure/const function attribute and memoization

Jan Hubicka — 2013-05-18T20:02:43

It is bit crazy idea though :)  Do you have reference to the corresponding thread?
I wonder what would be motivations for this.

BTW we deduce all loops to be finite within const/pure functions that is also
bit crazy effect of the attribute.

The memoization you mention is IMO not really safe even with current GCC.  With
bit of trickery one can convince GCC to early inline the memoizing const
function in some cases and not in others. Optimizers will then expect your
memoizing cache to not change across the non-inlined calls that may lead to
wrong code.

At the moment I can not think of anything that would break if you had pure/const
function modifying global memory and restoring it before returning.

Honza

Re: Installing libbacktrace w/ gcc-4.8?

Ian Lance Taylor — 2013-05-18T00:46:13

On Fri, May 17, 2013 at 5:36 PM, Ryan Johnson
<ryan.johnson< at >cs.utoronto.ca> wrote:

Yes, pretty much.  The build uses a couple of header files in the GCC
distribution, but not in any essential way.  In fact there is a patch
I need to review to make even that aspect of it simpler.

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

Ian

Re: Installing libbacktrace w/ gcc-4.8?

Ryan Johnson — 2013-05-18T00:36:09

Ah... I had gotten the impression that it was special sauce, part of gcc 
(like unwind.h is). Can it be built and installed stand-alone, then?

Regards,
Ryan

Re: Installing libbacktrace w/ gcc-4.8?

Ian Lance Taylor — 2013-05-17T22:18:45

On Fri, May 17, 2013 at 1:04 PM, Ryan Johnson
<ryan.johnson< at >cs.utoronto.ca> wrote:

It is neither an oversight nor a TODO.  It seems to me that
libbacktrace is not really part of GCC, so installing GCC should not
necessarily install libbacktrace.  Also, of course, libbacktrace
doesn't yet work on many important environments, including Mac OS and
Windows.  I think it's great if people find it useful.  I'd be fine
with a configure option to install libbacktrace if it defaults to not
installing it.


I'm glad you like it.

Ian

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.

RE: Pushing the limits on vector modes

Paulo Matos — 2013-05-17T14:37:48

Found, what it seems to be the most recent arc branch, arc-4_4-20090909-branch/.
http://gcc.gnu.org/viewvc/gcc/branches/arc-4_4-20090909-branch/

Paulo Matos

RE: Pushing the limits on vector modes

Paulo Matos — 2013-05-17T14:29:06

amylaar,

Do you recall how I can get those ARC branches, where they branches in official GCC SVN?

Paulo Matos

Re: Pushing the limits on vector modes

2013-05-17T14:12:12

Quoting Paulo Matos <pmatos< at >broadcom.com>:


Yes need some surgery to the mode generator machinery.  I had the same
problem with the mxp port, which you can still find in older ARC
branches.

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

Ilya Enkovich — 2013-05-17T13:44:15

2013/5/17 Jakub Jelinek <jakub< at >redhat.com>:

Actually when I create this SSA_NAME I do not know all its usages (and
therefore do not know if it is abnormal). The only reason to use
underlying var for SSA names was opportunity to easily find them in
GIMPLE dump by name. I still do not fully understand what restrictions
are implied by abnormal edges. Will it be OK to use anon SSA_NAMES
here for all new values?

Ilya

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

Re: Inquiry about GCC Summer Of Code project idea.

Ian Lance Taylor — 2013-05-17T13:07:21

On Thu, May 16, 2013 at 2:19 PM, Fotis Koutoulakis
<fotis.koutoulakis< at >gmail.com> wrote:

Make sure you can build and modify gccgo for some other target, e.g., GNU/Linux.

I don't even remember if the Hurd uses ELF.  If it does not, you will
need to figure out how to handle export information.  Currently it is
placed in a section of an ELF file.

Ian

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

Jakub Jelinek — 2013-05-17T12:36:03

I think this is wrong, you are using the same underlying
var __tmp.0 for two values concurrently when at least one of them
is (ab).  If _9 is not (ab), why don't you use just _9 (anon SSA_NAME),
or a different underlying decl for that?

Jakub

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

Richard Biener — 2013-05-17T12:28:08

You cannot have SSA names live across abnormal edges because there is
no way to insert compensation code on them.

Richard.

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

Re: Inquiry about GCC Summer Of Code project idea.

Thomas Schwinge — 2013-05-17T08:30:44

Hi!

One suggestion up-front: I think the GCC mailing lists (or generally all
hosted on sourceware.org/gcc.gnu.org) are configured to drop HTML email,
so you may want to adjust your MUA.


On Fri, 17 May 2013 00:19:17 +0300, Fotis Koutoulakis <fotis.koutoulakis< at >gmail.com> wrote:

We'll see, I guess.  It definitely is low-level stuff in glibc's early
startup/early TLS initialization.



Please don't be shy to ask early if there are any problems.  Often, it's
easy for us to give then one hint you need instead of funbling around in
the dark for a long time.

Do you have a machine suitable to run GNU/Hurd, and powerful enough for
building GCC?



Thanks, that's appreaciated -- and don't worry: there'll be enough things
you can work on.  :-)



I'd really like you to have a suitable GCC development environment set
up; rather sooner than later.


Grüße,
 Thomas

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.

Re: prepare_decl_rtl in tree-ssa-loop-ivopts.c doesn't work with (ADDR_EXPR (ARRAY_REF))?

Richard Biener — 2013-05-16T12:11:31

Yes, computing &array[0][offset] may be more expensive than computing
&array[0][0].

Richard.