Re: CPATH, LIBRARY_PATH, and cross-compilers
On Tue, Feb 12, 2013 at 9:41 PM, Ludovic Courtès l...@gnu.org wrote: Joel Sherrill joel.sherr...@oarcorp.com skribis: But it still doesn't address the situation where you have multiple cross compilers in your PATH all for different targets. Yeah, I thought about it, but couldn’t come up with a practical use case where you’d need to use different cross-compilers in a single build. When you create fat binaries. Richard. Ludo’.
Re: CPATH, LIBRARY_PATH, and cross-compilers
On Wed, Feb 13, 2013 at 12:13 PM, Richard Biener richard.guent...@gmail.com wrote: On Tue, Feb 12, 2013 at 9:41 PM, Ludovic Courtès l...@gnu.org wrote: Joel Sherrill joel.sherr...@oarcorp.com skribis: But it still doesn't address the situation where you have multiple cross compilers in your PATH all for different targets. Yeah, I thought about it, but couldn’t come up with a practical use case where you’d need to use different cross-compilers in a single build. When you create fat binaries. That is, a more pragmatic approach would be to not honor these environments in a cross compiler at all. Richard. Richard. Ludo’.
Re: expansion of vector shifts...
On Tue, Feb 12, 2013 at 11:31 PM, David Miller da...@davemloft.net wrote:
From: David Miller da...@redhat.com
Date: Fri, 16 Nov 2012 00:33:05 -0500 (EST)
From: Richard Sandiford rdsandif...@googlemail.com
Date: Mon, 29 Oct 2012 10:14:53 +
...given that the code is like you say written:
if (SHIFT_COUNT_TRUNCATED)
{
if (CONST_INT_P (op1)
...
else if (GET_CODE (op1) == SUBREG
subreg_lowpart_p (op1)
INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1
op1 = SUBREG_REG (op1);
}
INTEGRAL_MODE_P (GET_MODE (op1)) might be better than an explicit
VECTOR_MODE_P check. The code really doesn't make sense for anything
other than integers.
(It amounts to the same thing in practice, of course...)
Agreed, I've just committed the following. Thanks!
Fix gcc.c-torture/compile/pr53410-2.c on sparc.
* expmed.c (expand_shift_1): Don't strip non-integral SUBREGs.
This is broken on sparc again, although I'm confused about how this
has happened.
The suggestion was to use INTEGRAL_MODE_P as the test, so what's there
in expand_shift_1() is:
else if (GET_CODE (op1) == SUBREG
subreg_lowpart_p (op1)
INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1)))
INTEGRAL_MODE_P (GET_MODE (op1)))
op1 = SUBREG_REG (op1);
but INTEGRAL_MODE_P accepts vectors. This is really confusing because
I was absolutely sure I re-ran the test case with the fix I committed
and it didn't crash any more.
Maybe what we really mean to do here is check both op1 and SUBREG_REG
(op1) against SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P?
Yes.
Something like this:
gcc/
2013-02-12 David S. Miller da...@davemloft.net
* expmed.c (expand_shift_1): Only strip scalar integer subregs.
diff --git a/gcc/expmed.c b/gcc/expmed.c
index 4a6ddb0..954a360 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -2116,8 +2116,8 @@ expand_shift_1 (enum tree_code code, enum machine_mode
mode, rtx shifted,
% GET_MODE_BITSIZE (mode));
else if (GET_CODE (op1) == SUBREG
subreg_lowpart_p (op1)
- INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1)))
- INTEGRAL_MODE_P (GET_MODE (op1)))
+ SCALAR_INT_MODE_P (GET_MODE (SUBREG_REG (op1)))
+ SCALAR_INT_MODE_P (GET_MODE (op1)))
op1 = SUBREG_REG (op1);
}
Use of templates in c code?
I've been studying/reading gccs code, watching it compile though a debugger and reading. Today I noticed something odd in the c++ parser's file. I saw what appeared to be a template in a .c file. I am on a different computer now but it was vec and occurred about 1/6th of the way in, it should be easy to find. Is that allowed? Is my main question. I would support a c with templates it'd save macro usage, that could only be good! Or is there some construct of c I do not know of. Searching for c templates proved fruitless I got loads of c++ results Alec
Re: Use of templates in c code?
On Wed, Feb 13, 2013 at 1:31 PM, Alec Teal a.t...@warwick.ac.uk wrote: I've been studying/reading gccs code, watching it compile though a debugger and reading. Today I noticed something odd in the c++ parser's file. I saw what appeared to be a template in a .c file. It's just a filename ... we compile it with a C++ compiler. Richard. I am on a different computer now but it was vec and occurred about 1/6th of the way in, it should be easy to find. Is that allowed? Is my main question. I would support a c with templates it'd save macro usage, that could only be good! Or is there some construct of c I do not know of. Searching for c templates proved fruitless I got loads of c++ results Alec
Re: Use of templates in c code?
On 13/02/13 12:39, Richard Biener wrote: On Wed, Feb 13, 2013 at 1:31 PM, Alec Teal a.t...@warwick.ac.uk wrote: It's just a filename ... we compile it with a C++ compiler. Richard. I feel silly now, why not use .cpp? SVN's move not good enough? (or is it just because no one could be bothered?) Alec I am sorry if I am searching for a higher reason where there isn't one to be found.
Re: Use of templates in c code?
On Wed, Feb 13, 2013 at 8:31 AM, Alec Teal a.t...@warwick.ac.uk wrote: On 13/02/13 12:39, Richard Biener wrote: On Wed, Feb 13, 2013 at 1:31 PM, Alec Teal a.t...@warwick.ac.uk wrote: It's just a filename ... we compile it with a C++ compiler. Richard. I feel silly now, why not use .cpp? SVN's move not good enough? (or is it just because no one could be bothered?) The latter. Perhaps we should start renaming the files. It will help with this confusion and it will also be useful for tools like editors and such. Richi, should we wait for stage 1 to re-open to do a round of mass renames? Diego.
[ANN] ODB C++ ORM 2.2.0 released
Hi, I am pleased to announce the release of ODB 2.2.0. ODB is an open source object-relational mapping (ORM) system for C++. It allows you to persist C++ objects to a relational database without having to deal with tables, columns, or SQL and without manually writing any of the mapping code. ODB is implemented as a GCC plugin and reuses the GCC compiler frontend for C++ parsing. ODB supports all releases of GCC with plugin support (4.5-4.7) as well as 4.8 snapshots. With a few small modifications we've also managed to link the plugin statically on Windows, so ODB also works on Windows. Major new features in this release: * Ability to use multiple database systems (for example, MySQL, SQLite, etc.) from the same application. It comes in the 'static' and 'dynamic' flavors with the latter allowing the application to dynamically load the database support code for individual database systems if and when necessary. * Support for prepared queries which are a thin wrapper around the underlying database system's prepared statements functionality. Prepared queries provide a way to perform potentially expensive query preparation tasks only once and then execute the query multiple times. * Support for change-tracking containers which minimize the number of database operations necessary to synchronize the container state with the database. This release comes with change-tracking equivalents for std::vector and QList. * Support for custom sessions. This mechanism can be used to provide additional functionality, such as automatic change tracking, delayed database operations, auto change flushing, or object eviction. * Support for automatically-derived SQL name transformations. You can now add prefixes/suffixes to table, column, index, and sequence names, convert them to upper/lower case, or do custom regex transformations. * Automatic mapping of char[N] to database VARCHAR(N-1) (or similar). This release also adds support for Qt5 in addition to Qt4 and comes with a guide on using ODB with mobile and embedded systems (Raspberry Pi is used as a sample ARM target). A more detailed discussion of these features can be found in the following blog post: http://www.codesynthesis.com/~boris/blog/2013/02/13/odb-2-2-0-released/ For the complete list of new features in this version see the official release announcement: http://www.codesynthesis.com/pipermail/odb-announcements/2013/25.html ODB is written in portable C++ and you should be able to use it with any modern C++ compiler. In particular, we have tested this release on GNU/Linux (x86/x86-64/ARM), Windows (x86/x86-64), Mac OS X (x86), and Solaris (x86/x86-64/SPARC) with GNU g++ 4.2.x-4.8.x, MS Visual C++ 2008, 2010, and 2012, Sun Studio 12u2, and Clang 3.2. The currently supported database systems are MySQL, SQLite, PostgreSQL, Oracle, and SQL Server. ODB also provides profiles for Boost and Qt, which allow you to seamlessly use value types, containers, and smart pointers from these libraries in your persistent classes. More information, documentation, source code, and pre-compiled binaries are available from: http://www.codesynthesis.com/products/odb/ Enjoy, Boris
Re: CPATH, LIBRARY_PATH, and cross-compilers
Richard Biener richard.guent...@gmail.com skribis: On Wed, Feb 13, 2013 at 12:13 PM, Richard Biener richard.guent...@gmail.com wrote: On Tue, Feb 12, 2013 at 9:41 PM, Ludovic Courtès l...@gnu.org wrote: Joel Sherrill joel.sherr...@oarcorp.com skribis: But it still doesn't address the situation where you have multiple cross compilers in your PATH all for different targets. Yeah, I thought about it, but couldn’t come up with a practical use case where you’d need to use different cross-compilers in a single build. When you create fat binaries. That is, a more pragmatic approach would be to not honor these environments in a cross compiler at all. Possibly, though that’d be an incompatible change. At any rate, there’s a need for similar env. vars for cross-compilers. WDYT? Ludo’.
Re: Use of templates in c code?
On Wed, Feb 13, 2013 at 5:47 AM, Diego Novillo dnovi...@google.com wrote: On Wed, Feb 13, 2013 at 8:31 AM, Alec Teal a.t...@warwick.ac.uk wrote: On 13/02/13 12:39, Richard Biener wrote: On Wed, Feb 13, 2013 at 1:31 PM, Alec Teal a.t...@warwick.ac.uk wrote: It's just a filename ... we compile it with a C++ compiler. Richard. I feel silly now, why not use .cpp? SVN's move not good enough? (or is it just because no one could be bothered?) The latter. Perhaps we should start renaming the files. It will help with this confusion and it will also be useful for tools like editors and such. Richi, should we wait for stage 1 to re-open to do a round of mass renames? I have no opinion on whether it is better to rename files now or later. I do think it is better to rename the files at some point. I would vote for renaming to an extension of .cc. Other options are .C, .cp, .cpp, .cxx, .c++, .CPP (from gcc/cp/lang-specs.h). Ian
Re: Use of templates in c code?
On Wed, Feb 13, 2013 at 9:59 AM, Ian Lance Taylor i...@google.com wrote: I have no opinion on whether it is better to rename files now or later. I do think it is better to rename the files at some point. I would vote for renaming to an extension of .cc. Likewise. One problem I've noticed is that renames seem to confuse svn diff. For example: $ cd gcc/cp $ svn log -r81829 cp-gimplify.c r81829 | dnovillo | 2004-05-13 22:29:32 -0400 (Thu, 13 May 2004) | 29 lines [ ...] * cp-gimplify.c: Rename from cp-simplify.c. [...] $ svn diff -c81829 cp-gimplify.c svn: Unable to find repository location for 'cp-gimplify.c' in revision 81828 Annoyingly, SVN is perfectly capable of tracking file movement in the directory structure. This may be a problem for archeology. Perhaps the best approach is to decide for an extension for new files and leave existing files with the current extensions. Diego.
Re: Use of templates in c code?
On 13/02/13 13:47, Diego Novillo wrote: I feel silly now, why not use .cpp? SVN's move not good enough? (or is it just because no one could be bothered?) The latter. Perhaps we should start renaming the files. It will help with this confusion and it will also be useful for tools like editors and such. Richi, should we wait for stage 1 to re-open to do a round of mass renames? Diego. I'm at a computer now! A few questions, what is this stage 1? (link to documentation please, or a descriptive answer). for the choice of file extension, this is really a tiny thing, but I do have a reason for .cpp http://stackoverflow.com/questions/1545080/correct-c-code-file-extension-cc-vs-cpp So I have done some research :P I wouldn't go as far as to change header-file extensions because that's clear from the context and most tools now (read: Doxygen) are quite happy with .h being a c++ header file. I like .cpp because it's what I learned, see-pee-pee seems to be a natural short-hand of see-plus-plus and see-see just brings to mind carbon-copying. I am also used to seeing extensions that make sense, .py for python, .php for php why not go with this. The last reason is a reason but it's quite a null one. Seeing .cpp files makes them feel more accessible when first meeting them, that hesitation when seeing .cc or .C (I've never seen c++ as an extension) just makes it feel either old-skool and created by people from before my time (not accessible, daunting in fact) or not nice to glance over because of that thought in the .cc part (this could be a dyslexic thing it doesn't help!), conversely any confident person would not be deterred by such silly reasons (even though I know they're silly, I still feel them) and thus to them it doesn't matter. Alec I'm also thinking of re-writing the C++ parser there are some interesting todos (using lookahead rather than try the next option) it's a topic I enjoy and something I could (probably) do, especially given a working version already. thoughts and feelings on that real quick?
Re: Use of templates in c code?
On 02/13/2013 03:06 PM, Diego Novillo wrote: One problem I've noticed is that renames seem to confuse svn diff. For example: $ cd gcc/cp $ svn log -r81829 cp-gimplify.c r81829 | dnovillo | 2004-05-13 22:29:32 -0400 (Thu, 13 May 2004) | 29 lines [ ...] * cp-gimplify.c: Rename from cp-simplify.c. [...] $ svn diff -c81829 cp-gimplify.c svn: Unable to find repository location for 'cp-gimplify.c' in revision 81828 Annoyingly, SVN is perfectly capable of tracking file movement in the directory structure. This may be a problem for archeology. Perhaps the best approach is to decide for an extension for new files and leave existing files with the current extensions. Looks like it. As someone who used to spend a large part of his life on GCC archaeology, I really hope we aren't going to do anything to make that (even more) difficult. Andrew.
Re: Use of templates in c code?
On 13 February 2013 15:33, Alec Teal wrote: A few questions, what is this stage 1? (link to documentation please, or a descriptive answer). See http://gcc.gnu.org/develop.html for the choice of file extension, this is really a tiny thing, but I do have a reason for .cpp http://stackoverflow.com/questions/1545080/correct-c-code-file-extension-cc-vs-cpp So I have done some research :P Your reason is a question closed as unconstructive, where the top answers say it doesn't matter? Why does that support .cpp? How about using .cc because the existing C++ code in GCC already uses .cc
Re: Use of templates in c code?
On 13 February 2013 15:33, Alec Teal wrote: I'm also thinking of re-writing the C++ parser there are some interesting todos (using lookahead rather than try the next option) it's a topic I enjoy and something I could (probably) do, especially given a working version already. thoughts and feelings on that real quick? Do you mean rewrite or improve? Rewriting it would be a major task, last undertaken for GCC 3.4, and not to be undertaken lightly.
Re: Use of templates in c code?
On 13/02/13 16:24, Jonathan Wakely wrote: On 13 February 2013 15:33, Alec Teal wrote: I'm also thinking of re-writing the C++ parser there are some interesting todos (using lookahead rather than try the next option) it's a topic I enjoy and something I could (probably) do, especially given a working version already. thoughts and feelings on that real quick? Do you mean rewrite or improve? Rewriting it would be a major task, last undertaken for GCC 3.4, and not to be undertaken lightly. Not yet sure, the first thing would be the planning of it, and a prototype that actually parses, probably in Python, python rules! (for quick dev stuff anyway) it depends what I'd have to change and the output from the parser to the next stage (semantic analysis). It'd be a good chance to add some hooks (or something, again it's just a thought) for static analysis to use, fix some of those things that Clang is good for (apparently). Once again, purely a thought, I'd love to at least try, what's this copyright malarkey I've been hearing about? Alec.
Re: Use of templates in c code?
On 13/02/13 16:11, Jonathan Wakely wrote: On 13 February 2013 15:33, Alec Teal wrote: A few questions, what is this stage 1? (link to documentation please, or a descriptive answer). See http://gcc.gnu.org/develop.html for the choice of file extension, this is really a tiny thing, but I do have a reason for .cpp http://stackoverflow.com/questions/1545080/correct-c-code-file-extension-cc-vs-cpp So I have done some research :P Your reason is a question closed as unconstructive, where the top answers say it doesn't matter? Why does that support .cpp? How about using .cc because the existing C++ code in GCC already uses .cc How about scrolling down? It is such a small issue there is no definitive answer, the compiler doesn't care, but there is some debate on that page.
libsanitizer and qemu compatibility
Hi, I am working on enabing libsanitizer on ARM. I have a very simple patch to enable it, and a sample program seems to work on board. However, I would like to use qemu as an execution engine, but I get error messages from libsanitizer at startup:==30022== Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING. ** shadow start 0x1000 shadow_end 0x3fff ==30022== Process memory map follows: 0x-0x8000 0x8000-0x9000/home/lyon/src/tests/sanitizer.armhf 0x9000-0x0001 0x0001-0x00011000/home/lyon/src/tests/sanitizer.armhf 0x00011000-0xf4f5 0xf4f5-0xf4f52000 0xf4f52000-0xf4f54000 0xf4f54000-0xf4f58000 0xf4f58000-0xf4f5c000 [many others follow, belonging to libgcc_s.so, libm.so, libstdc++.so, libdl,so, libpthread.so, libc.so and libasan.so, and some with no filename] So I have a probably very naive question: can libsanitizer work under qemu (linux-user mode)? What should I change? [I have already modified qemu's output of /proc/self/maps to add a space character after the last number if there is no filename, to avoid parsing errors from libsanitizer]. Thanks, Christophe.
Re: Use of templates in c code?
On 13 February 2013 16:32, Alec Teal a.t...@warwick.ac.uk wrote: On 13/02/13 16:11, Jonathan Wakely wrote: On 13 February 2013 15:33, Alec Teal wrote: A few questions, what is this stage 1? (link to documentation please, or a descriptive answer). See http://gcc.gnu.org/develop.html for the choice of file extension, this is really a tiny thing, but I do have a reason for .cpp http://stackoverflow.com/questions/1545080/correct-c-code-file-extension-cc-vs-cpp So I have done some research :P Your reason is a question closed as unconstructive, where the top answers say it doesn't matter? Why does that support .cpp? How about using .cc because the existing C++ code in GCC already uses .cc How about scrolling down? It is such a small issue there is no definitive answer, the compiler doesn't care, but there is some debate on that page. I read it. That's not debate, just ill-informed speculation (cpp is the recommended extension for C++ as far as I know). We already have C++ code in GCC, the runtime library uses .cc and the G++ testsuite uses .C, adding .cpp as a third choice based on the opinions in that page or your feeling of unease doesn't seem like a good idea to me.
Re: Use of templates in c code?
On 13/02/13 17:00, Jonathan Wakely wrote: On 13 February 2013 16:32, Alec Teal a.t...@warwick.ac.uk wrote: On 13/02/13 16:11, Jonathan Wakely wrote: On 13 February 2013 15:33, Alec Teal wrote: A few questions, what is this stage 1? (link to documentation please, or a descriptive answer). See http://gcc.gnu.org/develop.html for the choice of file extension, this is really a tiny thing, but I do have a reason for .cpp http://stackoverflow.com/questions/1545080/correct-c-code-file-extension-cc-vs-cpp So I have done some research :P Your reason is a question closed as unconstructive, where the top answers say it doesn't matter? Why does that support .cpp? How about using .cc because the existing C++ code in GCC already uses .cc How about scrolling down? It is such a small issue there is no definitive answer, the compiler doesn't care, but there is some debate on that page. I read it. That's not debate, just ill-informed speculation (cpp is the recommended extension for C++ as far as I know). We already have C++ code in GCC, the runtime library uses .cc and the G++ testsuite uses .C, adding .cpp as a third choice based on the opinions in that page or your feeling of unease doesn't seem like a good idea to me. Why not rename them to?
Re: Use of templates in c code?
Diego Novillo dnovi...@google.com writes: One problem I've noticed is that renames seem to confuse svn diff. For example: $ cd gcc/cp $ svn log -r81829 cp-gimplify.c r81829 | dnovillo | 2004-05-13 22:29:32 -0400 (Thu, 13 May 2004) | 29 lines [ ...] * cp-gimplify.c: Rename from cp-simplify.c. [...] $ svn diff -c81829 cp-gimplify.c svn: Unable to find repository location for 'cp-gimplify.c' in revision 81828 Annoyingly, SVN is perfectly capable of tracking file movement in the directory structure. Subversion does track copies however that particular change isn't a copy as far as Subversion is concerned: $ svn log -vqr881829 | grep cp- A /trunk/gcc/cp/cp-gimplify.c D /trunk/gcc/cp/cp-simplify.c The new file must have been explicitly added, rather than copied or moved, and so the history is broken. An example of a history preserving copy is: $ svn log -vqr135882 | grep path.c D /trunk/gcc/c-incpath.c A /trunk/gcc/incpath.c (from /trunk/gcc/c-incpath.c:135880) -- Philip
Re: Use of templates in c code?
On 02/13/2013 05:01 PM, Alec Teal wrote: Why not rename them to? See the archaeology discussion. This is so vitally important to GCC maintainers that you change things at everyone's peril. Andrew.
Re: Use of templates in c code?
On 13 February 2013 17:01, Alec Teal wrote: On 13/02/13 17:00, Jonathan Wakely wrote: I read it. That's not debate, just ill-informed speculation (cpp is the recommended extension for C++ as far as I know). We already have C++ code in GCC, the runtime library uses .cc and the G++ testsuite uses .C, adding .cpp as a third choice based on the opinions in that page or your feeling of unease doesn't seem like a good idea to me. Why not rename them to? Because there is reason to prefer .cpp except one person who's never contributed a line of code to GCC saying he prefers that extension. FWIW I prefer .cc and actually work with the files every day. Continuing the discussion in this vein seems entirely pointless so I'll leave this thread here.
Re: Use of templates in c code?
On 13/02/13 17:11, Jonathan Wakely wrote: On 13 February 2013 17:01, Alec Teal wrote: On 13/02/13 17:00, Jonathan Wakely wrote: I read it. That's not debate, just ill-informed speculation (cpp is the recommended extension for C++ as far as I know). We already have C++ code in GCC, the runtime library uses .cc and the G++ testsuite uses .C, adding .cpp as a third choice based on the opinions in that page or your feeling of unease doesn't seem like a good idea to me. Why not rename them to? Because there is reason to prefer .cpp except one person who's never contributed a line of code to GCC saying he prefers that extension. That's really childish. I accept I have to prove myself, but people have feelings. FWIW I prefer .cc and actually work with the files every day. Continuing the discussion in this vein seems entirely pointless so I'll leave this thread here.
Re: expansion of vector shifts...
From: Richard Biener richard.guent...@gmail.com Date: Wed, 13 Feb 2013 12:15:13 +0100 On Tue, Feb 12, 2013 at 11:31 PM, David Miller da...@davemloft.net wrote: Maybe what we really mean to do here is check both op1 and SUBREG_REG (op1) against SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P? Yes. Ok, I'll commit this after doing some regstraps, thanks. Something like this: gcc/ 2013-02-12 David S. Miller da...@davemloft.net * expmed.c (expand_shift_1): Only strip scalar integer subregs. diff --git a/gcc/expmed.c b/gcc/expmed.c index 4a6ddb0..954a360 100644 --- a/gcc/expmed.c +++ b/gcc/expmed.c @@ -2116,8 +2116,8 @@ expand_shift_1 (enum tree_code code, enum machine_mode mode, rtx shifted, % GET_MODE_BITSIZE (mode)); else if (GET_CODE (op1) == SUBREG subreg_lowpart_p (op1) - INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1))) - INTEGRAL_MODE_P (GET_MODE (op1))) + SCALAR_INT_MODE_P (GET_MODE (SUBREG_REG (op1))) + SCALAR_INT_MODE_P (GET_MODE (op1))) op1 = SUBREG_REG (op1); }
Re: Use of templates in c code?
On Wed, 13 Feb 2013, Philip Martin wrote: The new file must have been explicitly added, rather than copied or moved, and so the history is broken. An example of a history preserving The issue there is that cvs2svn doesn't / didn't at the time support detecting moves, so moves from before the conversion to SVN aren't represented as such. People have talked about wanting to move files to various new subdirectories of the gcc directory, rather than having so many files all at the same directory level. I suggest that the time of moving a file to such a new subdirectory would be an appropriate time also to rename it to use .cc, rather than having two separate moves. -- Joseph S. Myers jos...@codesourcery.com
Re: Use of templates in c code?
On Wed, Feb 13, 2013 at 5:00 PM, Joseph S. Myers jos...@codesourcery.com wrote: On Wed, 13 Feb 2013, Philip Martin wrote: The new file must have been explicitly added, rather than copied or moved, and so the history is broken. An example of a history preserving The issue there is that cvs2svn doesn't / didn't at the time support detecting moves, so moves from before the conversion to SVN aren't represented as such. Ah, so if we rename a file with 'svn rename', its history will be preserved across the rename? In that case, renaming files should not be a problem. People have talked about wanting to move files to various new subdirectories of the gcc directory, rather than having so many files all at the same directory level. I suggest that the time of moving a file to such a new subdirectory would be an appropriate time also to rename it to use .cc, rather than having two separate moves. Sounds reasonable. Diego.
Re: Use of templates in c code?
On Feb 13, 2013, at 5:04 PM, Diego Novillo wrote: ... Ah, so if we rename a file with 'svn rename', its history will be preserved across the rename? In that case, renaming files should not be a problem. Yes, that's one of many ways that SVN (or most other source control systems) are superior over CVS. paul
Re: Use of templates in c code?
On Wed, Feb 13, 2013 at 5:18 PM, paul_kon...@dell.com wrote: On Feb 13, 2013, at 5:04 PM, Diego Novillo wrote: ... Ah, so if we rename a file with 'svn rename', its history will be preserved across the rename? In that case, renaming files should not be a problem. Yes, that's one of many ways that SVN (or most other source control systems) are superior over CVS. Right. Until I tried the experiment upthread, which really irritated and confused me. I had forgotten that the rename had actually been done before the transition to SVN, that's why it wasn't showing up. Diego.
Re: Register Allocation issues with microblaze-elf
On 13-02-13 1:36 AM, Michael Eager wrote:
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and gcc-head) compared with older (gcc-4.1.2).
Both are compiled using -O3.
One test case that I have has a long series of nested if's
each with the same comparison and similar computation.
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p);
if (nmax_no){
. . . ~20 levels of nesting
more computations with 'cp' and 'p'
. . . }}}
Gcc-4.6.2 generates many blocks like the following:
lwir28,r1,68-- load into dead reg
lwir31,r1,140-- load p from stack
lbuir28,r31,0
rsubkr31,r28,r19
lbuir31,r31,0
addkr29,r29,r31
swir31,r1,308
lwir31,r1,428-- load of max_no from stack
cmpr28,r31,r29-- n in r29
bgeidr28,$L46
gcc-4.1.2 generates the following:
lbuir3,r26,3
rsubkr3,r3,r19
lbuir3,r3,0
addkr30,r30,r3
swir3,r1,80
cmpr18,r9,r30-- max_no in r9, n in r30
bgeir18,$L6
gcc-4.6.2 (and gcc-head) load max_no from the stack in each block.
There also are extra loads into r28 (which is not used) and r31 at
the start of each block. Only r28, r29, and r31 are used.
I'm having a hard time telling what is happening or why. The
IRA dump has this line:
Ignoring reg 772, has equiv memory
where pseudo 772 is loaded with max_no early in the function.
The reload dump has
Reloads for insn # 254
Reload 0: reload_in (SI) = (reg/v:SI 722 [ max_no ])
GR_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (reg/v:SI 722 [ max_no ])
reload_reg_rtx: (reg:SI 31 r31)
and similar for each of the other insns using 722.
This is followed by
Spilling for insn 254.
Using reg 31 for reload 0
for each insn using pseudo 722.
Any idea what is going on?
So many changes happened since then (7 years ago), that it is very hard
to me to say something definitely. I also have no gcc-4.1 microblaze
(as I see microblaze was added to public gcc for 4.6 version) and it
makes me even more difficult to say something useful.
First of all, the new RA was introduced in gcc4.4 (IRA) which uses
different heuristics (Chaitin-Briggs graph coloring vs Chow's priority RA).
We could blame IRA when we have the same started conditions for it RA
gcc4.1 and gcc4.6-gcc-4.8. But I am sure it is not the same. More
aggressive optimizations creates higher register pressure. I compared
peak reg pressure in the test for gcc4.6 and gcc4.8. It became higher
(from 102 to 106). I guess the increase was even bigger since gcc4.1.
RA focused on generation of faster code. Looking at the fragment you
provided it, it is hard to say something about it. I tried -Os for
gcc4.8 and it generates desirable code for the fragment in question (by
the way the peak register pressure decreased to 66 in this case).
Any industrial RA uses heuristic algorithms, in some cases better
heuristics can work worse than worse heuristics. So you should probably
check is there any progress moving from gcc4.1 to gcc4.6 with
performance point of view for variety benchmarks. Introducing IRA
improves code for x86 4% on SPEC2000. Subsequent improving (like using
dynamic register classes) made further performance improvements.
Looking at the test code, I can make some conclusions for myself:
o We need a common pass decreasing reg pressure (I already expressed
this in the past) as optimizations become more aggressive. Some
progress was made to make few optimizations aware about RA (reg-pressure
scheduling, loop-invariant motions, and code hoisting) but there are too
many passes and it is wrong and impossible to make them all aware of
RA. Some register pressure decreasing heuristics are difficult to
implement in RA (like insn rearrangements or complex rematerialization)
and this pass could focus on them.
o Implement RA live range splitting in regions different from loops or
BB (now IRA makes splitting only on loop bounds and LRA in BB, the old
RA had no live range splitting at all).
I'd also recommend to try the following options concerning RA:
-fira-loop-pressure, -fsched-pressure, -fira-algorithm=CB|priority,
-fira-region=one,all,mixed. Actually -fira-algorithm=priority +
-fira-region=one is analog of what the old RA did.
I hope I answered to your question.
Re: Register Allocation issues with microblaze-elf
On 02/13/2013 02:38 PM, Vladimir Makarov wrote:
On 13-02-13 1:36 AM, Michael Eager wrote:
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and gcc-head) compared with older (gcc-4.1.2).
Both are compiled using -O3.
One test case that I have has a long series of nested if's
each with the same comparison and similar computation.
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p);
if (nmax_no){
. . . ~20 levels of nesting
more computations with 'cp' and 'p'
. . . }}}
Gcc-4.6.2 generates many blocks like the following:
lwir28,r1,68-- load into dead reg
lwir31,r1,140-- load p from stack
lbuir28,r31,0
rsubkr31,r28,r19
lbuir31,r31,0
addkr29,r29,r31
swir31,r1,308
lwir31,r1,428-- load of max_no from stack
cmpr28,r31,r29-- n in r29
bgeidr28,$L46
gcc-4.1.2 generates the following:
lbuir3,r26,3
rsubkr3,r3,r19
lbuir3,r3,0
addkr30,r30,r3
swir3,r1,80
cmpr18,r9,r30-- max_no in r9, n in r30
bgeir18,$L6
gcc-4.6.2 (and gcc-head) load max_no from the stack in each block.
There also are extra loads into r28 (which is not used) and r31 at
the start of each block. Only r28, r29, and r31 are used.
I'm having a hard time telling what is happening or why. The
IRA dump has this line:
Ignoring reg 772, has equiv memory
where pseudo 772 is loaded with max_no early in the function.
The reload dump has
Reloads for insn # 254
Reload 0: reload_in (SI) = (reg/v:SI 722 [ max_no ])
GR_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (reg/v:SI 722 [ max_no ])
reload_reg_rtx: (reg:SI 31 r31)
and similar for each of the other insns using 722.
This is followed by
Spilling for insn 254.
Using reg 31 for reload 0
for each insn using pseudo 722.
Any idea what is going on?
So many changes happened since then (7 years ago), that it is very hard to me
to say something
definitely. I also have no gcc-4.1 microblaze (as I see microblaze was added
to public gcc for 4.6
version) and it makes me even more difficult to say something useful.
First of all, the new RA was introduced in gcc4.4 (IRA) which uses different
heuristics
(Chaitin-Briggs graph coloring vs Chow's priority RA).
We could blame IRA when we have the same started conditions for it RA gcc4.1
and gcc4.6-gcc-4.8.
But I am sure it is not the same. More aggressive optimizations creates higher
register pressure. I
compared peak reg pressure in the test for gcc4.6 and gcc4.8. It became higher
(from 102 to 106).
I guess the increase was even bigger since gcc4.1.
I thought about register pressure causing this, but I think that should cause
spilling of one of the registers which were not used in this long sequence,
rather than causing a large number of additional loads.
Perhaps the cost analysis has a problem.
RA focused on generation of faster code. Looking at the fragment you provided
it, it is hard to say
something about it. I tried -Os for gcc4.8 and it generates desirable code for
the fragment in
question (by the way the peak register pressure decreased to 66 in this case).
It's both larger and slower, since the additional loads take much longer. I'll
take a
look at -Os.
It looks like the values of p++ are being pre-calculated and stored on the
stack. This results in
a load, rather than an increment of a register.
Any industrial RA uses heuristic algorithms, in some cases better heuristics
can work worse than
worse heuristics. So you should probably check is there any progress moving
from gcc4.1 to gcc4.6
with performance point of view for variety benchmarks. Introducing IRA
improves code for x86 4% on
SPEC2000. Subsequent improving (like using dynamic register classes) made
further performance
improvements.
My impression is that the performance is worse. Reports I've seen are that the
code is
substantially larger, which means more instructions.
I'm skeptical about comparisons between x86 and RISC processors. What works
well
for one may not work well for the other.
Looking at the test code, I can make some conclusions for myself:
o We need a common pass decreasing reg pressure (I already expressed this in
the past) as
optimizations become more aggressive. Some progress was made to make few
optimizations aware about
RA (reg-pressure scheduling, loop-invariant motions, and code hoisting) but
there are too many
passes and it is wrong and impossible to make them all aware of RA. Some
register pressure
decreasing heuristics are difficult to implement in RA (like insn
rearrangements or complex
rematerialization) and this pass could focus on them.
That might be useful.
o Implement RA live range splitting in regions different from loops or BB (now
IRA makes splitting
only on loop bounds and LRA in BB, the old RA had
Re: Register Allocation issues with microblaze-elf
On 13-02-13 6:36 PM, Michael Eager wrote:
On 02/13/2013 02:38 PM, Vladimir Makarov wrote:
On 13-02-13 1:36 AM, Michael Eager wrote:
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and gcc-head) compared with older (gcc-4.1.2).
Both are compiled using -O3.
One test case that I have has a long series of nested if's
each with the same comparison and similar computation.
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p);
if (nmax_no){
. . . ~20 levels of nesting
more computations with 'cp' and 'p'
. . . }}}
Gcc-4.6.2 generates many blocks like the following:
lwir28,r1,68-- load into dead reg
lwir31,r1,140-- load p from stack
lbuir28,r31,0
rsubkr31,r28,r19
lbuir31,r31,0
addkr29,r29,r31
swir31,r1,308
lwir31,r1,428-- load of max_no from stack
cmpr28,r31,r29-- n in r29
bgeidr28,$L46
gcc-4.1.2 generates the following:
lbuir3,r26,3
rsubkr3,r3,r19
lbuir3,r3,0
addkr30,r30,r3
swir3,r1,80
cmpr18,r9,r30-- max_no in r9, n in r30
bgeir18,$L6
gcc-4.6.2 (and gcc-head) load max_no from the stack in each block.
There also are extra loads into r28 (which is not used) and r31 at
the start of each block. Only r28, r29, and r31 are used.
I'm having a hard time telling what is happening or why. The
IRA dump has this line:
Ignoring reg 772, has equiv memory
where pseudo 772 is loaded with max_no early in the function.
The reload dump has
Reloads for insn # 254
Reload 0: reload_in (SI) = (reg/v:SI 722 [ max_no ])
GR_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (reg/v:SI 722 [ max_no ])
reload_reg_rtx: (reg:SI 31 r31)
and similar for each of the other insns using 722.
This is followed by
Spilling for insn 254.
Using reg 31 for reload 0
for each insn using pseudo 722.
Any idea what is going on?
So many changes happened since then (7 years ago), that it is very
hard to me to say something
definitely. I also have no gcc-4.1 microblaze (as I see microblaze
was added to public gcc for 4.6
version) and it makes me even more difficult to say something useful.
First of all, the new RA was introduced in gcc4.4 (IRA) which uses
different heuristics
(Chaitin-Briggs graph coloring vs Chow's priority RA).
We could blame IRA when we have the same started conditions for it RA
gcc4.1 and gcc4.6-gcc-4.8.
But I am sure it is not the same. More aggressive optimizations
creates higher register pressure. I
compared peak reg pressure in the test for gcc4.6 and gcc4.8. It
became higher (from 102 to 106).
I guess the increase was even bigger since gcc4.1.
I thought about register pressure causing this, but I think that
should cause
spilling of one of the registers which were not used in this long
sequence,
rather than causing a large number of additional loads.
Longer living pseudos has more probability to be spilled as they usually
conflicts with more pseudos during their lives and spilling them frees a
hard reg for many conflicting pseudos. That how RA heuristics work (in
the old RA log (live range span) was used. The bigger the value, the
more probability for spilling).
Perhaps the cost analysis has a problem.
I've checked it and it looks ok to me.
RA focused on generation of faster code. Looking at the fragment you
provided it, it is hard to say
something about it. I tried -Os for gcc4.8 and it generates
desirable code for the fragment in
question (by the way the peak register pressure decreased to 66 in
this case).
It's both larger and slower, since the additional loads take much
longer. I'll take a
look at -Os.
It looks like the values of p++ are being pre-calculated and stored on
the stack. This results in
a load, rather than an increment of a register.
If it is so. It might be another optimization which moves p++
calculations higher. IRA does not do it (more correctly a new IRA
feature implemented by Bernd Schmidt in gcc4.7 can move insns downwards
in CFG graph to decrease reg pressure).
I checked all rtl passes these calcualtions are not created by any RTL
pass. So it is probably some tree-ssa optimization.
Any industrial RA uses heuristic algorithms, in some cases better
heuristics can work worse than
worse heuristics. So you should probably check is there any progress
moving from gcc4.1 to gcc4.6
with performance point of view for variety benchmarks. Introducing
IRA improves code for x86 4% on
SPEC2000. Subsequent improving (like using dynamic register classes)
made further performance
improvements.
My impression is that the performance is worse. Reports I've seen are
that the code is
substantially larger, which means more instructions.
I'm skeptical about comparisons between x86 and RISC processors. What
works well
for one may not work well for
Re: libsanitizer and qemu compatibility
Hi Christophe, Are you talking about ARM Linux? It will be easier for us (asan developers) to fix this upstream first. Could you please file a bug at https://code.google.com/p/address-sanitizer/ ? On Wed, Feb 13, 2013 at 8:42 PM, Christophe Lyon christophe.l...@linaro.org wrote: Hi, I am working on enabing libsanitizer on ARM. I have a very simple patch to enable it, and a sample program seems to work on board. However, I would like to use qemu as an execution engine, but I get error messages from libsanitizer at startup:==30022== Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING. ** shadow start 0x1000 shadow_end 0x3fff ==30022== Process memory map follows: 0x-0x8000 0x8000-0x9000/home/lyon/src/tests/sanitizer.armhf 0x9000-0x0001 0x0001-0x00011000/home/lyon/src/tests/sanitizer.armhf 0x00011000-0xf4f5where is this crazy mapping come from? --kcc 0xf4f5-0xf4f52000 0xf4f52000-0xf4f54000 0xf4f54000-0xf4f58000 0xf4f58000-0xf4f5c000 [many others follow, belonging to libgcc_s.so, libm.so, libstdc++.so, libdl,so, libpthread.so, libc.so and libasan.so, and some with no filename] So I have a probably very naive question: can libsanitizer work under qemu (linux-user mode)? What should I change? [I have already modified qemu's output of /proc/self/maps to add a space character after the last number if there is no filename, to avoid parsing errors from libsanitizer]. Thanks, Christophe.
Re: Register Allocation issues with microblaze-elf
On Thu, Feb 14, 2013 at 12:36:46AM +0100, Michael Eager wrote:
On 02/13/2013 02:38 PM, Vladimir Makarov wrote:
On 13-02-13 1:36 AM, Michael Eager wrote:
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and gcc-head) compared with older (gcc-4.1.2).
Both are compiled using -O3.
One test case that I have has a long series of nested if's
each with the same comparison and similar computation.
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p);
if (nmax_no){
. . . ~20 levels of nesting
more computations with 'cp' and 'p'
. . . }}}
Gcc-4.6.2 generates many blocks like the following:
lwir28,r1,68-- load into dead reg
lwir31,r1,140-- load p from stack
lbuir28,r31,0
rsubkr31,r28,r19
lbuir31,r31,0
addkr29,r29,r31
swir31,r1,308
lwir31,r1,428-- load of max_no from stack
cmpr28,r31,r29-- n in r29
bgeidr28,$L46
gcc-4.1.2 generates the following:
lbuir3,r26,3
rsubkr3,r3,r19
lbuir3,r3,0
addkr30,r30,r3
swir3,r1,80
cmpr18,r9,r30-- max_no in r9, n in r30
bgeir18,$L6
gcc-4.6.2 (and gcc-head) load max_no from the stack in each block.
There also are extra loads into r28 (which is not used) and r31 at
the start of each block. Only r28, r29, and r31 are used.
I'm having a hard time telling what is happening or why. The
IRA dump has this line:
Ignoring reg 772, has equiv memory
where pseudo 772 is loaded with max_no early in the function.
The reload dump has
Reloads for insn # 254
Reload 0: reload_in (SI) = (reg/v:SI 722 [ max_no ])
GR_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (reg/v:SI 722 [ max_no ])
reload_reg_rtx: (reg:SI 31 r31)
and similar for each of the other insns using 722.
This is followed by
Spilling for insn 254.
Using reg 31 for reload 0
for each insn using pseudo 722.
Any idea what is going on?
So many changes happened since then (7 years ago), that it is very hard to
me to say something
definitely. I also have no gcc-4.1 microblaze (as I see microblaze was
added to public gcc for 4.6
version) and it makes me even more difficult to say something useful.
First of all, the new RA was introduced in gcc4.4 (IRA) which uses
different heuristics
(Chaitin-Briggs graph coloring vs Chow's priority RA).
We could blame IRA when we have the same started conditions for it RA
gcc4.1 and gcc4.6-gcc-4.8.
But I am sure it is not the same. More aggressive optimizations creates
higher register pressure. I
compared peak reg pressure in the test for gcc4.6 and gcc4.8. It became
higher (from 102 to 106).
I guess the increase was even bigger since gcc4.1.
I thought about register pressure causing this, but I think that should cause
spilling of one of the registers which were not used in this long sequence,
rather than causing a large number of additional loads.
Perhaps the cost analysis has a problem.
RA focused on generation of faster code. Looking at the fragment you
provided it, it is hard to say
something about it. I tried -Os for gcc4.8 and it generates desirable code
for the fragment in
question (by the way the peak register pressure decreased to 66 in this
case).
It's both larger and slower, since the additional loads take much longer.
I'll take a
look at -Os.
It looks like the values of p++ are being pre-calculated and stored on the
stack. This results in
a load, rather than an increment of a register.
Hi,
I remember having a similar issue about a year ago. IIRC, I foudn that
the ivopts pass was transforming things badly for microblaze. Disabling
it helped alot.
I can't tell if you are seeing the same thing, but it might be worth
trying -fno-ivopts in case you haven't already.
Cheers,
Edgar
Re: Register Allocation issues with microblaze-elf
On 02/13/2013 11:24 PM, Edgar E. Iglesias wrote:
On Thu, Feb 14, 2013 at 12:36:46AM +0100, Michael Eager wrote:
On 02/13/2013 02:38 PM, Vladimir Makarov wrote:
On 13-02-13 1:36 AM, Michael Eager wrote:
Hi --
I'm seeing register allocation problems and code size increases
with gcc-4.6.2 (and gcc-head) compared with older (gcc-4.1.2).
Both are compiled using -O3.
One test case that I have has a long series of nested if's
each with the same comparison and similar computation.
if (nmax_no){
n+=*(cp-*p++);
if (nmax_no){
n+=*(cp-*p);
if (nmax_no){
. . . ~20 levels of nesting
more computations with 'cp' and 'p'
. . . }}}
Gcc-4.6.2 generates many blocks like the following:
lwir28,r1,68-- load into dead reg
lwir31,r1,140-- load p from stack
lbuir28,r31,0
rsubkr31,r28,r19
lbuir31,r31,0
addkr29,r29,r31
swir31,r1,308
lwir31,r1,428-- load of max_no from stack
cmpr28,r31,r29-- n in r29
bgeidr28,$L46
gcc-4.1.2 generates the following:
lbuir3,r26,3
rsubkr3,r3,r19
lbuir3,r3,0
addkr30,r30,r3
swir3,r1,80
cmpr18,r9,r30-- max_no in r9, n in r30
bgeir18,$L6
gcc-4.6.2 (and gcc-head) load max_no from the stack in each block.
There also are extra loads into r28 (which is not used) and r31 at
the start of each block. Only r28, r29, and r31 are used.
I'm having a hard time telling what is happening or why. The
IRA dump has this line:
Ignoring reg 772, has equiv memory
where pseudo 772 is loaded with max_no early in the function.
The reload dump has
Reloads for insn # 254
Reload 0: reload_in (SI) = (reg/v:SI 722 [ max_no ])
GR_REGS, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (reg/v:SI 722 [ max_no ])
reload_reg_rtx: (reg:SI 31 r31)
and similar for each of the other insns using 722.
This is followed by
Spilling for insn 254.
Using reg 31 for reload 0
for each insn using pseudo 722.
Any idea what is going on?
So many changes happened since then (7 years ago), that it is very hard to me
to say something
definitely. I also have no gcc-4.1 microblaze (as I see microblaze was added
to public gcc for 4.6
version) and it makes me even more difficult to say something useful.
First of all, the new RA was introduced in gcc4.4 (IRA) which uses different
heuristics
(Chaitin-Briggs graph coloring vs Chow's priority RA).
We could blame IRA when we have the same started conditions for it RA gcc4.1
and gcc4.6-gcc-4.8.
But I am sure it is not the same. More aggressive optimizations creates higher
register pressure. I
compared peak reg pressure in the test for gcc4.6 and gcc4.8. It became higher
(from 102 to 106).
I guess the increase was even bigger since gcc4.1.
I thought about register pressure causing this, but I think that should cause
spilling of one of the registers which were not used in this long sequence,
rather than causing a large number of additional loads.
Perhaps the cost analysis has a problem.
RA focused on generation of faster code. Looking at the fragment you provided
it, it is hard to say
something about it. I tried -Os for gcc4.8 and it generates desirable code for
the fragment in
question (by the way the peak register pressure decreased to 66 in this case).
It's both larger and slower, since the additional loads take much longer. I'll
take a
look at -Os.
It looks like the values of p++ are being pre-calculated and stored on the
stack. This results in
a load, rather than an increment of a register.
Hi,
I remember having a similar issue about a year ago. IIRC, I foudn that
the ivopts pass was transforming things badly for microblaze. Disabling
it helped alot.
I can't tell if you are seeing the same thing, but it might be worth
trying -fno-ivopts in case you haven't already.
Thanks. I'll see if that helps.
--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 --- Comment #11 from rguenther at suse dot de rguenther at suse dot de 2013-02-13 09:05:16 UTC --- On Tue, 12 Feb 2013, meissner at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 --- Comment #10 from Michael Meissner meissner at gcc dot gnu.org 2013-02-12 19:16:56 UTC --- If -fno-merge-constants (and the default -fsection-anchors) is used, then the correct alignment for the table is set (and Altivec memory instructions are used). At a guess, it is likely be in the gimplify_init_constructor function in gimplify.c. There is special code to handle initializers, it may be well that with LTO we fail to do the correct thing here.
[Bug tree-optimization/55334] [4.8 Regression] mgrid regression (ipa-cp disables vectorization)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55334 --- Comment #25 from Richard Biener rguenth at gcc dot gnu.org 2013-02-13 09:09:09 UTC --- (In reply to comment #24) Created attachment 29429 [details] Experimental patch resolving more dependencies This is my (untested, highly experimental) patch to resolve such dependencies. Basically, it 1) treats MEM_REFs as sort-of COMPONENT_REFs on top INDIRECT_REFs and always pushes the offset index to access_fns of a data reference structure, and 2) relaxes the rule that DR_BASE_OBJECTs need to be the same thing for MEM_REFs of DECLs, where we are happy if the DECLs are the same now. That won't work (read: it will cause miscompiles). I believe with the most recent data-dependence reorg I added a bunch of testcases that show how to create breaking testcases ;)
[Bug c++/56302] New: [4.8 Regression] sys/sdt.h asms stopped working at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56302
Bug #: 56302
Summary: [4.8 Regression] sys/sdt.h asms stopped working at -O0
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: ja...@gcc.gnu.org
ReportedBy: ja...@gcc.gnu.org
void
foo (const int x)
{
__asm__ __volatile__ ( : : n (-1 * (int) sizeof (x)));
}
compiled just fine even at -O0 in 4.7, but starting with
http://gcc.gnu.org/viewcvs?root=gccview=revrev=192141
is no longer accepted at -O0.
[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181 --- Comment #16 from Richard Biener rguenth at gcc dot gnu.org 2013-02-13 09:28:36 UTC --- (In reply to comment #15) The fix causes a build regression for mn10300: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../../gcc/gcc/../libbacktrace\ ../../../../gcc/gcc/config/mn10300/mn10300.c -o mn10300.o ../../../../gcc/gcc/config/mn10300/mn10300.c: In function ‘void mn10300_scan_for_setlb_lcc()’: ../../../../gcc/gcc/config/mn10300/mn10300.c:3238:35: error: ISO C++ forbids comparison between pointer and integer [-fpermissive] make[2]: *** [mn10300.o] Error 1 make[2]: Leaving directory `/home/vaxbuild/build/mn10300-linux/gcc-stage1/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/vaxbuild/build/mn10300-linux/gcc-stage1' BUILDLOG: Execution result: 2, took 1152.871889203 sec for command make all-gcc install-gcc BUILDLOG: Aborting execution make: *** [cross-compiler] Error 2 This happens because the fix changed flow_loops_find(): -int +struct loops * flow_loops_find (struct loops *loops) ...with the caller in the mn10300 backend not being changed. which seems to be broken anyway, as ... #if 0 /* FIXME: We should free the storage we allocated, but for some unknown reason this leads to seg-faults. */ FOR_EACH_LOOP (liter, loop, 0) free_simple_loop_desc (loop); flow_loops_free (current_loops); #endif I'll fix the build issue.
[Bug c++/56302] [4.8 Regression] sys/sdt.h asms stopped working at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56302 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-13 09:36:26 UTC --- Created attachment 29431 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29431 gcc48-pr56302.patch Untested fix.
[Bug c++/56302] [4.8 Regression] sys/sdt.h asms stopped working at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56302 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-02-13 Target Milestone|--- |4.8.0 Ever Confirmed|0 |1
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 vries at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #28 from vries at gcc dot gnu.org 2013-02-13 09:53:07 UTC --- I seem to be running into the same problem as described in comment 19, while doing a x86_64-unknown-linux-gnu non-bootstrap build: ... ../.././gcc/ada/rts adainclude checking for C compiler default output file name... /bin/bash: ../.././gcc/ada/rts: Is a directory make[2]: *** [gnatlib-shared] Error 126 make[2]: Leaving directory `ref-13-02-13/nobootstrap/build/x86_64-unknown-linux-gnu/libada' make[1]: *** [all-target-libada] Error 2 ...
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Priority|P5 |P2 Status|WAITING |NEW --- Comment #29 from Kai Tietz ktietz at gcc dot gnu.org 2013-02-13 10:03:41 UTC --- I reverted patch. But still have no idea what was actual going wrong here.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #30 from vries at gcc dot gnu.org 2013-02-13 10:06:11 UTC --- This will probably fix it: ... Index: Makefile.in === --- Makefile.in (revision 195997) +++ Makefile.in (working copy) @@ -115,8 +115,8 @@ touch stamp-libada -rm -rf adainclude -rm -rf adalib - $(LN_S_RECUSIVE) $(ADA_RTS_DIR) adainclude - $(LN_S_RECUSIVE) $(ADA_RTS_DIR) adalib + $(LN_S_RECURSIVE) $(ADA_RTS_DIR) adainclude + $(LN_S_RECURSIVE) $(ADA_RTS_DIR) adalib osconstool: $(MAKE) -C $(GCC_DIR)/ada $(LIBADA_FLAGS_TO_PASS) ./bldtools/oscons/xoscons ...
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #31 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-13 10:09:02 UTC --- (In reply to comment #30) --- Makefile.in (revision 195997) +++ Makefile.in (working copy) @@ -115,8 +115,8 @@ touch stamp-libada -rm -rf adainclude -rm -rf adalib - $(LN_S_RECUSIVE) $(ADA_RTS_DIR) adainclude - $(LN_S_RECUSIVE) $(ADA_RTS_DIR) adalib + $(LN_S_RECURSIVE) $(ADA_RTS_DIR) adainclude + $(LN_S_RECURSIVE) $(ADA_RTS_DIR) adalib osconstool: $(MAKE) -C $(GCC_DIR)/ada $(LIBADA_FLAGS_TO_PASS) ./bldtools/oscons/xoscons ... Please install as obvious.
[Bug c++/56303] New: [C++11] ICE in lambda with closure on member variable of a template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56303
Bug #: 56303
Summary: [C++11] ICE in lambda with closure on member variable
of a template class
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: crill...@tiscali.it
Created attachment 29432
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29432
the ii file generated by the compiler
Hi,
I get an internal compiler error with a C++11 program on GCC 4.7.2,
targeting MinGW on Windows 7 64 bit. I've also checked that the same error is
generated on GCC 4.7.1 on a linux virtual machine (opensuse 12.2 64bit on
VirtualBox, hosted by my Windows 7 64 bit operating system).
As requested on instructions, I have used the -Wall -Wextra
-fno-strict-aliasing -fwrapv options to better detect errors in code but that
didn't change the result. I also used -pedantic, idem. I used -save-temps to
save the ii file that I attach to this post.
The error is Segmentation Fault.
I've seen I get it using a closure, also with variants in the use of []
operator: [], [this], [=] as indicated in the comment in the code.
When I write [] I get this not captured error instead (seems no compiler
error).
I attach the .ii file generated by the compiler (4.7.2 on Windows 7 64bit).
The program is :
#include set
#include vector
using namespace std;
templateclass elements_it
class my_iterator
{
public:
my_iterator(elements_it begin, elements_it end) :
begin_(begin), end_(end), i(0) {}
void f()
{
for_each(begin_, end_, [=](typename elements_it::value_type)
{
// segmentation fault with [], [this], [=]
// this not captured with []
if(v[i]) return;
});
}
private:
elements_it begin_;
elements_it end_;
size_t i;
vectorint v;
};
int main(int argc, char* argv[])
{
setint elements = { 1, 2, 3 };
my_iteratorsetint::iterator it(begin(elements), end(elements));
}
I get the following compiler error:
g++ -pedantic -Wall -Wextra -fno-strict-aliasing -fwrapv -save-temps --st
d=c++11 test_enumeration1.cpp -o test_enumeration1_gpp.exe
test_enumeration1.cpp: In lambda function:
test_enumeration1.cpp:21:10: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #32 from Kai Tietz ktietz at gcc dot gnu.org 2013-02-13 10:19:35 UTC --- Author: ktietz Date: Wed Feb 13 10:19:26 2013 New Revision: 196002 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196002 Log: PR target/52122 * Makefile.in (LN_S_RECUSIVE): New. (adainclude, adalib): Use LN_S_RECURSIVE for copy. Modified: trunk/libada/ChangeLog trunk/libada/Makefile.in
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #33 from Kai Tietz ktietz at gcc dot gnu.org 2013-02-13 10:20:49 UTC --- Author: ktietz Date: Wed Feb 13 10:20:30 2013 New Revision: 196003 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196003 Log: PR target/52122 * Makefile.in (LN_S_RECUSIVE): New. (adainclude, adalib): Use LN_S_RECURSIVE for copy. Modified: branches/gcc-4_7-branch/libada/ChangeLog branches/gcc-4_7-branch/libada/Makefile.in
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #34 from Kai Tietz ktietz at gcc dot gnu.org 2013-02-13 10:21:35 UTC --- Author: ktietz Date: Wed Feb 13 10:21:25 2013 New Revision: 196004 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196004 Log: PR target/52122 * Makefile.in (LN_S_RECUSIVE): New. (adainclude, adalib): Use LN_S_RECURSIVE for copy. Modified: branches/gcc-4_6-branch/libada/ChangeLog branches/gcc-4_6-branch/libada/Makefile.in
[Bug c++/56303] [C++11] ICE in lambda with closure on member variable of a template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56303 --- Comment #1 from crillion at tiscali dot it 2013-02-13 10:22:42 UTC --- Created attachment 29433 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29433 the source code which generates the error
[Bug target/52122] [4.6/4.7/4.8 Regression] incorrect ln -s replacement for mingw like targets in configure files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52122 --- Comment #35 from vries at gcc dot gnu.org 2013-02-13 10:25:21 UTC --- Kai, * Makefile.in (LN_S_RECUSIVE): New. please fix up the log messages. Thanks, - Tom
[Bug c++/56304] New: [C++1] ICE in get_expr_operands, at tree-ssa-operands.c for template class, using lambda with closure on member variable, also called by the constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56304
Bug #: 56304
Summary: [C++1] ICE in get_expr_operands, at
tree-ssa-operands.c for template class, using lambda
with closure on member variable, also called by the
constructor
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: crill...@tiscali.it
This bug is similar to 56303, but gives a slightly different error message: in
get_expr_operands, at tree-ssa-operands.c. The differences from 56303 case are:
1) a function f() is called from the constructor
2) in f(), a reference to a member variable is created and passed to a lambda
So, the program is a C++11 program on GCC 4.7.2, targeting MinGW on Windows 7
64 bit. I've also checked that the same error is generated on GCC 4.7.1 on a
linux virtual machine (opensuse 12.2 64bit on VirtualBox, hosted by my Windows
7 64 bit operating system).
As requested on instructions, I have used the -Wall -Wextra
-fno-strict-aliasing -fwrapv options to better detect errors in code but that
didn't change the result. I also used -pedantic, idem. I used -save-temps to
save the ii file that I attach to this post.
The error is get_expr_operands, at tree-ssa-operands.c.
I attach the .ii file generated by the compiler (4.7.2 on Windows 7 64bit).
The program is :
#include algorithm
#include vector
#include set
using namespace std;
templateclass elements_it
class my_iterator
{
public:
my_iterator(
elements_it elements_begin,
elements_it elements_end) :
elements_begin_(elements_begin),
elements_end_(elements_end),
elements_used(distance(elements_begin, elements_end))
{
f();
}
void f()
{
size_t ii = i;
for_each(elements_begin_, elements_end_, [](typename
elements_it::value_type)
{
if(elements_used[ii]) return;
g();
});
}
void g()
{
}
private:
elements_it elements_begin_;
elements_it elements_end_;
size_t i;
vectorint elements_used;
};
int main(int, char **)
{
setint elements1 = { 1, 2, 3 };
my_iteratorsetint::iterator i1(begin(elements1), end(elements1));
}
I get the following compiler error:
g++ -pedantic -Wall -Wextra -fno-strict-aliasing -fwrapv -save-temps --st
d=c++11 test_enumeration1.cpp -o test_enumeration1_gpp.exe
test_enumeration1.cpp: In lambda function:
test_enumeration1.cpp:50:1: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:1035
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/56304] [C++1] ICE in get_expr_operands, at tree-ssa-operands.c for template class, using lambda with closure on member variable, also called by the constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56304 --- Comment #1 from crillion at tiscali dot it 2013-02-13 10:36:34 UTC --- Created attachment 29434 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29434 the source code which generates the error
[Bug c++/56303] [C++11] ICE in lambda with closure on member variable of a template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56303 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.7.3, 4.8.0 Resolution||WORKSFORME --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-13 10:36:44 UTC --- I can reproduce with 4.7.2 but the problem is already fixed in mainline and 4_7-branch.
[Bug c++/56304] [C++1] ICE in get_expr_operands, at tree-ssa-operands.c for template class, using lambda with closure on member variable, also called by the constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56304 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target|MinGW | Status|UNCONFIRMED |RESOLVED Host|Windows 7 64 bit| Resolution||DUPLICATE Build|GCC 4.7.2 | --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-13 10:38:44 UTC --- Dup. *** This bug has been marked as a duplicate of bug 53037 ***
[Bug c/53037] warn_if_not_aligned(X)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53037 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||crillion at tiscali dot it --- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-13 10:38:44 UTC --- *** Bug 56304 has been marked as a duplicate of this bug. ***
[Bug c++/56304] [C++1] ICE in get_expr_operands, at tree-ssa-operands.c for template class, using lambda with closure on member variable, also called by the constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56304 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-13 10:40:03 UTC --- Oops, fixed reference Bug. *** This bug has been marked as a duplicate of bug 53137 ***
[Bug c++/53137] [4.7/4.8 Regression] g++ segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||crillion at tiscali dot it --- Comment #22 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-13 10:40:03 UTC --- *** Bug 56304 has been marked as a duplicate of this bug. ***
[Bug c++/56304] [C++1] ICE in get_expr_operands, at tree-ssa-operands.c for template class, using lambda with closure on member variable, also called by the constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56304 --- Comment #4 from crillion at tiscali dot it 2013-02-13 10:41:20 UTC --- Created attachment 29435 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29435 the ii file generated by the compiler (compressed with 7zip because bugzilla doens't accept it, since it's size is 1024 k) please let me know if .7z is not a good compression format, anyway on opensuse I found packages which can use this format.
[Bug c++/56304] [C++1] ICE in get_expr_operands, at tree-ssa-operands.c for template class, using lambda with closure on member variable, also called by the constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56304 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com 2013-02-13 10:44:11 UTC --- The problem is already fixed in mainline and 4_7-branch, thanks.
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494
--- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2013-02-13
10:55:15 UTC ---
Created attachment 29436
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29436
patch
-fsection-anchors enables pass_ipa_increase_alignment (the vectorizer can
not align globals after any function was assembled, so we do that upfront).
In LTO:
/* If this variable belongs to the global constant pool, retrieve the
pre-computed RTL or recompute it in LTO mode. */
if (TREE_CODE (decl) == VAR_DECL DECL_IN_CONSTANT_POOL (decl))
{
SET_DECL_RTL (decl, output_constant_def (DECL_INITIAL (decl), 1));
return;
but obviously output_constant_def when just getting DECL_INITIAL cannot
honor any special alignment requirements of decl. It will simply get
a new decl with standard alignment.
We know decl is already the decl associated with the constant, so we
should just re-use it.
So I believe the attached should fix this. Can PPC people plaease test?
[Bug lto/50494] gcc.dg/vect/vect-reduc-2char.c fails spuriously on ppc with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50494 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org 2013-02-13 10:55:59 UTC --- Eric added the original feature.
[Bug bootstrap/56128] [4.8 Regression] libsanitizer doesn't build with broken kernel headers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56128 Kostya Serebryany kcc at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #14 from Kostya Serebryany kcc at gcc dot gnu.org 2013-02-13 10:55:48 UTC --- This particular problem (with futex headers) should be fixed by the last merge (r196009)
[Bug tree-optimization/56294] BOOT_CFLAGS='-O2 -g -fno-ipa-sra' leads to bootstrap comparison failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56294 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org 2013-02-13 10:56:15 UTC --- With the debug counters I have identified the first function where the difference in behavior of intra-SRA behavior with -g vs -g0 caused the comparison failure but could not spot any differences in non-debug statements. Adding -fno-inline makes the comparison failure go away (-fno-early-inlining does not help) so at this point I suppose it's tree-inline that generates different stuff when there are references to SSA names from debug statements.
[Bug middle-end/56301] [4.7 Regression] wrong code with the fix for PR53844
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56301 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |WAITING Last reconfirmed||2013-02-13 Target Milestone|--- |4.7.3 Ever Confirmed|0 |1
[Bug fortran/56204] [4.8 regression] gfortran.dg/quad_[23].f90 FAIL on Solaris 9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56204 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2013-02-13 11:19:37 UTC --- --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-02-12 19:27:16 UTC --- (In reply to comment #0) The test is l.34: 34 if (fp2 /= fp4) call abort() but unfortunately gdb 7.5 can read neither variable. Can you uncomment the existing print lines and add print *, fp2 print *, fp4 before the abort line? Sure, this way I get 1.000 1.000 1.41421356237309504880168872420969798 1.41421356237309504880168872420969798 1.41421356237309504880168872420969798 1.41421356237309504880168872420969779 Probably, some rounding goes wrong - maybe replacing if (fp2 /= fp4) call abort() by if (abs (fp2 - fp4)/fp2 epsilon(fp2)) call abort() works which allows for a minor deviation of the value. This helps, but now we run into the next abort. Adding another set of print's shows 1.41421356237309504880168872420969798 1.41421356237309504880168872420969779 Changing the abort() conditions both times allows the test to pass, also tested with the prints commented again and the appropriate runtest invocation on i386-pc-solaris2.9, i386-pc-solaris2.10, and x86_64-unknown-linux-gnu. The quad_3.f90 test aborts here: #5 0x080511b1 in test_qp () at /vol/gcc/src/hg/trunk/local/gcc/testsuite/gfortran.dg/quad_3.f90:28 28 if (a-b(1) /= 0.0_qp .or. c-b(1) /= 0.0_qp) call abort() Uncommenting the prints shows: same value read again: 1.18973149535723176508575932662800647E+0932 1.18973149535723176508575932662800647E+0932 difference: looks OK now -1.87718493982104061421441469311027910E+0898 Rainer
[Bug fortran/56305] New: passing array of character with len1 to c_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56305 Bug #: 56305 Summary: passing array of character with len1 to c_loc Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: valerywe...@hotmail.com Dear All The following code compiles, but shouldnt it be rejected? V program aaa use, intrinsic :: iso_c_binding type(c_ptr) :: p character(len=2),dimension(1), target :: c p=c_loc(c(1)) end program aaa
[Bug preprocessor/56306] New: -m32 does not support all includes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56306 Bug #: 56306 Summary: -m32 does not support all includes Classification: Unclassified Product: gcc Version: 4.3.4 Status: UNCONFIRMED Severity: minor Priority: P3 Component: preprocessor AssignedTo: unassig...@gcc.gnu.org ReportedBy: uwe.seid...@siemens-enterprise.com Created attachment 29437 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29437 simple test program Scenario: Compilation of a 32bit application on a 64bit host. For compiler internal header files the preprocessor accesses the corret header files, e.g. #include bits/stdc++.h includes 32/bits/stdc++.h. For includes located somewher in the sysroot folders this usefull mechanism does not work. gcc-4.3 -m32 curlbr.c does not work if 32bit variant of curlbuild.h is provided in a 32/curl folder.
[Bug lto/56295] [4.8 Regression] Missed optimization with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-02-13 11:51:18 UTC --- (In reply to comment #5) Created attachment 29425 [details] Modified testcase This slightly modified testcase still shows some strange difference between LTO / non-LTO. The difference is from the compilation, not the link! That's because of the very same reason - us wrapping all global decls in MEM_REFs. We do that at compilation time (when we stream the GIMPLE IL), and this change persists. I have another patch ;)
[Bug fortran/56204] [4.8 regression] gfortran.dg/quad_[23].f90 FAIL on Solaris 9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56204 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2013-02-13 12:03:27 UTC --- Author: burnus Date: Wed Feb 13 12:03:18 2013 New Revision: 196011 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196011 Log: 2013-02-13 Tobias Burnus bur...@net-b.de Rainer Orth r...@cebitec.uni-bielefeld.de PR fortran/56204 * gfortran.dg/quad_2.f90: Use epsilon instead of ==. * gfortran.dg/quad_3.f90: Ditto. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/quad_2.f90 trunk/gcc/testsuite/gfortran.dg/quad_3.f90
[Bug fortran/56204] [4.8 regression] gfortran.dg/quad_[23].f90 FAIL on Solaris 9/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56204 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org 2013-02-13 12:06:02 UTC --- Thanks for testing. It looks as if it should have been FIXED by the committed patch. Please re-open if the issue still occurs.
[Bug preprocessor/56306] -m32 does not support all includes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56306 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Severity|minor |enhancement --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-02-13 12:09:58 UTC --- Well, there is no multilib setup for includes. include files should work for all multilibs. In this case this is a bug of whoever provides curlbuild.h. I don't see how this is a bug in GCC, so I'm re-labeling it as enhancement.
[Bug fortran/56305] passing array of character with len1 to c_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56305
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-02-13
12:19:39 UTC ---
The following code compiles, but shouldnt it be rejected?
It seems to be invalid Fortran 2003 but valid Fortran 2008 (w/ and w/o
TS29113). The gfortran's diagnostic handling for C_LOC still needs some changes
for -std=f2003, -std=f2008, -std=f2008ts (rejecting too much, some diagnostic
missing for -std=f2003).
Fortran 2003 has (15.1.2.5 C LOC (X)):
Argument. X shall either
(1) have interoperable type and type parameters and be [...]
(2) be a nonpolymorphic scalar, have no length type parameters, and be [...]
A type parameter of len=2 is not valid and also c is not a scalar – Thus, it
seems to be invalid.
However, it seems to be valid with Fortran 2008 (15.2.3.6 C LOC (X)); note
the change type parameter to kind type parameter
Argument. X shall have either the POINTER or TARGET attribute. It shall not be
a coindexed object. It shall either be a variable with interoperable type and
kind type parameters, or be a scalar, nonpolymorphic variable with no length
type parameters. If it is allocatable, it shall be allocated. If it is a
pointer, it shall be associated. If it is an array, it shall be contiguous and
have nonzero size. It shall not be a zero-length string.
TS 29113 changes the latter as follows:
{In 15.2.3.6 C_LOC(X), paragraph 3}
Delete 'scalar,'.
[Bug c++/54126] ICE on constexpr move ctor with const ref type instead of error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54126 --- Comment #5 from Ilya Mikhaltsou morpheby at gmail dot com 2013-02-13 12:20:21 UTC --- (In reply to comment #4) Created attachment 29430 [details] simple fail case I think I have an even simplier test case, I guess it's the same problem (at least the ICE message matches). I also think that bug 51707 is actually the same problem. Yes, looks like both mine and yours testcase actually do the same - they attempt to move some constexpr to another, and gcc fails. That looks like not implemented or buggy check for error. bug 51707 looks to be error on correct code and possibly fails on getting constant l-value reference. If they are exactly the same, then the bug actually lies in contexpr reference mechanics, and gcc fails on getting constexpr reference of any kind, not on moving constexpr. I'll try to investigate if it is the case as soon as I have some free time.
[Bug preprocessor/56306] -m32 does not support all includes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56306 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2013-02-13 12:22:19 UTC --- GCC can obviously alter its internal include paths to its own headers because it knows what they contain and how to find the contents. It can't possibly know about arbitrary non-GCC paths or whether it's correct or safe to append 32 to those paths.
[Bug preprocessor/56306] -m32 does not support all includes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56306 --- Comment #3 from Uwe Seidler uwe.seid...@siemens-enterprise.com 2013-02-13 12:35:34 UTC --- enhacemant is ok
[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181 --- Comment #17 from Richard Biener rguenth at gcc dot gnu.org 2013-02-13 13:03:46 UTC --- (In reply to comment #16) (In reply to comment #15) The fix causes a build regression for mn10300: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I../../../../gcc/gcc/../libbacktrace\ ../../../../gcc/gcc/config/mn10300/mn10300.c -o mn10300.o ../../../../gcc/gcc/config/mn10300/mn10300.c: In function ‘void mn10300_scan_for_setlb_lcc()’: ../../../../gcc/gcc/config/mn10300/mn10300.c:3238:35: error: ISO C++ forbids comparison between pointer and integer [-fpermissive] make[2]: *** [mn10300.o] Error 1 make[2]: Leaving directory `/home/vaxbuild/build/mn10300-linux/gcc-stage1/gcc' make[1]: *** [all-gcc] Error 2 make[1]: Leaving directory `/home/vaxbuild/build/mn10300-linux/gcc-stage1' BUILDLOG: Execution result: 2, took 1152.871889203 sec for command make all-gcc install-gcc BUILDLOG: Aborting execution make: *** [cross-compiler] Error 2 This happens because the fix changed flow_loops_find(): -int +struct loops * flow_loops_find (struct loops *loops) ...with the caller in the mn10300 backend not being changed. which seems to be broken anyway, as ... #if 0 /* FIXME: We should free the storage we allocated, but for some unknown reason this leads to seg-faults. */ FOR_EACH_LOOP (liter, loop, 0) free_simple_loop_desc (loop); flow_loops_free (current_loops); #endif I'll fix the build issue. Should be fixed now.
[Bug lto/56295] [4.8 Regression] Missed optimization with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56295 --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org 2013-02-13 13:31:24 UTC --- Author: rguenth Date: Wed Feb 13 13:31:18 2013 New Revision: 196013 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196013 Log: 2013-02-13 Richard Biener rguent...@suse.de PR lto/56295 * gimple-streamer-out.c (output_gimple_stmt): Undo wrapping globals in MEM_REFs. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-streamer-out.c
[Bug middle-end/56242] [4.8 Regression] libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:175:0: ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56242
--- Comment #4 from dave.anglin at bell dot net 2013-02-13 14:09:26 UTC ---
On 2013-02-12 6:03 PM, vries at gcc dot gnu.org wrote:
I've tried to reproduce this bug by building a cross compiler using the
hppa2.0w-unknown-linux-gnu target. I managed to build libjava, but I didn't
manage to reproduce the bug.
Yes. it doesn't reproduce on linux.
The thing I can see that's wrong is in NEXT_INSN (insn 11), which is note 152
but which should be note 153:
...
(insn 428 427 153 (sequence [
(jump_insn:TI 151 427 11 (set (pc)
(if_then_else (eq (reg:SI 28 %r28 [orig:123 D.12040+-2 ]
[123])
(const_int 10 [0xa]))
(label_ref:SI 165)
(pc)))
/test/gnu/gcc/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:162
28 {*pa.md:1439}
(expr_list:REG_DEAD (reg:SI 28 %r28 [orig:123 D.12040+-2 ]
[123])
(expr_list:REG_BR_PROB (const_int 2800 [0xaf0])
(nil)))
- 165)
(insn 11 151 152 (set (reg:SI 7 %r7 [orig:129 D.12038 ] [129])
(reg:SI 5 %r5 [orig:132 ivtmp.903 ] [132])) 40
{*pa.md:2211}
(nil))
])
/test/gnu/gcc/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:162
-1
(nil))
(note 153 428 152 [bb 19] NOTE_INSN_BASIC_BLOCK)
(note 152 153 276 19 (*L$Jpc=71164) NOTE_INSN_DELETED_LABEL 395)
...
I'll give your patch a try later today when my current build and check
finishes. I could give you
access to this test system if the change doesn't work out.
Thanks for looking at this bug.
[Bug debug/56307] New: FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra Created a debug-only replacement for s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56307 Bug #: 56307 Summary: FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra Created a debug-only replacement for s Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 Created attachment 29438 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29438 Tree dump Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /te st/gnu/gcc/gcc/gcc/testsuite/gcc.dg/tree-ssa/pr55579.c -fno-diagnostics-show-ca ret -O2 -g -fdump-tree-esra -S -o pr55579.s(timeout = 300) spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/gnu/gcc/gc c/gcc/testsuite/gcc.dg/tree-ssa/pr55579.c -fno-diagnostics-show-caret -O2 -g -fd ump-tree-esra -S -o pr55579.s PASS: gcc.dg/tree-ssa/pr55579.c (test for excess errors) FAIL: gcc.dg/tree-ssa/pr55579.c scan-tree-dump esra Created a debug-only replac ement for s
[Bug fortran/55852] [4.6/4.7/4.8 regression] internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852 --- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org 2013-02-13 14:38:49 UTC --- (In reply to comment #10) The test case fails because the match is too strict. Should be fixed - for the the trunk only - since 2012-01-09 via http://gcc.gnu.org/viewcvs?view=revisionrevision=195064
[Bug fortran/55852] [4.6/4.7/4.8 regression] internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852 --- Comment #12 from janus at gcc dot gnu.org 2013-02-13 14:44:13 UTC --- (In reply to comment #11) Should be fixed - for the the trunk only - since 2012-01-09 Ok, so can we close this guy? Or is there need for a backport?
[Bug fortran/54730] [4.6/4.7/4.8 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1066
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54730 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Attachment #29428|0 |1 is obsolete|| --- Comment #11 from Mikael Morin mikael at gcc dot gnu.org 2013-02-13 15:03:41 UTC --- Created attachment 29439 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29439 Fix that doesn't regress on norm2_3 and widechar_5
[Bug fortran/55852] [4.6/4.7/4.8 regression] internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852 --- Comment #13 from Tobias Burnus burnus at gcc dot gnu.org 2013-02-13 15:09:06 UTC --- Author: burnus Date: Wed Feb 13 15:08:59 2013 New Revision: 196016 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196016 Log: 2012-02-13 Tobias Burnus bur...@net-b.de Backport from mainline 2012-01-09 Uros Bizjak ubiz...@gmail.com PR fortran/55852 * gfortran.dg/intrinsic_size_3.f90: Make scan-tree-dump-times number matching more robust. Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/intrinsic_size_3.f90
[Bug target/56184] [4.8 Regression] Internal compiler error in push_reload during bootstrap stage 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184 --- Comment #7 from Vladimir Makarov vmakarov at gcc dot gnu.org 2013-02-13 15:15:14 UTC --- (In reply to comment #6) Unfortunately I'm not really familiar with the live range splitting code; maybe Vladimir can help with this? Yes, Ulrich. I've started to work on this.
[Bug middle-end/56242] [4.8 Regression] libjava/classpath/gnu/javax/swing/text/html/parser/support/textPreProcessor.java:175:0: ICE: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56242 --- Comment #5 from vries at gcc dot gnu.org 2013-02-13 15:44:21 UTC --- Created attachment 29440 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29440 delete-insn-tentative-fix-PR56242.patch I'll give your patch a try later today when my current build and check finishes. New version of the patch, the previous one did PATTERN (PATTERN ()). I'm bootstrapping this now on x86_64, and will test it on mips.
[Bug tree-optimization/37021] Fortran Complex reduction / multiplication not vectorized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37021
--- Comment #14 from Richard Biener rguenth at gcc dot gnu.org 2013-02-13
15:58:31 UTC ---
The following testcase shows the issue well:
_Complex double self[1024];
_Complex double a[1024][1024];
_Complex double b[1024];
void foo (void)
{
int i, j;
for (i = 0; i 1024; i+=3)
for (j = 0; j 1024; j+=3)
self[i] = self[i] + a[i][j]*b[j];
}
we have to get the complex multiplication pattern recognized by SLP
which looks like (without PRE):
bb 3:
bb 4:
# j_21 = PHI j_13(3), 0(7)
# self_I_RE_lsm.2_12 = PHI _26(3), self_I_RE_lsm.2_7(7)
# self_I_IM_lsm.3_28 = PHI _27(3), self_I_IM_lsm.3_8(7)
# ivtmp_16 = PHI ivtmp_1(3), 342(7)
_2 = REALPART_EXPR a[i_20][j_21];
_18 = IMAGPART_EXPR a[i_20][j_21];
_19 = REALPART_EXPR b[j_21];
_17 = IMAGPART_EXPR b[j_21];
_4 = _19 * _2;
_3 = _18 * _17;
_6 = _17 * _2;
_23 = _19 * _18;
_24 = _4 - _3;
_25 = _23 + _6;
_26 = _24 + self_I_RE_lsm.2_12;
_27 = _25 + self_I_IM_lsm.3_28;
j_13 = j_21 + 3;
ivtmp_1 = ivtmp_16 - 1;
if (ivtmp_1 != 0)
goto bb 3;
we fail to build the SLP tree for _25 = _23 + _6 because the matching
stmt is _24 = _4 - _3 which has a different operation (SSE4 addsub
would support vectorizing this). I don't see how we can easily
make this supported with the current pattern support ... the
support doesn't allow tieing together two SLP group members.
Simply allowing analysis to proceeed here reveals the fact that
the interleaving has a gap of 6 which makes the analysis fail.
Allowing it to proceed for ncopies == 1 (thus no actual interleaving
required) reveals the next check is slightly bogus in that case.
Fixing that ends us with
t.c:9: note: Load permutation 0 0 1 0 1 1 0 1
t.c:9: note: Build SLP failed: unsupported load permutation _27 = _25 +
self_I_IM_lsm.3_28;
... (to be continued)
[Bug c++/56302] [4.8 Regression] sys/sdt.h asms stopped working at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56302 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-13 16:09:35 UTC --- Author: jakub Date: Wed Feb 13 16:09:27 2013 New Revision: 196018 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196018 Log: PR c++/56302 * semantics.c (finish_asm_stmt): If input constraints allow neither register nor memory, try maybe_constant_value to get a constant if possible. * g++.dg/torture/pr56302.C: New test. * g++.dg/cpp0x/constexpr-56302.C: New test. * c-c++-common/pr56302.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr56302.c trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-56302.C trunk/gcc/testsuite/g++.dg/torture/pr56302.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/56302] [4.8 Regression] sys/sdt.h asms stopped working at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56302 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-02-13 16:13:08 UTC --- Fixed.
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 m...@gcc.gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #19 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2013-02-13 17:06:11 UTC --- I think in the release after next we can just deprecate stabs and all other non-dwarf debug formats (not remove them) and simply not worry about it. In the release after that, we then remove them. If someone doesn't like that, let them step forward as a stabs maintainer and fix it before release. This gives them 2 years to fix it or so. If they don't, then removal seems reasonable.
[Bug middle-end/56290] [4.8 Regression] ICE building OpenFOAM in in ipa_make_edge_direct_to_target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56290 --- Comment #4 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-02-13 17:14:46 UTC --- Created attachment 29441 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29441 testcase Preprocessed testcase reproducible with ./cc1plus -O3
[Bug middle-end/56290] [4.8 Regression] ICE building OpenFOAM in in ipa_make_edge_direct_to_target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56290 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #5 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-02-13 17:16:12 UTC --- Duplicate. I even confirmed that Jakub's untested patch for 56265 fixes the problem. *** This bug has been marked as a duplicate of bug 56265 ***
[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265 Aldy Hernandez aldyh at gcc dot gnu.org changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #5 from Aldy Hernandez aldyh at gcc dot gnu.org 2013-02-13 17:16:12 UTC --- *** Bug 56290 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/48133] [4.6/4.7/4.8 Regression] ICE: in get_loop_body, at cfgloop.c:831 with -O -funroll-loops -fthread-jumps -fno-tree-ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48133 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #16 from Marek Polacek mpolacek at gcc dot gnu.org 2013-02-13 17:31:29 UTC --- Seems like it, thus - fixed.
[Bug target/56184] [4.8 Regression] Internal compiler error in push_reload during bootstrap stage 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56184 --- Comment #8 from Vladimir Makarov vmakarov at gcc dot gnu.org 2013-02-13 17:40:33 UTC --- Author: vmakarov Date: Wed Feb 13 17:40:22 2013 New Revision: 196019 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196019 Log: 2013-02-13 Vladimir Makarov vmaka...@redhat.com PR target/56184 * ira.c (max_regno_before_ira): Move from ... (ira): ... here. (fix_reg_equiv_init): Use max_regno_before_ira instead of vec_safe_length. 2013-02-13 Vladimir Makarov vmaka...@redhat.com PR target/56184 * gcc.target/arm/pr56184.C: New test. Added: trunk/gcc/testsuite/gcc.target/arm/pr56184.C Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/55852] [4.6/4.7/4.8 regression] internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852 --- Comment #14 from Tobias Burnus burnus at gcc dot gnu.org 2013-02-13 17:51:17 UTC --- Author: burnus Date: Wed Feb 13 17:51:11 2013 New Revision: 196020 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196020 Log: 2013-02-13 Tobias Burnus bur...@net-b.de Backported from mainline 2013-01-07 Tobias Burnus bur...@net-b.de Thomas Koenig tkoe...@gcc.gnu.org Jakub Jelinek ja...@redhat.com PR fortran/55852 * expr.c (gfc_build_intrinsic_call): Avoid clashes with user's procedures. * gfortran.h (gfc_build_intrinsic_call): Update prototype. (GFC_PREFIX): Define. * simplify.c (gfc_simplify_size): Update call. 2013-02-13 Tobias Burnus bur...@net-b.de Backported from mainline 2013-01-07 Tobias Burnus bur...@net-b.de Uros Bizjak ubiz...@gmail.com PR fortran/55852 * gfortran.dg/intrinsic_size_3.f90: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/intrinsic_size_3.f90 Modified: branches/gcc-4_6-branch/gcc/fortran/ChangeLog branches/gcc-4_6-branch/gcc/fortran/expr.c branches/gcc-4_6-branch/gcc/fortran/gfortran.h branches/gcc-4_6-branch/gcc/fortran/simplify.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug fortran/55852] [4.6/4.7/4.8 regression] internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org 2013-02-13 17:52:27 UTC --- FIXED on the trunk (4.8) and on the 4.6/4.7 branches. Thanks for the report - and sorry for the regression.
[Bug c++/56135] [c++11] this incorrectly captured as null in template member function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56135 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2013-02-13 17:56:11 UTC --- Author: jason Date: Wed Feb 13 17:56:05 2013 New Revision: 196021 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196021 Log: PR c++/56135 * pt.c (tsubst_copy_and_build): Don't forget any new captures that arose from use of dependent names. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-this8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/56155] [C++11] enumeration with fixed underlying type - enumerators have wrong type within enumerator-list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56155 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2013-02-13 17:56:23 UTC --- Author: jason Date: Wed Feb 13 17:56:16 2013 New Revision: 196022 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196022 Log: PR c++/56155 * decl.c (build_enumerator): Always convert the value to a fixed underlying type. Added: trunk/gcc/testsuite/g++.dg/cpp0x/enum22.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug c++/55993] [C++11] derived-to-base conversion fails in constant expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55993 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2013-02-13 17:56:33 UTC --- Author: jason Date: Wed Feb 13 17:56:28 2013 New Revision: 196023 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=196023 Log: PR c++/55993 * semantics.c (cxx_fold_indirect_ref): Handle empty bases at non-zero offsets, too. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-empty6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c
