Problems with acats test suite not being run?
I noticed on http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02488.html (trunk revision 153541) that the acats test suite was not run... and looking into acats.log I see this: compilation abandoned /usr/local/src/trunk/objdir/gcc/testsuite/ada/acats/support/checkfil.ada: parse errors detected /usr/local/src/trunk/objdir/gcc/testsuite/ada/acats/support/checkfil.ada: chop may not be successful /usr/local/src/trunk/objdir/gcc/testsuite/ada/acats/support/checkfil.ada: error parsing offset info no compilation units found no source files written now, updating the tree (trunk revision 153546) I still get the same situation... Looking back., for me (trunk revision 153534) worked, http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02451.html. Anyone else seeing this? -- Cheers, /ChJ
Re: when (not) use bugzilla for GCC?
Joseph S. Myers wrote:
On Sun, 25 Oct 2009, Basile STARYNKEVITCH wrote:
I cannot understand when should I use or not bugzilla. More precisely, I have
several examples of bugs but I didn't use bugzilla for them
A big thanks to your reply. However, you did not answer to my example 1.
J.Pitrat's MALICE system on
http://pagesperso-orange.fr/jacques.pitrat/MALICE.html
The point is that I cannot reduce that example, because it is almost
3000 usually small files of generated C (totalizing 370865 lines or
13862311 bytes) like eg its TRIPLETS2.c file which contains
#include dx.h
void TRIPLETS2(void )
/*generated C source file TRIPLETS2.c of the CAIA system - Copyright
Jacques Pitrat 2009 - GPLv3 license. See COPYING3*/
{int N;
int NNNE;
int WZ1,WZ2,WZ3,WZ4,WZ5;
int jvj;
jvj=v[0];
v[0]+=11;
x[jvj+1]=26199;z[jvj+1]=(-100);
if(v[0]99700) (*f[6])();
if(v[90]==2441v[97]==0) {
(*f[4])();x[jvj+1]=incon;v[0]=jvj;return;
}
N=pile[v[22]];NNNE=pile[v[22]+1];v[22]+=2;
WZ5=v[22]+5;WZ4=v[22]+4;WZ3=v[22]+3;WZ2=v[22]+2;WZ1=v[22]+1;
x[jvj+2]=0;z[jvj+2]=0;
pile[v[22]]=100;pile[WZ1]=20;pile[WZ2]=101;pile[WZ3]=29;pile[WZ4]=jvj+4;
(*f[175])(); /*QUADRI2(100,20,101,29,jvj+4)*/
pile[WZ1]=41;pile[WZ2]=130;pile[WZ3]=N;pile[WZ4]=jvj+8;
(*f[256])(); /*QUADRI7(100,41,130,N,jvj+8)*/
pile[WZ1]=21;pile[WZ2]=140;pile[WZ3]=(-632);pile[WZ4]=jvj+9;
(*f[255])(); /*QUADRI6(100,21,140,(-632),jvj+9)*/
pile[WZ1]=41;pile[WZ2]=130;pile[WZ3]=0;pile[WZ4]=jvj+11;
(*f[256])(); /*QUADRI7(100,41,130,0,jvj+11)*/
pile[v[22]]=jvj+9;pile[WZ1]=111;pile[WZ2]=jvj+10;
(*f[68])(); /*TRI4(jvj+9,111,jvj+10)*/
pile[v[22]]=100;pile[WZ1]=484;pile[WZ2]=102;pile[WZ3]=jvj+11;pile[WZ4]=jvj+10;pile[WZ5]=jvj+6;
(*f[254])(); /*QUADRI5(100,484,102,jvj+11,jvj+10,jvj+6)*/
pile[v[22]]=jvj+4;pile[WZ1]=111;pile[WZ2]=jvj+5;
(*f[68])(); /*TRI4(jvj+4,111,jvj+5)*/
pile[v[22]]=jvj+5;pile[WZ1]=jvj+6;pile[WZ2]=103;pile[WZ3]=jvj+7;
(*f[58])(); /*TRI2(jvj+5,jvj+6,103,jvj+7)*/
pile[v[22]]=100;pile[WZ1]=22;pile[WZ2]=102;pile[WZ3]=jvj+8;pile[WZ4]=jvj+7;pile[WZ5]=jvj+3;
(*f[254])(); /*QUADRI5(100,22,102,jvj+8,jvj+7,jvj+3)*/
pile[v[22]]=jvj+2;pile[WZ1]=jvj+3;
(*f[503])(); /*PLUB2(jvj+2,jvj+3)*/
x[NNNE]=x[jvj+2];z[NNNE]=z[jvj+2];
l1:x[jvj+1]=incon;v[0]=jvj;v[22]-=2;return;
}
Every such C file starts with #include dx.h and dx.h itself includes
some system headers stdio.h ctype.h signal.h dlfcn.h time.h
unistd.h sys/mman.h errno.h stdlib.h
and declare nearly 3000 functions like
void TRANSFORMC0(void ); and also a dozen arrays like int sk[201][401];
int tu[60]; short int ts[60];
As you can see, the C source file above is not human-understandable. It
is generated. And there are almost three thousand files like this.
I am definitely not able to reduce that to a smaller example.
For what it is worth, MALICE is a reflexive constraint solving system.
It manages it own stacks. I think that v[22] is used as a top of
argument stack index into pile[] used as its argument stack, and I was
hoping that with -flto -O2, gcc could perhaps share a little better that
index.
Are you suggesting me to upload to bugzilla the nearly 3000 preprocessed
forms of the files? I could do that, but the *.i files totalize more
than one gigabyte. A bzip2 compressed tar archive of them is almost
80Mbytes.
I was trying to compile that stuff with
gcc-trunk -flto -O2 [A-Z]*.c -rdynamic -ldl -o malice
and there is a sigsegv in the lto2 process. I don't even know how to
debug that (just how to start in the gdb debugger the lto process with
the correct invocation).
I agree that this example is perhaps contrived or at least unusual, but
LTO bugs probably all involve several files (that what is LTO about),
and there are situations where reducing an example to something
manageable is not easy. I was with the intuition that this MALICE
example should be compilable by LTO. It is not that big by today's
standards (it is at least 10 times smaller than GCC). And the sigsegv
does not occur when memory is rare (I have 8Gb RAM and not all of it is
used when lto crashes.).
3. On the MELT branch, I regularily find bugs correct them, and it did
happen that someone registered a MELT bug on the bugzilla; I did correct it
but AFAIR was not permitted to close the bug. Sometimes I am sad of not being
able to report MELT bugs on bugzilla and to close them when I feel I have
covered them.
Log in to Bugzilla with your gcc.gnu.org address to get access to close
bugs, add versions and milestones, etc.
Did I understand correctly that GCC bugzilla treats magically the
*...@gcc.gnu.org email adresses matching accounts usable for SVN write
access? This is great news!
Regards.
--
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: enable-build-with-cxx bootstrap compare broken by r149964
Hi!
Just some random comments:
On Sat, Oct 24, 2009 at 12:10:52AM -0400, Jerry Quinn wrote:
+ if (mark_private)
+{
+ /* Inject '*' at beginning of name to force pointer comparison.
*/
+ char* buf = (char*) XNEWVEC (char, length + 1);
+ buf[0] = '*';
+ memcpy (buf + 1, name, length);
+ name_string = build_string (length + 1, buf);
+ XDELETEVEC (buf);
You could as well use XALLOCAVEC (char, length + 1) and remove
XDELETEVEC. No need to cast the result of XNEWVEC or XALLOCAVEC to
char *. And, the formatting is wrong, space goes after char, no space
between * and buf.
/* Generate the NTBS array variable. */
tree name_type = build_cplus_array_type
(build_qualified_type (char_type_node, TYPE_QUAL_CONST),
NULL_TREE);
-tree name_string = tinfo_name (target);
+//tree name_string = tinfo_name (target);
This should be removed, rather than commented out.
@@ -2921,10 +2893,6 @@
name_base = obstack_alloc (name_obstack, 0);
}
-/* Done with mangling. If WARN is true, and the name of G.entity will
- be mangled differently in a future version of the ABI, issue a
- warning. */
-
static void
finish_mangling_internal (const bool warn)
{
Why are you removing the comment?
@@ -3011,18 +2979,15 @@
SET_DECL_ASSEMBLER_NAME (decl, id);
}
-/* Generate the mangled representation of TYPE for the typeinfo name.
*/
+/* Generate the mangled representation of TYPE. */
const char *
-mangle_type_string_for_rtti (const tree type)
+mangle_type_string (const tree type)
Why this change?
bool operator==(const type_info __arg) const
{
return ((__name == __arg.__name)
- || __builtin_strcmp (__name, __arg.__name) == 0);
+ || (__name[0] != '*' __arg.__name[0] != '*'
+ __builtin_strcmp (__name, __arg.__name) == 0));
I see no point in both tests for * here, just __name[0] != '*'
should be enough (or __arg.__name[0] != '*'). If one string starts with *
and the other doesn't, strcmp will return non-0.
--- libstdc++-v3/libsupc++/tinfo.cc (revision 153489)
+++ libstdc++-v3/libsupc++/tinfo.cc (working copy)
@@ -41,7 +41,9 @@
#if __GXX_MERGED_TYPEINFO_NAMES
return name () == arg.name ();
#else
- return (arg == this) || (__builtin_strcmp (name (), arg.name ()) ==
0);
+ return (arg == this)
+|| (name ()[0] != '*' arg.name ()[0] != '*'
+ (__builtin_strcmp (name (), arg.name ()) == 0));
#endif
}
Likewise.
Jakub
Re: Problems with acats test suite not being run?
2009/10/26 Christian Joensson christian.joens...@gmail.com: I noticed on http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02488.html (trunk revision 153541) that the acats test suite was not run... and looking into acats.log I see this: compilation abandoned /usr/local/src/trunk/objdir/gcc/testsuite/ada/acats/support/checkfil.ada: parse errors detected /usr/local/src/trunk/objdir/gcc/testsuite/ada/acats/support/checkfil.ada: chop may not be successful /usr/local/src/trunk/objdir/gcc/testsuite/ada/acats/support/checkfil.ada: error parsing offset info no compilation units found no source files written now, updating the tree (trunk revision 153546) I still get the same situation... Looking back., for me (trunk revision 153534) worked, http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02451.html. well, problem disappeared with a clean build, instead of a rebuild/bubblestrap... perhaps long string with configure information spooked the whole thing, no idea.. -- Cheers, /ChJ
Re: enable-build-with-cxx bootstrap compare broken by r149964
On 10/26/2009 07:14 AM, Jakub Jelinek wrote: -/* Generate the mangled representation of TYPE for the typeinfo name. */ +/* Generate the mangled representation of TYPE. */ const char * -mangle_type_string_for_rtti (const tree type) +mangle_type_string (const tree type) Why this change? This change is part of reverting my earlier fake namespace patch. I agree with Jakub's other comments, though. Jason
Re: when (not) use bugzilla for GCC?
Basile STARYNKEVITCH bas...@starynkevitch.net writes: Are you suggesting me to upload to bugzilla the nearly 3000 preprocessed forms of the files? I could do that, but the *.i files totalize more than one gigabyte. A bzip2 compressed tar archive of them is almost 80Mbytes. That is a difficulty, but without a self-contained test case it's pretty hard to fix the bug. You can try reporting the bug with a URL for where to download the sources. Since LTO is fairly new a maintainer may be willing to download them and try it. Otherwise, go ahead and upload that 80M tar ball. gcc.gnu.org will cope. Did I understand correctly that GCC bugzilla treats magically the *...@gcc.gnu.org email adresses matching accounts usable for SVN write access? This is great news! Yes, that is how it works. Ian
Re: when (not) use bugzilla for GCC?
On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor i...@google.com wrote: Basile STARYNKEVITCH bas...@starynkevitch.net writes: Are you suggesting me to upload to bugzilla the nearly 3000 preprocessed forms of the files? I could do that, but the *.i files totalize more than one gigabyte. A bzip2 compressed tar archive of them is almost 80Mbytes. That is a difficulty, but without a self-contained test case it's pretty hard to fix the bug. You can try reporting the bug with a URL for where to download the sources. Since LTO is fairly new a maintainer may be willing to download them and try it. Otherwise, go ahead and upload that 80M tar ball. gcc.gnu.org will cope. Please don't. Bi-sect the list of object files by adding -r -nostdlib to the link line. This should result in a two or three file testcase. Either attach those or reduce them with delta. Richard.
Re: when (not) use bugzilla for GCC?
Richard Guenther wrote:
On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor i...@google.com wrote:
Basile STARYNKEVITCH bas...@starynkevitch.net writes:
Are you suggesting me to upload to bugzilla the nearly 3000
preprocessed forms of the files? I could do that, but the *.i files
totalize more than one gigabyte. A bzip2 compressed tar archive of
them is almost 80Mbytes.
That is a difficulty, but without a self-contained test case it's
pretty hard to fix the bug. You can try reporting the bug with a URL
for where to download the sources. Since LTO is fairly new a
maintainer may be willing to download them and try it. Otherwise, go
ahead and upload that 80M tar ball. gcc.gnu.org will cope.
Please don't. Bi-sect the list of object files by adding -r -nostdlib
to the link line. This should result in a two or three file testcase.
Either attach those or reduce them with delta.
I am not sure to understand what that means technically.
The sisegv is gotten by running
gcc -flto -O2 [A-Z]*.c -rdynamic -ldl -o malice-lto
where the [A-Z]*.c file glob pattern expand to nearly 3000 files.
Exactly those from
http://pagesperso-orange.fr/jacques.pitrat/malice-2009.tar.bz2
What command to you suggest me to run? How will I find the faulty files...
Regards.
--
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: when (not) use bugzilla for GCC?
On Mon, Oct 26, 2009 at 3:39 PM, Basile STARYNKEVITCH bas...@starynkevitch.net wrote: Richard Guenther wrote: On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor i...@google.com wrote: Basile STARYNKEVITCH bas...@starynkevitch.net writes: Are you suggesting me to upload to bugzilla the nearly 3000 preprocessed forms of the files? I could do that, but the *.i files totalize more than one gigabyte. A bzip2 compressed tar archive of them is almost 80Mbytes. That is a difficulty, but without a self-contained test case it's pretty hard to fix the bug. You can try reporting the bug with a URL for where to download the sources. Since LTO is fairly new a maintainer may be willing to download them and try it. Otherwise, go ahead and upload that 80M tar ball. gcc.gnu.org will cope. Please don't. Bi-sect the list of object files by adding -r -nostdlib to the link line. This should result in a two or three file testcase. Either attach those or reduce them with delta. I am not sure to understand what that means technically. The sisegv is gotten by running gcc -flto -O2 [A-Z]*.c -rdynamic -ldl -o malice-lto where the [A-Z]*.c file glob pattern expand to nearly 3000 files. Exactly those from http://pagesperso-orange.fr/jacques.pitrat/malice-2009.tar.bz2 What command to you suggest me to run? How will I find the faulty files... See the LTO section in http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction Richard.
Re: No c++0x threads using win32 threading model (with MinGW-w64)
On Tue, Sep 8, 2009 at 2:38 PM, Heiko Harders heiko.hard...@gmail.com wrote: Hello, (first of all: sorry to post this message to a second list, I've sent it to the wrong list at first) I am using g++ in MinGW-w64 running in a Windows environment. I'm especially interested in the c++0x threads because it allows standard cross-platform multi-threading. Unfortunately I didn't get this to work (using a very recent Mingw-w64 snapshot that uses gcc 4.5.0). I did some research and I think I found out why. Perhaps somebody on this list could confirm this and/or answer some of the questions I have about the win32 threading model. First of all, the c++0x threads don't seem to work because in the `thread' header file the file `gthr.h' is included, which includes in turn some threading model specific files (like `gthr_posix.h'). While the header `gthr_win32.h' does exist, it is not included from `gthr.h'. The comments in `gthr.h' further mention support for several threading models, but the win32 threading model is not amongst these. Am I looking in the right direction for reasons why the c++0x threads do not work with the win32 threading model? If the above is correct: is support for win32 c++0x threads being worked on at the moment? If that is the case, any indication when it will be in a usable state? What must be undertaken to implement this support? I hope somebody can give me some insight in these questions. Regards, Heiko Adding Kai and gcc-help to this email.
RFC: allowing fold to change location of args (PR/41451)
Hi folks. In this PR the problem is that a call to fold_build2_loc() returns one of the original arguments unchanged. In the code below we take this result and change its location before returning it. tem = fold_build2_loc (loc, code, type, fold_convert_loc (loc, TREE_TYPE (op0), TREE_OPERAND (arg0, 1)), op1); protected_set_expr_location (tem, loc); When --enable-checking=fold, fold verifies that none of the arguments changed, which in this case it obviously does. Would be ok to allow a TREE_EXP's location to change within fold? That is, add locus (for TREE_EXP's) to the list of allowed changeable fields in fold_checksum_tree()? Aldy
Some GCC porting questions
Hi all, I'd have two questions needed for work on porting gcc-3.2.3. 1. How can I tell from the RTL declaration of a function if it is declared INLINE of not? 2. Where is the code responsible for allocating those variables on the stack which don't fit in registers (needed to fix debug info generation)? Thanks in advance. Best regards, Alpar
Re: RFC: allowing fold to change location of args (PR/41451)
On Mon, Oct 26, 2009 at 4:39 PM, Aldy Hernandez al...@redhat.com wrote: Hi folks. In this PR the problem is that a call to fold_build2_loc() returns one of the original arguments unchanged. In the code below we take this result and change its location before returning it. tem = fold_build2_loc (loc, code, type, fold_convert_loc (loc, TREE_TYPE (op0), TREE_OPERAND (arg0, 1)), op1); protected_set_expr_location (tem, loc); When --enable-checking=fold, fold verifies that none of the arguments changed, which in this case it obviously does. Would be ok to allow a TREE_EXP's location to change within fold? That is, add locus (for TREE_EXP's) to the list of allowed changeable fields in fold_checksum_tree()? Why? It looks like the above should already take care of the correct location via passing loc to fold_build2_loc. Richard.
Re: RFC: allowing fold to change location of args (PR/41451)
? ? ?tem = fold_build2_loc (loc, code, type, ? ? ? ? ? ? ? ? ? ? ? ? ? ? fold_convert_loc (loc, TREE_TYPE (op0), ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TREE_OPERAND (arg0, 1)), op1); ? ? ?protected_set_expr_location (tem, loc); When --enable-checking=fold, fold verifies that none of the arguments changed, which in this case it obviously does. Would be ok to allow a TREE_EXP's location to change within fold? ?That is, add locus (for TREE_EXP's) to the list of allowed changeable fields in fold_checksum_tree()? Why? It looks like the above should already take care of the correct location via passing loc to fold_build2_loc. The correct location is being passed. The problem is that in the testcase in question, we modify the original statement (with the new locus). Modifying the original statement is a no no in fold_checksum_tree. We have two options: a) Allow locus changes in fold_checksum_tree. b) Fix fold-const throughout to make a copy of the result of fold_build* calls if we're about to change it's location-- in case fold is returning any of the original arguments. IMO (b) is too inefficient when we can easily do (a). Aldy
Re: RFC: allowing fold to change location of args (PR/41451)
On Mon, Oct 26, 2009 at 9:37 AM, Aldy Hernandez al...@redhat.com wrote: We have two options: a) Allow locus changes in fold_checksum_tree. b) Fix fold-const throughout to make a copy of the result of fold_build* calls if we're about to change it's location-- in case fold is returning any of the original arguments. IMO (b) is too inefficient when we can easily do (a). Except (b) is correct as fold should not be modifiying the tree at all. That is the whole point of fold_checksum_tree. We allow some things to change like TYPE_VARIANTs and such but we should not allow a huge change like changing the locus on a statement inside fold. Thanks, Andrew Pinski
Re: RFC: allowing fold to change location of args (PR/41451)
On Mon, Oct 26, 2009 at 5:37 PM, Aldy Hernandez al...@redhat.com wrote: ? ? ?tem = fold_build2_loc (loc, code, type, ? ? ? ? ? ? ? ? ? ? ? ? ? ? fold_convert_loc (loc, TREE_TYPE (op0), ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TREE_OPERAND (arg0, 1)), op1); ? ? ?protected_set_expr_location (tem, loc); When --enable-checking=fold, fold verifies that none of the arguments changed, which in this case it obviously does. Would be ok to allow a TREE_EXP's location to change within fold? ?That is, add locus (for TREE_EXP's) to the list of allowed changeable fields in fold_checksum_tree()? Why? It looks like the above should already take care of the correct location via passing loc to fold_build2_loc. The correct location is being passed. The problem is that in the testcase in question, we modify the original statement (with the new locus). Modifying the original statement is a no no in fold_checksum_tree. That wasn't my question. tem = fold_build2_loc (loc, code, type, fold_convert_loc (loc, TREE_TYPE (op0), TREE_OPERAND (arg0, 1)), op1); protected_set_expr_location (tem, loc); here tem is built by calling fold_build2_loc. So why is the location of tem not loc after that. This sounds like the actual bug (and the protected_set_expr_location should be redundant). Richard.
Re: RFC: allowing fold to change location of args (PR/41451)
That wasn't my question.
tem = fold_build2_loc (loc, code, type,
fold_convert_loc (loc, TREE_TYPE (op0),
TREE_OPERAND (arg0, 1)), op1);
protected_set_expr_location (tem, loc);
here tem is built by calling fold_build2_loc. So why is the location
of tem not loc after that. This sounds like the actual bug
(and the protected_set_expr_location should be redundant).
Indeed, the culprit is fold_convert_loc which is not setting the location.
OK for trunk pending tests?
PR bootstrap/41451
* fold-const.c (fold_convert_loc): Return a new node if all we're
going to change is the location.
(fold_binary_loc): Do not call protected_set_expr_location if
unecessary.
Index: fold-const.c
===
--- fold-const.c(revision 153549)
+++ fold-const.c(working copy)
@@ -2635,7 +2635,13 @@ fold_convert_loc (location_t loc, tree t
tree tem;
if (type == orig)
-return arg;
+{
+ if (!CAN_HAVE_LOCATION_P (arg) || EXPR_LOCATION (arg) == loc)
+ return arg;
+ arg = copy_node (arg);
+ SET_EXPR_LOCATION (arg, loc);
+ return arg;
+}
if (TREE_CODE (arg) == ERROR_MARK
|| TREE_CODE (type) == ERROR_MARK
@@ -10134,7 +10140,6 @@ fold_binary_loc (location_t loc,
tem = fold_build2_loc (loc, code, type,
fold_convert_loc (loc, TREE_TYPE (op0),
TREE_OPERAND (arg0, 1)), op1);
- protected_set_expr_location (tem, loc);
tem = build2 (COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0), tem);
goto fold_binary_exit;
}
@@ -10144,7 +10149,6 @@ fold_binary_loc (location_t loc,
tem = fold_build2_loc (loc, code, type, op0,
fold_convert_loc (loc, TREE_TYPE (op1),
TREE_OPERAND (arg1, 1)));
- protected_set_expr_location (tem, loc);
tem = build2 (COMPOUND_EXPR, type, TREE_OPERAND (arg1, 0), tem);
goto fold_binary_exit;
}
Re: Problems with acats test suite not being run?
On Mon, 2009-10-26 at 12:57 +0100, Christian Joensson wrote: 2009/10/26 Christian Joensson christian.joens...@gmail.com: I noticed on http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02488.html (trunk revision 153541) that the acats test suite was not run... and looking into acats.log I see this: compilation abandoned /usr/local/src/trunk/objdir/gcc/testsuite/ada/acats/support/checkfil.ada: parse errors detected /usr/local/src/trunk/objdir/gcc/testsuite/ada/acats/support/checkfil.ada: chop may not be successful /usr/local/src/trunk/objdir/gcc/testsuite/ada/acats/support/checkfil.ada: error parsing offset info no compilation units found no source files written now, updating the tree (trunk revision 153546) I still get the same situation... Looking back., for me (trunk revision 153534) worked, http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02451.html. well, problem disappeared with a clean build, instead of a rebuild/bubblestrap... perhaps long string with configure information spooked the whole thing, no idea.. Both 153543 and 153546 worked fine on gcc13 autotester: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02489.html http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02514.html Laurent
Re: when (not) use bugzilla for GCC?
Ian Lance Taylor wrote:
Basile STARYNKEVITCH bas...@starynkevitch.net writes:
Did I understand correctly that GCC bugzilla treats magically the
*...@gcc.gnu.org email adresses matching accounts usable for SVN write
access? This is great news!
Yes, that is how it works.
May I respectfully suggest to the person maintaining the bugzilla a
notice in the login page saying something like:
GCC maintainers having write after approval (or better) access to the
GCC trunk should preferably login with their xx...@gcc.gnu.org email
Regards.
--
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: when (not) use bugzilla for GCC?
Basile STARYNKEVITCH bas...@starynkevitch.net writes: May I respectfully suggest to the person maintaining the bugzilla a notice in the login page saying something like: GCC maintainers having write after approval (or better) access to the GCC trunk should preferably login with their xx...@gcc.gnu.org email Good idea, but nobody maintains bugzilla these days, at least beyond the bare minimum of taking a look if something breaks. If anybody wants to tackle this and knows what to do, let me know. Ian
Re: RFC: allowing fold to change location of args (PR/41451)
On Mon, Oct 26, 2009 at 6:28 PM, Aldy Hernandez al...@redhat.com wrote:
That wasn't my question.
tem = fold_build2_loc (loc, code, type,
fold_convert_loc (loc, TREE_TYPE (op0),
TREE_OPERAND (arg0, 1)), op1);
protected_set_expr_location (tem, loc);
here tem is built by calling fold_build2_loc. So why is the location
of tem not loc after that. This sounds like the actual bug
(and the protected_set_expr_location should be redundant).
Indeed, the culprit is fold_convert_loc which is not setting the location.
OK for trunk pending tests?
Certainly better. But I fail to see why a different location would be
better than the original here. I assume all tokens have a correct initial
location. Then why is for example for int i; in (int) i the location of
the conversion a better location than the one of i in the folded result?
Thus, why not throw protected_set_expr_location in the bit-bucket
completely?
Richard.
PR bootstrap/41451
* fold-const.c (fold_convert_loc): Return a new node if all we're
going to change is the location.
(fold_binary_loc): Do not call protected_set_expr_location if
unecessary.
Index: fold-const.c
===
--- fold-const.c (revision 153549)
+++ fold-const.c (working copy)
@@ -2635,7 +2635,13 @@ fold_convert_loc (location_t loc, tree t
tree tem;
if (type == orig)
- return arg;
+ {
+ if (!CAN_HAVE_LOCATION_P (arg) || EXPR_LOCATION (arg) == loc)
+ return arg;
+ arg = copy_node (arg);
+ SET_EXPR_LOCATION (arg, loc);
+ return arg;
+ }
if (TREE_CODE (arg) == ERROR_MARK
|| TREE_CODE (type) == ERROR_MARK
@@ -10134,7 +10140,6 @@ fold_binary_loc (location_t loc,
tem = fold_build2_loc (loc, code, type,
fold_convert_loc (loc, TREE_TYPE (op0),
TREE_OPERAND (arg0, 1)), op1);
- protected_set_expr_location (tem, loc);
tem = build2 (COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0), tem);
goto fold_binary_exit;
}
@@ -10144,7 +10149,6 @@ fold_binary_loc (location_t loc,
tem = fold_build2_loc (loc, code, type, op0,
fold_convert_loc (loc, TREE_TYPE (op1),
TREE_OPERAND (arg1, 1)));
- protected_set_expr_location (tem, loc);
tem = build2 (COMPOUND_EXPR, type, TREE_OPERAND (arg1, 0), tem);
goto fold_binary_exit;
}
Re: RFC: allowing fold to change location of args (PR/41451)
Certainly better. But I fail to see why a different location would be better than the original here. I assume all tokens have a correct initial location. Then why is for example for int i; in (int) i the location of the conversion a better location than the one of i in the folded result? I don't care either way. OK pending tests? PR bootstrap/41451 * fold-const.c (fold_binary_loc): Do not call protected_set_expr_location. Index: fold-const.c === --- fold-const.c(revision 153549) +++ fold-const.c(working copy) @@ -10134,7 +10134,6 @@ fold_binary_loc (location_t loc, tem = fold_build2_loc (loc, code, type, fold_convert_loc (loc, TREE_TYPE (op0), TREE_OPERAND (arg0, 1)), op1); - protected_set_expr_location (tem, loc); tem = build2 (COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0), tem); goto fold_binary_exit; } @@ -10144,7 +10143,6 @@ fold_binary_loc (location_t loc, tem = fold_build2_loc (loc, code, type, op0, fold_convert_loc (loc, TREE_TYPE (op1), TREE_OPERAND (arg1, 1))); - protected_set_expr_location (tem, loc); tem = build2 (COMPOUND_EXPR, type, TREE_OPERAND (arg1, 0), tem); goto fold_binary_exit; }
Re: RFC: allowing fold to change location of args (PR/41451)
On Mon, Oct 26, 2009 at 10:42 PM, Aldy Hernandez al...@redhat.com wrote: Certainly better. But I fail to see why a different location would be better than the original here. I assume all tokens have a correct initial location. Then why is for example for int i; in (int) i the location of the conversion a better location than the one of i in the folded result? I don't care either way. OK pending tests? Ok. Thanks, Richard. PR bootstrap/41451 * fold-const.c (fold_binary_loc): Do not call protected_set_expr_location. Index: fold-const.c === --- fold-const.c (revision 153549) +++ fold-const.c (working copy) @@ -10134,7 +10134,6 @@ fold_binary_loc (location_t loc, tem = fold_build2_loc (loc, code, type, fold_convert_loc (loc, TREE_TYPE (op0), TREE_OPERAND (arg0, 1)), op1); - protected_set_expr_location (tem, loc); tem = build2 (COMPOUND_EXPR, type, TREE_OPERAND (arg0, 0), tem); goto fold_binary_exit; } @@ -10144,7 +10143,6 @@ fold_binary_loc (location_t loc, tem = fold_build2_loc (loc, code, type, op0, fold_convert_loc (loc, TREE_TYPE (op1), TREE_OPERAND (arg1, 1))); - protected_set_expr_location (tem, loc); tem = build2 (COMPOUND_EXPR, type, TREE_OPERAND (arg1, 0), tem); goto fold_binary_exit; }
Re: -use-linker-plugin passed to ld
On Fri, 23 Oct 2009, Ian Lance Taylor wrote: Steven Bosscher stevenb@gmail.com writes: I was just wondering why this is not a -f* flag, e.g. -fuse-linker-plugin? Any opinions on the best user interface for this? The color that spells -fuse-linker-plugin seems better, in line with other options. How it's implemented, especially regarding having to ignore it in middle-end is unimportant wrt. spelling, IMVHO. brgds, H-P
Testsuite regular expression question
I am looking at a failure of gcc.dg/debug/dwarf2/inline2.c on IA64
HP-UX. The problem I have is with the assembler scan:
/* { dg-final { scan-assembler-times byte.*?0x3.*? DW_AT_inline 3 } } */
IA64 HP-UX is using 'data1' instead of 'byte' in the output. Now that
should be easy to fix and if I change the string to:
/* { dg-final { scan-assembler-times data1.*?0x3.*? DW_AT_inline 3 } } */
I do get this test to pass. But other systems are using 'byte' so of
course I need to allow for either byte or data1. I have tried:
/* { dg-final { scan-assembler-times (byte|data1).*?0x3.*? DW_AT_inline 3 } }
*/
/* { dg-final { scan-assembler-times (byte\|data1).*?0x3.*? DW_AT_inline 3 }
} */
/* { dg-final { scan-assembler-times \(byte\|data1\).*?0x3.*? DW_AT_inline 3
} } */
And various other escapes, parenthesis, etc but cannot get any of them
to work. Does anyone know what this RE should look like to allow 'byte'
or 'data1' in the string? It seems to break as soon as I introduce
parenthesis anywhere in the RE.
Steve Ellcey
s...@cup.hp.com
Re: Some GCC porting questions
palpar palpa...@gmail.com writes: 1. How can I tell from the RTL declaration of a function if it is declared INLINE of not? You have to look at the tree decl, at DECL_DECLARED_INLINE_P. 2. Where is the code responsible for allocating those variables on the stack which don't fit in registers (needed to fix debug info generation)? Look for calls to assign_stack_temp, assign_temp, and friends. Ian
Re: -use-linker-plugin passed to ld
On Mon, Oct 26, 2009 at 06:10:06PM -0400, Hans-Peter Nilsson wrote: On Fri, 23 Oct 2009, Ian Lance Taylor wrote: Steven Bosscher stevenb@gmail.com writes: I was just wondering why this is not a -f* flag, e.g. -fuse-linker-plugin? Any opinions on the best user interface for this? The color that spells -fuse-linker-plugin seems better, in line with other options. How it's implemented, especially regarding having to ignore it in middle-end is unimportant wrt. spelling, IMVHO. I agree with H-P. -- Daniel Jacobowitz CodeSourcery
undefined reference to `gt_pch_nx_tree_code'
Hi, I am writing a new pass for gcc that uses the GTY markers, 1. I have included the source file in GTFILES_H in gcc/Makefile.in. 2. I have the gt-path.h mentioned in the compilation for source file 3. I have the #include gt-path.h at the very end of the code of source file. I see the gt-path.h is getting created in the build/gcc directory. But I am getting the below error. Is there something I am missing in the Makefile, I tried to look at a similar example of tree-mudflap.c that uses GTY markers, I do not see any difference in the steps I have followed. I havent done gcc dev before, so I'd really appreciate any help in this regard. main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -lmpfr -lgmp -rdynamic -ldl libbackend.a(gtype-desc.o): In function `gt_ggc_m_P9tree_code4htab': /home/aravinda/svnbuild/gcc/gtype-desc.c:1968: undefined reference to `gt_ggc_mx_tree_code' libbackend.a(gtype-desc.o): In function `gt_pch_n_P9tree_code4htab': /home/aravinda/svnbuild/gcc/gtype-desc.c:4133: undefined reference to `gt_pch_nx_tree_code' collect2: ld returned 1 exit status make[3]: *** [cc1-dummy] Error 1 Thanks, Aravinda
[Bug fortran/41714] [OOP] ALLOCATE SOURCE= does not properly copy the value from SOURCE
--- Comment #8 from janus at gcc dot gnu dot org 2009-10-26 09:08 --- Subject: Bug 41714 Author: janus Date: Mon Oct 26 09:08:03 2009 New Revision: 153547 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153547 Log: 2009-10-26 Janus Weil ja...@gcc.gnu.org PR fortran/41714 * gimple.h (tree_annotate_all_with_location): Remove prototype. * gimplify.c (tree_should_carry_location_p, tree_annotate_one_with_location,tree_annotate_all_with_location): Remove obsolete functions. 2009-10-26 Janus Weil ja...@gcc.gnu.org PR fortran/41714 * trans.c (gfc_trans_code): Remove call to 'tree_annotate_all_with_location'. Location should already be set. * trans-openmp.c (gfc_trans_omp_workshare): Ditto. * trans-stmt.c (gfc_trans_allocate): Do correct data initialization for CLASS variables with SOURCE tag, plus some cleanup. 2009-10-26 Janus Weil ja...@gcc.gnu.org PR fortran/41714 * gfortran.dg/class_allocate_4.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/class_allocate_4.f03 Modified: trunk/gcc/ChangeLog trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-openmp.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans.c trunk/gcc/gimple.h trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41714
[Bug fortran/41714] [OOP] ALLOCATE SOURCE= does not properly copy the value from SOURCE
--- Comment #9 from janus at gcc dot gnu dot org 2009-10-26 09:13 --- Fixed with r153547. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41714
[Bug fortran/41827] New: [Cleanup] Remove SET_EXPR_LOCATION in gfc_trans_code
At the end of gfc_trans_code one finds the following:
gfc_set_backend_locus (code-loc);
if (res != NULL_TREE ! IS_EMPTY_STMT (res))
{
if (TREE_CODE (res) != STATEMENT_LIST)
SET_EXPR_LOCATION (res, input_location);
/* Add the new statement to the block. */
gfc_add_expr_to_block (block, res);
}
}
/* Return the finished block. */
return gfc_finish_block (block);
}
In principle the call to SET_EXPR_LOCATION should not be needed here, since the
location should already be set correctly at this point; cf. the discussion in
http://gcc.gnu.org/ml/fortran/2009-10/msg00205.html
and follow-ups. However, this patch
Index: gcc/fortran/trans.c
===
--- gcc/fortran/trans.c (Revision 153547)
+++ gcc/fortran/trans.c (Arbeitskopie)
@@ -1281,9 +1281,6 @@ gfc_trans_code (gfc_code * code)
if (res != NULL_TREE ! IS_EMPTY_STMT (res))
{
- if (TREE_CODE (res) != STATEMENT_LIST)
- SET_EXPR_LOCATION (res, input_location);
-
/* Add the new statement to the block. */
gfc_add_expr_to_block (block, res);
}
yields (at least) the following regressions:
FAIL: gfortran.dg/gomp/appendix-a/a.24.1.f90 -O (test for errors, line 20)
FAIL: gfortran.dg/gomp/appendix-a/a.24.1.f90 -O (test for errors, line 14)
FAIL: gfortran.dg/gomp/appendix-a/a.24.1.f90 -O (test for errors, line 20)
FAIL: gfortran.dg/gomp/appendix-a/a.24.1.f90 -O (test for excess errors)
FAIL: gfortran.dg/gomp/appendix-a/a.35.1.f90 -O (test for warnings, line 13)
FAIL: gfortran.dg/gomp/appendix-a/a.35.1.f90 -O (test for excess errors)
FAIL: gfortran.dg/gomp/appendix-a/a.35.3.f90 -O (test for warnings, line 10)
FAIL: gfortran.dg/gomp/appendix-a/a.35.3.f90 -O (test for excess errors)
FAIL: gfortran.dg/gomp/appendix-a/a.35.4.f90 -O (test for warnings, line 11)
FAIL: gfortran.dg/gomp/appendix-a/a.35.4.f90 -O (test for excess errors)
FAIL: gfortran.dg/gomp/appendix-a/a.35.6.f90 -O (test for warnings, line 9)
FAIL: gfortran.dg/gomp/appendix-a/a.35.6.f90 -O (test for excess errors)
FAIL: gfortran.dg/gomp/block-1.f90 -O (test for errors, line 5)
FAIL: gfortran.dg/gomp/block-1.f90 -O (test for excess errors)
FAIL: gfortran.dg/gomp/crayptr3.f90 -O (test for errors, line 19)
FAIL: gfortran.dg/gomp/crayptr3.f90 -O (test for errors, line 20)
FAIL: gfortran.dg/gomp/crayptr3.f90 -O (test for excess errors)
FAIL: gfortran.dg/gomp/pr33439.f90 -O (test for errors, line 8)
FAIL: gfortran.dg/gomp/pr33439.f90 -O (test for errors, line 10)
FAIL: gfortran.dg/gomp/pr33439.f90 -O (test for errors, line 21)
FAIL: gfortran.dg/gomp/pr33439.f90 -O (test for errors, line 22)
FAIL: gfortran.dg/gomp/pr33439.f90 -O (test for errors, line 33)
FAIL: gfortran.dg/gomp/pr33439.f90 -O (test for excess errors)
FAIL: gfortran.dg/gomp/sharing-1.f90 -O (test for errors, line 12)
FAIL: gfortran.dg/gomp/sharing-1.f90 -O (test for errors, line 24)
FAIL: gfortran.dg/gomp/sharing-1.f90 -O (test for errors, line 25)
FAIL: gfortran.dg/gomp/sharing-1.f90 -O (test for errors, line 26)
FAIL: gfortran.dg/gomp/sharing-1.f90 -O (test for excess errors)
FAIL: gfortran.dg/gomp/sharing-2.f90 -O (test for errors, line 12)
FAIL: gfortran.dg/gomp/sharing-2.f90 -O (test for errors, line 16)
FAIL: gfortran.dg/gomp/sharing-2.f90 -O (test for errors, line 57)
FAIL: gfortran.dg/gomp/sharing-2.f90 -O (test for errors, line 58)
FAIL: gfortran.dg/gomp/sharing-2.f90 -O (test for errors, line 64)
FAIL: gfortran.dg/gomp/sharing-2.f90 -O (test for errors, line 65)
FAIL: gfortran.dg/gomp/sharing-2.f90 -O (test for excess errors)
FAIL: gfortran.dg/gomp/sharing-3.f90 -O (test for errors, line 28)
FAIL: gfortran.dg/gomp/sharing-3.f90 -O (test for errors, line 30)
FAIL: gfortran.dg/gomp/sharing-3.f90 -O (test for errors, line 33)
FAIL: gfortran.dg/gomp/sharing-3.f90 -O (test for errors, line 34)
FAIL: gfortran.dg/gomp/sharing-3.f90 -O (test for excess errors)
One should find out for which kind of statements the SET_EXPR_LOCATION is
actually needed, and fix those in an appropriate way.
--
Summary: [Cleanup] Remove SET_EXPR_LOCATION in gfc_trans_code
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41827
[Bug debug/41828] New: DW_AT_name should not be present for anonymous aggregates
As mentioned in http://bugzilla.redhat.com/530304 , we shouldn't be adding DW_AT_name: anonymous struct and similar, the aggregates don't have any name. Similarly, adding ._0 etc. to .debug_pubtypes looks wrong. -- Summary: DW_AT_name should not be present for anonymous aggregates Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-debug Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41828
[Bug debug/41828] DW_AT_name should not be present for anonymous aggregates
--- Comment #1 from jakub at gcc dot gnu dot org 2009-10-26 09:34 --- Created an attachment (id=18895) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18895action=view) gcc45-pr41828.patch Patch I'm going to bootstrap/regtest. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41828
[Bug libstdc++/41792] overloading the address operator confuses the standard containers
--- Comment #2 from jkherciueh at gmx dot net 2009-10-26 09:44 --- (In reply to comment #1) Didn't I reply to this issue already on the mailing list, recently? Anyway, within C++03 the is supposed to not be overloaded, you can take it for example from the lines in the standard about allocator::address. James Kanze (comp.lang.c++) pointed out that it's just a requirement for CopyConstructible. It's in Table 30. Also, about list specifically, when we recently we did a change involving in a member function, provided by LWG chair Howard Hinnant, we carefully reconsidered this issue, and verified that within of C++03 we are fine. As an extenssion, I agree it would make sense to have something like boost::address_of in such cases (whose implementation, as far I remember, it's just *ugly*) Yup, as an extension, it could make sense: The only reason to take the address is in iterator::operator*(), so the source would not be littered with address_of(). Also, in C++0X, one has to provide addressof() anyhow. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41792
[Bug tree-optimization/41826] invalid read in get_constraint_for_ptr_offset
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-26 10:00 --- Mine. -- 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 |2009-10-26 10:00:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41826
[Bug target/41780] File gcc/config/arm/lib1funcs.asm broken for THUMB version 1 since r150545
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2009-10-26 10:22 ---
Target: arm-elf
Configured with: /home/sh/gcc-4.5-20091015/configure
--prefix=/opt/tool-chain-elf --target=arm-elf --verbose --with-gnu-as
--with-gnu-ld --enable-languages=c
Thread model: single
gcc version 4.5.0 20091015 (experimental) (GCC)
Test program (test.c):
volatile unsigned a = 0;
int main()
{
a /= 123;
return 0;
}
arm-elf-gcc -mthumb test.c
/opt/tool-chain-elf/lib/gcc/arm-elf/4.5.0/../../../../arm-elf/bin/ld:
/opt/tool-chain-elf/lib/gcc/arm-elf/4.5.0/thumb/libgcc.a(_dvmd_tls.o)(__div0):
warning: interworking not enabled.
first occurrence:
/opt/tool-chain-elf/lib/gcc/arm-elf/4.5.0/thumb/libgcc.a(_udivsi3.o): arm call
to thumb
/opt/tool-chain-elf/lib/gcc/arm-elf/4.5.0/../../../../arm-elf/bin/ld:
/opt/tool-chain-elf/lib/gcc/arm-elf/4.5.0/thumb/libgcc.a(_udivsi3.o)(__udivsi3):
warning: interworking not enabled.
first occurrence:
/opt/tool-chain-elf/lib/gcc/arm-elf/4.5.0/thumb/libgcc.a(_udivsi3.o): arm call
to thumb
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780
[Bug target/41684] [4.4/4.5 regression] binutils testsuite failures when built with 4.4/4.5
--- Comment #11 from ramana at gcc dot gnu dot org 2009-10-26 10:36 --- (In reply to comment #10) (In reply to comment #7) I'm currently bootstrapping and testing a patch which disable section anchors on arm. It will be interesting to see if it fixes any testsuite failures. Done. It caused no new failures but fixed several objc ones: Did it fix your binutils testsuite failures ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41684
[Bug debug/41806] G++ fails to compile a testcase with -fcompare-debug
--- Comment #1 from jakub at gcc dot gnu dot org 2009-10-26 10:55 --- I believe this is the http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01030.html issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41806
[Bug target/41684] [4.4/4.5 regression] binutils testsuite failures when built with 4.4/4.5
--- Comment #12 from kirill at shutemov dot name 2009-10-26 11:06 --- (In reply to comment #11) Did it fix your binutils testsuite failures ? Yes, it did. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41684
[Bug target/41684] [4.4/4.5 regression] binutils testsuite failures when built with 4.4/4.5
-- ramana at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ramana at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-10-15 07:45:43 |2009-10-26 11:20:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41684
[Bug fortran/41772] [4.4 Regression] Wrong code due to TRANSFER of EMPTY array section
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41772
[Bug target/41621] [4.4 regression] powerpc-linux-gnu 32bit testsuite regressions with -Os
--- Comment #1 from jakub at gcc dot gnu dot org 2009-10-26 11:23 --- Can't reproduce. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41621
[Bug target/14202] [arm] Thumb __builtin_setjmp not interworking safe
--- Comment #14 from ramana at gcc dot gnu dot org 2009-10-26 11:37 --- Unassigning self. No longer working on this. -- ramana at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|ramana 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=14202
[Bug target/38203] attribute `noreturn' isn't effective when -mthumb param is active
--- Comment #4 from ramana at gcc dot gnu dot org 2009-10-26 11:38 --- Not working on this. -- ramana at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|ramana 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=38203
[Bug bootstrap/41345] [4.5 Regression] bootstrap comparison failure with --disable-checking
--- Comment #5 from jakub at gcc dot gnu dot org 2009-10-26 11:39 ---
c#4 confirmed, shorter testcase with -fcompare-debug -O2 -g:
void
foo (int *x)
{
int a;
for (a = 0; a 2; a++)
if (x[a])
goto lab;
__builtin_unreachable ();
lab:;
}
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-10-26 11:39:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41345
[Bug libstdc++/41792] [C++0x] overloading the address operator confuses the standard containers
--- Comment #3 from paolo dot carlini at oracle dot com 2009-10-26 12:11 --- (In reply to comment #2) James Kanze (comp.lang.c++) pointed out that it's just a requirement for CopyConstructible. It's in Table 30. Thanks for the pointer, I discussed this issue a few times without actually ever reading those lines, I admit. Yup, as an extension, it could make sense: The only reason to take the address is in iterator::operator*(), so the source would not be littered with address_of(). Also, in C++0X, one has to provide addressof() anyhow. Yes, C++0x is different, much better, with the new scoped allocator model, which is still slightly in flux. Just in case you didn't notice already, C++0x will also include answers to 580. unused allocator members, and 635. domain of allocator::address, which Howard filed at the same time of that change to our std::list. And also 431. Swapping containers with unequal allocators, by the way, which, if I'm not mistaken we already implement withing the old C++03 allocator model, per some other exchanges with Howard. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-26 12:11:06 date|| Summary|overloading the address |[C++0x] overloading the |operator confuses the |address operator confuses |standard containers |the standard containers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41792
[Bug tree-optimization/41826] invalid read in get_constraint_for_ptr_offset
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-26 12:22 --- Subject: Bug 41826 Author: rguenth Date: Mon Oct 26 12:21:50 2009 New Revision: 153550 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153550 Log: 2009-10-26 Richard Guenther rguent...@suse.de PR tree-optimization/41826 * tree-ssa-structalias.c (get_constraint_for_ptr_offset): Avoid access to re-allocated vector fields. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41826
[Bug tree-optimization/41826] invalid read in get_constraint_for_ptr_offset
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-26 12:24 --- Fixed on the trunk sofar. Confirmed on the 4.4 and 4.3 branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.3.4 4.4.2 Known to work||4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41826
[Bug lto/41569] .../prev-gcc/xgcc used for the install step of the lto-plugin
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-26 12:25 --- I have a patch (it seems not using AM_MAINTAINER_MODE is the problem). -- 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|2009-10-19 14:19:08 |2009-10-26 12:25:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41569
[Bug target/29206] [4.3/4.4/4.5 regression] gcj-dbtool segfaults
--- Comment #16 from dl9pf at gmx dot de 2009-10-26 12:29 --- Confirmed also for 4.4.1 on arm-linux-gnueabi. -- dl9pf at gmx dot de changed: What|Removed |Added CC||dl9pf at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29206
[Bug fortran/41829] New: [OOP] Runtime error with dynamic dispatching
Hello, -- Summary: [OOP] Runtime error with dynamic dispatching Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sfilippone at uniroma2 dot it GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41829
[Bug fortran/41829] [OOP] Runtime error with dynamic dispatching
--- Comment #1 from sfilippone at uniroma2 dot it 2009-10-26 12:38 --- (In reply to comment #0) Hello, Sorry, hit the keyboard too soon. With trunk at rev. 153550 the attached code compiles cleanly but does not work: -- [sfili...@donald bug10]$ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gnu45/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --prefix=/usr/local/gnu45 --enable-languages=c,c++,fortran Thread model: posix gcc version 4.5.0 20091026 (experimental) (GCC) [sfili...@donald bug10]$ gfortran -o td10 test-der10.f03 [sfili...@donald bug10]$ ./td10 FOO%DOIT base version Getit value :1 At line 69 of file test-der10.f03 Fortran runtime error: internal error: bad vindex in dynamic dispatch With the NAG compiler I get the expected result: FOO%DOIT base version Getit value : 1 FOO2%DOIT derived version Getit value : 3 --- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41829
[Bug bootstrap/41345] [4.5 Regression] bootstrap comparison failure with --disable-checking
--- Comment #6 from jakub at gcc dot gnu dot org 2009-10-26 12:38 --- Created an attachment (id=18896) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18896action=view) gcc45-pr41345.patch Fix I'm going to bootstrap/regtest. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41345
[Bug fortran/41829] [OOP] Runtime error with dynamic dispatching
--- Comment #2 from sfilippone at uniroma2 dot it 2009-10-26 12:39 --- Created an attachment (id=18897) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18897action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41829
[Bug tree-optimization/41783] r151561 (PRE fix) regresses zeusmp
--- Comment #12 from matz at gcc dot gnu dot org 2009-10-26 13:00 --- Subject: Bug 41783 Author: matz Date: Mon Oct 26 13:00:36 2009 New Revision: 153551 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153551 Log: PR tree-optimization/41783 * tree-ssa-alias.c (get_continuation_for_phi): Export, add a special case for simple diamonds * tree-ssa-alias.h (get_continuation_for_phi): Declare. * tree-ssa-pre.c (translate_vuse_through_block): Add same_valid argument, use alias oracle to skip some vdefs. (phi_translate_1): Change call to above, don't allocate new value ids if they can stay the same. (compute_avail): Allow vuse walking when looking up references. testsuite/ * gcc.dg/pr41783.c: New test. * gcc.dg/tree-ssa/ssa-pre-23.c: Adjust. * gcc.dg/tree-ssa/ssa-pre-24.c: Don't xfail anymore. * gcc.dg/tree-ssa/ssa-pre-27.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr41783.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-23.c trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-pre-24.c trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-alias.h trunk/gcc/tree-ssa-pre.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
[Bug tree-optimization/41783] r151561 (PRE fix) regresses zeusmp
--- Comment #13 from matz at gcc dot gnu dot org 2009-10-26 13:04 --- Fixed. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
[Bug lto/41569] .../prev-gcc/xgcc used for the install step of the lto-plugin
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-26 13:52 --- Actually it didn't work. But make install-lto-plugin; make install works (and does not rebuild lto-plugin). But I'm double-checking that as well now ... -- 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=41569
[Bug debug/41801] [4.5 Regression] VTA: ICE in loc_cmp.
--- Comment #1 from jakub at gcc dot gnu dot org 2009-10-26 14:06 ---
Simpler testcase at -g -O -milp32:
struct T
{
void
foo () volatile
{
__sync_lock_release (t);
__sync_synchronize ();
}
bool t;
};
int
main ()
{
T t = { false };
t.foo ();
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41801
[Bug c++/41020] [4.5 Regression] Can't declare an extern C friend of a builtin function
--- Comment #10 from dodji at gcc dot gnu dot org 2009-10-26 14:40 --- Subject: Bug 41020 Author: dodji Date: Mon Oct 26 14:40:16 2009 New Revision: 153552 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153552 Log: Fix PR c++/41020 gcc/cp/ChangeLog: PR c++/41020 * decl.c (decls_match): Use DECL_IS_BUILTIN instead of DECL_BUILT_IN. gcc/testsuite/ChangeLog: PR c++/41020 * g++.dg/lookup/extern-c-redecl2.C: New test. * g++.dg/lookup/extern-c-redecl3.C: Likewise. * g++.dg/lookup/extern-c-redecl4.C: Likewise. * g++.dg/lookup/extern-c-redecl5.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/lookup/extern-c-redecl2.C trunk/gcc/testsuite/g++.dg/lookup/extern-c-redecl3.C trunk/gcc/testsuite/g++.dg/lookup/extern-c-redecl4.C trunk/gcc/testsuite/g++.dg/lookup/extern-c-redecl5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug lto/41569] .../prev-gcc/xgcc used for the install step of the lto-plugin
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-10-26 14:41 --- Even that doesn't work. Weird. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41569
[Bug c++/41830] New: Missing warning: control reaches end of non-void function in -O2
Example:
class Bug {};
const Bug bug() {}
compile with -Wreturn-type -O1: no warning
compile with -Wreturn-type -O2: no warning
compile with -Wreturn-type -O3: warning printed
If I read the documentation correctly, -Wreturn type should work with or
without optimizing.
--
Summary: Missing warning: control reaches end of non-void
function in -O2
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: grxnprzn at gmx dot net
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41830
[Bug fortran/41829] [OOP] Runtime error with dynamic dispatching
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-26 14:44 --- Created an attachment (id=18898) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18898action=view) another test case This example nicely illustrates why we need a vtable. Here is a more compactified version of the test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41829
[Bug fortran/41831] New: Bug with management of NaNs
I find that there is a bug with respect to the
management of the NaNs from C to fortran.
This bug happens on Ubuntu 64bits (and not with 32bits).
returnanan.c defines 2 functions
nan = returnanan() : returns a NAN,
void returnanan2(nan) : sets the NAN in the input argument, passed by address.
test.f computes NAN with 3 methods :
#1 : uses returnanan()
#2 : creates NAN with (1-ONE)/(1-ONE)
#3 : uses returnanan2(nan)
This produces the following output :
(returnanan) nan = nan // OK
X #1: 0. // WRONG
X #2: NaN // OK
(returnanan2) nan = nan // OK
X #3: NaN // OK
My conclusion is that there is a problem when the
NAN is passed from the C to the fortran.
I cannot explain the fact that if the address of the
NAN is passed to the C function, it works.
This bug is related to Scilab, see :
http://bugzilla.scilab.org/show_bug.cgi?id=4378
Best regards,
Michaël Baudin
--
Software Development Engineer
michael.bau...@scilab.org
The Scilab Consortium
http://www.scilab.org/
===
returnanan.c:
#define C2F(name) name##_
#include stdio.h
double C2F(returnanan)(void)
{
static int first = 1;
static double nan = 1.0;
if ( first )
{
nan = (nan - (double) first)/(nan - (double) first);
first = 0;
}
printf ( (returnanan) nan = %e\n,nan);
return ((double)nan);
}
void C2F(returnanan2)(double * nan)
{
double one = 1.0;
*nan = (1.0 - one)/(1.0 - one);
printf ( (returnanan2) nan = %e\n,*nan);
}
===
test.f
PROGRAM test
DATA ONE/1.0D0/
DOUBLE PRECISION X
X = returnanan()
PRINT * , X #1:, X
X = (1-ONE)/(1-ONE)
PRINT * , X #2:, X
call returnanan2(X)
PRINT * , X #3:, X
END
===
Now type :
gcc -c returnanan.c
gfortran -c test.f
gfortran -o mytest returnanan.o test.o
./mytest
===
$ gcc -v
Utilisation des specs internes.
Target: x86_64-linux-gnu
Configuré avec: ../src/configure -v --with-pkgversion='Ubuntu 4.3.3-5ubuntu4'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug
--enable-objc-gc --enable-mpfr --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Modèle de thread: posix
gcc version 4.3.3 (Ubuntu 4.3.3-5ubuntu4)
--
Summary: Bug with management of NaNs
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot baudin at scilab dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41831
[Bug lto/41832] New: lto1: internal compiler error: verify_stmts failed
configure xorg-server-1.4.2 with -O -flto in $CFLAGS make Eventually it fails with: gcc -DHAVE_DIX_CONFIG_H -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/local/include -I/usr/local/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../../../../include -I../../../../include -I../../../../Xext -I../../../../composite -I../../../../damageext -I../../../../xfixes -I../../../../Xi -I../../../../mi -I../../../../miext/shadow -I../../../../miext/damage -I../../../../render -I../../../../randr -I../../../../fb -DHAVE_XORG_CONFIG_H -DXF86PM -I/usr/local/include -O -flto -I/usr/include/drm -I/usr/include/X11/dri -o cvt cvt-cvt.o cvt-xf86cvt.o ../../../../hw/xfree86/dummylib/libdummy-nonserver.a -lm -lrt In function 'xf86CVTMode': lto1: error: invalid conversion in return statement struct _DisplayModeRec * struct DisplayModeRec * return Mode_13; lto1: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper: /usr/local/bin/gcc returned 1 exit status collect2: lto-wrapper returned 1 exit status make: *** [cvt] Error 1 -- Summary: lto1: internal compiler error: verify_stmts failed Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: b3timmons at speedymail dot org GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41832
[Bug fortran/41831] Bug with management of NaNs
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-26 15:10 --- NaNs don't exist in Fortran's data types except for the Fortran 2003's IEEE types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41831
[Bug lto/41832] lto1: internal compiler error: verify_stmts failed
--- Comment #1 from b3timmons at speedymail dot org 2009-10-26 15:21 --- Created an attachment (id=18899) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18899action=view) cvt.i of cvt program from xorg-server-1.4.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41832
[Bug lto/41832] lto1: internal compiler error: verify_stmts failed
--- Comment #2 from b3timmons at speedymail dot org 2009-10-26 15:23 --- Created an attachment (id=18900) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18900action=view) xf86cvt.i containing function that compiler complains about -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41832
[Bug lto/41832] lto1: internal compiler error: verify_stmts failed
--- Comment #3 from b3timmons at speedymail dot org 2009-10-26 15:28 --- A workaround is to add -fno-tree-copy-prop -fno-tree-copyrename to $CFLAGS -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41832
[Bug bootstrap/41451] [4.5 Regression] Bootstrap failure with fold checking
-- aldyh at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41451
[Bug lto/41808] error: non-trivial conversion at assignment
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-26 15:47 --- Bad idea, loads of fallout. Another variant would be to again require a type conversion for struct T * to struct U * assignments (or add even more special cases...). We're a long way from treating pointers as values... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41808
[Bug debug/41801] [4.5 Regression] VTA: ICE in loc_cmp.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-26 16:03:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41801
[Bug c++/41785] [4.5 Regression] [C++0x] ICE on canonical types with variadic templates and CRTP
--- Comment #6 from dodji at gcc dot gnu dot org 2009-10-26 16:03 --- Patch posted to http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01563.html . -- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-10-22 09:34:12 |2009-10-26 16:03:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41785
[Bug c++/41020] [4.5 Regression] Can't declare an extern C friend of a builtin function
--- Comment #11 from dodji at gcc dot gnu dot org 2009-10-26 16:06 --- Fixed in 4.5.0 -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41020
[Bug debug/41801] [4.5 Regression] VTA: ICE in loc_cmp.
--- Comment #2 from jakub at gcc dot gnu dot org 2009-10-26 16:31 --- Created an attachment (id=18901) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18901action=view) gcc45-pr41801.patch Seems to be a RTL expansion bug, nothing debug info related, just nothing verifies it except for var-tracking.c. Weird that it didn't get caught much earlier. I don't have access to any of the weird targets with ptr_mode != Pmode, so I can't test this patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41801
[Bug rtl-optimization/41833] New: vec_splat followed by vec_splat could be improved
Take:
#include altivec.h
vector float f(vector float a)
{
vector float b = vec_splat (a, 2);
return vec_splat (b, 0);
}
--- CUT ---
The second vec_splat could be removed as we already splatted the value across
the vector once, there is no need to do it again.
--
Summary: vec_splat followed by vec_splat could be improved
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: pinskia at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
GCC target triplet: powerpc*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41833
[Bug rtl-optimization/41833] vec_splat followed by vec_splat could be improved
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-26 16:44 --- I have a patch which fixes this at the RTL level. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-26 16:44:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41833
[Bug middle-end/41750] gcc 4.5.0 miscompiles binutils
--- Comment #17 from hjl dot tools at gmail dot com 2009-10-26 16:59 --- Revision 152433 is OK and revision 152642 is bad. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug middle-end/38002] gcc crash using -fvisibility-ms-compat
--- Comment #4 from boz_gnu at boz dot org dot uk 2009-10-26 17:39 ---
(In reply to comment #3)
Reduced testcase, not a regression.
Here's a further reduction which still reproduces the crash:
namespace std __attribute__ ((__visibility__ (default))) {
class type_info { };
};
void foo() {
int i;
typeid(i);
}
--
boz_gnu at boz dot org dot uk changed:
What|Removed |Added
CC||boz_gnu at boz dot org dot
||uk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38002
[Bug tree-optimization/41834] New: Missed may be uninitialized warning on array reference
Using GCC 4.4.1 and the command on the following test
gcc -O2 -Wall -Wextra
#include stdio.h
int foo (int b)
{
int a[10], c, i;
for (i = 0; i b; i++)
{
a[i] = b;
c = b;
}
if (a[2] == 5 c == 5)
{
printf(hello world\n);
}
return 0;
}
testWarn.c: In function 'foo': testWarn.c:5: warning: 'c' may be used
uninitialized in this function
However, a warning for a[2] being possibly uninitialized is missing.
If I understand right, this should be handled by late warning pass which just
after DCE. Looking at post DCE dump
foo (int b)
{
unsigned int D.1282;
int i;
int c;
int a[10];
_Bool D.1243;
_Bool D.1242;
_Bool D.1241;
int D.1240;
bb 2:
if (b_5(D) 0)
goto bb 3;
else
goto bb 4;
bb 3:
# i_21 = PHI 0(2), i_8(3)
D.1282_25 = (unsigned int) i_21;
MEM[base: a, index: D.1282_25, step: 4] = b_5(D);
i_8 = i_21 + 1;
if (i_8 != b_5(D))
goto bb 3;
else
goto bb 4;
bb 4:
# c_17 = PHI b_5(D)(3), c_4(D)(2)
D.1240_9 = a[2];
D.1241_10 = D.1240_9 == 5;
D.1242_11 = c_17 == 5;
D.1243_12 = D.1242_11 D.1241_10;
if (D.1243_12 != 0)
goto bb 5;
else
goto bb 6;
bb 5:
__builtin_puts (hello world[0]);
bb 6:
return 0;
}
there is a path to bb 4, which does not initialize a. Why do we not generate a
warning? Is it due a missing PHI for a?
--
Summary: Missed may be uninitialized warning on array reference
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rahul at icerasemi dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41834
[Bug c++/41785] [4.5 Regression] [C++0x] ICE on canonical types with variadic templates and CRTP
--- Comment #7 from dodji at gcc dot gnu dot org 2009-10-26 18:31 --- Subject: Bug 41785 Author: dodji Date: Mon Oct 26 18:31:22 2009 New Revision: 153564 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153564 Log: Fix PR c++/41785 gcc/cp/ChangeLog: PR c++/41785 * pt.c (template_args_equal): Handle comparison of an ARGUMENT_PACK_SELECT node with the arguments node it selects into. * cp-tree.def: Fix a typo in the description of TYPE_PACK_EXPANSION. gcc/testsuite/ChangeLog: PR c++/41785 * gcc/testsuite/g++.dg/cpp0x/variadic96.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic96.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.def trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41785
[Bug c++/41785] [4.5 Regression] [C++0x] ICE on canonical types with variadic templates and CRTP
--- Comment #8 from dodji at gcc dot gnu dot org 2009-10-26 18:36 --- Fixed in 4.5.0 -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41785
[Bug c++/41752] [C++0x] Canonical type with variadic templates and CRTP
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-10-26 18:39:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41752
[Bug c++/41752] [C++0x] Canonical type with variadic templates and CRTP
--- Comment #2 from dodji at gcc dot gnu dot org 2009-10-26 18:39 --- This should be fixed by the patch for PR c++/41785 -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41752
[Bug tree-optimization/41835] New: ICE with -flto -O3 (BB N can not throw but has an EH edge)
Looks like something is not removing the EH edges.
Anyways here is a simple testcase:
file 1):
void Stop_Profile( void );
struct CProfileSample {
~CProfileSample( void ) {
Stop_Profile();
}
};
void integrateVelocities(int);
void predictUnconstraintMotion(int size)
{
CProfileSample __profile;
for ( int i=0;isize;i++)
integrateVelocities(1);
}
--- CUT ---
File 2:
void integrateVelocities(int) { }
void Stop_Profile( void ) { }
--- CUT ---
--
Summary: ICE with -flto -O3 (BB N can not throw but has an EH
edge)
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41835
[Bug c++/38796] [c++0x] defaulted operator= with non-default return type accepted
--- Comment #2 from jason at gcc dot gnu dot org 2009-10-26 19:07 --- Subject: Bug 38796 Author: jason Date: Mon Oct 26 19:07:14 2009 New Revision: 153565 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153565 Log: PR c++/38796, Core issue 906 gcc/cp * cp-tree.h (DECL_DEFAULTED_OUTSIDE_CLASS_P): New. (DECL_DEFAULTED_IN_CLASS_P): New. * class.c (user_provided_p): Non-static. (check_methods): Use it. (check_bases_and_members): Check defaulted fns. (defaultable_fn_p): Move and rename to... * method.c (defaultable_fn_check): ...this. (defaulted_late_check): New. * pt.c (tsubst_decl): Call it. * decl2.c (grokfield): Adjust. * decl.c (cp_finish_decl): Adjust. (grok_special_member_properties): Use user_provided_p. libstdc++-v3 * include/std/future (~Future_result_base): Default outside class body. * include/std/system_error (error_category()): Likewise. * libsupc++/nested_exception.h (nested_exception): Remove exception specifications from defaulted methods. Added: trunk/gcc/testsuite/g++.dg/cpp0x/defaulted15.C trunk/gcc/testsuite/g++.dg/cpp0x/defaulted16.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/decl2.c trunk/gcc/cp/method.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/future trunk/libstdc++-v3/include/std/system_error trunk/libstdc++-v3/libsupc++/nested_exception.h trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/assign_neg.cc trunk/libstdc++-v3/testsuite/30_threads/packaged_task/cons/copy_neg.cc trunk/libstdc++-v3/testsuite/30_threads/promise/cons/assign_neg.cc trunk/libstdc++-v3/testsuite/30_threads/promise/cons/copy_neg.cc trunk/libstdc++-v3/testsuite/30_threads/shared_future/cons/assign_neg.cc trunk/libstdc++-v3/testsuite/30_threads/unique_future/cons/assign_neg.cc trunk/libstdc++-v3/testsuite/30_threads/unique_future/cons/copy_neg.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38796
[Bug middle-end/41750] gcc 4.5.0 miscompiles binutils
--- Comment #18 from hjl dot tools at gmail dot com 2009-10-26 19:19 --- This is another IPA-SRA bug. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jamborm at gcc dot gnu dot ||org Last reconfirmed|-00-00 00:00:00 |2009-10-26 19:19:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug target/41799] __enable_execute_stack introduced for mingw32 in r134089 doesn't work for kernel-mode components
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-10-26 19:24 --- Patch post at http://gcc.gnu.org/ml/gcc-patches/2009-10/msg01577.html to ML -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41799
[Bug lto/41832] lto1: internal compiler error: verify_stmts failed
--- Comment #4 from b3timmons at speedymail dot org 2009-10-26 20:10 --- Forgot to add info from output of gcc -v: Target: x86_64-unknown-linux-gnu Configured with: /home/b3po/build/gcc/gcc/configure --with-mpfr=/usr/local --with-gmp=/usr/local --with-ppl=/usr/local --with-cloog=/usr/local --with-mpc=/usr/local --with-libelf=/usr/local --enable-languages=c,c++ --enable-__cxa_atexit --enable-targets=all Thread model: posix gcc version 4.5.0 20091026 (experimental) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41832
[Bug debug/41828] DW_AT_name should not be present for anonymous aggregates
--- Comment #2 from jakub at gcc dot gnu dot org 2009-10-26 20:18 --- Subject: Bug 41828 Author: jakub Date: Mon Oct 26 20:18:26 2009 New Revision: 153568 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153568 Log: PR debug/41828 * cp-lang.c (cxx_dwarf_name): Return NULL instead of anonymous ... for anonymous aggregate names. * dwarf2out.c (add_pubname, add_pubtype, generic_parameter_die, add_name_and_src_coords_attributes, gen_namespace_die, dwarf2out_set_name): Handle dwarf2_name returning NULL. * g++.dg/debug/dwarf2/anonname1.C: New test. Added: trunk/gcc/testsuite/g++.dg/debug/dwarf2/anonname1.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-lang.c trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41828
[Bug bootstrap/41345] [4.5 Regression] bootstrap comparison failure with --disable-checking
--- Comment #7 from jakub at gcc dot gnu dot org 2009-10-26 20:21 --- Subject: Bug 41345 Author: jakub Date: Mon Oct 26 20:21:09 2009 New Revision: 153569 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153569 Log: PR bootstrap/41345 * cfgcleanup.c (trivially_empty_bb_p): New function. (try_optimize_bb): Use it instead of checking BB_HEAD == BB_END. * gcc.dg/pr41345.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr41345.c Modified: trunk/gcc/ChangeLog trunk/gcc/cfgcleanup.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41345
[Bug c/41836] New: lto1: internal compiler error: in lto_symtab_register_decl, at lto-symtab.c:134
$ gcc -v -flto -fprofile-generate gcc-bug2.c Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/b3po/build/gcc/gcc/configure --with-mpfr=/usr/local --with-gmp=/usr/local --with-ppl=/usr/local --with-cloog=/usr/local --with-mpc=/usr/local --with-libelf=/usr/local --enable-languages=c,c++ --enable-__cxa_atexit --enable-targets=all Thread model: posix gcc version 4.5.0 20091026 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-flto' '-fprofile-generate' '-mtune=generic' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1 -quiet -v gcc-bug2.c -quiet -dumpbase gcc-bug2.c -mtune=generic -auxbase gcc-bug2 -version -flto -fprofile-generate -o /tmp/ccYElYVT.s GNU C (GCC) version 4.5.0 20091026 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20091026 (experimental), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.7 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../x86_64-unknown-linux-gnu/include #include ... search starts here: #include ... search starts here: /usr/local/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/include-fixed /usr/include End of search list. GNU C (GCC) version 4.5.0 20091026 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20091026 (experimental), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.7 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 51f39aedff8c196534353c80fb0ba358 COLLECT_GCC_OPTIONS='-v' '-flto' '-fprofile-generate' '-mtune=generic' as -V -Qy -o /tmp/cccPjClJ.o /tmp/ccYElYVT.s GNU assembler version 2.19.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Ubuntu) 2.19.1 COMPILER_PATH=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/:/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/:/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-flto' '-fprofile-generate' '-mtune=generic' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/collect2 -flto --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 /usr/lib/../lib64/crt1.o /usr/lib/../lib64/crti.o /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/crtbegin.o -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0 -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/../../.. /tmp/cccPjClJ.o -lgcov -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/crtend.o /usr/lib/../lib64/crtn.o Using built-in specs. COLLECT_GCC=/usr/local/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /home/b3po/build/gcc/gcc/configure --with-mpfr=/usr/local --with-gmp=/usr/local --with-ppl=/usr/local --with-cloog=/usr/local --with-mpc=/usr/local --with-libelf=/usr/local --enable-languages=c,c++ --enable-__cxa_atexit --enable-targets=all Thread model: posix gcc version 4.5.0 20091026 (experimental) (GCC) COLLECT_GCC_OPTIONS='-combine' '-c' '-o' '/tmp/ccVjwVw6.lto.o' '-v' '-fprofile-generate' '-mtune=generic' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto1 -quiet -dumpbase cccPjClJ.o -mtune=generic -auxbase-strip /tmp/ccVjwVw6.lto.o -version -fprofile-generate @/tmp/cc4z8ZY7 -o /tmp/ccW87tP5.s GNU GIMPLE (GCC) version 4.5.0 20091026 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20091026 (experimental), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.7 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU GIMPLE (GCC) version 4.5.0 20091026 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20091026 (experimental), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.7 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 lto1: internal compiler error: in lto_symtab_register_decl, at lto-symtab.c:134 -- Summary: lto1: internal compiler error: in lto_symtab_register_decl, at lto-symtab.c:134 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org
[Bug libstdc++/38923] symbol versioning disabled due to non-portable sed script
--- Comment #15 from jakub at gcc dot gnu dot org 2009-10-26 20:28 --- Subject: Bug 38923 Author: jakub Date: Mon Oct 26 20:28:24 2009 New Revision: 153570 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=153570 Log: PR libstdc++/38923 * acinclude.m4 (GLIBCXX_CHECK_LINKER_FEATURES): Avoid using too many *s. Accept ld version without text in ()s. * configure: Regenerated. * acinclude.m4 (LIBGOMP_CHECK_LINKER_FEATURES): Avoid using too many *s. Accept ld version without text in ()s. * configure: Regenerated. Modified: trunk/libgomp/ChangeLog trunk/libgomp/acinclude.m4 trunk/libgomp/configure trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38923
[Bug c/41836] lto1: internal compiler error: in lto_symtab_register_decl, at lto-symtab.c:134
--- Comment #1 from b3timmons at speedymail dot org 2009-10-26 20:32 --- Created an attachment (id=18902) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18902action=view) preprocessed source of trivial test file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41836
[Bug libgcj/35552] GCJ ARM compiled programs give segmentation fault
--- Comment #2 from dl9pf at gmx dot de 2009-10-26 20:32 --- Could this be a problem with boehm-gc ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35552
[Bug c/41836] lto1: internal compiler error: in lto_symtab_register_decl, at lto-symtab.c:134
--- Comment #2 from b3timmons at speedymail dot org 2009-10-26 20:35 --- Also fails with -fwhopr instead of -flto Also fails with -fprofile-arcs instead of -fprofile-generate -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41836
[Bug lto/40790] plugin-api.h unconditionally includes stdint.h
--- Comment #18 from ebotcazou at gcc dot gnu dot org 2009-10-26 20:41 --- Fixed on Solaris 10 by http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00629.html There is still a problem in the testsuite though: http://gcc.gnu.org/ml/gcc-testresults/2009-10/msg02530.html Executing on build: gcc -g -O2 /nile.build/botcazou/gcc-head/src/gcc/testsuite/\ gcc.dg/plugin/selfassign.c -I. -I/nile.build/botcazou/gcc-head/src/gcc/testsuit\ e -I/nile.build/botcazou/gcc-head/src/gcc/testsuite/../../gcc -I/nfs/nile/nile.\ build/botcazou/gcc-head/sparc-sun-solaris2.9/gcc/testsuite/gcc/../../../gcc -I\ /nile.build/botcazou/gcc-head/src/gcc/testsuite/../../include -I/nile.build/bot\ cazou/gcc-head/src/gcc/testsuite/../../libcpp/include -I/nile.build/botcazou/g\ cc-head/install_sparc/include -I/nile.build/botcazou/gcc-head/install_sparc/in\ clude -I/nile.build/botcazou/gcc-head/install_sparc/include -O -DIN_GCC -fPIC -\ shared -o selfassign.so(timeout = 300) In file included from /nile.build/botcazou/gcc-head/src/gcc/testsuite/../../gcc\ /gcc-plugin.h:28,^M from /nile.build/botcazou/gcc-head/src/gcc/testsuite/gcc.dg/pl\ ugin/selfassign.c:5:^M /nile.build/botcazou/gcc-head/src/gcc/testsuite/../../gcc/system.h:418:20: erro\ r: stdint.h: No such file or directory^M Stage 3 compiler has #define HAVE_STDINT_H 1 in auto-host.h so the include is triggered, but -I/nile.build/botcazou/gcc-head/sparc-sun-solaris2.9/gcc/include is not passed on the command line. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40790
[Bug tree-optimization/41834] Missed may be uninitialized warning on array reference
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-26 20:54 --- It is because there would be very many spurious warnings. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41834
[Bug tree-optimization/41835] ICE with -flto -O3 (BB N can not throw but has an EH edge)
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-26 20:56 --- Confirmed. There is a crude fixup pass, but this should be handled by IPA nothrow (which doesn't exist). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||lto Last reconfirmed|-00-00 00:00:00 |2009-10-26 20:56:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41835
[Bug tree-optimization/41750] [4.5 Regression] gcc 4.5.0 miscompiles binutils
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Component|middle-end |tree-optimization Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|2009-10-26 19:19:42 |2009-10-26 20:57:48 date|| Summary|gcc 4.5.0 miscompiles |[4.5 Regression] gcc 4.5.0 |binutils|miscompiles binutils Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41750
[Bug lto/41832] lto1: internal compiler error: verify_stmts failed
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-10-26 21:00 --- I can't reproduce this with ./xgcc -B. -r -nostdlib -O -flto cvt.i xf86cvt.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41832
