Re: CPATH, LIBRARY_PATH, and cross-compilers
On Tue, Feb 12, 2013 at 9:41 PM, Ludovic Courtès wrote: > Joel Sherrill 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 wrote: > On Tue, Feb 12, 2013 at 9:41 PM, Ludovic Courtès wrote: >> Joel Sherrill 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 wrote:
> From: David Miller
> Date: Fri, 16 Nov 2012 00:33:05 -0500 (EST)
>
>> From: Richard Sandiford
>> 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
>
> * 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 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 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 wrote: > On 13/02/13 12:39, Richard Biener wrote: >> >> On Wed, Feb 13, 2013 at 1:31 PM, Alec Teal 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 skribis: > On Wed, Feb 13, 2013 at 12:13 PM, Richard Biener > wrote: >> On Tue, Feb 12, 2013 at 9:41 PM, Ludovic Courtès wrote: >>> Joel Sherrill 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 wrote: > On Wed, Feb 13, 2013 at 8:31 AM, Alec Teal wrote: >> On 13/02/13 12:39, Richard Biener wrote: >>> >>> On Wed, Feb 13, 2013 at 1:31 PM, Alec Teal 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 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 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 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 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 Date: Wed, 13 Feb 2013 12:15:13 +0100 > On Tue, Feb 12, 2013 at 11:31 PM, David Miller 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 >> >> * 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 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, 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 (n . . . }}} 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 (n . . . }}} 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 no live range splitting at all). Each of the blocks of code is in it's own BB. I haven't checked, but I'd guess that most of the registers are in use on entry and still live on exit, so the block has no r
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 (n . . . }}} 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 the other. IRA improved code for many RISC processors. Although tetter RA has smaller effect for these processors as they have more registers. Looking at the test code, I can make some conclusions for my
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 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-0xf4f5 << where 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 (n >> n+=*(cp-*p++); > >> if (n >> n+=*(cp-*p); > >> if (n >> . . . ~20 levels of nesting > >> > >> . . . }}} > >> > >> 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 (n . . . }}} 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
