gmane.comp.gcc.devel

Re: Crashes inside libgcc_s_dw2-1.dll

Eli Zaretskii — 2013-05-20T03:43:29

I believe that's because the versions of the library which I could
find don't have enough debug information.  Does someone know where can
I find a library with debug info?  Failing that, would a disassembly
near the address where it crashes be useful?

Anyway, what we see is not a crash, but a call to 'abort' from Windows
runtime.  The immediate suspect for that is the line near the end of
__deregister_frame_info_bases where there's a call to gcc_assert.
Does that make sense?

Thanks.

Re: Crashes inside libgcc_s_dw2-1.dll

Ian Lance Taylor — 2013-05-20T00:48:06

It is not a fundamental bug to depend on libgcc as a shared library.
The libgcc code is trying to do the right thing when the library is
unloaded.  I don't see any obvious bug in the code.  Evidently
something is going wrong, but the e-mail messages you linked to don't
provide enough information to know what it is.  In particular they
don't show where in __deregister_frame_info_bases the crash is
occurring.

Ian

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.

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 
Goog

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 sen

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.