Re: git mirror at infradead?
On 06/07/09 07:21, Ralf Wildenhues wrote: > Hello Bernardo, > > sorry if this is not an official mirror of the GCC tree, but > has not been updated since > June 1. Any chance you (or whoever is responsible) could look into it? The git-svn process was stuck on a read(), with the socket to gcc.gnu.org still open. Killing the process and running the update script again fixed it. The same happened a few months ago. I'm not sure what triggers it, and whether git-svn or svnserve is to blame for it. I now made the cron job complain to me by email if it detects a stuck process, so I shall notice sooner, but thank you for reporting. BTW, we also have another up-to-date git mirror, supposedly the "official" one: http://gcc.gnu.org/git/?p=gcc.git I never got around to give it the necessary love, though, such as configuring a few more branches. Also, sourceware still running git 1.5 doesn't help (git-svn was greatly improved in git 1.6). -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/
Re: git mirror at infradead?
Hello Bernie, * Bernie Innocenti wrote on Sun, Jun 07, 2009 at 12:17:44PM CEST: > On 06/07/09 07:21, Ralf Wildenhues wrote: > > sorry if this is not an official mirror of the GCC tree, but > > has not been updated since > > June 1. Any chance you (or whoever is responsible) could look into it? > > The git-svn process was stuck on a read(), with the socket to > gcc.gnu.org still open. Killing the process and running the update > script again fixed it. Thanks! > BTW, we also have another up-to-date git mirror, supposedly the > "official" one: > >http://gcc.gnu.org/git/?p=gcc.git Is this mirror an independent conversion from the infradead one (i.e., I have to throw away the repo and re-download a full repo? Or can I reuse objects)? > I never got around to give it the necessary love, though, such as > configuring a few more branches. Oh. Yes, at least the still-active release branches would be nice to have. > Also, sourceware still running git 1.5 > doesn't help (git-svn was greatly improved in git 1.6). Does that mean you would like to redo the full export after updating git-svn? If yes, then I'd want to wait until after that before switching. Thanks, Ralf
Re: git mirror at infradead?
On 06/07/09 12:40, Ralf Wildenhues wrote: > Is this mirror an independent conversion from the infradead one (i.e., I > have to throw away the repo and re-download a full repo? Or can I reuse > objects)? It's an independent mirror, and I wouldn't recommend switching to it yet. There are permissions problems, and I might end up rsyncing the whole infradead repository rather than fixing things locally. >> I never got around to give it the necessary love, though, such as >> configuring a few more branches. > > Oh. Yes, at least the still-active release branches would be nice to > have. There was a problem with git-svn creating very large temporary files for each branch or tag, but iirc it was solved in 1.6. > Does that mean you would like to redo the full export after updating > git-svn? If yes, then I'd want to wait until after that before > switching. Indeed. I could build git locally in my account, but I'd rather have a sourceware admin update git system-wise. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/
Re: git mirror at infradead?
On 06/07/09 13:38, Bernie Innocenti wrote: > On 06/07/09 12:40, Ralf Wildenhues wrote: >> Is this mirror an independent conversion from the infradead one (i.e., I >> have to throw away the repo and re-download a full repo? Or can I reuse >> objects)? > > It's an independent mirror, and I wouldn't recommend switching to it yet. > > There are permissions problems, and I might end up rsyncing the whole > infradead repository rather than fixing things locally. Daniel, could you please execute these commands on sourceware? cd /sourceware/projects/gcc-home/gitfiles chmod g+w -R . find . -type d -print0 | xargs -0 chmod g+s Where is the cron job to update the mirror? Could you make it writable by group gcc, or just disable it so I can start mine from my user crontab? Thanks! -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/
gcc 4.4.0 error at postreload.c:396
Hi,
I search gcc ML and find this.
http://gcc.gnu.org/ml/gcc/2009-05/msg00413.html
but here i have source with no 64 bit CPU.
is the fix now in and should i test current gcc4.4 ?
I also like to know if there is possible to build a gcc with better error
messages ?
It show as error place last bracket of the function.
Get a report of GCC 4.4.0 internal compiler error.happen on the last
bracket of the function.see --> mark
he report that GCC 4.3.2 work ok with same source.
the source is in ffmpeg package and gcc4.4.0 (release)run on cygwin.
A preprocessed source i do not have, hope this can help and somebody can
tell me what problem can be or how get more precise info about problem.
Here is output:
$ make_68k_v4
/bin/ffmpeg8/version.sh "/bin/ffmpeg8" version.h
/usr/local/amiga/bin/m68k-amigaos-gcc-4.4.0.exe -V 4.4.0
-DHAVE_AV_CONFIG_H -I.
-I"/bin/ffmpeg8" -mnobitfield -m68060 -std=c99
-Wdeclaration-after-statement -W
disabled-optimization -fno-math-errno -D_ISOC99_SOURCE
-D_POSIX_C_SOURCE=200112
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -fno-common
-fomit-frame-pointer -Wal
l -Wno-switch -Wpointer-arith -Wredundant-decls -Wcast-qual
-Wwrite-strings -Wun
def -O3 -c -o libavcodec/mpegvideo.o libavcodec/mpegvideo.c
libavcodec/mpegvideo.c: In function 'init_rl':
libavcodec/mpegvideo.c:760: warning: pointer targets in assignment
differ in sig
nedness
libavcodec/mpegvideo.c:765: warning: pointer targets in assignment
differ in sig
nedness
libavcodec/mpegvideo.c: In function 'MPV_motion_lowres':
libavcodec/mpegvideo.c:1707: error: insn does not satisfy its constraints:
(insn 937 3765 3766 59 libavcodec/mpegvideo.c:1488 (set (reg:SI 0 d0
[931])
(plus:SI (mem/f:SI (reg:SI 9 a1) [7 S4 A16])
(reg:SI 0 d0 [931]))) 131 {*addsi3_internal} (nil))
libavcodec/mpegvideo.c:1707: internal compiler error: in
reload_cse_simplify_ope
rands, at postreload.c:396
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
GCC 4.3.2 don't have this error - compiles "mpegvideo.c" file without
problems.
Regards
static inline void MPV_motion_lowres(MpegEncContext *s,
uint8_t *dest_y, uint8_t *dest_cb, uint8_t
*dest_cr,
int dir, uint8_t **ref_picture,
h264_chroma_mc_func *pix_op)
{
int mx, my;
int mb_x, mb_y, i;
const int lowres= s->avctx->lowres;
const int block_s= 8>>lowres;
mb_x = s->mb_x;
mb_y = s->mb_y;
switch(s->mv_type) {
case MV_TYPE_16X16:
mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
0, 0, 0,
ref_picture, pix_op,
s->mv[dir][0][0], s->mv[dir][0][1], 2*block_s);
break;
case MV_TYPE_8X8:
mx = 0;
my = 0;
for(i=0;i<4;i++) {
hpel_motion_lowres(s, dest_y + ((i & 1) + (i >> 1) *
s->linesize)*block_s,
ref_picture[0], 0, 0,
(2*mb_x + (i & 1))*block_s, (2*mb_y + (i
>>1))*block_s,
s->width, s->height, s->linesize,
s->h_edge_pos >> lowres, s->v_edge_pos >>
lowres,
block_s, block_s, pix_op,
s->mv[dir][i][0], s->mv[dir][i][1]);
mx += s->mv[dir][i][0];
my += s->mv[dir][i][1];
}
if(!CONFIG_GRAY || !(s->flags&CODEC_FLAG_GRAY))
chroma_4mv_motion_lowres(s, dest_cb, dest_cr, ref_picture,
pix_op, mx, my);
break;
case MV_TYPE_FIELD:
if (s->picture_structure == PICT_FRAME) {
/* top field */
mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
1, 0, s->field_select[dir][0],
ref_picture, pix_op,
s->mv[dir][0][0], s->mv[dir][0][1], block_s);
/* bottom field */
mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
1, 1, s->field_select[dir][1],
ref_picture, pix_op,
s->mv[dir][1][0], s->mv[dir][1][1], block_s);
} else {
if(s->picture_structure != s->field_select[dir][0] + 1 &&
s->pict_type != FF_B_TYPE && !s->first_field){
ref_picture= s->current_picture_ptr->data;
}
mpeg_motion_lowres(s, dest_y, dest_cb, dest_cr,
0, 0, s->field_select[dir][0],
ref_picture, pix_op,
s->mv[dir][0][0], s->mv[dir][0][1], 2*block_s);
}
break;
case MV_TYPE_16X8:
for(i=0; i<2; i++){
uint8_t ** ref2picture;
if(s->picture_structure == s->field_select[dir][i] + 1 ||
s->pict_type == FF_B_TYPE || s->first_field){
ref2picture= ref_picture;
}else{
ref2picture= s->current_pict
libJIT + GCC integration and PLDI 2009
Hi Everyone I will be participating at PLDI 2009 SRC (ACM Programming Language Design and Implementation) with my poster "Mathematical Apparatus for Aggressive Optimization of Register Allocation in a Library for Just-In-Time Compilation in Microsoft Common Intermediate Language Runtimes on Embedded Systems Software". The web page of this conference is at http://www-plan.cs.colorado.edu/~pldi09/ . This conference will be held in Ireland, Dublin, Trinity College from 15 June to 20 June. I think this might be a great opportunity to meet in person with other people, and discuss plans around libJIT + gcc integration. If somebody also will attend this conference, please let me know, so we may meet there in person. Thanks, Kirill -- http://code.google.com/p/libjit-linear-scan-register-allocator/
Re: VTA merge?
On Jun 5, 2009, Daniel Berlin wrote: >> >> We can measure some of these things now. Some can even be measured >> objectively ;-) > Do you have any of them handy (memory use, compile time with release > checking only, etc) so that we can start the public > argument^H^H^H^H^H^discussion? > ;) :-) I don't, really. Part of the guidance I expected was on what the relevant measures should be. I wouldn't want to decide that for myself, because I can't say for sure that I fully understand the concerns in people's minds, and I wouldn't want to spend a lot of time collecting irrelevant data, or data that might be perceived as biased because of my lack of experience with benchmarks. That said, I planned on collecting and presenting at least some data, but I ran out of time before the deadline I'd set for myself (must post before the summit), while working on addressing the various suggestions I'd received for the bug fixes and new features I recently submitted. So the question is, what should I measure? Memory use for any specific set of testcases, summarized over a bootstrap with memory use tracking enabled, something else? Likewise for compile time? What else? -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: VTA merge?
On Jun 6, 2009, Eric Botcazou wrote: >> So if I understand the above right then VTA is a new source of >> code-generation differences with -g vs. -g0. A possibly quite >> bad one (compared to what we have now). > IIUC it's a paradigm shift: currently the absence of differences in the > generated code is guaranteed by the absence of differences in the IR all the > way from the initial GENERIC down to the final RTL. In other words, unless a > pass makes an active mistake, it preserves the invariant. It would be nice if it worked this way, but the dozens of patches to fix -g/-g0 compile differences I posted over the last several months show it's really not that simple, because the codegen IR does not tell the whole story. We have kind of IR extensions for debug info, for types and templates, for aliasing information, even for GC of internal data structures, and all of these do affect codegen, sometimes in very subtle ways. It would be nice if things were as you describe above, I agree, but that's not where we are, and in ways other than the ones I mentioned above. Speaking specifically of debug information, the little attention given to preserving information needed to generate correct debug info means that introducing errors is not just a matter of active mistakes. Most of the debug information errors we have now do not follow from actively breaking debug info data structures, but rather from passively failing to keep them up to date, or even missing data structures to that end. Now, once we realize we need additional data structures to retain a correct mapping between source-level constructs and the result of transformations that occur throughout compilation, it shouldn't be hard to realize that there are two options: 1. maintain those IR data structures regardless of whether we're emitting debug information, spending computation time and memory to keep computation identical, so as to avoid risk, and in the end discard the results the user didn't ask for; or 2. avoid the unnecessary computation and memory use by accepting that there are going to be IR differences between compilations with or without -g, and work torwards minimizing the risks of such differences. I can certainly understand the wish to keep debug info IR out of sight, and have it all be maintained sort of by magic, without need for developers to even think about it. While I share that wish and even tried to satisfy it in the design, I've come to the conclusion that it can't be done. And it's not just a “it can't be done without major surgery in GCC as it is today”, it's a “it can't be done at all”. Let me share with you the example by which I proved it to myself. Consider an IR API that offers interfaces to remove and add operations to sequences. If you want to move an operation, you remove it from its original position and add it to another. Problem is, the moment you remove it, any debug info monitor running behind the scenes has to behave as if the operation would no longer be seen, making any changes to the debug info IR so as to minimize the absence of that operation, and not keeping any references to it. Then, when that operation is re-added, debug info monitor must deal with it as a new operation, so it can't fully recover from whatever loss of debug info the removal caused. The loss can be even greater if the operation, rather than being just moved, is re-created, without concern for debug information. Think removing an insn and creating a new insn out of its pattern, without preserving the debug info locators. Would you consider this kind of transformation an active mistake, or failure to play by the rules? Even if the API is extended so as to move operations without loss of debug info, and all existing pairs of remove/add that could/should be implemented in terms of this new interface, new code could still be added that used remove and add rather than move. This would generate exactly the same executable code, but it would prevent debug information from being preserved. Would you qualify the addition of new such code as active mistakes, or failure to play by the rules? After pondering about this, do you agree that paying attention to debug information concerns is not only something we already do routinely (just not enough), it is something that can't really be helped? If so, the question turns into how much computation you're willing to perform and baggage you're willing to carry to reduce the risk of errors caused by deviations from the rules. Apparently most GCC developers don't mind carrying around the source locator information in INSNs, EXPRs and STMTs, even though the lack of care for checking their correctness has led to very many errors that went undetected over the years. Andrew Macleod and Aldy Hernandez have been giving these issues a lot more attention than I have, and they can probably say more about how deep the hole created by all these years of erosion got. Apparently most GCC de
Re: git mirror at infradead?
On Sun, Jun 7, 2009 at 8:08 AM, Bernie Innocenti wrote: > On 06/07/09 13:38, Bernie Innocenti wrote: >> On 06/07/09 12:40, Ralf Wildenhues wrote: >>> Is this mirror an independent conversion from the infradead one (i.e., I >>> have to throw away the repo and re-download a full repo? Or can I reuse >>> objects)? >> >> It's an independent mirror, and I wouldn't recommend switching to it yet. >> >> There are permissions problems, and I might end up rsyncing the whole >> infradead repository rather than fixing things locally. > > Daniel, could you please execute these commands on sourceware? > > cd /sourceware/projects/gcc-home/gitfiles > chmod g+w -R . > find . -type d -print0 | xargs -0 chmod g+s > Done. > Where is the cron job to update the mirror? Could you make it writable > by group gcc, or just disable it so I can start mine from my user crontab? I can't make it writable, but i have disabled it. > > Thanks! > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ >
gcc-4.3-20090607 is now available
Snapshot gcc-4.3-20090607 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090607/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 148266 You'll find: gcc-4.3-20090607.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090607.tar.bz2 C front end and core compiler gcc-ada-4.3-20090607.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090607.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090607.tar.bz2 C++ front end and runtime gcc-java-4.3-20090607.tar.bz2 Java front end and runtime gcc-objc-4.3-20090607.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090607.tar.bz2The GCC testsuite Diffs from 4.3-20090531 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: LLVM as a gcc plugin?
> GMP and MPFR are required components of GCC, and every developer has to > deal with them. For interfacing between GCC and LLVM, the experts who'll > be able to answer the questions are generally going to be found on the > LLVM lists, not the gcc list, and those (like you) who participate on > both lists, well, you're on both lists. That is not the case here. There is already a version of gcc that uses llvm. What we are trying to find is if the GCC plugin infrastructure is generic enough to support similar use cases. In a previous mail I raised some issues in GCC that illustrate this. > So as a practical matter, it seems that LLVM lists are more suitable. > If it's ever decided that LLVM becomes a required piece of GCC, like > GMP and MPFR, that would change. Cheers, -- Rafael Avila de Espindola Google | Gordon House | Barrow Street | Dublin 4 | Ireland Registered in Dublin, Ireland | Registration Number: 368047
Re: VTA merge?
> It would be nice if it worked this way, but the dozens of patches to fix > -g/-g0 compile differences I posted over the last several months show > it's really not that simple, because the codegen IR does not tell the > whole story. We have kind of IR extensions for debug info, for types > and templates, for aliasing information, even for GC of internal data > structures, and all of these do affect codegen, sometimes in very subtle > ways. Yes, precisely, they are IR extensions, most passes shouldn't have to bother with them. Fixing bugs there can probably be done once for all passes. > Speaking specifically of debug information, the little attention given > to preserving information needed to generate correct debug info means > that introducing errors is not just a matter of active mistakes. Most > of the debug information errors we have now do not follow from actively > breaking debug info data structures, but rather from passively failing > to keep them up to date, or even missing data structures to that end. I was only talking about code generation, not debug info generation. > I can certainly understand the wish to keep debug info IR out of sight, > and have it all be maintained sort of by magic, without need for > developers to even think about it. While I share that wish and even > tried to satisfy it in the design, I've come to the conclusion that it > can't be done. And it's not just a “it can't be done without major > surgery in GCC as it is today”, it's a “it can't be done at all”. Well understood. So, in the end, we seem to agree that your approach is fundamentally different from what we have now. I only added that in my opinion it is inherently less robust as far as -g vs -g0 code is concerned (unless it is enabled unconditionally) and we shouldn't trade this loss of robustness for nothing. -- Eric Botcazou
Having trouble printing the subvars of structs, under certain conditions
I am using gcc 4.1.1 to do research involving gimple. For this work I need to
know the sizes of all of my variables, without running the program and calling
"sizeof".
To accomplish this, I inserted a call to:
dump_referenced_vars(dump_file_ptr);
At first, everything looked fine. The output looks something like this:
...
Variable: ibin, UID 1428, char[16], is global, call clobbered, default
def: ibin_100
Variable: ie, UID 1429, struct great, sub-vars: { SFT.124 SFT.123 SFT.122 }
Variable: itmp, UID 1430, long unsigned int
...
>From this information, I can work out the sizes of all 3 variables
(ibin, ie, and itmp).
The ie variable is a struct with 3 subbvariables (SFT.124, SFT.123,SFT.122).
To compute the size of ie, I need to recursively find the name of each
subvar, but this is not the problem that I want to ask about.
The problem is that the subvars of a struct do not always print. I
specifically see that it does not print subvars if one of the subvars
is an array or itself
a struct. For example, here is a code snippet for a struct with an
array element:
typedef struct card{ int a; char *b; float c[10];} cardtyp;
static cardtyp c1;
And here is the dump_referenced_vars output for it:
Variable: c1, UID 1916, struct cardtyp, is global, call clobbered,
default def: c1_1
Notice that it does not list the subvars, so I cannot catch the size
of cardtype.
It also does not print subvars for arrays of struct variables:
Variable: kns, UID 1272, struct great[17], is addressable, is global,
call clobbered, default def: kns_29
So how can I get this information? (By the way, I'm not particularly
concerned with referenced variables. I would be even happier to have
the information
for all variables, whether referenced or not.)
Thank you for your help,
Cheng-Yu
Re: Using MPC Library with GCC
From: "Allan McRae"
I have noticed that mpc is not automatically detected even when
installed in the standard library path (with gcc-4.5-20090604). This
means that building with mpc always requires using the
--with-mpc-lib=/usr/lib flag.
This is fixed by adjusting configure{.ac} to have:
mpclibs="-lmpc"
See: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00615.html
Intermediate representation
Hello, I want to go through the entire internal tree in GCC but I have a problem with functions. Indeed I would like to know the declarations and functions called by a function. I assume I have to go into the function's scope but I don't know how. I read the source code but I didn't find anything. Thanks.
