Re: How to GTYize a struct properly?
> ../../gcc-boehm-custom-marking/gcc/value-prof.h:48: syntax error,
> unexpected '*', expecting ')'
>
> What should I do about it?
>
Have to typedef the pointer due to gengtype silliness, IIRC.
IE typedef struct histogram_value_t *histogram_value_t_p;
then use histogram_value_t_p in the structure with the gty marker.
Still not too good:
/* The value to measure. */
typedef struct histogram_value_t *histogram_value;
struct histogram_value_t GTY(())
{
struct
{
tree value;/* The value to profile. */
tree stmt; /* Insn containing the value. */
gcov_type *counters; /* Pointer to first counter. */
histogram_value GTY((chain_next("%h.next"))) next; /* Linked
list pointer. */
} hvalue;
enum hist_type type; /* Type of information to measure. */
unsigned n_counters; /* Number of required counters. */
union
{
struct
{
int int_start;/* First value in interval. */
unsigned int steps; /* Number of values in it. */
} intvl;/* Interval histogram data. */
} GTY((default("intvl"))) hdata; /* Profiled information specific
data. */
};
../../gcc-boehm-custom-marking/gcc/value-prof.h:45: syntax error,
unexpected '{', expecting ID
The error is on the opening bracket on the first inner anonymous
struct. Maybe this struct should be made non-inner or non-anonymous?
Also, what's the deal with single-element union?
--
Laurynas
comparison is always true due to limited range of data type
I was told in January that the "comparison is always true due to
limited range of data type" warning has been guarded by -Walways-true
in gcc-4.2.0. But it's still issued unconditionally in
gcc-4.2.0-0.20060806r115974.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
Re: type consistency of gimple
Mark Mitchell wrote: > Kenneth Zadeck wrote: > > So, I guess my inclination would be to just write out the type > information now, and thereby avoid the dependency on fixing GIMPLE. > Please don't take this the wrong way, but this approach is the reason GIMPLE is not flat/tupelized, not type consistent *right now*, and why this discussing is even occurring at all. I do not *fault* Diego (and others) for the decision to get a prototype of GIMPLE/tree-ssa first, and clean it up later. As a matter of fact, I would have done the same thing and made the same choices. But we should be aware that most of the time, the hard cleanup never comes because: 1. you quickly gain critical mass of others contributing passes right after the prototype is written (this is what happened with GIMPLE/tree-ssa, even though the thing was changing out from under us, and in fact, a lot of the passes that depended on it don't even exist today, like goto-elimination :P) 2. By the time you are done enough with the prototype that you feel comfortable going back to fix it, the number of things depending on the way the prototype does things has raised the engineering effort to revisit the decisions from person months to person years. 3. It's very hard to do it incrementally, because anything can generate trees that violate the invariants. The only real incremental approach is to pick a point in the compiler, and ensure that everything up to that point generates okay trees, and verify at that point. Then you keep moving the point forward. There are other reasons, of course, such as resource and people management, but hard incrementalness generally means no "spare-time contributors" will attack it. I'm not saying your approach isn't the way to go, I'm just saying that we should be aware that rarely have we actually been able to revisit the the changes we want to revisit later on, when it has come to serious infrastructure. If this is a cleanup we actually want done, IMHO, we should do it first. --Dan
Re: building gcc 4.1.1 on HP-UX 10.20
On Sat, Aug 12, 2006 at 02:53:47PM -0400, John David Anglin wrote: > > In order to build gcc 4.1.1 on HP-UX 10.20 I had to install GNU awk > > and also configure with --disable-threads. The vendor's awk did not > > build the options.h file correctly; the exact symptom was duplicated > > OPT_d and OPT_w symbols in the enum. Then, the build blew up when it > > tried to use pthreads (which don't exist on HP-UX 10.20, or at least > > not in a form that gcc expects). > > Bug reports should be filed for these two problems. Do you have > PHCO_20721 and PHCO_26158 installed? Locale might the behavior > of awk in generating options.h. I have PHCO_20721 installed, but not PHCO_26158. And I just wasted about a half hour of my life trying to *find* it. It seems that HP has not only stopped writing patches for HP-UX 10.20 (which is fine, understandable) but has also removed them all from their machines. I haven't tried the Bit Torrent networks yet :-/ My locale is set to 'en_US.iso88591'. Here's the exact sequence (without gawk available): $ bzip2 -dc gcc-core-4.1.1.tar.bz2 | tar xvf - $ bzip2 -dc gcc-g++-4.1.1.tar.bz2 | tar xvf - $ mkdir gcc-build $ cd gcc-build $ CC=/net/appl/gcc-3.3/bin/gcc LANG=C ../gcc-4.1.1/configure --prefix=/net/appl/gcc-4.1 --with-gnu-as --enable-languages=c,c++ $ make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap [...] /net/appl/gcc-3.3/bin/gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/build -I../../gcc-4.1.1/gcc/../include -I./../intl -I../../gcc-4.1.1/gcc/../libcpp/include -o build/genmddeps.o ../../gcc-4.1.1/gcc/genmddeps.c In file included from tm.h:5, from ../../gcc-4.1.1/gcc/genmddeps.c:21: options.h:318: error: redefinition of `OPT_d' options.h:316: error: `OPT_d' previously defined here options.h:797: error: redefinition of `OPT_w' options.h:795: error: `OPT_w' previously defined here make[2]: *** [build/genmddeps.o] Error 1 $ sed -n -e 316,318p -e 795,797p gcc/options.h OPT_d, /* -d */ OPT_D, /* -D */ OPT_d, /* -d */ OPT_w, /* -w */ OPT_W, /* -W */ OPT_w, /* -w */ $ what /usr/bin/awk /usr/bin/awk: $Revision: 78.14.1.16 $ PATCH_10_20: awk.g.o awk.lx.o b.o main.o tran.o lib.o run.o parse.o proctab.o hpux_rel.o 99/12/17 (Oops... looks like I forgot to set LANG=C on the make as well as the configure. I don't want to go back and redo the bootstrap now.) > Personally, I always use GNU tools (e.g., gawk, sed, make, texinfo) > for my builds as I find this avoids a lot of problems. Yes, I'm using GNU sed and GNU make already. The issues with HP-UX 10.20's sed and GCC are well known, but this is the first time I've run into an awk issue, so I figured it should be documented. $ cd gcc $ gawk -f ../../gcc-4.1.1/gcc/opt-gather.awk ../../gcc-4.1.1/gcc/c.opt ../../gcc-4.1.1/gcc/common.opt ../../gcc-4.1.1/gcc/config/pa/pa.opt ../../gcc-4.1.1/gcc/config/pa/pa-hpux.opt ../../gcc-4.1.1/gcc/config/pa/pa-hpux1010.opt > tmp-optionlist $ /bin/sh ../../gcc-4.1.1/gcc/../move-if-change tmp-optionlist optionlist $ gawk -f ../../gcc-4.1.1/gcc/opt-functions.awk -f ../../gcc-4.1.1/gcc/opth-gen.awk \ < optionlist > tmp-options.h $ /bin/sh ../../gcc-4.1.1/gcc/../move-if-change tmp-options.h options.h $ cd .. $ make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap [...now it gets past the awk problem...] > Regarding the use of pthreads, that's strange. Without --disable-threads, > GCC should use DCE threads on hpux10. GCC definitely knows about the > threads available in HP-UX 10. See for example, gthr-dce.h. I have GNU pth installed in /usr/local, and (according to gcc/config.log) it's finding pthread.h. This is probably confusing it. [...] ./xgcc -B./ -B/net/appl/gcc-4.1/hppa2.0-hp-hpux10.20/bin/ -isystem /net/appl/gcc-4.1/hppa2.0-hp-hpux10.20/include -isystem /net/appl/gcc-4.1/hppa2.0-hp-hpux10.20/sys-include -L/usr/local/src/gcc-build/gcc/../ld -O2 -O2 -O -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -D_T_HPUX10 -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I -I../../gcc-4.1.1/gcc -I../../gcc-4.1.1/gcc/ -I../../gcc-4.1.1/gcc/../include -I./../intl -I../../gcc-4.1.1/gcc/../libcpp/include -threads -fexceptions -c ../../gcc-4.1.1/gcc/unwind-dw2.c -o libgcc/threads/unwind-dw2.o In file included from ../../gcc-4.1.1/gcc/gthr.h:103, from ../../gcc-4.1.1/gcc/unwind-dw2.c:42: ../../gcc-4.1.1/gcc/gthr-dce.h: In function
Re: type consistency of gimple
Daniel Berlin wrote on 08/14/06 09:04: > If this is a cleanup we actually want done, IMHO, we should do it first. > Agreed. This is a good opportunity for us to design a GIMPLE type system. Besides the obvious space savings and cleanliness, it is also needed to remove lang_hooks.types_compatible_p. Jeff's point about our optimizers is also true. Nick, remember that issue with MIPS optimizations you were discussing with Jeff a few days ago? I didn't follow most of the details, but it involved ivopts and sign issues. Could you send a summary? If we had a GIMPLE type-system, we could allow the implicit type conversions. However, having implicit type conversions implies having types associated with expression tree leaves. Space-wise, it's best if we can have types at expression tree roots.
Re: type consistency of gimple
Daniel Berlin wrote: > Mark Mitchell wrote: >> Kenneth Zadeck wrote: >> >> So, I guess my inclination would be to just write out the type >> information now, and thereby avoid the dependency on fixing GIMPLE. > Please don't take this the wrong way, but this approach is the reason > GIMPLE is not flat/tupelized, not type consistent *right now*, and why > this discussing is even occurring at all. I agree with the thrust of your email. If engineering excellence were our primary goal, and we had a master engineering plan for GCC, and we all committed to following the master plan, we'd clearly put something like type-consistent GIMPLE early on the plan because everyone agrees it is The Right Thing from an engineering point of view. However, (a) all of the antecedents in the previous sentence are false, and (b) we are resource-limited. So, GCC development tends to let the pressure build on some set of infrastructure until it has been painfully obvious for some amount of time that it has to change. (In my experience, the same thing happens in developing proprietary software; convincing product management to let you spend significant time fixing something that's not on the next release's feature list requires some good salesmanship.) Demonstrating proof-of-concept for functionality is important because it (a) builds community interest (as you mention by saying how new code tends to appear immediately after something works), and (b) convinces people with resources (including companies and individuals that make non-sponsored contributions to the toolchain) that a particular technology has good potential RoI. I think the ultimate question here is the usual: is this the *best* use of the engineering time we have available? And that value-judgment is ultimately made by the people funding LTO; I haven't yet had a chance to talk to our customer about this issue. But, my personal opinion is that I would rather see LTO working, and not try to solve orthogonal problems along the way. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: type consistency of gimple
Diego Novillo wrote: > If we had a GIMPLE type-system, we could allow the implicit type > conversions. Right, I was trying to make this point earlier, but not being clear. It doesn't matter if every last conversion is explicit, as long as there are clear rules about where conversions may be implicit, and what the semantics of those conversions are. The question of where exactly to let implicit conversions occur can be driven by space considerations and convenience. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: How to GTYize a struct properly?
"Laurynas Biveinis" <[EMAIL PROTECTED]> writes:
> > > ../../gcc-boehm-custom-marking/gcc/value-prof.h:48: syntax error,
> > > unexpected '*', expecting ')'
> > >
> > > What should I do about it?
> > >
> >
> > Have to typedef the pointer due to gengtype silliness, IIRC.
> >
> > IE typedef struct histogram_value_t *histogram_value_t_p;
> >
> > then use histogram_value_t_p in the structure with the gty marker.
>
>
> Still not too good:
>
> /* The value to measure. */
> typedef struct histogram_value_t *histogram_value;
> struct histogram_value_t GTY(())
> {
> struct
> {
> tree value; /* The value to profile. */
> tree stmt; /* Insn containing the value. */
> gcov_type *counters;/* Pointer to first counter. */
> histogram_value GTY((chain_next("%h.next"))) next; /*
> Linked
> list pointer. */
> } hvalue;
> enum hist_type type;/* Type of information to
> measure. */
> unsigned n_counters;/* Number of required counters.
> */
> union
> {
> struct
> {
> int int_start;/* First value in interval. */
> unsigned int steps; /* Number of values in it. */
> } intvl;/* Interval histogram data. */
> } GTY((default("intvl"))) hdata;/* Profiled information
> specific data. */
> };
>
> ../../gcc-boehm-custom-marking/gcc/value-prof.h:45: syntax error,
> unexpected '{', expecting ID
>
>
> The error is on the opening bracket on the first inner anonymous
> struct. Maybe this struct should be made non-inner or non-anonymous?
> Also, what's the deal with single-element union?
gengtype doesn't support anonymous structures or unions, you need to
give them a name. (I don't remember if this is simply a limitation of
the existing implementation or if it's more fundamental.)
Wrong code generated (assignment incorrectly optimized out)
This is gcc-4.2.0-0.20060806r115974
Source:
--
typedef struct descr *descr_t;
typedef descr_t *value_t;
struct descr {descr_t descr;};
typedef struct {descr_t descr; value_t fields[2];} object_t_2;
value_t **marked_top, **marked_limit;
void gc(void);
object_t_2 pair_12138, list_12140, pair_12196, list_12198, pair_12319,
list_12321, list_12328, pair_12334, pair_12336, record_12376,
pair_12413, list_12415, record_12420;
value_t symbol_7584, symbol_12137, symbol_7525, symbol_11238, symbol_7778,
symbol_12326, symbol_11917, symbol_7927, symbol_7525, symbol_11238,
symbol_12335, CheckArity, symbol_7584, symbol_7583, BadArguments;
static inline void
set_global_field(value_t obj, int i, value_t value) {
value_t *ptr = (value_t *)obj + i + 1;
*ptr = value;
*marked_top++ = ptr;
if (marked_limit < marked_top) gc();
}
int test(void) {
set_global_field(&pair_12138.descr, 0, symbol_7584);
set_global_field(&list_12140.descr, 0, symbol_12137);
set_global_field(&pair_12196.descr, 0, symbol_7525);
set_global_field(&list_12198.descr, 0, symbol_7778);
set_global_field(&pair_12319.descr, 1, symbol_11238);
set_global_field(&list_12321.descr, 0, symbol_7778);
set_global_field(&list_12328.descr, 0, symbol_11917);
set_global_field(&pair_12334.descr, 0, symbol_7525);
set_global_field(&pair_12334.descr, 1, symbol_11238);
set_global_field(&pair_12336.descr, 0, symbol_12335);
set_global_field(&record_12376.descr, 0, CheckArity);
set_global_field(&pair_12413.descr, 0, symbol_7584);
set_global_field(&list_12415.descr, 0, symbol_7583);
set_global_field(&record_12420.descr, 0, BadArguments);
return 0;
}
--
When compiled with gcc -S -O2 source.c, the last set_global_field call
generates the following code:
leal4(%edx), %eax
cmplmarked_limit, %eax
movlBadArguments, %ecx
movl$record_12420+4, (%edx)
movl%eax, marked_top
jbe .L28
movl%ecx, record_12420+4
callgc
.L28:
leave
xorl%eax, %eax
ret
The assignment of BadArguments to the field of record_12420
is performed only in one branch, while it should be done
unconditionally.
Reducing the number of set_global_field calls avoids the bug.
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
Re: building gcc 4.1.1 on HP-UX 10.20
> > Regarding the use of pthreads, that's strange. Without --disable-threads, > > GCC should use DCE threads on hpux10. GCC definitely knows about the > > threads available in HP-UX 10. See for example, gthr-dce.h. > > I have GNU pth installed in /usr/local, and (according to gcc/config.log) > it's finding pthread.h. This is probably confusing it. Definitely. The configuration process isn't set up to handle GNU pth. It would take a bit of work to check for GNU pth, and to provide the necessary option and spec support to build and link with GNU pth. Dave -- J. David Anglin [EMAIL PROTECTED] National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Re: LOG_LINKS field not set because of gcse1 (or fwprop1) pass
On Mon, Aug 14, 2006 at 08:37:41AM +0200, Paolo Bonzini wrote:
> But isn't reg 32 dead, because it is only set by insn 98:
>
> (insn 98 96 101 9 (set (reg/v:HI 32 [ size ])
> (reg:HI 43)) 33 {movhi} (insn_list:REG_DEP_TRUE 96 (nil))
> (nil))
>
> after copyprop?
No, because insn 96, which reads reg 32, might be executed the next time
through the loop.
--
Rask Ingemann Lambertsen
Re: Wrong code generated (assignment incorrectly optimized out)
> > This is gcc-4.2.0-0.20060806r115974 Can you submit a real bug report to http://gcc.gnu.org/bugzilla as mentioned on http://gcc.gnu.org/bugs.html? Thanks, Andrew Pinski
Re: gcc4.2 compiler
On Aug 11, 2006, at 4:21 AM, kees de jong wrote: When I changed the program to use openmp and compiled it with the new -fopenmp switch, everything went fine. But what amazed me, on running this program it only used 6 seconds to complete the multiplication! Glad to hear it and thanks for the feedback.
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: >> And back to my original answer: it's up to each language to decide >> that. > > Hence my original question: is it legal or not? What did the C++ > developers decide? The C++ standard implies that for all pointer-to-object types have the same size and that all pointer-to-function types have the same size. (Technically, it doesn't say that that; it says that you can convert T* -> U* -> T* and get the original value.) However, nothing in the standard says that pointer-to-object types must have the same size as pointer-to-function types. In theory, I believe that G++ should permit the sizes to be different. However, as far as I know, none of the G++ developers considered that possibility, which probably means that we have made the assumption that they are all the same size at some points. I would consider places where that assumption is made to be bugs in the front end. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: gcc4.2 compiler
kees de jong wrote on 08/11/06 07:21: > If you want to look at the program concerned, please > let me know that. I can than make some small > alterations (it is a little bit interactive, using the > Dutch language) and send it to you. > Thanks for the feedback. As long as your code is not doing heavy synchronization or task spawning, the OMP runtime will not interfere much. Perhaps you'd be interested in setting up performance tracking on your application and/or compare to other OMP implementations?
Re: type consistency of gimple
Hi, On Mon, 14 Aug 2006, Mark Mitchell wrote: > pressure build on some set of infrastructure until it has been painfully > obvious for some amount of time that it has to change. (In my > experience, the same thing happens in developing proprietary software; > convincing product management to let you spend significant time fixing > something that's not on the next release's feature list requires some > good salesmanship.) How true :) Nevertheless the goals for the FSF GCC should IMHO be purely based on rather technical arguments and considerations, not the drive by paying customers. Normally we have the maintainer concept to guarantee some sort of that. This obviously creates conflicts when maintainers having to accept the solution and developers creating that solution (for customers or driven by own demand doesn't matter) are the same people. I think if in doubt the maintainer hat should win and I realize this is sometimes difficult (because the danger is that a feature will not be implemented at all if the customer isn't paying the cleanup, but the cleanup is the prerequisite to accept the feature). I have no good solution for this, but I feel that rushing things in because of customer milestones or deadlines is the wrong thing (I'm not accusing you of rushing things). Especially if most of the involved people agree on what is optimal on a technical basis nothing should prevent that from becoming implemented. Ciao, Michael.
Re: type consistency of gimple
> Diego Novillo writes: Diego> Agreed. This is a good opportunity for us to design a GIMPLE type Diego> system. Besides the obvious space savings and cleanliness, it is also Diego> needed to remove lang_hooks.types_compatible_p. And this last statement is the key point. We can and probably should implement a prototype LTO without cleaning up the type system, but for LTO to be usable in a production compiler, the GIMPLE type system will need to be fixed. Cleaning the type system is not an immediate requirement -- not a dependency for the initial implementation of LTO -- but LTO cannot be generally usable without this problem being addressed. A more compact representation is a byproduct, but multi-language correctness is necessary for full, production functionality. David
Re: type consistency of gimple
Michael Matz wrote: >> pressure build on some set of infrastructure until it has been painfully >> obvious for some amount of time that it has to change. (In my >> experience, the same thing happens in developing proprietary software; >> convincing product management to let you spend significant time fixing >> something that's not on the next release's feature list requires some >> good salesmanship.) > > How true :) Nevertheless the goals for the FSF GCC should IMHO be purely > based on rather technical arguments and considerations, not the drive by > paying customers. Even when I was contributing purely as a volunteer, I had motivations of my own, like wanting to use a particular feature in a program I was writing. I don't think we can realistically expect that the SC can set up a master plan for everyone to follow. The SC or the maintainers are in my opinion completely justified in blocking the inclusion of a technically inferior patch, even if it has some short-term benefit. There's no reason that any contributor should get to jam in a patch that's going to make things hard for everyone else in future. So, I'm not arguing that "whoever gets there first wins", by any means. But, I don't think we can ignore the motivations of contributors, either; we've got to accept that they'll invest time/effort/money in GCC only to the extent they see return on that investment. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
[C frontend] Wtraditional / Wconversion and decimal float
Dear all,
Wtraditional warns for "Conversions by prototypes between
fixed/floating point values and vice versa. The absence
of these prototypes when compiling with traditional C would cause
serious problems. "
In addition, the following program:
void ffloat(float x);
void h(void)
{
float y;
ffloat(y);
}
compiled with gcc -Wtraditional gives the following warning : passing
argument 1 of 'ffloat' as 'float' rather than 'double' due to
prototype
In the case of decimal float values, apart from conversions between
integers and decimal float and viceversa, Wtraditional also warns for
conversions between decimal and binary floats and for conversions from
a decimal float type to a smaller decimal float type.
My questions are:
1) Which are the rules when compiling with traditional C, no
prototype is given and decimal floats are involved?
2) If the above question has a sensible answer, shouldn't we warn also
when a smaller decimal float is converted to bigger decimal float ?
(Keep in mind that this is not about losing precision or data, it is
about conversions that are different in the absence of prototypes and
compiling with traditional C).
3) The above question may not have a sensible answer. It may be either
because decimal float "is a GCC extensions and thus not relevant to
traditional C compatibility", as it says in the gcc manual page about
Wtraditional and nested functions. Or because the behaviour is
undefined or not documented. Whatever the reason, why we have code
(and a testcase!) to deal with this? Could I just remove them ? I am
preparing a patch to add support for decimal float in Wcoercion and
currently it removes that code and the testcase.
If you are still with me, thanks for your patience.
Cheers,
Manuel.
Re: type consistency of gimple
David Edelsohn wrote: >> Diego Novillo writes: >> > > Diego> Agreed. This is a good opportunity for us to design a GIMPLE type > Diego> system. Besides the obvious space savings and cleanliness, it is also > Diego> needed to remove lang_hooks.types_compatible_p. > > And this last statement is the key point. We can and probably > should implement a prototype LTO without cleaning up the type system, but > for LTO to be usable in a production compiler, the GIMPLE type system will > need to be fixed. Cleaning the type system is not an immediate > requirement -- not a dependency for the initial implementation of LTO -- > but LTO cannot be generally usable without this problem being addressed. > A more compact representation is a byproduct, but multi-language > correctness is necessary for full, production functionality. > > David > > I am modifying my code so that their is a preprocessor flag, STUPID_TYPE_SYSTEM that either writes or does not write the redundant type nodes. The comments by Diego imply that not only is this a space issue but that will have to be solved in order to get rid of one or more of the lang_hooks. Thus, it does make some sense to work on this sooner rather than later. I would suggest that we ask those with patches to strengthen the type system to contribute those patches to the lto branch and for diego (who I believe has the last working type checker) to contribute that type checker to the lto branch. And that we further invite those in the community who are willing to attack some of these problems to contribute those patches to the lto branch as they become available, on the basis that perhaps we can provide some fast path to getting them in the mainline if we are able to solve this problem in a timely manner. When we get to the point where can compile C with the type checker, we should turn it on in the lto branch and remove my STUPID_TYPE_SYSTEM code. This will keep the pressure up but at the same time allow us to get a prototype in a timely manner. Kenny
Re: type consistency of gimple
On Aug 14, 2006, at 9:52 AM, Michael Matz wrote: How true :) Nevertheless the goals for the FSF GCC should IMHO be purely based on rather technical arguments and considerations, not the drive by paying customers. :-) I'd of course argue that a compiler with no customers (I'd use the term users, however) is a pointless exercise and tends to have no developers. I think there is a balance to be had here. I can understand Mark's desire to decouple the two bits of work and get one done. This results in a shorter schedule and allows for merging in work sooner. I think that would go a long way to ensuring that we get any progress in this area. In the end, I'm interested in PCH file growth when LTO isn't used and compile time increases at -O0 and weighing any regressions in that area against the benefit of LTO. It would be great if there were none, but accepting some might be ok. I'd baulk at a 40% time regression however. I don't see the need to argue against the patch without seeing the numbers.
Re: does gcc support multiple sizes, or not?
> The C++ standard implies that for all pointer-to-object types have the > same size and that all pointer-to-function types have the same size. > (Technically, it doesn't say that that; it says that you can convert T* > -> U* -> T* and get the original value.) Then they don't need to be the same size in most cases since usually when multiple pointer sizes are allowed, the underlying OS/RTL only uses the number of bits corresponding to the narrower size.
Re: Documentation for loop infrastructure
Apologies for the previous incomplete reply. Here's the rest of the
comments I had for this patch.
> + @itemize
> + @item @code{flow_loops_dump}: Dumps the information about loops to file.
^^^
a
> + @item @code{verify_loop_structure}: Checks consistency of the loop
structures.
> + @item @code{loop_latch_edge}: Returns the latch edge of a loop.
> + @item @code{loop_preheader_edge}: If loops have preheaders, returns
> + the preheader edge of a loop.
> + @item @code{flow_loop_nested_p}: Tests whether loop is a sub-loop of
other loop.
^
another
> + @item @code{tree_num_loop_insns}, @code{num_loop_insns}: Estimates
number of
^^^
the
> + insns in the loop, on trees and on RTL.
>
s/trees/GIMPLE/ everwhere.
I would prefer if we start using GIMPLE instead of 'trees'. Otherwise,
it may be hard to tell whether we refer to GIMPLE, GENERIC or FE
trees. I realize that this inconsistency will be with us a long time,
but I think it's important to start making it now as we change the
underlying data structures.
> + @code{get_loop_body_in_bfs_order}: Enumerates the basic blocks in
the loop in
> + dfs order, ordered by dominance relation, and bfs order,
^^^ ^^^
DFS BFS
These acronyms should be expanded on first use.
> + @item In induction variable analysis, it is not necessary to specify the
> + loop with respect to that the behavior of the SSA name is inspected.
I could not parse this.
> + @item It makes updating of SSA form during loop transformations
> + Without LCSSA, operations like loop unrolling may force creation of phi
^^^
PHI
> + Given a SSA name, its behavior in loops can be analyzed using
^
an
> + @code{analyze_scalar_evolution} function. The returned SCEV however
^^^
the
> Before start of the analysis of the induction variables
^^^
> + in a loop, @code{iv_analysis_loop_init} function must be called for
Before analyzing induction variables in a loop L, the function
@code{iv_analysis_loop_init} must be called on L.
> + @item @code{iv_analyze}: Analyzes a single register used in the
> + If no use of the register in this insn is found, following insns are
^^^
the
Re: Wrong code generated (assignment incorrectly optimized out)
Andrew Pinski <[EMAIL PROTECTED]> writes:
>> This is gcc-4.2.0-0.20060806r115974
>
> Can you submit a real bug report to http://gcc.gnu.org/bugzilla
> as mentioned on http://gcc.gnu.org/bugs.html?
Done; http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28727
--
__("< Marcin Kowalczyk
\__/ [EMAIL PROTECTED]
^^ http://qrnik.knm.org.pl/~qrczak/
Re: does gcc support multiple sizes, or not?
Mark Mitchell <[EMAIL PROTECTED]> writes: | DJ Delorie wrote: | >> And back to my original answer: it's up to each language to decide | >> that. | > | > Hence my original question: is it legal or not? What did the C++ | > developers decide? | | The C++ standard implies that for all pointer-to-object types have the | same size and that all pointer-to-function types have the same size. | (Technically, it doesn't say that that; it says that you can convert T* | -> U* -> T* and get the original value.) However, nothing in the | standard says that pointer-to-object types must have the same size as | pointer-to-function types. Indeed. However, the C++ definition has been amended at the last Lillehammer meeting to allow that cast as "conditionally supported": either it is valid or it errors out. the compiler has to tell. -- Gaby
Re: does gcc support multiple sizes, or not?
> However, the C++ definition has been amended at the last Lillehammer > meeting to allow that cast as "conditionally supported": either it is > valid or it errors out. the compiler has to tell. Also, the mechanism to create multiple pointer sizes (attribute((mode))) is a GCC extension. Hence, my original question wasn't about about the C++ language supporting it, it was about *gcc* (and thus cc1plus) supporting it.
Re: LOG_LINKS field not set because of gcse1 (or fwprop1) pass
On Sun, Aug 13, 2006 at 10:16:02PM +0200, Rask Ingemann Lambertsen wrote: > Note that right after expand, we have: > > (note 91 90 0 NOTE_INSN_BASIC_BLOCK) > > ;; size = size - 1 > (insn 93 91 96 (set (reg:HI 42) > (const_int -1 [0x])) -1 (nil) > (nil)) > > (insn 96 93 97 (parallel [ > (set (reg:HI 43) > (plus:HI (reg/v:HI 32 [ size ]) > (reg:HI 42))) > (clobber (reg:CC 12 cc)) > ]) -1 (nil) > (nil)) > > (insn 97 96 98 (set (reg:HI 43) > (reg:HI 43)) -1 (nil) > (expr_list:REG_EQUAL (plus:HI (reg/v:HI 32 [ size ]) > (reg:HI 42)) > (nil))) Note that insn 97 is entirely my fault, but ought to be harmless. > (insn 98 97 0 (set (reg/v:HI 32 [ size ]) > (reg:HI 43)) -1 (nil) > (nil)) > > ;; if (size != 0) goto ; else (void) 0; > (insn 100 98 101 10 (set (reg:HI 44) > (const_int 0 [0x0])) -1 (nil) > (nil)) > > (insn 101 100 102 10 (set (reg:CC 12 cc) > (compare:CC (reg/v:HI 32 [ size ]) > (reg:HI 44))) -1 (nil) > (nil)) All other issues aside, the code is being messed up already at expand. For comparison, arm-elf gets this much better RTL: (code_label 51 50 52 7 "" [0 uses]) (note 52 51 0 NOTE_INSN_BASIC_BLOCK) ;; size = size - 1 (insn 54 52 0 (set (reg/v:SI 114 [ size ]) (plus:SI (reg/v:SI 114 [ size ]) (const_int -1 [0x]))) -1 (nil) (nil)) ;; if (size != 0) goto ; else (void) 0; (insn 56 54 57 (set (reg:CC 24 cc) (compare:CC (reg/v:SI 114 [ size ]) (const_int 0 [0x0]))) -1 (nil) (nil)) The RTL from expand for i686-pc-linux-gnu is essentially the same as for arm-elf. -- Rask Ingemann Lambertsen
Re: How to add a NOP instruction in each basic block for obj code that gcc generates
Jeff wrote: I added fprintf (asm_out_file, "\tnop\n"); to the end of case CODE_LABEL. Then I recompile the gcc. Unfortunately, it doesn't seem that a NOP was inserted. Any ideaes? What testcase did you try? Not every basic block starts with a label. Only basic blocks that are the target of a branch start with a label, which is maybe only half of them. So if you tried a simple testcase without an if statement or loop, then you won't get a nop emitted. A more serious problem however is that emitting an extra instruction like this will cause out-of-range addressing problems. Many targets have limited range branch offsets, and adding extra instructions can cause the branches to end up out of range. (Likewise, trying to do this at the assembler level has the same problem.) Some targets with very limited addressing modes (thumb, mips16, sh, etc) require inline constant pools that are carefully constructed to be within range, and may end up out-of-range if you emit extra instructions. So to do this portably, you need to emit the extra instructions before branch shortening, and before the machine dependent reorg pass. You can try using gen_nop () if the target has a named "nop" pattern in the md file, but you might need to construct an pattern that looks like a user extended asm construct. Making it volatile will prevent the optimizer from deleting it. The simplest way to get an insn into every basic block would be to use the CFG. Scan all basic blocks, and insert an instruction into each one. FOR_EACH_BB will interate over all basic blocks. Try looking at some of the places that use it. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: #pragma once
Drgt <[EMAIL PROTECTED]> writes: > It seems, that "#pragma once" isn't in ISO, and will never be, especially > because it is Microsoft (am I right ?) C extension. > (http://gcc.gnu.org/ml/gcc/2004-06/msg01887.html) I believe that gcc was actually the first compiler to implement "#pragma once". It was added back in 1989 in gcc 1.35 by RMS. It is, perhaps, ironic that it is now considered to be a Microsoft extension. Then in 1991 RMS added support for automatically detecting when a header file puts all the non-comment text inside #ifndef/#define/ #endif. When that happens, and gcc sees another #include for the same header file, and the relevant macro is #defined, gcc will skip reading the header file entirely. That first appeared in gcc 2.0. Given that ability, RMS decided that there was no need to support #pragma once, and, since he doesn't like #pragma (or at least didn't at the time), he changed #pragma once at that time to issue an unavoidable warning. Note that #pragma once still worked; it just issued a warning. But #pragma once was still used in practice, so the warning was removed by Jason Merrill in 2003, for gcc 3.3. In short, #pragma once works fine today. What makes you think that it doesn't work? Ian
Re: [C frontend] Wtraditional / Wconversion and decimal float
On Mon, Aug 14, 2006 at 06:30:26PM +0100, Manuel López-Ibáñez wrote: > Dear all, > > Wtraditional warns for "Conversions by prototypes between > fixed/floating point values and vice versa. The absence > of these prototypes when compiling with traditional C would cause > serious problems. " > In the case of decimal float values, apart from conversions between > integers and decimal float and viceversa, Wtraditional also warns for > conversions between decimal and binary floats and for conversions from > a decimal float type to a smaller decimal float type. > > My questions are: > > 1) Which are the rules when compiling with traditional C, no > prototype is given and decimal floats are involved? ISO C in section 6.5.2.2 paragraph 6 specifies default argument promotion for floats that are passed to functions without prototypes. There is no default argument promotion for decimal floating types, as specified in 6.5 of the current draft at http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1176.pdf. Sorry, I gave you incomplete information when you asked me about this before. > 2) If the above question has a sensible answer, shouldn't we warn also > when a smaller decimal float is converted to bigger decimal float ? A decimal float argument is not converted, so this isn't an issue for function calls. > 3) The above question may not have a sensible answer. It may be either > because decimal float "is a GCC extensions and thus not relevant to > traditional C compatibility", as it says in the gcc manual page about > Wtraditional and nested functions. Or because the behaviour is > undefined or not documented. Whatever the reason, why we have code > (and a testcase!) to deal with this? Could I just remove them ? I am > preparing a patch to add support for decimal float in Wcoercion and > currently it removes that code and the testcase. As for testcase you showed that passes a float to a function with a prototype, it makes sense to me that it gets a warning for -Wtraditional. Janis
Feature request - error for implicit int return in pointer context
Hello!
I've been bitten by a bug in some software I use every day (I didn't
write it, but it's a part of. When compiling it with gcc-4.1.1, I'm
getting tons of warnings, and the bug was triggering a warning too, I
think it should have been an error.
It's the case where the return value of an undeclared function is used
as a pointer, e.g:
void *fun(void)
{
void *ret = foo();
return ret;
}
$ gcc -c -Wall hello.c
hello.c: In function 'fun':
hello.c:3: warning: implicit declaration of function 'foo'
hello.c:3: warning: initialization makes pointer from integer without a
cast
What happens here is that gcc implies that the function returns an
integer, and then is proven to be wrong, because the value is used as a
pointer.
I read somewhere that gcc issues warnings rather than errors when it
understands what the code means. I believe it's the case where it
doesn't. Standard compliance requires gcc to interpret the return
result in a way that doesn't correspond to the actual context of the
call.
This code is virtually guaranteed to break on 64 bit platforms (i.e.
when pointers and integers have a different size).
I don't know much about gcc implementation, but if it's not hard to
check the context of the function call (or, alternatively, the
provenance of the integer that is about to be cast to a pointer), I'll
appreciate if this case is promoted to an error, and least for 64-bit
targets.
--
Regards,
Pavel Roskin
Re: [C frontend] Wtraditional / Wconversion and decimal float
On Mon, Aug 14, 2006 at 12:45:55PM -0700, Janis Johnson wrote: > On Mon, Aug 14, 2006 at 06:30:26PM +0100, Manuel López-Ibáñez wrote: > > 3) The above question may not have a sensible answer. It may be either > > because decimal float "is a GCC extensions and thus not relevant to > > traditional C compatibility", as it says in the gcc manual page about > > Wtraditional and nested functions. Or because the behaviour is > > undefined or not documented. Whatever the reason, why we have code > > (and a testcase!) to deal with this? Could I just remove them ? I am > > preparing a patch to add support for decimal float in Wcoercion and > > currently it removes that code and the testcase. > > As for testcase you showed that passes a float to a function with a > prototype, it makes sense to me that it gets a warning for > -Wtraditional. I always feel so silly responding to my own messages. It makes sense to have warnings about calls where default argument promotions would have made a difference, but not for the calls in gcc.dg/dfp/Wconversion-2.c. Janis
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: >> However, the C++ definition has been amended at the last Lillehammer >> meeting to allow that cast as "conditionally supported": either it is >> valid or it errors out. the compiler has to tell. > > Also, the mechanism to create multiple pointer sizes > (attribute((mode))) is a GCC extension. I'm very suspicious of allowing users to specify this via attributes. Having pointers-to-objects or pointers-to-functions with different sizes (within one of those classes) seems problematic, but perhaps you can say more about how you expect this to work in the presence of conversions and such. I expected that what you were asking was whether the back end could reasonably say that function pointers had size four, say, while data pointers had size two. I think that's reasonable, but I don't find it nearly so reasonable to say that some "int *" pointers have size four while others have size two. But, maybe I just need appropriate motivation. Also, there is a nasty class of bugs in G++ stemming from the GCC attribute extensions because there are no well-defined rules about how to tell if two types with different attributes are the same or different, and if they are different what conversions (if any) can be used to convert back and forth. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Feature request - error for implicit int return in pointer context
Pavel Roskin <[EMAIL PROTECTED]> writes: > I don't know much about gcc implementation, but if it's not hard to > check the context of the function call (or, alternatively, the > provenance of the integer that is about to be cast to a pointer), I'll > appreciate if this case is promoted to an error, and least for 64-bit > targets. Try -Werror-implicit-function-declaration. Not the same, but pretty close. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: does gcc support multiple sizes, or not?
> > DJ Delorie wrote: > >> However, the C++ definition has been amended at the last Lillehammer > >> meeting to allow that cast as "conditionally supported": either it is > >> valid or it errors out. the compiler has to tell. > > > > Also, the mechanism to create multiple pointer sizes > > (attribute((mode))) is a GCC extension. > > I'm very suspicious of allowing users to specify this via attributes. > Having pointers-to-objects or pointers-to-functions with different sizes > (within one of those classes) seems problematic, but perhaps you can say > more about how you expect this to work in the presence of conversions > and such. Aren't there some targets (like ia64-hpux) that support two different sizes of pointers, it also be nice to be able for the user access to them also from a high level so they can write code that can call between the two ABIs. -- Pinski
Re: does gcc support multiple sizes, or not?
Andrew Pinski wrote: > Aren't there some targets (like ia64-hpux) that support two different > sizes of pointers Those are entirely separate ABIs, controlled by a command-line option. There are not multiple pointer sizes within any single program. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
> I'm very suspicious of allowing users to specify this via attributes. Me too, but that's what extensions are all about. You never know what the user is going to need to do. The M16C is an example - it has a 16 bit pointer, but has a few special opcodes for using a 32 bit pointer to access additional ROM data. Plus, functions exist in a 24 bit address space. > Having pointers-to-objects or pointers-to-functions with different sizes > (within one of those classes) seems problematic, but perhaps you can say > more about how you expect this to work in the presence of conversions > and such. I don't know about conversions, but I can easily imagine cases where the program's address space isn't as big as the chip's address space. Consider a 32-bit program on a 64-bit CPU, which needs to access memory mapped devices. Or an API converter that lets 32 bit programs run in a 64 bit OS. They'd need to compute pointers as integers of the right size, then cast them. > I expected that what you were asking was whether the back end could > reasonably say that function pointers had size four, say, while data > pointers had size two. I think that's reasonable, That is totally unsupported by GCC. I've ranted about that before, because the m16c has a 16 bit data pointer and a 24 bit function pointer. > but I don't find it nearly so reasonable to say that some "int *" > pointers have size four while others have size two. But, maybe I > just need appropriate motivation. Well, it seems to work just fine in C. Example: In m16c, you can declare an SImode pointer type, which is initialized to point to a function. The assembler does the right thing, letting you initialize a reset vector (32 bit pointers) without having to set up the RAM thunks to support 16 bit function pointers. > Also, there is a nasty class of bugs in G++ stemming from the GCC > attribute extensions because there are no well-defined rules about how > to tell if two types with different attributes are the same or > different, and if they are different what conversions (if any) can be > used to convert back and forth. We have target hooks for function attributes, no reason to avoid target hooks for data attributes.
Re: does gcc support multiple sizes, or not?
> Aren't there some targets (like ia64-hpux) that support two different > sizes of pointers, Heck, the i386 has ALWAYS supported multiple pointer sizes (16, 16+16, 32, and 32+16). We've just refused to pay the (high) price for supporting them.
Re: [C frontend] Wtraditional / Wconversion and decimal float
On 14/08/06, Janis Johnson <[EMAIL PROTECTED]> wrote: It makes sense to have warnings about calls where default argument promotions would have made a difference, but not for the calls in gcc.dg/dfp/Wconversion-2.c. But there are no default promotions for decimal float, as you say in your previous mail, so the default promotion could never make a difference whenever the value passed as argument or the expected type is a decimal float type. Am I right here? Does this mean that I should remove the corresponding code from gcc/c-typeck.c:convert_arguments() and also remove gcc.dg/dfp/Wconversion-2.c ? Sorry for insist, I would not like to misunderstand your answer. Cheers, Manuel.
Re: type consistency of gimple
> "Dan" == Daniel Berlin <[EMAIL PROTECTED]> writes: Dan> I do not *fault* Diego (and others) for the decision to get a Dan> prototype of GIMPLE/tree-ssa first, and clean it up later. FWIW my experience writing a front end was that trees remain weird to work with -- sometimes fixing type compatibility will fix a bug, other times it doesn't seem to be necessary. It's much simpler to deal with interfaces which (a) document what is required and (b) complain if you do something wrong. The less fuzzy the middle end is about what it accepts, the better. Dan> 1. you quickly gain critical mass of others contributing passes right Dan> after the prototype is written Dan> 3. It's very hard to do it incrementally, because anything can generate Dan> trees that violate the invariants. A few things that may help: * A pass to do type checking (this has been kicked around for a while AIUI) * Just have gimplification fix up types * Have a flag so that, post-gimplification, build* will abort if a non-type-safe tree is created. It seems like this would be a simple way to track down the passes that are creating un-typesafe trees. As to performance regressions that would occur with "useless casts" -- those seem like latent bugs to me. Tom
Imported GNU Classpath 0.92
Hi, GNU Classpath 0.92 was released last week. It contains a lot of new standard library classes and bug fixes. See http://savannah.gnu.org/forum/forum.php?forum_id=4573 And the list of fixed bugs: http://gcc.gnu.org/bugzilla/buglist.cgi?product=classpath&target_milestone=0.92 This version has been imported now into the libjava directory on the trunk. It has been tested on a variety of platforms. But if we missed something please let us know ([EMAIL PROTECTED]). Thanks, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: >> I'm very suspicious of allowing users to specify this via attributes. > > Me too, but that's what extensions are all about. You never know what > the user is going to need to do. Sorry, but I think that's far too casual. The long history of GCC extensions causing various kinds of problems is proof positive that new extensions should be added only with extreme care. We've already established the position that new extensions should come with a list of changes to the relevant language standards with the same rigor that would be used to modify the language itself. >> but I don't find it nearly so reasonable to say that some "int *" >> pointers have size four while others have size two. But, maybe I >> just need appropriate motivation. > > Well, it seems to work just fine in C. Well, I think it's in direct conflict with the C++ standard. If "X" is a 32-bit pointer type, and "x" is a value of type X, "Y" is a 16-bit pointer type, then: (X*)(Y*)x is supposed to get you back the value of "x", but I don't see how that can work, in general. So, if you want to do this in C++, you need to work through the language standard and work out how having two distinct classes of pointers is going to work. I think that's doable, but not trivial. For example, you might make the 16-bit pointers "pointers" what the standard calls pointers, and then make the 32-bit pointers "big pointers". You could say that within a single class of pointers, all the usual pointer rules apply. Then, work through things like conversions between the two (is one direction implicit? are these static_casts or reinterpret_casts?), what mangling to use for big pointers, how to encode the types in RTTI, etc. If you really just need these things in a few places (like reset vectors), then I think you'd be better off with a __builtin_long_pointer() intrinsic (returning a 32-bit integer, not pointer) to use in the initializers. You only need two classes of pointers if you expect people to use the second class in non-trivial expressions, i.e., dereference them, perform pointer arithmetic on them, etc. There's also nothing inherently wrong with assembly code; if it's necessary to express the reset vector in assembly code, well, then, so be it. I can well see why doing it in C/C++ is nicer, but I don't think we should try to extend GNU C/C++ to encompass everything that can be done with an assembler. >> Also, there is a nasty class of bugs in G++ stemming from the GCC >> attribute extensions because there are no well-defined rules about how >> to tell if two types with different attributes are the same or >> different, and if they are different what conversions (if any) can be >> used to convert back and forth. > > We have target hooks for function attributes, no reason to avoid > target hooks for data attributes. Sure -- but you still have to say what the semantics are! In my opinion, "it seems to work" arguments are far too loose for making semantic changes to the C++ front end. We've been burned too many times. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Feature request - error for implicit int return in pointer context
On Mon, 2006-08-14 at 22:44 +0200, Andreas Schwab wrote: > Pavel Roskin <[EMAIL PROTECTED]> writes: > > > I don't know much about gcc implementation, but if it's not hard to > > check the context of the function call (or, alternatively, the > > provenance of the integer that is about to be cast to a pointer), I'll > > appreciate if this case is promoted to an error, and least for 64-bit > > targets. > > Try -Werror-implicit-function-declaration. Not the same, but pretty > close. Thanks! I know. In fact, I'm using at least "-Wall -Werror" for my code and for the code I'm working with, so it's implied. I'm talking about code that I have never seen until the binary did a poo-poo on my machine. Sure, I can petition Fedora, Novell, Debian and others to use -Werror-implicit-function-declaration, but I don't think I'll have convincing arguments. There is lots of old code in existence that lacks some declarations and that would work if compiled for a 64-bit system. This sloppiness can be tolerated to a degree. But if an undeclared function returns a pointer, this will break the code almost definitely. That's why I want gcc to reject this code. Then it won't be me reporting brokenness to e.g. Fedora after 2 days of setting up the build environment and chasing unrelated issues in the libraries. It will be Fedora fixing this crap before it comes to the users. If the prototypes disappear, most code that worked would still work the same way. In fact, -Wconversion will find the exceptions provided that the prototypes are present. The compiler would not convert pointer arguments to int. Pointers will be sent as pointers. But the return value will be converted to int and thus broken. Hence my plea: if you can detect it, please reject it. Another approach would be to assume functions to return a pointer in the pointer context. I think it would be against standards, therefore I'm not asking for it. Also, this approach could lead to silently miscompiled code if different files use the function is different contexts, e.g.: file1.c: if (!foo()) /* assuming int, using 32 bits */ return; file2.c: void *ptr = foo(); /* assuming pointer, using 64 bits */ Without such "smartness", file2.c would fail to compile, forcing user to add foo() to the headers thus fixing file1.c. Thus, if the function is ever called in the definitely pointer context, it would trigger an error. -- Regards, Pavel Roskin
Re: How to GTYize a struct properly?
"Laurynas Biveinis" <[EMAIL PROTECTED]> writes:
> After my best effor so far:
>
> struct histogram_value_t GTY(())
> {
> struct
> {/* <--- line 48, error below occurs here */
> tree value; /* The value to profile. */
> tree stmt; /* Insn containing the value. */
> gcov_type *counters;/* Pointer to first counter. */
> struct histogram_value_t GTY((chain_next("%h.next")) *next;
> /*
> Linked list pointer. */
At the risk of stating the obvious, those parentheses after "GTY" look
unbalanced to me.
--
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l)) (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k)))'((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)
Re: does gcc support multiple sizes, or not?
> Well, I think it's in direct conflict with the C++ standard. If "X" is > a 32-bit pointer type, and "x" is a value of type X, "Y" is a 16-bit > pointer type, then: > > (X*)(Y*)x > > is supposed to get you back the value of "x", but I don't see how that > can work, in general. Where in the standard does it say that? I could only find references to conversions to base classes. Plus, Borland C++ has had multiple sized pointers since the 80's. > You only need two classes of pointers if you expect people to use > the second class in non-trivial expressions, i.e., dereference them, > perform pointer arithmetic on them, etc. Like the m16c, which lets you put additional less-frequently used data in function memory? Perhaps, a table of strings, or some CRC lookups?
Re: type consistency of gimple
Kenneth Zadeck wrote: > I am modifying my code so that their is a preprocessor flag, > STUPID_TYPE_SYSTEM that either writes or does not write the redundant > type nodes. I think the macro name is needlessly negative, but I think the idea is fine. Could we just say something like EXPLICIT_TYPE_INFORMATION instead? > I would suggest that we ask those with patches to strengthen the type > system to contribute those patches to the lto branch and for diego (who > I believe has the last working type checker) to contribute that type > checker to the lto branch. I agree. I think it's very desirable for the type-checker to be a separate pass so that we can run it at various points in the compilation to check for consistency; that will help us isolate problems. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: >> Well, I think it's in direct conflict with the C++ standard. If "X" is >> a 32-bit pointer type, and "x" is a value of type X, "Y" is a 16-bit >> pointer type, then: >> >> (X*)(Y*)x >> >> is supposed to get you back the value of "x", but I don't see how that >> can work, in general. I made an error in the code above; I should have said "(X)(Y)x" since I had already defined "X" and "Y" to be pointer types. > Where in the standard does it say that? [expr.reinterpret.cast] A pointer to an object can be explicitly converted to a pointer to an object of different type.13) Except that converting an rvalue of type "pointer to T1" to the type "pointer to T2" (where T1 and T2 are object types and where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value, the result of such a pointer conversion is unspecified. The "except that" sentence implies the statement above, assuming that the pointed-to type does not have stricter alignment. So, if casting a 32-bit pointer to int to a 16-bit pointer to char and back does not always yield the same value, then something has to give. Fundamentally, pointer types in C++ are compound types determined solely by the pointed-to-type; what you're doing (by adding attributes to the pointer) is adding a new operator for forming compound types. That's a language extension, so it needs to be specified. It's not enough just to tweak the back end to allow the mode attribute. >> You only need two classes of pointers if you expect people to use >> the second class in non-trivial expressions, i.e., dereference them, >> perform pointer arithmetic on them, etc. > > Like the m16c, which lets you put additional less-frequently used data > in function memory? Perhaps, a table of strings, or some CRC lookups? If you really need two classes of pointers, then, sure, you need them. All I did was ask whether or not you really need them and offer a possible solution if you *don't* need them. I am aware of "near" and "far" pointers in Borland (and other) compilers. That's good news; you may have an example to help work through the issues. That doesn't mean that there are no issues. You seem to be trying to convince me that this is a simple thing and that we should just do it and let the chips fall where they may. You might be right -- but since almost every other such change has lead to trouble, I'm not inclined to take chances. Please do the work up front to specify how this interacts with all aspects of the language. That's user documentation we need anyhow. I do think this sounds like a useful feature. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Gcc On Solaris Sparc Versus Solaris Intel
Gentle People?
I am currently running gcc 3.1 on both my Ultra 5
Solaris 8 Sparc machine and on Solaris 8 Intel machine.
The Application C source code that compiles and executes
perfectly on the Ultra 5 will not compile on the Intel machine!
The compilation errors, shown below, seem to relate to
syntax errors, and not simply missing files. Remember this
same code compiles perfectly on the Sparc machine. There is no
inline assembly language or obvious machine dependent code
involved.
Why would there be such a difference in the between gcc on
Sparc versus Intel? I would of thought that the C Parcer Defination
and thus top level compiler behavior would be identical for all gcc
versions andf platforms?
Someone mentioned that the header files are different:
I wonder why? I would of thought at that level of abstraction
they would be identical.
Would an update to a newew version of code fix this problem?
Thanks for the help.
Thomas Dineen
gcc cmd_parser.c -ggdb -w -c -o cmd_parser.o
In file included from cmd_parser.c:13:
structures.h:484: parse error before "exec_struct_sun"
structures.h:489: parse error before "Exec_union"
structures.h:498: parse error before ’}’ token
typedef union
{
unsigned char load[BUF_SIZE];
exec_struct_sun Exec_load; // Line 484
} Exec_union;
typedef struct
{
Exec_union un; // Line 489
int n_page_size;
int n_segment_size;
int n_text_offset;
int n_data_offset;
int n_text_rel_offset;
int n_data_rel_offset;
int n_symbol_offset;
int n_string_offset;
} Exec_Struct; // Line 498
// Cut from another .h file:
typedef struct {
unsigned char a_dynamic:1; /* has a __DYNAMIC */
unsigned char a_toolversion:7; /* version of toolset used create this
file */
unsigned char a_machtype; /* machine type */
unsigned short a_magic; /* magic number */
unsigned int a_text; /* size of text segment */
unsigned int a_data; /* size of initialized data */
unsigned int a_bss; /* size of uninitialized data */
unsigned int a_syms; /* size of symbol table */
unsigned int a_entry; /* entry point */
unsigned int a_trsize; /* size of text relocation */
unsigned int a_drsize; /* size of data relocation */
} exec_struct_sun;
Re: does gcc support multiple sizes, or not?
> The "except that" sentence implies the statement above, assuming > that the pointed-to type does not have stricter alignment. So, if > casting a 32-bit pointer to int to a 16-bit pointer to char and back > does not always yield the same value, then something has to give. reinterpret_cast doesn't require that the intermediate form have the same bit pattern. On the m16c, for example, it's technically possible to convert from a 24 bit function pointer to a 16 bit pointer to that function's thunk, and back. Not *all* pointers can be converted, but pointers to functions can. Not that I'd want to write that kind of support code, but it's possible. The way I read it, "a pointer" to an object can be converted to "a pointer" to a different type of object, but as reinterpret_cast already leaves the const qualifier alone, it seems to be focusing on the object's type, not the pointer's type. IMHO, this allows the interpretation that a "pointer of a given size" to an object can be cast to a "pointer of the same size" to a different object. Thus, a "far *foo" can be cast to a "far *bar" and back. But, this has gone way past what I really needed. I didn't need to know if we *should* support multiple pointer sizes, I need to know *if* we support them, so I know which way to fix the code. If they're not supported, I'll work on failing gracefully. If they are supported, I'll fix that bug so it works. If you say C++ doesn't support them, I'll take it out and make it obvious that C++ doesn't support them, as long as C still supports them (because I use that feature a lot). I just don't want it to crash when the user does something that appears to be legal based on the gcc manual.
Re: Gcc On Solaris Sparc Versus Solaris Intel
On Aug 14, 2006, at 6:29 PM, Thomas Dineen wrote: Gentle People? Wow, someone's been spreading false accusations about us. :-) I am currently running gcc 3.1 on both my Ultra 5 Solaris 8 Sparc machine and on Solaris 8 Intel machine. The Application C source code that compiles and executes perfectly on the Ultra 5 will not compile on the Intel machine! The gcc mainline list is the wrong place for such questions. Please don't cross post to more than one list. All user questions should go to gcc-help only. The compilation errors, shown below Actually, you hide all the detail that would normally allow us to answer the question. gcc -E has the detail that should make this case clear. If you review it, it should lead the way.
Re: how can I add gcc backend code into GCC package
On Aug 14, 2006, at 7:09 PM, [EMAIL PROTECTED] wrote: We have porting our S+core 32b CPU gcc backend for gcc-4.1.1, and have finished applying process in FSF, but how can i add our backend code into gcc package? Please see http://gcc.gnu.org/contribute.html in general. You'd need to file an assignment. You'd need to up port this to the top of the tree. You'd need to submit that to gcc-patches. You'd need to check this in. Then you could submit for the 4.1 branch, if you really wanted it there. I glanced quickly at the patch, seems about right.
Re: does gcc support multiple sizes, or not?
> I'm very suspicious of allowing users to specify this via attributes. > Having pointers-to-objects or pointers-to-functions with different sizes > (within one of those classes) seems problematic, but perhaps you can say > more about how you expect this to work in the presence of conversions > and such. I think there's some confusion here. For most back-ends, only one pointer size is supported. The only times that back-ends support alternate pointer sizes are in cases where we have a 64-bit machine but the OS/RTL only uses 32 bits for pointers. Alpha/VMS is an example of this. In those cases, you often have circumstances where some "external" interfaces (e.g., to OS or RTL) has structures with 32-bit pointers and others has 64-bit pointers. So you need to be able to express the interfaces to both of these and that requires both pointer sizes. This is not intended for "random" programmer usage.
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: >> The "except that" sentence implies the statement above, assuming >> that the pointed-to type does not have stricter alignment. So, if >> casting a 32-bit pointer to int to a 16-bit pointer to char and back >> does not always yield the same value, then something has to give. > > reinterpret_cast doesn't require that the intermediate form have the > same bit pattern. Exactly so. However, all valid pointers must be handles, so unless the 32-bit address space is "sparse", something will go wrong. > The way I read it, "a pointer" to an object can be converted to "a > pointer" to a different type of object, but as reinterpret_cast > already leaves the const qualifier alone, it seems to be focusing on > the object's type, not the pointer's type. There's no distinction in ISO C++; every object type has exactly one associated pointer type. The point of reinterpret_cast is to let you convert A* to B* where A and B are unrelated object types. It's an operation on pointers, not general objects; for example, you can't do "reinterpret_cast(7)", but you can do "reinterpret_cast((int*)0))". > If you say C++ doesn't support them, I'll take it out and make it > obvious that C++ doesn't support them, as long as C still supports > them (because I use that feature a lot). I just don't want it to > crash when the user does something that appears to be legal based on > the gcc manual. Good call. I don't feel qualified to comment for C, but for C++, I think it's correct to say that we don't support them. I think we *could* support them, in theory, but that would be a good bit of work. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
Richard Kenner wrote: >> I'm very suspicious of allowing users to specify this via attributes. >> Having pointers-to-objects or pointers-to-functions with different sizes >> (within one of those classes) seems problematic, but perhaps you can say >> more about how you expect this to work in the presence of conversions >> and such. > > I think there's some confusion here. > So you need to be able to express the interfaces to both of these and > that requires both pointer sizes. The confusion is perhaps that you're thinking that my statement that we need to specify the semantics is clearly implies that I don't think it's a useful feature? I do think it's a useful feature, but I also think that you can't just drop it into C++ without thinking about all the consequences of that action. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: does gcc support multiple sizes, or not?
> The confusion is perhaps that you're thinking that my statement that we > need to specify the semantics is clearly implies that I don't think it's > a useful feature? I do think it's a useful feature, but I also think > that you can't just drop it into C++ without thinking about all the > consequences of that action. Sure. However, I wasn't addressing the usefulness issue but rather the semantic issue of whether you lose data when converting a pointer from 64- to 32-bit by saying that the cases for which this extension is intended are such where that can't happen.
Re: does gcc support multiple sizes, or not?
> > reinterpret_cast doesn't require that the intermediate form have the > > same bit pattern. > > Exactly so. However, all valid pointers must be handles, so unless the > 32-bit address space is "sparse", something will go wrong. I would go so far as to say that it's defined (hence supported) if the intermediate form is at least as many bits as the other types.
Re: does gcc support multiple sizes, or not?
DJ Delorie wrote: >>> reinterpret_cast doesn't require that the intermediate form have the >>> same bit pattern. >> Exactly so. However, all valid pointers must be handles, so unless the >> 32-bit address space is "sparse", something will go wrong. I didn't help things here by saying "handles"; I meant "handled". Sorry! > I would go so far as to say that it's defined (hence supported) if the > intermediate form is at least as many bits as the other types. I'm not sure if I understand. In ISO C++, it would be fine for "char *" to have more bits than all other pointers. The standard says X* -> Y* -> X* is value-preserving if Y has no stricter alignment than X. Since "char" has weak alignment requirements, Y can be "char". Is that what you mean? In ISO C++, there's of course no notion of "char *far" or "char *near"; there's just "char *". So, there's no way to directly map your intended type system onto the conversion sequence above. The spirit of the standard would seem to be that "X* near" -> "X* far" -> "X* near" be value-preserving, but to make no guarantees about "X* far" -> "X* near" -> "X* far". -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
