Re: warning: initialization makes integer from pointer without a cast
On 3/29/06, Mike Stump <[EMAIL PROTECTED]> wrote:
> On Mar 28, 2006, at 1:41 PM, Jack Howarth wrote:
> > I do have one other issue to resolve in this legacy c code which I
> > am unclear on.
>
> Wrong list. This list is for the development of gcc, not other
> software.
>
> > warning: initialization makes integer from pointer without a cast
>
> Yup.
>
> > ...for the line with a NULL. My immediate inclination was to
> > substitute '0' for the NULL which does indeed eliminate the
> > warning.
>
> Ick.
>
> > Is there a more appropriate fix?
>
> int i = NULL;
>
> should be written as:
>
> int i = 0;
>
> but, I don't know why that wasn't obvious.
>
for this prepstruct bound_description {
int type;
WORDdescr;
} bnddescr[] = {
BNDTYP_NULL,"null",
BNDTYP_BOND,"bond",
BNDTYP_ANGLE, "angle",
BNDTYP_FIXED, "fixed",
BNDTYP_DIHED, "dihed",
BNDTYP_CTLIM, "ctlim",
BNDTYP_BOUND, "bound",
BNDTYP_DIST,"dist",
BNDTYP_EXP, "exp",
BNDTYP_OTHER, "other",
BNDTYP_TRIANGLE,"triang",
NULL
};
for this processor replace NULL by (void *)0 this is out put of preprocessor
struct bound_description {
int type;
char * descr;
} bnddescr[] = {
1, "null",
2, "bond",
3, "angle",
3, "fixed",
4, "dihed",
5, "ctlim",
6, "bound",
7, "dist",
8, "exp",
9, "other",
10, "triang",
((void *)0)
};
there is type mismatch while assign srtuct ...
if u replace NULL by, '0' ascii value of '0' is assign to first
element of struct
Regards
Rajath.N.R
Re: GNU Pascal branch
All, FWIW, I would like to add my support for creating a branch for gpc with the eventual goal of integrating Pascal into mainline. I would bootstrap and test this branch, report bugs and do my best to help with solutions although I'm new at this. I think both projects would benefit. I'll venture some predictions: GCC 1. Another language would test the middle and back ends more and expose more bugs. There would be the process, structure, and motivation to fix them because gpascal is integrated. 2. I know of one person from the gpc world who participates in gcc and understands the gcc-4+ internals. I'm sure more would follow. 3. It would be cool to have more languages! --enable-languages=c,c++,java,objc,obj-c++,fortran,treelang,ada,pascal, Mwahahahah!!! 4. There are multi-language Pascal-C, etc systems that GCC would be left out of without gpascal. GPC 1. The later versions of gcc are getting faster. Moving gpc off of gcc-3 and into gcc-4 would speed things up. GCC-3.4.6 is the end of the line for GCC-3. 2. By targeting integration rather than proximity, all the recent work in getting gpascal to work with gcc-4 would be less likely to bitrot. 3. GPC would get much wider exposure. It would probably eventually ship along with the rest of gcc in OS distributions including *ahem* MacOSX. 4. I've seen questions on the gpc mailing list about the availability of OpenMP for Pascal. I don't think OpenMP treats Pascal but gcc has OpenMP integrated into the C, C++, and Fortran frontends and has a common OMP runtime. If OMP was wanted as an extension or became part of OpenMP then your best bet is GCC. 5. I believe that more people would join the GPC maintenance effort. I get the sense that there are wounds from old battles. Based on the replies I believe that many of the complaints (perceived and/or real): poor response to bug reports, second class citizen feelings - would fall by the wayside if a branch with the goal of full integration were initiated. This would require that friendly dialog would ensue and that new people are eased into a different culture in a welcoming manner. This would require a change in workflow and project structure for gpascal. But I think it is worth it. I really hope that these issues and others can be resolved for the benefit of all. Peace, Ed Smith-Rowland
gcc-4.2-20060401 is now available
Snapshot gcc-4.2-20060401 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060401/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 112606 You'll find: gcc-4.2-20060401.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20060401.tar.bz2 C front end and core compiler gcc-ada-4.2-20060401.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20060401.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20060401.tar.bz2 C++ front end and runtime gcc-java-4.2-20060401.tar.bz2 Java front end and runtime gcc-objc-4.2-20060401.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20060401.tar.bz2The GCC testsuite Diffs from 4.2-20060325 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: successfully removed the convert callback
> "Rafael" == Rafael Espíndola <[EMAIL PROTECTED]> writes: Rafael> I found a bit strange that there were no java regression since Rafael> convert_ieee_real_to_integer is no longer used. Is a testcase Rafael> missing? Did you run Jacks? As I recall it has a test for this. Tom
Re: GNU Pascal branch
Ed Smith-Rowland wrote: All, FWIW, I would like to add my support for creating a branch for gpc with the eventual goal of integrating Pascal into mainline. I would bootstrap and test this branch, report bugs and do my best to help with solutions although I'm new at this. I think both projects would benefit. I'll venture some predictions: GCC 1. Another language would test the middle and back ends more and expose more bugs. There would be the process, structure, and motivation to fix them because gpascal is integrated. 2. I know of one person from the gpc world who participates in gcc and understands the gcc-4+ internals. I'm sure more would follow. 3. It would be cool to have more languages! --enable-languages=c,c++,java,objc,obj- c++,fortran,treelang,ada,pascal, Mwahahahah!!! plus modula ! 4. There are multi-language Pascal-C, etc systems that GCC would be left out of without gpascal. GPC 1. The later versions of gcc are getting faster. Moving gpc off of gcc-3 and into gcc-4 would speed things up. GCC-3.4.6 is the end of the line for GCC-3. 2. By targeting integration rather than proximity, all the recent work in getting gpascal to work with gcc-4 would be less likely to bitrot. 3. GPC would get much wider exposure. It would probably eventually ship along with the rest of gcc in OS distributions including *ahem* MacOSX. 4. I've seen questions on the gpc mailing list about the availability of OpenMP for Pascal. I don't think OpenMP treats Pascal but gcc has OpenMP integrated into the C, C++, and Fortran frontends and has a common OMP runtime. If OMP was wanted as an extension or became part of OpenMP then your best bet is GCC. 5. I believe that more people would join the GPC maintenance effort. I get the sense that there are wounds from old battles. Based on the replies I believe that many of the complaints (perceived and/or real): poor response to bug reports, second class citizen feelings - would fall by the wayside if a branch with the goal of full integration were initiated. This would require that friendly dialog would ensue and that new people are eased into a different culture in a welcoming manner. This would require a change in workflow and project structure for gpascal. But I think it is worth it. I really hope that these issues and others can be resolved for the benefit of all. This is an excellent résumé of the situation. Thanks, Adriaan van Os
[RFC] Ignore TREE_CONSTANT_OVERFLOW in integer_zerop
Following some of my recent middle-end clean-ups, I believe that we're now at the point where incrementally the middle-end can start ignoring the TREE_OVERFLOW bits on constant tree nodes. As a step in this direction, the patch below removes the TREE_CONSTANT_OVERFLOW checks from integer_zerop, integer_onep, and friends in tree.c. This patch bootstraps and regression tests on i686-pc-linux-gnu (including Ada) with no new failures. The major true user of TREE_CONSTANT_OVERFLOW is the C front-end, which doesn't use any of these functions to determine whether it should issue a diagnostic when an overflowed integer is used in a context requiring a compile-time constant. Over the years, this overflow testing in the middle-end has caused numerous bugs, the most recent being last week's PR26859. Removing this test cleans up the semantics of integer constants a little. In the unlikely event that any problems are discovered, by routines relying on these functions testing checking for overflow, the trivial fix is to rewrite the callers as: if (integer_zerop (t) && ! TREE_CONSTANT_OVERFLOW (t)) ... There is now a stronger requirement on fold-const.c and friends that it now be extra careful preserving TREE_CONSTANT_OVERFLOW for the C front-end. Optimizations such as "0 * x" -> "0" where we test for zero using integer_zerop, have been checked to make sure that we return the original zero, which the overflow bits set as appropriate. Once this patch is approved there's some follow-up clean-up that can be done, removing the duplication in the many "local" functions that test for zero but couldn't previously use integer_zerop due to the historical overflow semantics. Presumably everyone agrees that this evolution is a good thing. The contention is whether everyone agrees that we're ready for such a step. Is such a transition safe for stage 3 mainline, and/or would front-ends prefer some time to double check that this won't cause problems on conformance tests not part of GCC's testsuite. Thoughts? 2006-04-01 Roger Sayle <[EMAIL PROTECTED]> * tree.c (integer_zerop): Ignore TREE_CONSTANT_OVERFLOW. (integer_onep): Likewise. (integer_all_onesp): Likewise. (integer_pow2p): Likewise. (integer_nonzerop): Likewise. (real_zerop): Likewise. (real_onep): Likewise. (real_twop): Likewise. (real_minus_onep): Likewise. (int_size_in_bytes): Likewise. (host_integerp): Likewise. Index: tree.c === *** tree.c (revision 112378) --- tree.c (working copy) *** integer_zerop (tree expr) *** 1209,1215 STRIP_NOPS (expr); return ((TREE_CODE (expr) == INTEGER_CST - && ! TREE_CONSTANT_OVERFLOW (expr) && TREE_INT_CST_LOW (expr) == 0 && TREE_INT_CST_HIGH (expr) == 0) || (TREE_CODE (expr) == COMPLEX_CST --- 1209,1214 *** integer_onep (tree expr) *** 1226,1232 STRIP_NOPS (expr); return ((TREE_CODE (expr) == INTEGER_CST - && ! TREE_CONSTANT_OVERFLOW (expr) && TREE_INT_CST_LOW (expr) == 1 && TREE_INT_CST_HIGH (expr) == 0) || (TREE_CODE (expr) == COMPLEX_CST --- 1225,1230 *** integer_all_onesp (tree expr) *** 1250,1257 && integer_zerop (TREE_IMAGPART (expr))) return 1; ! else if (TREE_CODE (expr) != INTEGER_CST ! || TREE_CONSTANT_OVERFLOW (expr)) return 0; uns = TYPE_UNSIGNED (TREE_TYPE (expr)); --- 1248,1254 && integer_zerop (TREE_IMAGPART (expr))) return 1; ! else if (TREE_CODE (expr) != INTEGER_CST) return 0; uns = TYPE_UNSIGNED (TREE_TYPE (expr)); *** integer_pow2p (tree expr) *** 1303,1309 && integer_zerop (TREE_IMAGPART (expr))) return 1; ! if (TREE_CODE (expr) != INTEGER_CST || TREE_CONSTANT_OVERFLOW (expr)) return 0; prec = (POINTER_TYPE_P (TREE_TYPE (expr)) --- 1300,1306 && integer_zerop (TREE_IMAGPART (expr))) return 1; ! if (TREE_CODE (expr) != INTEGER_CST) return 0; prec = (POINTER_TYPE_P (TREE_TYPE (expr)) *** integer_nonzerop (tree expr) *** 1341,1347 STRIP_NOPS (expr); return ((TREE_CODE (expr) == INTEGER_CST - && ! TREE_CONSTANT_OVERFLOW (expr) && (TREE_INT_CST_LOW (expr) != 0 || TREE_INT_CST_HIGH (expr) != 0)) || (TREE_CODE (expr) == COMPLEX_CST --- 1338,1343 *** real_zerop (tree expr) *** 1434,1440 STRIP_NOPS (expr); return ((TREE_CODE (expr) == REAL_CST - && ! TREE_CONSTANT_OVERFLOW (expr) && REAL_VALUES_EQUAL (TREE_REAL_CST (expr), dconst0)) || (TREE_CODE (expr) == COMPLEX_CST && real_zerop (TREE_REALPART (expr)) --- 1430,1435 *** real_onep (tree expr) *** 1449,1455 *
[Bug fortran/17298] Scalarization of non-elemental intrinsic: __transfer1 / Build failure
Steve, Note, your patch conflicted with one of the other 7 patches I tested today. You'll need to make sure the merge is correct. I presume that is my missing argument patch? I was going to commit it just now but ran into: -c ../../trunk/gcc/crtstuff.c -DCRT_BEGIN \ -o crtbegin.o In file included from /usr/include/stdio.h:36, from ../../trunk/gcc/tsystem.h:90, from ../../trunk/gcc/crtstuff.c:68: /usr/include/bits/types.h:146: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [crtbegin.o] Error 1 make[3]: Leaving directory `/svn/gcc-4.2/build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/svn/gcc-4.2/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/svn/gcc-4.2/build' make: *** [all] Error 2 ... so I guess that I will have to take care of the conflict because I cannot come back to it until tomorrow morning. Now that I am out of last weeks mess, I will start reviewing once more. Thanks for doing the honours - 7 in one session is too many. Paul
