Re: Experimental Patchwork setup
On 06/08/2010 10:37 PM, Ian Lance Taylor wrote: Are there ways that we can adjust our e-mail messages to make this work better? Two things: 1) we should make the [bracket] prefixes more standard for patches destined to feature branches; 2) we should likely not send multiple patches in one email as attachments. Another point about (1): I believe patchwork should *not* track most of the branch patches, and the commit detection shouldn't care about release branch commits, only trunk. This is because those are 99% of the time for trunk too, and whether the patches went on the release branches is effectively already tracked via bugzilla. Paolo
Re: Experimental Patchwork setup
On 9 June 2010 02:21, Jeremy Kerr j...@ozlabs.org wrote: There is one header you can add to emails: X-Patchwork-Hint: ignore I am not sure how to add headers with gmail which is what I use for GCC development. I would rather have patchwork recognize something like: :patchwork: ignore: in the body of the email. Thanks for doing this! Manuel.
Re: Experimental Patchwork setup
On 9 June 2010 02:21, Jeremy Kerr j...@ozlabs.org wrote: Hi Ian, I can see already that to be useful for gcc today it will need some curating. E.g., http://patchwork.ozlabs.org/patch/54974/ is both 1) committed; 2) on a branch. This one http://patchwork.ozlabs.org/patch/54958/ is committed to trunk. There are a number of ways to keep the patch states up-to-date: 2) Use the command-line patchwork client to update patch state when a patch is committed. People have done this with a git post-commit hook to update the state of the patch in patchwork; I'm not sure if svn has something equivalent. Yes it does. If you tell us how the git pots-commit hook works, we could try to implement a version for svn and GCC. Cheers, Manuel.
Re: Experimental Patchwork setup
Hi Manuel, 2) Use the command-line patchwork client to update patch state when a patch is committed. People have done this with a git post-commit hook to update the state of the patch in patchwork; I'm not sure if svn has something equivalent. Yes it does. If you tell us how the git pots-commit hook works, we could try to implement a version for svn and GCC. This is what I've used for git: [...@pororo helloworld]$ cat .git/hooks/post-applypatch #!/bin/bash sha=$(git rev-parse HEAD) hash=$(git show $sha | pwparser --hash) pwclient update -s Accepted -c $sha -h $hash - where 'pwparser' is symlink to parser.py from the patchwork tree (http://git.ozlabs.org/?p=patchwork;a=blob;f=apps/patchwork/parser.py), and 'pwclient' is downloadable from the patchwork setup. And for those unfamiliar with git: 'git rev-parse HEAD' prints the commit ID of the latest commit, and 'git show $sha' prints out the commit itself - all we need is the diff, pwparser will ignore everything else. Cheers, Jeremy
Re: Experimental Patchwork setup
Hi, On Wed, Jun 09, 2010 at 08:21:17AM +0800, Jeremy Kerr wrote: There is one header you can add to emails: X-Patchwork-Hint: ignore - this will tell patchwork to ignore the patch completely. I use this when sending a this is the stuff I'm merging for the next release email, as all of the patches have already been through the list. I believe the common practice for such patches is to put the string RFC somewhere into the subject of such patches, usually into square brackets. Would you consider looking for that instead? Editing headers is often inconvenient, especially if the email messages are generated, for example by quilt. Thanks for doing this, Martin
Re: Experimental Patchwork setup
Hi Martin, There is one header you can add to emails: X-Patchwork-Hint: ignore - this will tell patchwork to ignore the patch completely. I use this when sending a this is the stuff I'm merging for the next release email, as all of the patches have already been through the list. I believe the common practice for such patches is to put the string RFC somewhere into the subject of such patches, usually into square brackets. Would you consider looking for that instead? In the example I gave, they're not really RFC, they're just a last call for objections before the patches are sent upstream. So, probably not - I don't want RFC patches to be dropped immediately, especially as other projects using patchwork.ozlabs.org will be affected. However, I believe the plan is to move the gcc patchwork instance to its own server if the ozlabs.org patchwork provides to be useful; in this case, the gcc folks are free to do whatever they like :) Cheers, Jeremy
a typo in ira-emit.c?
Hi :
I am studying ira right now, there is following code in change_loop
if (parent_allocno == NULL
|| REGNO (ALLOCNO_REG (parent_allocno)) == REGNO (original_reg))
{
if (internal_flag_ira_verbose 3 ira_dump_file)
fprintf (ira_dump_file, %i vs parent %i:,
ALLOCNO_HARD_REGNO (allocno),
ALLOCNO_HARD_REGNO (parent_allocno));
set_allocno_reg (allocno, create_new_reg (original_reg));
}
Is it possible that parent_allocno == NULL here? or the fprintf might broken.
Thanks.
--
Best Regards.
No output files on 4.6/Cygwin
I have a problem with recent builds of GCC4.6 (trunk)
on Cygwin 1.7. The compiler itself builds correctly, but
when I run it on even the simplest input, e.g.
gcc in.c -o a.exe
with in.c = int main() {}, no executable file is created.
No oputput is created even with the -S and -E options.
The same used to happen with GCC 4.5 experimental
in its early development days, but later started to work
again. Is it a known issue of GCC or Cygwin? Has
anyone managed to get a working 4.6 build on Cygwin?
Best regards,
Piotr Wyderski
Re: Experimental Patchwork setup
Yes it does. If you tell us how the git pots-commit hook works, we could try to implement a version for svn and GCC. This is what I've used for git: [...@pororo helloworld]$ cat .git/hooks/post-applypatch #!/bin/bash sha=$(git rev-parse HEAD) hash=$(git show $sha | pwparser --hash) pwclient update -s Accepted -c $sha -h $hash We'll need to cut out the ChangeLog parts before computing the hash. I'll work on something. Segher
Re: Experimental Patchwork setup
Two things: 1) we should make the [bracket] prefixes more standard for patches destined to feature branches; Another point about (1): I believe patchwork should *not* track most of the branch patches, and the commit detection shouldn't care about release branch commits, only trunk. This is because those are 99% of the time for trunk too, and whether the patches went on the release branches is effectively already tracked via bugzilla. Patches that go to trunk first, and then to some branch, should already be handled correctly as far as I can see. So there is no need to mark email messages specially for this. 2) we should likely not send multiple patches in one email as attachments. We shouldn't do that anyway :-) Maybe patchwork can even handle this, dunno. Segher
Re: No output files on 4.6/Cygwin
On Wed, Jun 9, 2010 at 11:51 AM, Piotr Wyderski
piotr.wyder...@gmail.com wrote:
I have a problem with recent builds of GCC4.6 (trunk)
on Cygwin 1.7. The compiler itself builds correctly, but
when I run it on even the simplest input, e.g.
gcc in.c -o a.exe
with in.c = int main() {}, no executable file is created.
No oputput is created even with the -S and -E options.
Maybe a mismatched cygwin1.dll. Do you have the right version of
cygwin1.dll on path? e.g the one against which gcc was compiled?.
Cygwin fails silently to execute the image in case of a mismatched
dll.
Best regards,
Piotr Wyderski
Wojciech
Re: No output files on 4.6/Cygwin
Wojciech Meyer wrote: Maybe a mismatched cygwin1.dll. Do you have the right version of cygwin1.dll on path? e.g the one against which gcc was compiled?. Cygwin fails silently to execute the image in case of a mismatched dll. I am not 100% sure that my Cygwin installation is OK, as it has been upgraded from 1.5 without uninstalling the latter (i.e. I wiped it out using a mere rm -rf), but the image itself works: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/i686-pc-cygwin/4.6.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ../configure --prefix=/opt/gcc-trunk -v --enable-bootstrap --enable-version-specific-runtime-libs --ena ble-shared --enable-shared-libgcc --with-gnu-ld --with-gnu-as --enable-dwarf2-exceptions --disable-symvers --disable-nls --with-arch=core2 --with-tune=generic --enable-threads=posix --enable-languages=c,c++ AM_CXXFLAGS=-w Thread model: posix gcc version 4.6.0 20100607 (experimental) (GCC) Best regards Piotr Wyderski
Vector subscription, register storage class
Hi,
I'm working on the vector subscription patch in terms of GSoC 2010 project.
The patch basically does the following, if we have a vector subscription like:
#define vector __attribute__((vector_size(16)))
vector int a;
a[1] = 10;
then the code a[1] = 10 is transformed into the code *((int *)a + 1) = 10.
The problem however is, when we have a register-declared variable like:
register vector int a = {1,2,3,4};
It should be addressable, but register keyword disallows it. To solve
this problem I modify c-decl.c:start_decl like this:
Index: c-decl.c
===
--- c-decl.c(revision 160230)
+++ c-decl.c(working copy)
@@ -4071,6 +4071,11 @@
}
}
+ /* Vectors need to be addressable for subscripting to work,
+ so drop the qualifier. */
+ if (TREE_CODE (TREE_TYPE (decl)) == VECTOR_TYPE)
+C_DECL_REGISTER (decl) = 0;
+
if (TREE_CODE (decl) == FUNCTION_DECL
DECL_DECLARED_INLINE_P (decl)
DECL_UNINLINABLE (decl)
Which allows now to subscript register-declared variables.
But still I have an example that does not work:
struct vec_s {
vector short member;
};
int main () {
register struct vec_s v2;
v2.member[2] = 4;
return 0;
}
The question is should it work at all? And what would be the optimal
way to implement it?
--
Thank you,
Artem Shinkarov
Re: No output files on 4.6/Cygwin
On 09/06/2010 11:51, Piotr Wyderski wrote:
I have a problem with recent builds of GCC4.6 (trunk)
on Cygwin 1.7. The compiler itself builds correctly, but
when I run it on even the simplest input, e.g.
gcc in.c -o a.exe
with in.c = int main() {}, no executable file is created.
No oputput is created even with the -S and -E options.
The same used to happen with GCC 4.5 experimental
in its early development days, but later started to work
again. Is it a known issue of GCC or Cygwin? Has
anyone managed to get a working 4.6 build on Cygwin?
Yeh, I posted testresults just a little while ago(*). Are you sure you're
picking up the newest version of cyggcc_s-1.dll (and all the other language
runtimes) that got built with the compiler, rather than the standard system
one(s)? You did a full make install and put the new $prefix/bin (if not
using the standard prefix) at the head of your PATH?
cheers,
DaveK
--
(*) - http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg02996.html
Re: No output files on 4.6/Cygwin
On 09/06/2010 17:10, Dave Korn wrote:
Oh, and an afterthought:
On 09/06/2010 11:51, Piotr Wyderski wrote:
I have a problem with recent builds of GCC4.6 (trunk)
on Cygwin 1.7. The compiler itself builds correctly, but
when I run it on even the simplest input, e.g.
gcc in.c -o a.exe
with in.c = int main() {}, no executable file is created.
No oputput is created even with the -S and -E options.
The same used to happen with GCC 4.5 experimental
in its early development days, but later started to work
again. Is it a known issue of GCC or Cygwin? Has
anyone managed to get a working 4.6 build on Cygwin?
Wasn't it last time because you didn't have --disable-sjlj-exceptions in
your configure command and so you ended up with sjlj-based DLLs that didn't
play nicely with the Cygwin distro's DW2-based ones? Sorry, that setting
still isn't defaulted on for Cygwin targets yet; it should be, and I'll make a
note to fix it.
cheers,
DaveK
Re: No output files on 4.6/Cygwin
Dave, Are you sure you're picking up the newest version of cyggcc_s-1.dll (and all the other language runtimes) that got built with the compiler, rather than the standard system one(s)? How can I check that? You did a full make install and put the new $prefix/bin (if not using the standard prefix) at the head of your PATH? Yes: export PATH=/opt/gcc-trunk/bin/:$PATH Wasn't it last time because you didn't have --disable-sjlj-exceptions in your configure command and so you ended up with sjlj-based DLLs that didn't play nicely with the Cygwin distro's DW2-based ones? Yes, then it was the case. But doesn't my --enable-dwarf2-exceptions already imply --disable-sjlj-exceptions? It works with gcc-4.5. I've just updated my repo and will schedule a nightly build of trunk with configure settings taken from the bundled gcc4 compiler from Cygwin pack in order to see what will happen. Best regards Piotr Wyderski
Re: No output files on 4.6/Cygwin
On 09/06/2010 17:31, Piotr Wyderski wrote: Are you sure you're picking up the newest version of cyggcc_s-1.dll (and all the other language runtimes) that got built with the compiler, rather than the standard system one(s)? How can I check that? Well, verifying your path is correct should be sufficient. You did a full make install and put the new $prefix/bin (if not using the standard prefix) at the head of your PATH? Yes: export PATH=/opt/gcc-trunk/bin/:$PATH That should be fine then. Wasn't it last time because you didn't have --disable-sjlj-exceptions in your configure command and so you ended up with sjlj-based DLLs that didn't play nicely with the Cygwin distro's DW2-based ones? Yes, then it was the case. But doesn't my --enable-dwarf2-exceptions already imply --disable-sjlj-exceptions? It works with gcc-4.5. It does? I've never been aware of any such option; as far as I know, you have to disable sjlj exceptions, and there's no configure option to positively enable dw2 ones. I've just updated my repo and will schedule a nightly build of trunk with configure settings taken from the bundled gcc4 compiler from Cygwin pack in order to see what will happen. That's the simplest way to guarantee compatibility. cheers, DaveK
Re: externally_visible and resoultion file
Yes, this is also what I saw without plugin. I just wonder why v is linked with plugin if resolution file is not used to eliminate need of externally_visible attribute here. Probably because of the same linker-plugin bug that causes bar to be resolved. Just to make sure I understand the problem: - The IR file for a.c contains definitions for v and bar. - The linker identifies that both symbols are referenced from outside the LTO world (PREVAILING_DEF rather than PREVAILING_DEF_IRONLY), but gcc isn't (yet) reading that info from the resolution file. - WPA eliminates bar() and makes v static in the replacement object file. - There are still references to those symbols in b.o, which was compiled outside LTO. - The linker should be complaining about undefined symbols in both cases, but isn't (perhaps because it's still seeing defs left over from the IR files). The symbol bar has a value of 0, while the reference to v seems to have the right address. Is that about right? What you're expecting is a link-time error reporting both bar and v as undefined, right? -cary
Re: Vector subscription, register storage class
On Wed, 9 Jun 2010, Artem Shinkarov wrote:
It should be addressable, but register keyword disallows it. To solve
this problem I modify c-decl.c:start_decl like this:
I think that's too early, since you still want vector (explicitly
taking the address) to be rejected for a vector with register storage
class. I don't claim it's optimal, but Andrew Pinski's patch handles
marking vectors addressable even when they have the register storage
class.
But still I have an example that does not work:
struct vec_s {
vector short member;
};
int main () {
register struct vec_s v2;
v2.member[2] = 4;
return 0;
}
The question is should it work at all? And what would be the optimal
way to implement it?
If you allow subscripting register vectors, then surely this case should
work as well.
--
Joseph S. Myers
jos...@codesourcery.com
Re: license copyright patch to MELT for dual GPLv3+ GFDL1.2+
On Wed, Jun 09, 2010 at 12:11:01PM -0700, Mark Mitchell wrote:
I think that literate programming approaches (whether the full Knuth
version, or the more mild JavaDoc version, or auto-extraction of
command-line options or whatever) are valuable. RMS, based on my
communications with him, is less convinced that they are valuable. I
think he agrees that his opinions of the technical merits shouldn't
override a consensus opinion of the developers, but it does influence
how hard he wants to work on changing the licensing regime, and it is a
legitimately hard problem to solve.
Meanwhile, I think we should try to make use of the fact that RMS is
permitting auto-generated reference documentation (which I have been
instructed not to call a manual) using JavaDoc/Doxygen tools. If we use
those tools, and demonstrate their value, we're then in a stronger
position to say how generation of actual manuals is important.
What I don't understand is what is so special about Doxygen.
MELT is a lispy dialect, and is bootstrapped in the sense of being its
own tranlator.
Could you understand that for me Basile (who don't know doxygen's
internals), since I am MELT designer implementor, and since MELT
translator (i.e. the code generating C code from MELT source) has been
implemented by me Basile in MELT, it is much easier to implement MELT
documentation's generator in MELT than to patch Doxygen for that
purpose.
So why using Doxygen is permitted for documentation generation, while
using a GCC plugin or branch (this is what MELT is) is prohibited?
Could people understand at least my misunderstanding? Why generating
documentation with Doxygen (probably not a GNU, FSF copyrighted,
software like GCC is) is permitted, while generating the documentation
of a branch of GCC [=MELT] with itself, [MELT=] a branch or plugin of GCC is
prohibited?
Sorry, I don't understand the logic here. And I am not sure it is only a
cultural (I am French, not US American) or language issue (I am not a
native English speaker).
OF course, I don't claim that MELT documentation generating mode is as
powerful as complete as Doxygen. It is actally a very simple hack
(only generating .texi format) much less powerful than doxygen.
Please explain me why using Doxygen is permitted, while using a branch
of GCC is not permitted, to generate that same's branch documentation.
Sorry, I don't understand the logic.
Please also explain who should I contact, and how? Please also explain
how the GNU Emacs is generated. I guess it is by a software of the GNU
emacs package.
Cheers.
PS. What I probably did understand or at least guess, is that to be
permitted to redistribute the generated documention of MELT, I'll have
to wait many [dozens?] years. I probably will lose interest in GCC by
then, or perhaps even I'll be already dead (and perhaps RMS also, since
he is born in 1953, and I was born in 1959). I even could imagine that
GCC won't be very relevant by then (hint: the SIGPLAN programming
language award went to a C compiler which is free -at least for some
definition of free- but not GCC).
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: license copyright patch to MELT for dual GPLv3+ GFDL1.2+
Basile Starynkevitch wrote: Meanwhile, I think we should try to make use of the fact that RMS is permitting auto-generated reference documentation (which I have been instructed not to call a manual) using JavaDoc/Doxygen tools. If we use those tools, and demonstrate their value, we're then in a stronger position to say how generation of actual manuals is important. What I don't understand is what is so special about Doxygen. Basile, there's nothing special about Doxygen. It's just an example of a tool that generates cross-reference information. I think you can reasonably distinguish the kind of thing that comes out of JavaDoc or Doxygen from a manual. If you don't know what kind of output JavaDoc and Doxygen produce, please go read about them for a while and look at some examples. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: license copyright patch to MELT for dual GPLv3+ GFDL1.2+
On Wed, Jun 09, 2010 at 10:46:26PM +0200, Basile Starynkevitch wrote:
Please also explain who should I contact, and how? Please also explain
how the GNU Emacs is generated. I guess it is by a software of the GNU
emacs package.
Sorry for the typo, I mean
how the GNU emacs documentation is generated
GNU emacs has documentation annotations, like MELT has (I copied the
idea from Emacs)!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: Patch pinging
Still, we'll see... Apparently not :( Why not? At most, you just need not to make sure nothing ever send mail to people who think that kind of thing is bozoid... M
Re: license copyright patch to MELT for dual GPLv3+ GFDL1.2+
On Wed, Jun 09, 2010 at 01:57:03PM -0700, Mark Mitchell wrote:
Basile Starynkevitch wrote:
Meanwhile, I think we should try to make use of the fact that RMS is
permitting auto-generated reference documentation (which I have been
instructed not to call a manual) using JavaDoc/Doxygen tools. If we use
those tools, and demonstrate their value, we're then in a stronger
position to say how generation of actual manuals is important.
What I don't understand is what is so special about Doxygen.
Basile, there's nothing special about Doxygen. It's just an example of
a tool that generates cross-reference information. I think you can
reasonably distinguish the kind of thing that comes out of JavaDoc or
Doxygen from a manual. If you don't know what kind of output JavaDoc
and Doxygen produce, please go read about them for a while and look at
some examples.
I did read many doxygen generated documentation, and in my eyes, the
documentation generated by MELT is ofvery similar nature: also, the
cross-reference, inheritance, etc.
The MELT generated documentation was heavily inspired by what Emacs
Doxygen are doing.
So I still don't understand why generating cross-reference documentation
with Doxygen for C++ code is permitted, while generating cross-reference
documentation witb ÂMELT for MELT code is prohibited.
Did *you* have a tiny look at the documentation of MELT generated by MELT?
http://gcc.gnu.org/wiki/MELT%20tutorial?action=AttachFiledo=viewtarget=GCC-MELT--gcc-internals-snapshot.pdf
Cheers!
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basileatstarynkevitchdotnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: license copyright patch to MELT for dual GPLv3+ GFDL1.2+
Basile Starynkevitch wrote: So I still don't understand why generating cross-reference documentation with Doxygen for C++ code is permitted, while generating cross-reference documentation witb ÂMELT for MELT code is prohibited. As far as I know, nobody said that. http://gcc.gnu.org/wiki/MELT%20tutorial?action=AttachFiledo=viewtarget=GCC-MELT--gcc-internals-snapshot.pdf That contains much more than cross-reference documentation! -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: externally_visible and resoultion file
On Wed, Jun 9, 2010 at 7:43 PM, Cary Coutant ccout...@google.com wrote: Yes, this is also what I saw without plugin. I just wonder why v is linked with plugin if resolution file is not used to eliminate need of externally_visible attribute here. Probably because of the same linker-plugin bug that causes bar to be resolved. Just to make sure I understand the problem: - The IR file for a.c contains definitions for v and bar. - The linker identifies that both symbols are referenced from outside the LTO world (PREVAILING_DEF rather than PREVAILING_DEF_IRONLY), but gcc isn't (yet) reading that info from the resolution file. - WPA eliminates bar() and makes v static in the replacement object file. - There are still references to those symbols in b.o, which was compiled outside LTO. - The linker should be complaining about undefined symbols in both cases, but isn't (perhaps because it's still seeing defs left over from the IR files). The symbol bar has a value of 0, while the reference to v seems to have the right address. Is that about right? What you're expecting is a link-time error reporting both bar and v as undefined, right? That's correct. Richard. -cary
Re: Experimental Patchwork setup
On 06/09/2010 10:03 AM, Jeremy Kerr wrote: Hi Manuel, 2) Use the command-line patchwork client to update patch state when a patch is committed. People have done this with a git post-commit hook to update the state of the patch in patchwork; I'm not sure if svn has something equivalent. Yes it does. If you tell us how the git pots-commit hook works, we could try to implement a version for svn and GCC. This is what I've used for git: [...@pororo helloworld]$ cat .git/hooks/post-applypatch #!/bin/bash sha=$(git rev-parse HEAD) hash=$(git show $sha | pwparser --hash) pwclient update -s Accepted -c $sha -h $hash The hash would be different for git diff and svn diff due to the different headers. So, git people would have to add the hook themselves, while svn people could skip that step assuming that a centralized hook is running on the svn server. On the other hand, svn patch ids are not stable, for two reasons. The first is the (revision ) and (working tree) markers, which differ from the time the patch is made, to the time it is committed. These markers could be removed by pwparser using a simple regex. The second is that paths in svn patches are relative, so people can run svn diff from the GCC directory and get a different patch id than if they ran svn diff gcc. Certainly, we don't want to require svn people to run svn diff from the toplevel exclusively. So, maybe the commit hook would have to try removing common paths one by one and pass all the resulting hashes to pwclient... Paolo
Re: a typo in ira-emit.c?
On 06/09/2010 06:45 AM, Amker.Cheng wrote:
Hi :
I am studying ira right now, there is following code in change_loop
if (parent_allocno == NULL
|| REGNO (ALLOCNO_REG (parent_allocno)) == REGNO (original_reg))
{
if (internal_flag_ira_verbose 3 ira_dump_file)
fprintf (ira_dump_file, %i vs parent %i:,
ALLOCNO_HARD_REGNO (allocno),
ALLOCNO_HARD_REGNO (parent_allocno));
set_allocno_reg (allocno, create_new_reg (original_reg));
}
Is it possible that parent_allocno == NULL here? or the fprintf might broken.
Yes, I think it can be NULL in some complicated cases when a loop exit
edge comes not in the parent loop.
Re: a typo in ira-emit.c?
Yes, I think it can be NULL in some complicated cases when a loop exit edge comes not in the parent loop. By that, you mean the case an regno lives on edges which transfer between adjacent loops, and not lives in parent loop? So, the fprintf would access null pointer in this case. Thanks for explanation. -- Best Regards.
Re: Experimental Patchwork setup
Hi Paolo, The hash would be different for git diff and svn diff due to the different headers. The headers are not included in the hash. However, the filenames will need to be the same - patchwork expects '-p1' patches, but normalises the top-level directory. For example, at http://patchwork.ozlabs.org/patch/55140/ --- gcc/config/rs6000/e500.h(revision 160245) +++ gcc/config/rs6000/e500.h(working copy) The parser normalises this to: --- a/config/rs6000/e500.h +++ b/config/rs6000/e500.h which may or may not be what you want here (svn outputs -p0?). The only difficulty is that the parser does not specify an order for the files in a patch; I believe git orders the file changes alphabetically by filename, but svn does not. This may cause different hashes. Cheers, Jeremy
[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom
--- Comment #4 from ubizjak at gmail dot com 2010-06-09 06:27 ---
(In reply to comment #1)
It may be broken by revision 160394:
http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00307.html
The add-lea transformation doesn't even trigger in this testcase... You still
have normal add instruction with a flags clobber up to and including sched2
pass.
Later, compilation breaks in machine reorg pass with:
Program received signal SIGSEGV, Segmentation fault.
distance_non_agu_define (code=value optimized out, insn=0x718c2750,
operands=0x1298aa0) at ../../gcc-svn/trunk/gcc/config/i386/i386.c:13826
13826 if (insn != BB_HEAD (bb))
(gdb) l
13821 basic_block bb = BLOCK_FOR_INSN (insn);
13822 int distance = 0;
13823 df_ref *def_rec;
13824 enum attr_type insn_type;
13825
13826 if (insn != BB_HEAD (bb))
13827 {
13828 rtx prev = PREV_INSN (insn);
13829 while (prev distance LEA_SEARCH_THRESHOLD)
13830 {
It looks to me that bb is NULL, which isn't a good sign anyway.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
[Bug libstdc++/44475] New: bunch of warnings of second definition on osf
bash-4.1$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/jayk/libexec/gcc/alphaev67-dec-osf5.1/4.5.0/lto-wrapper Target: alphaev67-dec-osf5.1 Configured with: /home/jayk/src/gcc-4.5.0/configure -disable-nls -disable-bootstrap -with-gmp=/home/jayk -prefix=/home/jayk Thread model: posix gcc version 4.5.0 (GCC) bootstrap compiler I believe was: bash-4.1$ /home/jayk/bin/alphaev67-dec-osf5.1-gcc-4.3.5 -v Using built-in specs. Target: alphaev67-dec-osf5.1 Configured with: /home/jayk/src/gcc-4.3.5/configure -disable-nls -with-gmp=/home/jayk -prefix=/home/jayk Thread model: posix gcc version 4.3.5 (GCC) I'll build again without -disable-bootstrap. libtool: install: ranlib /home/jayk/lib/libstdc++.a ar: Warning: ignoring second definition of _ZNK9__gnu_cxx24__concurrence_lock_error4whatEv defined in archive ar: Warning: ignoring second definition of _ZNK9__gnu_cxx26__concurrence_unlock_error4whatEv defined in archive ar: Warning: ignoring second definition of _ZN9__gnu_cxx24__concurrence_lock_errorD1Ev defined in archive ar: Warning: ignoring second definition of _ZTVN9__gnu_cxx24__concurrence_lock_errorE defined in archive ar: Warning: ignoring second definition of _ZN9__gnu_cxx24__concurrence_lock_errorD0Ev defined in archive ar: Warning: ignoring second definition of _ZN9__gnu_cxx26__concurrence_unlock_errorD1Ev defined in archive ar: Warning: ignoring second definition of _ZTVN9__gnu_cxx26__concurrence_unlock_errorE defined in archive ar: Warning: ignoring second definition of _ZN9__gnu_cxx26__concurrence_unlock_errorD0Ev defined in archive ar: Warning: ignoring second definition of _ZN9__gnu_cxx13__scoped_lockD1Ev defined in archive ar: Warning: ignoring second definition of _ZTIN9__gnu_cxx26__concurrence_unlock_errorE defined in archive ar: Warning: ignoring second definition of _ZTIN9__gnu_cxx24__concurrence_lock_errorE defined in archive ar: Warning: ignoring second definition of _ZTSN9__gnu_cxx24__concurrence_lock_errorE defined in archive ar: Warning: ignoring second definition of _ZTSN9__gnu_cxx26__concurrence_unlock_errorE defined in archive ar: Warning: ignoring second definition of _ZNK9__gnu_cxx24__concurrence_lock_error4whatEv defined in archive ar: Warning: ignoring second definition of _ZNK9__gnu_cxx26__concurrence_unlock_error4whatEv defined in archive ar: Warning: ignoring second definition of _ZN9__gnu_cxx24__concurrence_lock_errorD1Ev defined in archive ar: Warning: ignoring second definition of _ZTVN9__gnu_cxx24__concurrence_lock_errorE defined in archive ar: Warning: ignoring second definition of _ZN9__gnu_cxx24__concurrence_lock_errorD0Ev defined in archive ar: Warning: ignoring second definition of _ZN9__gnu_cxx26__concurrence_unlock_errorD1Ev defined in archive ar: Warning: ignoring second definition of _ZTVN9__gnu_cxx26__concurrence_unlock_errorE defined in archive ar: Warning: ignoring second definition of _ZN9__gnu_cxx26__concurrence_unlock_errorD0Ev defined in archive ar: Warning: ignoring second definition of _ZTIN9__gnu_cxx26__concurrence_unlock_errorE defined in archive ar: Warning: ignoring second definition of _ZTIN9__gnu_cxx24__concurrence_lock_errorE defined in archive ar: Warning: ignoring second definition of _ZN9__gnu_cxx13__scoped_lockD1Ev defined in archive ar: Warning: ignoring second definition of _ZTSN9__gnu_cxx24__concurrence_lock_errorE defined in archive ar: Warning: ignoring second definition of _ZTSN9__gnu_cxx26__concurrence_unlock_errorE defined in archive ar: Warning: ignoring second definition of _ZNK9__gnu_cxx24__concurrence_lock_error4whatEv defined in archive ar: Warning: ignoring second definition of _ZNK9__gnu_cxx26__concurrence_unlock_error4whatEv defined in archive ar: Warning: ignoring second definition of _ZN9__gnu_cxx24__concurrence_lock_errorD1Ev defined in archive ar: Warning: ignoring second definition of _ZTVN9__gnu_cxx24__concurrence_lock_errorE defined in archive ar: Warning: ignoring second definition of _ZN9__gnu_cxx24__concurrence_lock_errorD0Ev defined in archive ar: Warning: ignoring second definition of _ZN9__gnu_cxx26__concurrence_unlock_errorD1Ev defined in archive ar: Warning: ignoring second definition of _ZTVN9__gnu_cxx26__concurrence_unlock_errorE defined in archive ar: Warning: ignoring second definition of _ZN9__gnu_cxx26__concurrence_unlock_errorD0Ev defined in archive ar: Warning: ignoring second definition of _ZTIN9__gnu_cxx26__concurrence_unlock_errorE defined in archive ar: Warning: ignoring second definition of _ZTIN9__gnu_cxx24__concurrence_lock_errorE defined in archive ar: Warning: ignoring second definition of _ZTSN9__gnu_cxx24__concurrence_lock_errorE defined in archive ar: Warning: ignoring second definition of _ZTSN9__gnu_cxx26__concurrence_unlock_errorE defined in archive ar: Warning: ignoring second definition of _ZNK9__gnu_cxx24__concurrence_lock_error4whatEv defined in archive ar: Warning: ignoring second definition of _ZNK9__gnu_cxx26__concurrence_unlock_error4whatEv defined in
[Bug c/44476] New: tclStrToD.c takes very long to compile (forever?)
I'll probably have to debug this myself..but compiling Tcl 8.5.8's tclStrToD.c on alphaev67-dec-osf5.1 takes an inordinately long time. I've left it running for many minutes. Everything else in Tcl compiled fairly rapidly, just this one file is going and going. I tried without optimizing too. gcc -c -O -mieee -Wall -fPIC -I. -I/home/jayk/src/tcl8.5.8/unix/../unix -I/home/jayk/src/tcl8.5.8/unix/../generic -I/home/jayk/src/tcl8.5.8/unix/../libtommath -DPACKAGE_NAME=\tcl\ -DPACKAGE_TARNAME=\tcl\ -DPACKAGE_VERSION=\8.5\ -DPACKAGE_STRING=\tcl\ 8.5\ -DPACKAGE_BUGREPORT=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DTCL_CFGVAL_ENCODING=\iso8859-1\ -DTCL_SHLIB_EXT=\.so\ -DTCL_CFG_OPTIMIZED=1 -DTCL_CFG_DEBUG=1 -DTCL_TOMMATH=1 -DMP_PREC=4 -DTCL_WIDE_INT_IS_LONG=1 -DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRTOL=1 -DHAVE_WAITPID=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1 -DTIME_WITH_SYS_TIME=1 -DHAVE_STRUCT_TM_TM_ZONE=1 -DHAVE_TM_ZONE=1 -DHAVE_GMTIME_R=1 -DHAVE_LOCALTIME_R=1 -DHAVE_MKTIME=1 -DHAVE_TM_GMTOFF=1 -DHAVE_TIMEZONE_VAR=1 -DHAVE_STRUCT_STAT_ST_BLKSIZE=1 -DHAVE_ST_BLKSIZE=1 -Dsocklen_t=int -DHAVE_INTPTR_T=1 -DHAVE_UINTPTR_T=1 -DNO_UNION_WAIT=1 -DHAVE_SIGNED_CHAR=1 -DHAVE_LANGINFO=1 -DHAVE_CHFLAGS=1 -DHAVE_SYS_IOCTL_H=1 -DUSE_FIONBIO=1 -DTCL_UNLOAD_DLLS=1 /home/jayk/src/tcl8.5.8/unix/../generic/tclStrToD.c bash-4.1$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/jayk/libexec/gcc/alphaev67-dec-osf5.1/4.5.0/lto-wrapper Target: alphaev67-dec-osf5.1 Configured with: /home/jayk/src/gcc-4.5.0/configure -disable-nls -disable-bootstrap -with-gmp=/home/jayk -prefix=/home/jayk Thread model: posix gcc version 4.5.0 (GCC) -- Summary: tclStrToD.c takes very long to compile (forever?) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jay dot krell at cornell dot edu GCC host triplet: alphaev67-dec-osf5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44476
[Bug c/44476] tclStrToD.c takes very long to compile (forever?)
--- Comment #1 from jay dot krell at cornell dot edu 2010-06-09 07:28 --- It is hung here: #0 0x0001206feb24 in __gmpn_invert_limb () #1 0x0001206fd9b0 in __gmpn_divrem_2 () #2 0x0001206f1f84 in __gmpn_divrem () #3 0x0001206d0e20 in mpfr_div () #4 0x0001206d27c4 in mpfr_const_pi_internal () I'm going to try rebuilding with gmp/mpfr/mpc in-tree (ie: with current gcc and without assembly). Which doesn't work with gmp 4.3.2 for a reason I didn't debug..I'll try 5.0.1.. I don't remember how I'd built gmp/mpfr/mpc, very possibly with native cc, possibly with the optimized assembly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44476
[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom
--- Comment #5 from ubizjak at gmail dot com 2010-06-09 07:46 --- Looking into it. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-09 07:46:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #37 from gcc at breakpoint dot cc 2010-06-09 07:50 --- Created an attachment (id=20873) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20873action=view) this fails to compile in -O2 with the fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #38 from gcc at breakpoint dot cc 2010-06-09 07:54 --- (In reply to comment #28) Please bootstrap and test this addition to e500.h /* When setting up caller-save slots (MODE == VOIDmode) ensure we allocate space for DFmode. Save gprs in the correct mode too. */ #define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \ (TARGET_E500_DOUBLE ((MODE) == VOIDmode || (MODE) == DFmode) \ ? DFmode \ : choose_hard_reg_mode ((REGNO), (NREGS), false)) Okay. Now I found something: inst/bin/powerpc-linux-gnuspe-gcc extract_chmLib.i -o extract_chmLib.S -S -O2 extract_chmLib.c: In function '_extract_callback': extract_chmLib.c:29: internal compiler error: in change_address_1, at emit-rtl.c:1954 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. extract_chmLib.i is attached. Adding -mfloat-gprs=single which avoids using 64bit gprs for double makes this go away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug fortran/44477] New: Sequential I/O with END FILE: File position should be at EoF
Based on http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/cfb5f9dca46d5114# After ENDFILE for non-streams, the current file position should be at the endfile record. Thus, running the program below with NAG gives: READ/WRITE attempted after ENDFILE on unit 10 Program terminated by I/O error on unit 10 (File=XXX,Formatted,Sequential) And with Pathf95: A WRITE operation is invalid if the file is positioned after the end-of-file. While with gfortran it simply runs. (Ditto for g95 and ifort.) [One could continue to do so as extension, but one should do so knowingly.] F2008: 9.8.3 ENDFILE statement Execution of an ENDFILE statement for a file connected for sequential access writes an endfile record as the next record of the file. The file is then positioned after the end file record, which becomes the last record of the file. If the file also may be connected for direct access, only those records before the endfile record are considered to have been written. Thus, only those records may be read during subsequent direct access connections to the file. After execution of an ENDFILE statement for a file connected for sequential access, a BACKSPACE or REWIND statement shall be used to reposition the file prior to execution of any data transfer input/output statement or ENDFILE statement. Execution of an ENDFILE statement for a file connected for stream access causes the terminal point of the file to become equal to the current file position. Only file storage units before the current position are considered to have been written; thus only those file storage units may be subsequently read. Subsequent stream output statements may be used to write further data to the file. Execution of an ENDFILE statement for a file that is connected but does not exist creates the file; if the file is connected for sequential access, it is created prior to writing the endfile record. !--- OPEN(10, FILE='XXX', FORM='FORMATTED', ACTION='WRITE', POSITION='REWIND') ENDFILE(10) write(10,*) 'aa' end -- Summary: Sequential I/O with END FILE: File position should be at EoF Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44477
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
--- Comment #3 from paolo dot carlini at oracle dot com 2010-06-09 08:27 --- Janis, this doesn't make sense to me, and for sure happens only with decimal. Can you have a look? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||janis187 at us dot ibm dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473
[Bug libstdc++/44475] bunch of warnings of second definition on osf
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-09 08:32 --- Rainer, can you help me on this? I don't even know how to categorize it, if it's purely an ar issue or what else, I think you know this target... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||ro at CeBiTec dot Uni- ||Bielefeld dot DE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44475
[Bug c/44476] tclStrToD.c takes very long to compile (forever?)
--- Comment #2 from jay dot krell at cornell dot edu 2010-06-09 08:42
---
Two line repro, no repro with 4.3.5, hangs with 4.5.0.
I'll rebuild the compiler though.
Seem like a gmp bug.
bash-4.1$ alphaev67-dec-osf5.1-gcc-4.3.5 -c 1.c
bash-4.1$ alphaev67-dec-osf5.1-gcc-4.5.0 -c 1.c
bash-4.1$ cat 1.c
double log (double );
int xTclDoubleDigits(void) { return log(10.0); }
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44476
[Bug libstdc++/43838] [4.4/4.5/4.6 Regression] Incorrect output from abi::__cxa_demangle
--- Comment #7 from paolo dot carlini at oracle dot com 2010-06-09 08:54
---
Non pre-processed testcase. Apparently some buffer is overflowed.
#include cxxabi.h
namespace abcdefgxyzzzabb
{
class Aaa { };
namespace klmn
{
class Baaa { };
}
}
namespace boost
{
namespace tuples
{
class null_type;
templatetypename T1 = null_type, typename T2 = null_type,
typename T3 = null_type, typename T4 = null_type,
typename T5 = null_type, typename T6 = null_type,
typename T7 = null_type, typename T8 = null_type,
typename T9 = null_type, typename T10 = null_type
struct tuple { };
}
}
int main()
{
int status = 0;
const char* mangled_name
= typeid(boost::tuples::tupleabcdefgxyzzzabb::Aaa,
abcdefgxyzzzabb::klmn::Baaa).name();
__builtin_printf(Mangled name:\n%s\n\n, mangled_name);
const char* dem_name = abi::__cxa_demangle(mangled_name, 0, 0, status);
if (0 == status)
__builtin_printf(Demangled name:\n\n%s\n\n, dem_name);
return 0;
}
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Summary|Incorrect output from |[4.4/4.5/4.6 Regression]
|abi::__cxa_demangle |Incorrect output from
||abi::__cxa_demangle
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #39 from harry dot he at freescale dot com 2010-06-09 08:59 --- Hi, Kyle Moffett, in testall.c, r9 is used by a register variable, however, in E500ABI guide, r9 should be used for parameter passing, this test case seems not reasonable. Harry He -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA
--- Comment #11 from jamborm at gcc dot gnu dot org 2010-06-09 09:02 --- (In reply to comment #10) (In reply to comment #9) (In reply to comment #8) I don't think you need flow-sensitivity. Basically when you have only aggregate uses (as in this case) Vectors are considered scalars in GCC. That is why the solutions described above work. then you only want to scalarize if the destination of the use is scalarized as well (to be able to copyprop out the aggregate copy). Well, that is what I thought until someone filed PR 43846. Hm, yes. But there you know that D.2464.m[0] = D.2473_20; D.2464.m[1] = D.2472_19; D.2464.m[2] = D.2471_18; *b_1(D) = D.2464; D.2464 will be dead after scalarization. If D.2464 was larger than just m, that would not necessarily be the case and we would still want to avoid the extra copies. However, I it is true that it would make sense to take grp_assignment_read into account only if the whole access subtree would end up with grp_unscalarized_data set to zero but that would require quite a rewrite of analyze_access_subtree and would not help in this case because grp_unscalarized_data is zero, the union is covered by scalar replacements. The real issue is that In the particular case of the current bug the aggregate remains live because of the load from va.v which we cannot scalarize(*). we determine this very late, in sra_modify_assign (right after the big comment) and in the most general form this can be determined only when we already have the whole access tree (so if we wanted to do this during analysis, we would have to scan the function body twice). Nevertheless, for scalar accesses that have scalar sub-accesses this is always true and it can be easily detected and so we can simply disallow them, like I wrote in comment #7. And disallow them always, since otherwise it would be easy to _add_ stuff to the function that is causing trouble now so that any heuristics is confused and decides to produce replacements. I'll submit a patch in a while. (*) we can scalarize this particular case if you manage to build a proper constructor from the elements - but that's probably a bit involved. Well, I don't think I want to implement that... but I am curious, would that actually lead to better (or even different) code if I placed something like that into the loop? And I also thought that in gimple, constructors only could have invariants in them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA
--- Comment #12 from jamborm at gcc dot gnu dot org 2010-06-09 09:05 --- (In reply to comment #11) D.2464.m[0] = D.2473_20; D.2464.m[1] = D.2472_19; D.2464.m[2] = D.2471_18; *b_1(D) = D.2464; D.2464 will be dead after scalarization. If D.2464 was larger than just m, that would not necessarily be the case and we would still want to avoid the extra copies. Of course this would be true only if the last assignment was *b_1(D) = D.2464.m; but the argument is the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
[Bug tree-optimization/44462] Redundant looping pure functions whose return value is dead are not optimized out
--- Comment #3 from rguenther at suse dot de 2010-06-09 09:10 --- Subject: Re: Redundant looping pure functions whose return value is dead are not optimized out On Tue, 8 Jun 2010, pinskia at gcc dot gnu dot org wrote: --- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-08 20:10 --- Why do we remove register LHS in DCE again? Because it reduces the amount of garbage produced by expand :). Which means the expander could drop it ... Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44462
[Bug target/34734] attribute((progmem)) not handled properly in C++ for AVRs
--- Comment #4 from mschulze at ivs dot cs dot ovgu dot de 2010-06-09
09:16 ---
I found a way to place data in program memory for C++ without producing the
annoying warnings. The trick is omiting __attribute__((__progmem__)) and
instead always use __attribute__((section(.progmem.something))) for placing
your data into a special section beginning with .progmem.. I tested this with
different avr-g++ compiler versions (3.4.4, 4.1.1, 4.2.1, 4.3.3, 4.4.0, and
4.4.3), and it always results in the desired behavior.
Example:
[mschu...@teeth tst]$ cat progmem.cpp
static char __attribute((section(.progmem.something))) str[]=program memory
data;
const char* test() {
return str;
}
[mschu...@teeth tst]$ /usr/bin/avr-g++ -Wall -mmcu=atmega1281 -c progmem.cpp
[mschu...@teeth tst]$ /usr/bin/avr-g++ --version
avr-g++ (GCC) 4.3.3
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[mschu...@teeth tst]$
Regards,
Michael
--
mschulze at ivs dot cs dot ovgu dot de changed:
What|Removed |Added
CC||mschulze at ivs dot cs dot
||ovgu dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34734
[Bug libstdc++/44413] inefficient code for std::string::compare on x86-64
--- Comment #6 from paolo at gcc dot gnu dot org 2010-06-09 09:16 --- Subject: Bug 44413 Author: paolo Date: Wed Jun 9 09:15:51 2010 New Revision: 160456 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160456 Log: 2010-06-09 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/44413 * include/ext/vstring_util.h (__vstring_utility::_S_compare): Simplify, just return -1, 0, 1. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/ext/vstring_util.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44413
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #40 from harry dot he at freescale dot com 2010-06-09 09:23 --- with my toolchain (From CodeSourcery, 4.4-78), o1test gives correct behavior with built-in flags(-te500v2), but wrong behaviors with -fcaller-saves -O -fno-omit-frame-pointer -fno-dce -fno-split-wide-types. Results are same even after I rebuilt the toolchain with the patch to e500.h. is there any tricks here? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug bootstrap/43170] gcc 4.5 20100218 bootstrap compare fails on os x 10.6
--- Comment #75 from iains at gcc dot gnu dot org 2010-06-09 09:27 --- Subject: Bug 43170 Author: iains Date: Wed Jun 9 09:27:04 2010 New Revision: 160457 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160457 Log: config: PR bootstrap/43170 * tls.m4 (GCC_CHECK_TLS): Add volatile qualifier to the test references. Move the main () test reference ahead of pthread_create(). Add a comment to explain the requirements of the test. libgomp: PR bootstrap/43170 * configure: Regenerate. libjava: PR bootstrap/43170 * configure: Regenerate. libmudflap: PR bootstrap/43170 * configure: Regenerate. libstdc++-v3: PR bootstrap/43170 * configure: Regenerate. Modified: trunk/config/ChangeLog trunk/config/tls.m4 trunk/libgomp/ChangeLog trunk/libgomp/configure trunk/libjava/ChangeLog trunk/libjava/configure trunk/libmudflap/ChangeLog trunk/libmudflap/configure trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43170
[Bug c/44476] tclStrToD.c takes very long to compile (forever?)
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-09 09:29 --- Please report it to mpfr developers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44476
[Bug target/44474] GCC inserts redundant test instruction due to incorrect clobber
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Component|c |target GCC target triplet||i?86-*-* x86_64-*-* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44474
[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
[Bug other/43838] [4.4/4.5/4.6 Regression] Incorrect output from abi::__cxa_demangle
--- Comment #8 from paolo dot carlini at oracle dot com 2010-06-09 09:37 --- Recategorizing as other (like 42230)... and maybe HJ is interested in playing a bit with this one too. -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com Component|libstdc++ |other http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43838
[Bug fastjar/28359] fastjar directory traversal problem
--- Comment #19 from jakub at gcc dot gnu dot org 2010-06-09 09:39 --- Created an attachment (id=20874) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20874action=view) CVE-2010-0831.patch Just for the record, the patch that went in leaves fastjar still vulnerable. The main issue is that tmp_buff isn't the current directory component, but current directory component with all previous directory component, so the .. and . tests will match only for the first component. https://launchpad.net/bugs/540575 has some patch, but it is very ugly and inefficient. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
[Bug c/44478] New: -Wunused- but-set-variable is incredible noisy in kernel builds
When building a Linux kernel the new default of having -Wunused-but-set-variable is incredibly noisy in kernel build. I get hundreds of new warnings from that. I looked at some of the circumstances and it's typically int var = VALUE; #ifdef SYMBOL if (do something) var = other value #endif with SYMBOL being undefined in this build. I don't think it's feasible to avoid the warning short of turning it off. I suspect other code bases will have the same problem. Can the warning be removed from -Wall please? -- Summary: -Wunused- but-set-variable is incredible noisy in kernel builds Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: andi-gcc at firstfloor dot org GCC host triplet: x86_64-linux GCC target triplet: x86_64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478
[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-09 09:49 --- I'm sure you are right, but I don't understand your explanation: even when SYMBOL is undefined, why no code actually uses (roughly speaking, reads) var? That's the point of the warning and your example doesn't seem to shed any special light on that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478
[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-09 09:53 ---
The warning is useful and can find (and already found) several real bugs e.g.
in gcc itself. Icc has similar warning.
If kernel has lots of useless code like that and doesn't wish to use this
warning, it can add -Wno-unused-but-set-{variable,parameter} to CFLAGS it uses.
Note that in the snippet you mentioned -Wunused would warn always, no matter
whether SYMBOL is defined or not. When it is not defined, var is unused (also
warned with 4.5 and earlier), when it is defined, var is only set but never
used.
I guess what you really mean is that kernel has lots of snippets that set some
variable to some value and then only conditionally (in #ifdef guarded code)
uses it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478
[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds
--- Comment #3 from andi-gcc at firstfloor dot org 2010-06-09 10:13 --- Sorry my example was not very good. Anyways this typically happens with #ifdefs, so the some ifdef path is actually using the variable, it's just not enabled in the current build. In theory the ifdefs could be put around the variables too, but it would increase the ifdef frequency a lot. Another case i've also seen is to use it as a dummy output variable of inline assembler, where the assembler is in a macro and it's sometimes used and sometimes not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478
[Bug rtl-optimization/43332] valgrind warns about using uninitialized variable with -fsched-pressure -fschedule-insns
--- Comment #7 from zsojka at seznam dot cz 2010-06-09 10:14 --- I have just finished bootstrap of r160198 with valgrind checking, the problem is no longer reproducible there. I am sorry for the delay, make check with valgrind checking takes about a month there (1.3GHz), bootstrap about a week... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43332
[Bug fortran/43040] Wrong decl for mathbuiltins - wrong code with LTO
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2010-06-09 10:18 --- Subject: Bug 43040 Author: fxcoudert Date: Wed Jun 9 10:17:56 2010 New Revision: 160459 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160459 Log: PR fortran/43040 * f95-lang.c (gfc_init_builtin_functions): Remove comment. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/f95-lang.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43040
[Bug fortran/43040] Wrong decl for mathbuiltins - wrong code with LTO
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2010-06-09 10:20 --- Checked that it is not an issue. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43040
[Bug c++/44473] iterators already defined for std::vector when using std::decimal
--- Comment #4 from redi at gcc dot gnu dot org 2010-06-09 10:22 --- (From update of attachment 20871) attachment's mimetype changed to text/plain -- redi at gcc dot gnu dot org changed: What|Removed |Added Attachment #20871|application/octet-stream|text/plain mime type|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44473
[Bug tree-optimization/44462] Redundant looping pure functions whose return value is dead are not optimized out
--- Comment #4 from hubicka at ucw dot cz 2010-06-09 10:29 --- Subject: Re: Redundant looping pure functions whose return value is dead are not optimized out Why do we remove register LHS in DCE again? Because it reduces the amount of garbage produced by expand :). Which means the expander could drop it ... This won't save us from not optimizing out functions returning void. They can be looping pure too (most of sanity checks are) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44462
[Bug bootstrap/44432] [boot with C++] configure does not check presence of host C++ compiler
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-06-09 10:32 --- Subject: Bug 44432 Author: amylaar Date: Wed Jun 9 10:32:23 2010 New Revision: 160460 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160460 Log: PR bootstrap/44432 * configure.ac: Before using ZW_PROG_COMPILER_DEPENDENCIES for C++, check that C++ compiler works. * configure: Regenerate. Modified: trunk/libcpp/ChangeLog trunk/libcpp/configure trunk/libcpp/configure.ac -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44432
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-09 10:40 --- Subject: Bug 42843 Author: amylaar Date: Wed Jun 9 10:40:28 2010 New Revision: 160461 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160461 Log: gcc: PR testsuite/42843 * gcc-plugin.h (int plugin_is_GPL_compatible): Declare as extern C. * doc/plugins.texi (Plugin license check): Update information on type of plugin_is_GPL_compatible. * Makefile.in (PLUGINCC): Define as $(COMPILER). (PLUGINCFLAGS): Define as $(COMPILER_FLAGS). gcc/testsuite: PR testsuite/42843 * gcc.dg/plugin/selfassign.c (pass_warn_self_assign): Use enumerator TV_NONE to initialize tv_id field. * g++.dg/plugin/selfassign.c (pass_warn_self_assign): Likewise. * gcc.dg/plugin/one_time_plugin.c (one_pass): Likewise. * g++.dg/plugin/dumb_plugin.c (pass_dumb_plugin_example): Likewise. Include toplev.h . * gcc.dg/plugin/finish_unit_plugin.c: Include cgraph.h. * g++.dg/plugin/attribute_plugin.c: Include toplev.h and plugin.h . * g++.dg/plugin/pragma_plugin.c: Include toplev.h . Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/doc/plugins.texi trunk/gcc/gcc-plugin.h trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/plugin/attribute_plugin.c trunk/gcc/testsuite/g++.dg/plugin/dumb_plugin.c trunk/gcc/testsuite/g++.dg/plugin/pragma_plugin.c trunk/gcc/testsuite/g++.dg/plugin/selfassign.c trunk/gcc/testsuite/gcc.dg/plugin/finish_unit_plugin.c trunk/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c trunk/gcc/testsuite/gcc.dg/plugin/selfassign.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug bootstrap/44432] [boot with C++] configure does not check presence of host C++ compiler
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-09 10:47 --- Fixed in trunk by revision 160460. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.6.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44432
[Bug testsuite/42843] --enable-build-with-cxx plugin tests fail
--- Comment #5 from amylaar at gcc dot gnu dot org 2010-06-09 10:49 --- Fixed in trunk by revision 160461. -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.5.0 4.6.0 |4.5.0 Known to work||4.6.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42843
[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds
--- Comment #4 from jakub at gcc dot gnu dot org 2010-06-09 10:52 ---
We don't warn on
void foo (void)
{
int dummy;
asm ( : =r (dummy));
}
- the use in the asm is considered as a use, not just set.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #4 from andi-gcc at firstfloor dot org 2010-06-09 10:55 --- I was told that the whopr link step would inherit the optimization flags from the build step. Is that not true? Here's a reduced test case with only a single input file (reduced too) gcc46 -O2 -fwhopr -c igmp.mini.i gcc46 -r -fwhopr igmp.mini.o -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #5 from andi-gcc at firstfloor dot org 2010-06-09 10:56 --- Created an attachment (id=20875) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20875action=view) reduced input file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug tree-optimization/44393] [4.5/4.6 Regression] ICE: verify_ssa failed: no immediate_use list with -Os -ftree-loop-distribution
--- Comment #5 from zsojka at seznam dot cz 2010-06-09 11:02 ---
The testcase also fails when it is changed to:
...
{
extern void *bar(void) __attribute__((malloc));
int **pp = bar(), *p = bar();
...
so there isn't any access through NULL pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44393
[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds
--- Comment #5 from andi-gcc at firstfloor dot org 2010-06-09 11:08 ---
Hmm yes there was another temporary and a inline inbetween
unsigned inlinefunc(void)
{
unsigned var;
asm( ... : =r (var));
return var;
}
#define macro(x,y)
{
unsigned var = inlinefunc();
x = var;
y = var 16;
};
caller macro(x,y) y is just a dummy
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478
[Bug tree-optimization/16427] dead 0 memset not optimized away
--- Comment #3 from andi-gcc at firstfloor dot org 2010-06-09 11:09 --- Jakub, for this example: how would you suggest to work around this warning? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16427
[Bug fastjar/28359] fastjar directory traversal problem
--- Comment #20 from marcus at jet dot franken dot de 2010-06-09 11:20 --- Jakubs patch looks good to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28359
[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA
--- Comment #13 from jamborm at gcc dot gnu dot org 2010-06-09 11:20 --- Subject: Bug 44423 Author: jamborm Date: Wed Jun 9 11:20:03 2010 New Revision: 160462 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160462 Log: 2010-06-09 Martin Jambor mjam...@suse.cz PR tree-optimization/44423 * tree-sra.c (dump_access): Dump also grp_assignment_read. (analyze_access_subtree): Pass negative allow_replacements to children if the current type is scalar. * testsuite/gcc.dg/tree-ssa/pr44423.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr44423.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
[Bug regression/40886] [4.3/4.4 Regression] No loop counter reversal for simple loops anymore
--- Comment #16 from andi-gcc at firstfloor dot org 2010-06-09 11:21 --- I don't need a backport to 4.4 and I double checked it works as expected in gcc 4.5. Closing. -- andi-gcc at firstfloor dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40886
[Bug lto/44464] ICE during linux kernel whopr build
-- andi-gcc at firstfloor dot org changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug rtl-optimization/44479] New: false dependencies are computed after vectorization
When compiling function:
void xxx(short* __restrict__ a, short* __restrict__ b)
{
int i;
for (i = 0; i 8; i++)
{
a[i] = b[i];
}
}
before sched2 we have:
(note 13 12 14 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 14 13 15 3 ./a.c:6 (set (reg:SI 2 cx [orig:106 *vect_p.14_18 ] [106])
(mem:SI (reg/v/f:SI 1 dx [orig:103 b ] [103]) [2 *vect_p.14_18+0 S4
A32])) 44 {*movsi_1} (expr_list:REG_EQUIV (mem:SI (reg/v/f:SI 1 dx [orig:103 b
] [103]) [2 *vect_p.14_18+0 S4 A32])
(nil)))
(insn 15 14 18 3 ./a.c:6 (set (mem:SI (reg/v/f:SI 0 ax [orig:102 a ] [102]) [2
*vect_p.18_24+0 S4 A32])
(reg:SI 2 cx [orig:106 *vect_p.14_18 ] [106])) 44 {*movsi_1}
(expr_list:REG_DEAD (reg:SI 2 cx [orig:106 *vect_p.14_18 ] [106])
(nil)))
(insn 18 15 19 3 ./a.c:6 (set (reg:SI 2 cx [orig:107 *vect_p.22_11 ] [107])
(mem:SI (plus:SI (reg/v/f:SI 1 dx [orig:103 b ] [103])
(const_int 4 [0x4])) [2 *vect_p.22_11+0 S4 A32])) 44 {*movsi_1}
(expr_list:REG_EQUIV (mem:SI (plus:SI (reg/v/f:SI 1 dx [orig:103 b ] [103])
(const_int 4 [0x4])) [2 *vect_p.22_11+0 S4 A32])
(nil)))
(insn 19 18 20 3 ./a.c:6 (set (mem:SI (plus:SI (reg/v/f:SI 0 ax [orig:102 a ]
[102])
(const_int 4 [0x4])) [2 *vect_p.27_12+0 S4 A32])
(reg:SI 2 cx [orig:107 *vect_p.22_11 ] [107])) 44 {*movsi_1}
(expr_list:REG_DEAD (reg:SI 2 cx [orig:107 *vect_p.22_11 ] [107])
(nil)))
insn 15 is a store and 18 is a load from a different location (two different
restrict pointers). These insns should not have a dependency between them but
we can see in sched2 that they do have:
;; ==
;; -- basic block 3 from 14 to 62 -- after reload
;; ==
;; --- forward dependences:
;; --- Region Dependences --- b 3 bb 0
;; insn codebb dep prio cost reservation
;; -- --- ---
;; 1444 3 018 4 decodern,p2 : 62 25 24 23 19 18 15
;; 1544 3 114 1 decoder0,(p4+p3): 62 61 24 22
18
;; 1844 3 214 4 decodern,p2 : 62 24 22 19
;; 1944 3 210 1 decoder0,(p4+p3): 62 61 22
;; 2244 3 310 4 decodern,p2 : 62 24 23
;; 2344 3 2 6 1 decoder0,(p4+p3): 62 61
;; 2444 3 410 4 decodern,p2 : 62 25
;; 2544 3 2 6 1 decoder0,(p4+p3): 62 61
;; 6141 3 4 6 3 decoder0,(p2+(p0|p1)) : 62
;; 62 477 3 9 6 6 decoder0:
Using built-in specs.
COLLECT_GCC=./xgcc
Target: i386-elf-linux
Configured with: ../gcc-4.6-20100605/configure --target=i386-elf-linux
--enable-languages=c
Thread model: posix
gcc version 4.6.0 20100605 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-O3' '-fsched-verbose=10' '-fno-ivopts' '-fdump-rtl-all'
'-v' '-save-temps' '-mtune=i386' '-march=i386'
cc1 -E -quiet -v -iprefix ./../lib/gcc/i386-elf-linux/4.6.0/ ./a.c -mtune=i386
-march=i386 -fsched-verbose=10 -fno-ivopts -fdump-rtl-all -O3 -fpch-preprocess
-o a.i
ignoring nonexistent directory ./../lib/gcc/i386-elf-linux/4.6.0/include
ignoring nonexistent directory
./../lib/gcc/i386-elf-linux/4.6.0/include-fixed
ignoring nonexistent directory
./../lib/gcc/i386-elf-linux/4.6.0/../../../../i386-elf-linux/sys-include
ignoring nonexistent directory
./../lib/gcc/i386-elf-linux/4.6.0/../../../../i386-elf-linux/include
ignoring nonexistent directory
./../lib/gcc/../../lib/gcc/i386-elf-linux/4.6.0/include
ignoring nonexistent directory
./../lib/gcc/../../lib/gcc/i386-elf-linux/4.6.0/include-fixed
ignoring nonexistent directory
./../lib/gcc/../../lib/gcc/i386-elf-linux/4.6.0/../../../../i386-elf-linux/sys-include
ignoring nonexistent directory
./../lib/gcc/../../lib/gcc/i386-elf-linux/4.6.0/../../../../i386-elf-linux/include
#include ... search starts here:
#include ... search starts here:
End of search list.
COLLECT_GCC_OPTIONS='-O3' '-fsched-verbose=10' '-fno-ivopts' '-fdump-rtl-all'
'-v' '-save-temps' '-mtune=i386' '-march=i386'
cc1 -fpreprocessed a.i -quiet -dumpbase a.c -mtune=i386 -march=i386 -auxbase a
-O3 -version -fsched-verbose=10 -fno-ivopts -fdump-rtl-all -o a.s
GNU C (GCC) version 4.6.0 20100605 (experimental) (i386-elf-linux)
compiled by GNU C version 4.1.2 20080704 (Red Hat 4.1.2-44), GMP
version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C (GCC) version 4.6.0 20100605 (experimental) (i386-elf-linux)
compiled by GNU C version 4.1.2 20080704 (Red Hat 4.1.2-44), GMP
version 4.3.2, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 70c36ceb949c29da0fad8309ce635380
COLLECT_GCC_OPTIONS='-O3'
[Bug rtl-optimization/44479] false dependencies are computed after vectorization
--- Comment #1 from roy dot 1rosen at gmail dot com 2010-06-09 11:28 --- Created an attachment (id=20876) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20876action=view) preprocessed file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44479
[Bug c/44478] -Wunused- but-set-variable is incredible noisy in kernel builds
--- Comment #6 from jakub at gcc dot gnu dot org 2010-06-09 11:36 --- Then it has nothing to do with the asm. If the macro is widely used and very often sets a var that isn't used, all you can do is add (void) cast to shut the warning up. (void) (y = var 16); in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44478
[Bug bootstrap/44299] Bootstrap broken for cygwin and mingw targets
--- Comment #5 from ktietz at gcc dot gnu dot org 2010-06-09 11:53 --- Fixed by patch at revision 159965. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44299
[Bug rtl-optimization/44479] false dependencies are computed after vectorization
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-09 11:56 --- I will have a look at some point. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-09 11:56:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44479
[Bug regression/40886] [4.3/4.4 Regression] No loop counter reversal for simple loops anymore
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.0.0 |4.0.0 4.3.5 4.4.3 Target Milestone|4.3.6 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40886
[Bug tree-optimization/16427] dead memset not optimized away
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-06-09 11:59 --- It's now optimized by RTL DSE but we keep the stack allocated. Re-confirmed on the tree-level. Should be easy to extend DSE to handle this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-10-22 22:17:10 |2010-06-09 11:59:50 date|| Summary|dead 0 memset not optimized |dead memset not optimized |away|away http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16427
[Bug fortran/43685] libgfortran: Consider using __int128
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2010-06-09 12:01 --- I don't understand what you mean by that: currently, we have the following typedefs on platforms which support a 128-bit int type: typedef __int128_t GFC_INTEGER_16; typedef __uint128_t GFC_UINTEGER_16; I don't think it changes anything to put __int128 instead of __int128_t. This is a special case anyway, because other kinds use the stdint.h name: int8_t, int16_t, int32_t and int64_t. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43685
[Bug tree-optimization/44423] [4.5/4.6 Regression] Massive performance regression in SSE code due to SRA
--- Comment #14 from martin at mpa-garching dot mpg dot de 2010-06-09 12:06 --- SSE performance is fine again, thanks a lot! One more question, if that's OK... Depending on ARRSZ the testcase uses wildly varying amounts of CPU time; it's about half a second for ARRSZ=1024, but almost 10 seconds for ARRSZ=20 on my machine, which is extremely strange because the operation count is the same in both cases. I suspect that something weird is happening with respect to the cache and prefetching. Should I open another PR for this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44423
[Bug fortran/43710] suspicious string comparisons
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2010-06-09 12:07 --- Hey, I actually have the answer to this one: yes, it is intended as is, and not, it is a bit more complicated that Jerry says. We maintain a hash table of identifiers, so that when we have multiple times the same string, it's always allocated only once. See how gfc_get_string works, especially the comment at the top: /* Given printf-like arguments, return a stable version of the result string. We already have a working, optimized string hashing table in the form of the identifier table. Reusing this table is likely not to be wasted, since if the function name makes it to the gimple output of the frontend, we'll have to create the identifier anyway. */ The other, extra-nice benefits of these are 1. we do not have to compare strings, but simply pointers; 2. we don't have to worry about releasing memory on a per-case basis. As such, I'm closing this PR. If you think the analysis is incorrect, please reopen. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43710
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-09 12:08 --- (In reply to comment #4) I was told that the whopr link step would inherit the optimization flags from the build step. Is that not true? That's not true. Here's a reduced test case with only a single input file (reduced too) gcc46 -O2 -fwhopr -c igmp.mini.i gcc46 -r -fwhopr igmp.mini.o Thanks. Confirmed (also with -flto). Program received signal SIGSEGV, Segmentation fault. 0x00a196e8 in var_map_base_init (map=0x16479c0) at /space/rguenther/src/svn/trunk/gcc/tree-ssa-live.c:87 87if (!ann-base_var_processed) (gdb) p ann $1 = (var_ann_t) 0x0 probably not too hard to track down. The decl is a PARM_DECL and not registered with referenced vars. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-09 12:08:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-06-09 12:15 ---
Actually - we seem to get IPA SRA parm repacements done but the original
parameter SSA names are not released.
(gdb) call debug_function (cfun-decl, 0)
igmp_mc_get_next (unnamed type * ISRA.14, struct ip_mc_list * ISRA.15)
{
struct ip_mc_list * im;
(gdb) call debug_generic_expr ($5)
im_1
Martin - can you have a look?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|rguenth at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug bootstrap/44470] [4.6 Regression] Failed to bootstrap with - -with-arch=atom
--- Comment #6 from ubizjak at gmail dot com 2010-06-09 12:15 ---
Following patch is also needed to fix conditional splitting (it does not fix
original uncovered problem where BLOCK_FOR_INSN returns null):
Index: i386.md
===
--- i386.md (revision 160445)
+++ i386.md (working copy)
@@ -6087,8 +6087,15 @@
switch (get_attr_type (insn))
{
case TYPE_LEA:
- return #;
+ if (reload_completed ix86_lea_for_add_ok (PLUS, insn, operands))
+return #;
+ gcc_assert (rtx_equal_p (operands[0], operands[2]));
+ if (x86_maybe_negate_const_int (operands[1], MODEmode))
+return sub{imodesuffix}\t{%1, %0|%0, %1};
+
+ return add{imodesuffix}\t{%1, %0|%0, %1};
+
case TYPE_INCDEC:
gcc_assert (rtx_equal_p (operands[0], operands[1]));
if (operands[2] == const1_rtx)
@@ -6138,8 +6145,14 @@
switch (get_attr_type (insn))
{
case TYPE_LEA:
- return #;
+ if (reload_completed ix86_lea_for_add_ok (PLUS, insn, operands))
+return #;
+ if (x86_maybe_negate_const_int (operands[1], SImode))
+return sub{l}\t{%1, %k0|%k0, %1};
+
+ return add{l}\t{%1, %k0|%k0, %1};
+
case TYPE_INCDEC:
if (operands[2] == const1_rtx)
return inc{l}\t%k0;
@@ -6222,8 +6235,15 @@
switch (get_attr_type (insn))
{
case TYPE_LEA:
- return #;
+ if (reload_completed ix86_lea_for_add_ok (PLUS, insn, operands))
+return #;
+ gcc_assert (rtx_equal_p (operands[0], operands[2]));
+ if (x86_maybe_negate_const_int (operands[1], HImode))
+return sub{w}\t{%1, %0|%0, %1};
+
+ return add{w}\t{%1, %0|%0, %1};
+
case TYPE_INCDEC:
gcc_assert (rtx_equal_p (operands[0], operands[1]));
if (operands[2] == const1_rtx)
@@ -6313,8 +6333,22 @@
switch (get_attr_type (insn))
{
case TYPE_LEA:
- return #;
+ if (reload_completed ix86_lea_for_add_ok (PLUS, insn, operands))
+return #;
+ gcc_assert (rtx_equal_p (operands[0], operands[2]));
+ if (x86_maybe_negate_const_int (operands[1], QImode))
+ {
+ if (widen)
+ return sub{l}\t{%1, %k0|%k0, %1};
+ else
+ return sub{b}\t{%1, %0|%0, %1};
+ }
+ if (widen)
+return add{l}\t{%k1, %k0|%k0, %k1};
+ else
+return add{b}\t{%1, %0|%0, %1};
+
case TYPE_INCDEC:
gcc_assert (rtx_equal_p (operands[0], operands[1]));
if (operands[2] == const1_rtx)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44470
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #8 from rguenth at gcc dot gnu dot org 2010-06-09 12:16 --- CC'ing martin even. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #9 from andi-gcc at firstfloor dot org 2010-06-09 12:16 --- Unfortunate. Fixing that in the makefiles would be major effort for all the -f and -m flags, which sometimes vary by target. I thought LTO was designed to minimize makefile changes? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #10 from andi-gcc at firstfloor dot org 2010-06-09 12:18 --- The tree input that leads to the NULL annotation is a error_mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug fortran/43685] libgfortran: Consider using __int128
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-09 12:41 --- Close as WONTFIX. The int128 changes still do not offer to enter the integer directly (instead of using 123L with shifts) And one issue was fixed as part of http://gcc.gnu.org/viewcvs?view=revisionrevision=157407 (in libgfortran.h). -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43685
[Bug bootstrap/44469] [4.5/4.6 Regression] internal compiler error: in fixup_reorder_chain, at cfglayout.c:797
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-09 12:51 --- I guess for empty bbs with no successor where the predecessor ends in an conditional jump without side-effects try_optimize_cfg can't do just delete_basic_block, but needs to call some function to actually adjust the conditional jump into unconditional. Perhaps try_redirect_by_replacing_jump or something similar. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44469
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #11 from rguenth at gcc dot gnu dot org 2010-06-09 13:01 --- (In reply to comment #10) The tree input that leads to the NULL annotation is a error_mark Not for me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-06-09 13:03 --- (In reply to comment #9) Unfortunate. Fixing that in the makefiles would be major effort for all the -f and -m flags, which sometimes vary by target. I thought LTO was designed to minimize makefile changes? Yes. But you want to be able to have different optimizations at compile/link time. Also we would need to start on how to automagically merge different settings at compile-time ... Well - option handling is still an awkward area. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #41 from amodra at gmail dot com 2010-06-09 13:26 --- Created an attachment (id=20877) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20877action=view) e500.h and caller-save.c patch The ICE in #38 is due to a bug in caller-save.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug lto/44464] ICE during linux kernel whopr build
--- Comment #13 from andi-gcc at firstfloor dot org 2010-06-09 13:35 --- What happens then when some files need different options that other files? This sounds more and more like a showstopper if you're right. I was not prepared to redesign the Makefiles -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44464
