Re: Bootstrap failures on solaris
On Jun 9, 2009, "Arthur Haas" wrote: > Now that this patch has been commited, the build on i386-pc-solaris2.10 > /export/home/arth/gnu/gcc.git/gcc/gcc.c: In function 'compare_files': > /export/home/arth/gnu/gcc.git/gcc/gcc.c:6635:2: error: request for > implicit conversion from 'void *' to 'caddr_t' not permitted in C++ Every other call to munmap in gcc/ is given a char* or has a cast to caddr_t. This patch should fix it. I'll check it in shortly. for gcc/ChangeLog from Alexandre Oliva * gcc.c (compare_files): Cast munmap argumento to caddr_t. Index: gcc/gcc.c === --- gcc/gcc.c.orig 2009-06-08 04:45:28.0 -0300 +++ gcc/gcc.c 2009-06-10 04:17:33.0 -0300 @@ -6632,7 +6632,7 @@ compare_files (char *cmpfile[]) for (i = 0; i < 2; i++) if (map[i]) - munmap (map[i], length[i]); + munmap ((caddr_t) map[i], length[i]); if (ret >= 0) return ret; -- 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: increasing the number of GCC reviewers
On Tue, Jun 9, 2009 at 9:29 PM, Andrew Haley wrote: >> This is precisely my point. It should be perfectly acceptable that some >> people be authorized to approve some few patches without understanding >> the whole of GCC, and even without knowing all of it. > > GCC isn't really like that. Changes in one part can affect things much > later on, and you really have to know why. That doesn't mean you have > to understand all of the compiler, but you need to have a lot of > knowledge. This is a problem with GCC's lack of modularity, not with Basile's point of view. Ciao! Steven
Re: gcc 4.4.0 error at postreload.c:396
Bernd Roesch wrote: 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 ? The fix is machine-dependent (the message you quoted referred to the poster's proprietary port), so likely not. Please create a bugzilla entry and CC me. You will need a preprocessed file but it is easy to create one: just add --save-temps to the command line and you'll find that GCC now generates a mpegvideo.i file with the preprocessed sources. 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. Yes, it is not optimal. For front-end errors, gcc 4.5.0 will have better positions. For this kind of back-end error it is difficult to find a position because anyway the error depends on all the optimizations done so far, and it is only remotely connected to the source code. Paolo
Re: Please update http://gcc.gnu.org/gcc-4.3/buildstat.html
> Dennis Clarke wrote: >> Re: http://gcc.gnu.org/gcc-4.3/buildstat.html >> >> I was looking for testsuite results to compare with on Solaris and I saw >> that nearly every report for GCC 4.3.3 was done by Tom G. Christensen. >> >> All GCC 4.3.3 reports on Solaris from one person : >> > > You better get cracking on 4.4.0 aswell since I posted most of those > reports too ;) no rest for the weary .. you have been very busy indeed. How did you do with the new PPL bits ? That went smoothly ? >> I think it is great we have any report at all but for the sake of >> diversity and some comparison data I'll add mine in there : >> > More testresults are always welcome. I think a few datapoints are always better than one. Tough to plot a trend or do comparison with one datapoint. >> Results for 4.3.3 (GCC) testsuite on sparc-sun-solaris2.8 >> http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg00501.html >> > Thank you. > >> I'll get the i386 reports later this week. >> > Sounds good. > > The testresults will be added with the next round of updates which I > plan to do early next week. > cool :-) Dennis
AW: AIX link error with g++ 4.4.0
_ Von:Fehringer Franz Gesendet: Mittwoch, 10. Juni 2009 10:55 An: 'gcc-h...@gnu.org'; 'g...@gnu.org' Betreff:AIX link error with g++ 4.4.0 Hello all, I have exactly the same error like described in http://gcc.gnu.org/ml/gcc-help/2009-05/msg00323.html namely collect2: library libstdc++ -lsupc++ not found I have a POWER6 with AIX 6.1.2, for the build --disable-shared was used (i think this is the reason why this error does not show up in regular shared library builds). When i invoke g++ with both -v and -save-temps and then invoke the final collect2 step manually (using cut and paste) the link succeeds. According to my investigations, the reason for this kind of failure is * collect2 is executed via execvp in gcc.c resp. pex-unix.c * the link line (i.e. the collect2 invocation) contains -lstdc++ -lsupc++ since we are in the C++ realm. * The error now is, that -lstdc++ -lsupc++ is given in the execvp argument vector as one argument instead two separate arguments. * As a result the call to resolve_lib_name in collect2.c fails, since it can handle only one -lxxx per call and not multiple ones. Should i file a bug report and is there an easy resolution? Best regards Franz
Adding a new Struct (RECORD_TYPE)
Hi,
I try to create and populate a new struct into my the generated code.
Something like:
struct ddm_temaplate{
int loop_interations;
int ddm_thread_num;
};
What I have up to now is the following:
static tree build_ddm_template_struct() {
tree type = lang_hooks.types.make_type(RECORD_TYPE);
tree id, field, fields;
id = get_identifier("loop_interations");
fields = build_decl (FIELD_DECL,id, integer_type_node);
id = get_identifier("ddm_thread_num");
field = build_decl (FIELD_DECL, id, integer_type_node);
TREE_CHAIN (field) = fields;
fields = field;
finish_builtin_struct(type, "__ddm_template", fields, NULL_TREE);
return type;
}
/* After this call I get somthing like struct __ddm_template
.ddm_template_instance.38; ...*/
static tree build_struct_instance(tree type) {
tree arg_struct_instance, var;
arg_struct_instance = create_tmp_var(type, ".ddm_template_instance");
return arg_struct_instance;
}
and I use them as
type = build_ddm_template_struct();
struct_instance = build_struct_instance(type);
fields = TYPE_FIELDS (type);
t = build3(COMPONENT_REF, type, struct_instance, fields, NULL_TREE);
tree astmt = build_gimple_modify_stmt(t,build_int_cstu
(lang_hooks.types.type_for_size (32, true),99));
print_generic_stmt(stderr, astmt,0); /* Here i get something like
.ddm_template_instance.38.loop_interations = 99; */
bsi_insert_after(&si, astmt, BSI_NEW_STMT);
This code will create an error when verify_loop_closed_ssa() is called.
I believe the problem is that loop_interations field does not get an SSA
name.
Can anyone help me fixing this problem.
Thanks in advance
Petros
Re: increasing the number of GCC reviewers
On Tue, 9 Jun 2009, Daniel Berlin wrote: > be, most things support it, and there are some cool possibilities, > like gerrit (http://code.google.com/p/gerrit/). It is precisely built I think a critical feature of any fancy code review system (or of how it is configured for GCC) used for a significant amount of GCC review is that all the patches and reviews are automatically sent to gcc-patches in plain text so that they get archived in the static list archives and can continue to be referred to that way, grepped, etc., after the next N transitions. Email replies to patch submissions should also continue to work smoothly. Given these requirements, anyone can use or not use any code review system as they please. Bugzilla has worked very well in this regard in allowing multiple workflows (reading new submissions and comments through email and replying there / searching for past bugs and replying through the web interface). > to handle the problem of finding the right reviewers, making sure > patches don't fall through the cracks, while still making sure it's I believe (based on observation of what has been done so far) people will submit patches in any way possible, including several we do not advise at all such as attaching patches against a GCC 3.x release tarball to a bug in Bugzilla or sending those patches to gcc-bugs, and making sure patches don't fall through the cracks means detecting patches sent in all these ways and tracking their status. -- Joseph S. Myers jos...@codesourcery.com
Re: increasing the number of GCC reviewers
> > GCC isn't really like that. Changes in one part can affect things much > > later on, and you really have to know why. That doesn't mean you have > > to understand all of the compiler, but you need to have a lot of > > knowledge. > > This is a problem with GCC's lack of modularity, not with Basile's > point of view. I don't think it's a totally modularity issue. Compilers, by their nature, are some of the most complicated and interdependent programs around. Sure, one could improve the modularity of GCC, but a key to evaluating a change is to know if the change is being done in the right place. In order to be able to make that determination, you have to know about all the other places that might also exist. Modularity isn't going to help THAT problem much.
Re: increasing the number of GCC reviewers
On Wed, 10 Jun 2009, Richard Kenner wrote: > > > GCC isn't really like that. Changes in one part can affect things much > > > later on, and you really have to know why. That doesn't mean you have > > > to understand all of the compiler, but you need to have a lot of > > > knowledge. > > > > This is a problem with GCC's lack of modularity, not with Basile's > > point of view. > > I don't think it's a totally modularity issue. Compilers, by their nature, > are some of the most complicated and interdependent programs around. Sure, > one could improve the modularity of GCC, but a key to evaluating a change > is to know if the change is being done in the right place. In order to be > able to make that determination, you have to know about all the other > places that might also exist. Modularity isn't going to help THAT problem > much. This is one area where reviews of the form "OK if there are (no objections / no objections from an area X maintainer) within 48 hours" can be useful: if a maintainer can judge that a patch will safely fix a problem but it's possible that a maintainer from another area, or a more specific maintainer, might judge that a different approach for a fix would be better. For that matter, a maintainer could comment on the choice of area in which to fix the bug without knowing about the precise details of how it should be fixed there; there are lots of partial review possibilities that already happen (and we don't need to classify them in detail, but may wish to encourage them where patches fall between maintainer areas). -- Joseph S. Myers jos...@codesourcery.com
Re: opaque vector types?
On Wednesday 06 May 2009, DJ Delorie wrote: > Is there an opaque vector type? Something that can be assigned > to/from other vector types of the same size, without warning? > > I'm working on a coprocessor which has separate SIMD arithmetic > operations for each data size, but only one SIMD logical operation for > all sizes. I.e. there's four ADD insns (V8QI, V4HI, etc) , but only > one AND insn. I'd like to use an opaque vector type for the AND > builtin, to avoid warnings. FWIW ARM/NEON solve this by defining the full set of builtins for all types, and some of them (e.g. AND) happen to expand to the same machine instructions. In practice I'd expect this actually makes writing vector code easier/safer because you don't loose type safety every time you use the AND builtin. Having some of your intrinsics be type specific, and some type agnostic seems a somewhat strange programming model. I'd expect everything to be types, or everything to use opaque vectors (and select the opcode based on the actual argument types). The latter is problematic because C doesn't really have polymorphism. Paul
Re: Expanding a load instruction
I'll be looking into this but I thought that GO_IF_LEGITIMATE_ADDRESS
is for branches ?
This is not my case. I've simplified my test case into:
struct test {
const char *name; /* full name */
chara; /* symbol */
signed char b;
unsigned short c; /* creation/c mask value */
};
extern struct test tab[]; /* the master list of tabter types */
void bar(unsigned short);
int main(void)
{
int i;
for (i=0;i<128;i++)
if(tab[i].b)
bar(tab[i].c);
}
The compiler loads tab[i].b and, to do so, loads up the address of &tab[i].b.
Then, when it wants to pass the value of tab[i].c it tries to do a
ldhu r5, 1(r10)
which is wrong in our case. Because it is loading a HI, the offset
must be a multiple of 2. It so happens that currently the problem is
arrising when considering this RTX
(insn:HI 77 76 124 struct2.c:17 (set (reg:DI 8 r8)
(sign_extend:DI (mem:HI (plus:DI (reg:DI 48 r48 [orig:134
ivtmp.19 ] [134])
(const_int 1 [0x1])) [0 S2 A16]))) 61
{extendhidi2_cyc64} (nil))
Am I wrong to think that, in this case, GO_IF_LEGITIMATE_ADDRESS would
not help? On my architecture, we actually have a scratch register we
can use.
I'm thinking of using a define_peephole2 to correct this as a later
pass, taking the address and moving it into a register thus getting a
0 offset.
I just feel that is so ugly, there should be a way to tell GCC that a
mem cannot be defined with:
(mem:HI (plus:DI (reg:DI 48 r48 [orig:134 ivtmp.19 ] [134])
(const_int 1 [0x1])) [0 S2 A16]))) 61
{extendhidi2_cyc64} (nil))
in the case of a HI because of the constant (and then same for SI/DI of course).
Thanks again for your help, and I will continue looking into this,
Jc
On Tue, Jun 9, 2009 at 6:36 PM, Dave
Korn wrote:
> Jean Christophe Beyler wrote:
>> Dear all,
>>
>> I've moved forward on this issue. Again, the problem is not that the
>> data is not aligned but that the compiler tries to generate this
>> instruction:
>>
>> (set (reg:HI 141) (mem/s/j:HI (plus:DI (reg:DI 134 [ ivtmp.23 ])
>> (const_int 1 [0x1])) [0 .geno+0 S2 A16]))
>>
>> And, in my target architecture, this is not authorized. I want to
>> transform this into:
>>
>> (set (reg:DI 135) (plus:DI (reg:DI 134 [ ivtmp.23 ])
>> (const_int 1 [0x1])) [0 .geno+0 S2 A16]))
>> (set (reg:HI 141) (mem/s/j:HI (reg:DI 135))
>>
>>
>> I've tried playing with define_expand, I can detect this problem, I
>> can emit my first move and then the second but for some reason, the
>> compiler reassembles them back together.
>>
>> Any ideas why I am getting that? Am I doing anything wrong? After I
>> expand this, I use the DONE macro...
>
>
> How about forbidding the form you don't allow in GO_IF_LEGITIMATE_ADDRESS?
>
> cheers,
> DaveK
>
Re: Expanding a load instruction
Jean Christophe Beyler wrote: > I'll be looking into this but I thought that GO_IF_LEGITIMATE_ADDRESS > is for branches ? No, absolutely not. GILA is a general filter that has overall control over which forms of addressing modes used to address memory may be generated in RTL. http://gcc.gnu.org/onlinedocs/gccint/Addressing-Modes.html Hmm, I must have been looking at a slightly outdated build of the docs; according to that page it's been deprecated on HEAD in favour of the hook TARGET_LEGITIMATE_ADDRESS_P. You'll need to check the particular sources you're using, that must be a fairly recent change(*). cheers, DaveK -- (*) - Yes: it was changed in r.147534, around four weeks ago. http://gcc.gnu.org/viewcvs?view=rev&revision=147534
RE: increasing the number of GCC reviewers
> -Original Message- > From: Joseph S. Myers [mailto:jos...@codesourcery.com] > Sent: Tuesday, June 09, 2009 6:51 PM > To: Ian Lance Taylor > Cc: Basile STARYNKEVITCH; GCC Mailing List > Subject: Re: increasing the number of GCC reviewers > > > At the human level I suspect it would help to have people who > watch for > submissions from non-regulars (including those attached to > Bugzilla) and > help them prepare patches following all the usual conventions > and get them > reviewed (checking for copyright assignments at an early > stage as needed) > and make sure the submissions don't get lost. At the > technical level, > while submissions on gcc-patches take a wide variety of > forms, approvals > are more restricted; it ought to be possible for software to do a > reasonably good job of tracking which submissions have been > reviewed / > approved / committed (including noticing people trying to > submit patches > through Bugzilla), and of identifying the most likely > relevant maintainers > to review patches, aided by humans in keeping the data clean. >From my experience having patches go to a mailing list is a sure way to have >them get lost. When it goes into someone's inbox, it's likely to get pushed >down, and "out of sight, out of mind" quickly. While the ML is archived, it is >not as useful to search through as having a specific patch tracker/database, >e.g. as found on SourceForge or Savannah projects. AFAIK the only gcc patch >tracker being used is not used on a mandatory basis. While I'm not suggesting that gcc use SF/Savannah, it seems odd that gcc has a bug database, but no patch tracking database.
Re: Expanding a load instruction
Ok, I wrongly read what this macro did. Sorry about that. I was
looking at the i386 port and use of this variable and this code came
up:
#ifdef REG_OK_STRICT
#define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR) \
do {\
if (legitimate_address_p ((MODE), (X), 1))\
goto ADDR; \
} while (0)
#else
#define GO_IF_LEGITIMATE_ADDRESS(MODE, X, ADDR) \
do {\
if (legitimate_address_p ((MODE), (X), 0))\
goto ADDR; \
} while (0)
#endif
and :
#define LEGITIMIZE_ADDRESS(X, OLDX, MODE, WIN) \
do {\
(X) = legitimize_address ((X), (OLDX), (MODE)); \
if (memory_address_p ((MODE), (X))) \
goto WIN; \
} while (0)
It seems that I should do the same as them no for my solution. First
implement the legitimate_address function and then probably define it
in both macros.
As for the target hook, we are using GCC 4.3.2 for the moment and,
sadly, have not yet any plans to move forward to the latest version of
GCC.
Thanks again,
Jc
On Wed, Jun 10, 2009 at 10:29 AM, Dave
Korn wrote:
> Jean Christophe Beyler wrote:
>> I'll be looking into this but I thought that GO_IF_LEGITIMATE_ADDRESS
>> is for branches ?
>
> No, absolutely not. GILA is a general filter that has overall control over
> which forms of addressing modes used to address memory may be generated in
> RTL.
>
> http://gcc.gnu.org/onlinedocs/gccint/Addressing-Modes.html
>
> Hmm, I must have been looking at a slightly outdated build of the docs;
> according to that page it's been deprecated on HEAD in favour of the hook
> TARGET_LEGITIMATE_ADDRESS_P. You'll need to check the particular sources
> you're using, that must be a fairly recent change(*).
>
>
> cheers,
> DaveK
> --
> (*) - Yes: it was changed in r.147534, around four weeks ago.
> http://gcc.gnu.org/viewcvs?view=rev&revision=147534
>
>
Re: increasing the number of GCC reviewers
Joseph S. Myers wrote: On Tue, 9 Jun 2009, Daniel Berlin wrote: be, most things support it, and there are some cool possibilities, like gerrit (http://code.google.com/p/gerrit/). It is precisely built I think a critical feature of any fancy code review system (or of how it is configured for GCC) used for a significant amount of GCC review is that all the patches and reviews are automatically sent to gcc-patches in plain text so that they get archived in the static list archives and can continue to be referred to that way, grepped, etc., after the next N transitions. Email replies to patch submissions should also continue to work smoothly. Yes, Daniel just mentioned a possibility. It is good to consider possible developments even if for now you're just keeping the old workflow. gerrit was developed at Google, but git's own development (and Linux's) proceeds only on mailing lists, and for this reason git has a command like git send-email --cc jos...@codesourcery.com master..HEAD to submit a private branch all at once to gcc-patches@ and CC you. :-) It is true however that currently we are not encouraging outsiders to contribute, because old timers work on mostly large patches (or large sequences of patches) that reviewers know about. For the same reason, it is easier for small patches to fall through the cracks than large ones. Paolo
RE: increasing the number of GCC reviewers
On Wed, 10 Jun 2009, Weddington, Eric wrote: > From my experience having patches go to a mailing list is a sure way to > have them get lost. When it goes into someone's inbox, it's likely to > get pushed down, and "out of sight, out of mind" quickly. While the ML > is archived, it is not as useful to search through as having a specific > patch tracker/database, e.g. as found on SourceForge or Savannah > projects. AFAIK the only gcc patch tracker being used is not used on a > mandatory basis. > > While I'm not suggesting that gcc use SF/Savannah, it seems odd that gcc > has a bug database, but no patch tracking database. Sure, a database is useful; I identified Bugzilla as a model that has worked well. Email works very well for the initial feed of all GCC development traffic since the last time it was checked including bugs, comments on bugs, patches and comments on patches, and provides the first pass of acquainting people with new developments coming in and allowing quick responses; the database for finding later bugs meeting given criteria that didn't get dealt with in the initial email pass. The database works well for tracking over time narrowly focused discussion on a particular well-defined bug; rather less well when the discussion diverges and there is no longer a clear concept of exactly what bug the database entry relates to (I think the same would apply to any system tracking patch discussion: it would get less useful when the discussion diverges away from a patch to deal with a clearly defined issue). If Bugzilla included patch attachments in the body of emails it sent rather than as URLs only, it might even work OK for patch review, especially if it could somehow tell when messages should go to gcc-patches and when to gcc-bugs. If I want to find a particular past *development* discussion, I don't necessarily remember which list it appeared on but may have other context for it; grepping my mailboxes for it sometimes helps, as may searching for information in the online archives, and in both cases it is very useful that bug discussions appear in gcc-bugs mailboxes and archives rather than needing a different search system in a different database to be used for those. Sending a message to my inbox and *not* to the relevant mailing list is a very good way of making it less likely I'll respond to it; I'll ignore direct copies of messages that "should have" gone to a mailing list on the basis that I'll deal with the list copy later when reading my list mailbox, but I may not notice that the message did not in fact go to a list after all. -- Joseph S. Myers jos...@codesourcery.com
Re: Expanding a load instruction
Jean Christophe Beyler wrote: > It seems that I should do the same as them no for my solution. First > implement the legitimate_address function and then probably define it > in both macros. Sounds about right. > As for the target hook, we are using GCC 4.3.2 for the moment and, > sadly, have not yet any plans to move forward to the latest version of > GCC. Don't need to worry about it until you go to GCC 4.5.0 or above, then. cheers, DaveK
Re: increasing the number of GCC reviewers
On Wed, 10 Jun 2009, Paolo Bonzini wrote: > It is true however that currently we are not encouraging outsiders to > contribute, because old timers work on mostly large patches (or large > sequences of patches) that reviewers know about. For the same reason, it is > easier for small patches to fall through the cracks than large ones. And for all the other reasons I mentioned about patches from outsiders being liable to be harder to review. And when they are reviewed the contributor may lose interest and not go through all the steps needed to address issues from the review. So I don't think any tracking system should treat "needs changes from the submitter" as a state meaning "maintainers can ignore this indefinitely until a new submission"; patches in that state from new contributors could just as much do with human help from more experienced contributors to get the patches into shape (and I think such human help for badly formed contributions would be just as valuable in attracting new contributors as any technical solutions). -- Joseph S. Myers jos...@codesourcery.com
Re: skip_evaluation
In asking this, I'm particularly puzzled by code like this in
build_base_path in cp/class.c:
/* Don't bother with the calculations inside sizeof; they'll ICE if the
source type is incomplete and the pointer value doesn't matter. */
if (skip_evaluation)
{
expr = build_nop (build_pointer_type (target_type), expr);
if (!want_pointer)
expr = build_indirect_ref (EXPR_LOCATION (expr), expr, NULL);
return expr;
}
Presumably the early return is OK within a sizeof expression; it is OK
within an expression like (0 ? x : y)?
From reading the code, I'd say yes. The bug that Jason fixed is
related to stuff that cannot appear within a constant expression except
within sizeof -- for example
struct B {};
struct D : public B {
static const int i = sizeof((B*)(D*)0);
};
struct Z {};
struct A : Z {};
Z* implicitToZ (Z*);
struct B : A {
static const int i = sizeof(implicitToZ((B*)0));
};
struct B {};
struct D;
D* p;
struct D: public B {
static const int i = sizeof ((B*)p);
};
(see PR27177). All of these would still be forbidden within (0?x:y).
Paolo
Re: AW: AIX link error with g++ 4.4.0
"Fehringer Franz" writes: > I have exactly the same error like described in > http://gcc.gnu.org/ml/gcc-help/2009-05/msg00323.html > namely > collect2: library libstdc++ -lsupc++ not found > I have a POWER6 with AIX 6.1.2, for the build --disable-shared was used > (i think this is the reason why this error does not show up in regular > shared library builds). > When i invoke g++ with both -v and -save-temps and then invoke the final > collect2 step manually (using cut and paste) the link succeeds. > According to my investigations, the reason for this kind of failure is > * collect2 is executed via execvp in gcc.c resp. pex-unix.c > * the link line (i.e. the collect2 invocation) contains -lstdc++ > -lsupc++ since we are in the C++ realm. > * The error now is, that -lstdc++ -lsupc++ is given in the execvp > argument vector as one argument instead two separate arguments. > * As a result the call to resolve_lib_name in collect2.c fails, > since it can handle only one -lxxx per call and not multiple ones. > Should i file a bug report and is there an easy resolution? Please never send e-mail to both gcc-h...@gcc.gnu.org and g...@gcc.gnu.org. This message is only appropriate for gcc-h...@gcc.gnu.org. Thanks. The bug is in the way that gcc/gpg++spec.c uses LIBSTDCXX_STATIC, or possibly in the way that macro is defined in gcc/config/rs6000/aix.h. I don't see a simple fix. Please do file a bug, per http://gcc.gnu.org/bugs.html. Thanks. Ian
Re: AW: AIX link error with g++ 4.4.0
Ian Lance Taylor wrote: > "Fehringer Franz" writes: > >> I have exactly the same error like described in >> http://gcc.gnu.org/ml/gcc-help/2009-05/msg00323.html >> namely >> collect2: library libstdc++ -lsupc++ not found > The bug is in the way that gcc/gpg++spec.c uses LIBSTDCXX_STATIC, or > possibly in the way that macro is defined in gcc/config/rs6000/aix.h. I > don't see a simple fix. This is something I hacked together a while ago vs. 4.3.2 when I discovered you couldn't add -lsupc++ to LIBSTDCXX_STATIC because it counts as a single word in argv. (I later decided I didn't need to do this anyway, can't remember why I thought I needed to.) It's unconditional and would need to be made so but I think it would be the basis of a solution. Franz, you could attach it to the bug report when you file it, it might be useful to somebody. cheers, DaveK diff -purN -x CYGWIN-PATCHES -x 'aclocal.m4*' -x autom4te.cache -x config.cache -x config.log -x config.status -x config.h -x config.h.in -x ABOUT-NLS -x Makefile.in.in -x Makevars.template -x '*SlackBuild*' -x '*.egg-info' -x '*.class' -x '*.pyc' -x '*.mo' -x '*.gmo' -x '*.orig' -x '*.rej' -x '*.spec' -x '*.temp' -x '*~' -x '*.stackdump' -x COPYING -x INSTALL -x compile -x config-ml.in -x config.guess -x config.sub -x depcomp -x elisp-comp -x install-sh -x libtool.m4 -x ltoptions.m4 -x ltsugar.m4 -x ltversion.m4 -x 'lt~obsolete.m4' -x ltmain.sh -x mdate-sh -x missing -x mkinstalldirs -x py-compile -x symlink-tree -x texinfo.tex -x ylwrap -x config.rpath -x configure -x omf.make -x xmldocs.make -x gnome-doc-utils.make -x gnome-doc-utils.m4 -x intltool.m4 -x intltool-extract -x intltool-extract.in -x intltool-merge -x intltool-merge.in -x intltool-update -x intltool-update.in origsrc/gcc-4.3.2/gcc/cp/g++spec.c src/gcc-4.3.2/gcc/cp/g++spec.c --- origsrc/gcc-4.3.2/gcc/cp/g++spec.c 2007-08-06 12:10:19.0 +0100 +++ src/gcc-4.3.2/gcc/cp/g++spec.c 2008-09-08 01:42:32.96875 +0100 @@ -44,6 +44,9 @@ along with GCC; see the file COPYING3. #ifndef LIBSTDCXX_PROFILE #define LIBSTDCXX_PROFILE LIBSTDCXX #endif +#ifndef LIBSUPCXX +#define LIBSUPCXX "-lsupc++" +#endif void lang_specific_driver (int *in_argc, const char *const **in_argv, @@ -257,7 +260,7 @@ lang_specific_driver (int *in_argc, cons #endif /* Make sure to have room for the trailing NULL argument. */ - num_args = argc + added + need_math + shared_libgcc + (library > 0) + 1; + num_args = argc + added + need_math + shared_libgcc + (library > 0 ? 2 : 0) + 1; arglist = XNEWVEC (const char *, num_args); i = 0; @@ -319,6 +322,10 @@ lang_specific_driver (int *in_argc, cons if (arglist[j][0] != '-' || arglist[j][1] == 'l') added_libraries++; j++; + arglist[j] = LIBSUPCXX; + if (arglist[j][0] != '-' || arglist[j][1] == 'l') + added_libraries++; + j++; } if (saw_math) arglist[j++] = saw_math;
Re: skip_evaluation
Paolo Bonzini writes:
>> Presumably the early return is OK within a sizeof expression; it is OK
>> within an expression like (0 ? x : y)?
>
> From reading the code, I'd say yes. The bug that Jason fixed is
> related to stuff that cannot appear within a constant expression
> except within sizeof -- for example
>
>struct B {};
>struct D : public B {
>static const int i = sizeof((B*)(D*)0);
>};
>
>struct Z {};
>struct A : Z {};
>Z* implicitToZ (Z*);
>struct B : A {
>static const int i = sizeof(implicitToZ((B*)0));
>};
>
>struct B {};
>struct D;
>D* p;
>struct D: public B {
>static const int i = sizeof ((B*)p);
>};
>
> (see PR27177). All of these would still be forbidden within (0?x:y).
OK, but should they perhaps give an error which would perhaps not be
given if skip_evaluation is true?
Ian
RE: increasing the number of GCC reviewers
> -Original Message- > From: Joseph Myers [mailto:jos...@codesourcery.com] > Sent: Wednesday, June 10, 2009 8:52 AM > To: Weddington, Eric > Cc: Ian Lance Taylor; Basile STARYNKEVITCH; GCC Mailing List > Subject: RE: increasing the number of GCC reviewers > > > While I'm not suggesting that gcc use SF/Savannah, it seems > odd that gcc > > has a bug database, but no patch tracking database. > > Sure, a database is useful; I identified Bugzilla as a model that has > worked well. I would think that setting up a bugzilla database for patches would might allow some clarification of the approval process. Fields could be set up to categorize the patch into one or more approval areas (e.g. patch needs approval from target maintainer and middle-end maintainer), and ways to mark the patch with what is needed (e.g., needs ChangeLog, GNU coding standards, fix in specified area (w/ reference to comment), etc.), general status of patch (e.g. NEW, WAITING FOR CHANGE, APPROVED, REJECTED, whatever), priority and target milestone. Perhaps with having a database of patches, reviewers could search for "open patches" and pick and choose a patch to review as they like and time permitting, much like it's done with the bug database today. If people do not want to be promoted to reviewers today because of the fear that they cannot keep up with gcc-patches (that somehow they have to keep track of every single patch coming in), then maybe a patch database is way to allow them to ease into participating in the review process and to do the partial reviews that would still help move things along.
Re: skip_evaluation
struct B {};
struct D : public B {
static const int i = sizeof((B*)(D*)0);
};
struct Z {};
struct A : Z {};
Z* implicitToZ (Z*);
struct B : A {
static const int i = sizeof(implicitToZ((B*)0));
};
struct B {};
struct D;
D* p;
struct D: public B {
static const int i = sizeof ((B*)p);
};
(see PR27177). All of these would still be forbidden within (0?x:y).
OK, but should they perhaps give an error which would perhaps not be
given if skip_evaluation is true?
build_cp_class does not give errors after it tests skip_evaluation. The
constant-expression errors are given in the parsers.
Paolo
Re: skip_evaluation
On Wed, Jun 10, 2009 at 10:51 AM, Paolo Bonzini wrote:
>
>>> struct B {};
>>> struct D : public B {
>>> static const int i = sizeof((B*)(D*)0);
>>> };
>>>
>>> struct Z {};
>>> struct A : Z {};
>>> Z* implicitToZ (Z*);
>>> struct B : A {
>>> static const int i = sizeof(implicitToZ((B*)0));
>>> };
>>>
>>> struct B {};
>>> struct D;
>>> D* p;
>>> struct D: public B {
>>> static const int i = sizeof ((B*)p);
>>> };
>>>
>>> (see PR27177). All of these would still be forbidden within (0?x:y).
>>
>> OK, but should they perhaps give an error which would perhaps not be
>> given if skip_evaluation is true?
>
> build_cp_class does not give errors after it tests skip_evaluation. The
> constant-expression errors are given in the parsers.
which arguably is not a good place to issue such errors. Support
for constexpr implies that we refrain from issuing such semantics
error from the parser. However, constexpr patches will come somewhere in
July, so Ian probably does not want to wait for that now.
-- Gaby
Re: increasing the number of GCC reviewers
On Wed, Jun 10, 2009 at 08:15, Richard Kenner wrote: >> This is a problem with GCC's lack of modularity, not with Basile's >> point of view. > > I don't think it's a totally modularity issue. Compilers, by their nature, > are some of the most complicated and interdependent programs around. I agree. Modularity mostly gives you modular complexity, it does not reduce the inherent complexity of the compiler. It does make some aspects of reviewing easier to handle, of course. Diego.
Re: Polyhedral Model
On Mon, 2009-04-27 at 19:26 -0300, Cristianno Martins wrote: > Hi, > > Thank you for helping me with those informations. From now on, I'll be > checking the Graphite framework, and I intend to contribute to that by > providing support to automatic parallelization. However, my project > focus on multicore architectures; I guess this is not a problem, is > it? Hey Christiano, I have not heard anything from you for a while. How is your project going? Tobi > > Thanks in advance, > > On Mon, Apr 27, 2009 at 6:46 PM, Tobias Grosser wrote: > > On Mon, 2009-04-27 at 19:58 +0100, Dave Korn wrote: > >> Cristianno Martins wrote: > >> > >> > Well, I didn't find anything about a implementation of this kind of > >> > optimization inside of gcc. Also, I need to know if someone is working > >> > on something like this using the gcc compiler. > >> > >> http://gcc.gnu.org/wiki/Graphite > >> > > > > Yes this is the right point and you are welcome to take part in > > development of Graphite. To be honest there is a lot of work left to be > > done even if there are already working several people on Graphite. ;-) > > If you want you can join our weekly phone calls on Wednesday or you just > > sent some questions to the mailing lists so we can help you to get > > started with graphite. > > The file that might be interesting for you is graphite-poly.h in the > > graphite branch. This is the interface/data structure of our polyhedral > > representation. It would be great if you could look into it and give us > > some feedback. > > > > Tobias > > > > > > >
Re: Please update http://gcc.gnu.org/gcc-4.3/buildstat.html
Dennis Clarke wrote: > How did you do with the new PPL bits ? That went smoothly ? They're not mandatory for 4.4.x so I've simply ignored them for now. -tgc
Re: git mirror at infradead?
Bernie Innocenti wrote: I won't re-create the repository from scratch, then. re-creating it from scratch should be fine as long as the metadata uses svn+ssh://gcc.gnu.org/svn/gcc. I'd think that git svn clone -s file://path/to/svn/root \ --rewrite-root=svn+ssh://gcc.gnu.org/svn/gcc would be the way to go. Jason
Re: Please update http://gcc.gnu.org/gcc-4.3/buildstat.html
> Dennis Clarke wrote: > > How did you do with the new PPL bits ? That went smoothly ? >> > They're not mandatory for 4.4.x so I've simply ignored them for now. ah .. how very tricky of you :-) Dennis
Re: git mirror at infradead?
On Wed, Jun 10, 2009 at 9:38 PM, Jason Merrill wrote: > Bernie Innocenti wrote: >> >> I won't re-create the repository from scratch, then. > > re-creating it from scratch should be fine as long as the metadata uses > svn+ssh://gcc.gnu.org/svn/gcc. I'd think that > > git svn clone -s file://path/to/svn/root \ > --rewrite-root=svn+ssh://gcc.gnu.org/svn/gcc > > would be the way to go. Unless git svn fixed a bug i reported about rewrite roots, this will crash eventually. I had to work around it with some hacks :( > > Jason >
