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]==2441&&v[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
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: basilestarynkevitchnet 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 : > 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 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 wrote: > Basile STARYNKEVITCH 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 wrote:
Basile STARYNKEVITCH 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: basilestarynkevitchnet 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 wrote: > Richard Guenther wrote: >> >> On Mon, Oct 26, 2009 at 2:59 PM, Ian Lance Taylor wrote: >>> >>> Basile STARYNKEVITCH 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 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 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 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 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 : > > 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 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: basilestarynkevitchnet 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 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 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 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 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 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 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
Re: Testsuite regular expression question
On Mon, 26 Oct 2009, Steve Ellcey wrote:
> 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.
I think you need two backslashes escaping the paren and maybe one before
the pipe. I'm not sure about the \| vs | though, give the double escape
paren a try both ways. You can see some examples via:
find gcc/testsuite | xargs grep 'scan-assembler-times.*[(|]'
--Kaveh
