java broken on Linux/x86-64
Running the testsuite on the trunk, I get lots of failures: === libjava Summary for unix === # of expected passes1811 # of unexpected failures1087 # of expected failures 6 # of untested testcases 1097 This has been introduced in the last 24 hours. The libjava.log file shows: Exception during runtime initialization java.lang.ExceptionInInitializerError <> Caused by: java.lang.NegativeArraySizeException <> FAIL: PR9577 run Exception during runtime initialization java.lang.ExceptionInInitializerError <> Caused by: java.lang.NegativeArraySizeException <> FAIL: longfield run This is on Linux/x86-64, Andreas -- Andreas Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgphoJGnOtatb.pgp Description: PGP signature
Re: LTO, LLVM, etc.
Mathieu Lacage wrote: > A path where different solutions for different problems are evolved > independently and then merged where it makes sense seems better to me > than a path where a single solution to two different problems is > attempted from the start. > > Which is thus why I think that "there are inherent reasons that you must > necessarily have multiple representations". There are a lot of places, in GCC and otherwise, where having a unified framework for things has been a clear advantage. So, I think your statement that "genericity is most often bad" is too strong; it's bad sometimes, and good other times. You're definitely right that false commonality can lead to bad results; but, on the other hand, a frequent complaint is that people have to write "the same code" twice because something that could have been shared was not. That's why I think we should be talking about the effort required to implement the approaches before us, and the payoffs from where those approaches lead us, rather than generalities about design. (And, if you really want a prize, you can put "risk-adjusted" in front of "effort" and "payoffs" above!) Thanks, -- Mark Mitchell CodeSourcery, LLC [EMAIL PROTECTED] (916) 791-8304
Questions about long long type
Hello, I have two questions about long long type. Firstly, shall I support it in the machine.md file, or just leave it to libgcc? Dose the libgcc support it if I don't implement in the machine.md file? Secondly, is the long long type equal to DImode in the 32bit machine? Such as adddi3, subdi3. Thanks for your reply. Eric.
Re: java broken on Linux/x86-64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jaeger wrote: > Running the testsuite on the trunk, I get lots of failures: > >=== libjava Summary for unix === > > # of expected passes1811 > # of unexpected failures1087 > # of expected failures 6 > # of untested testcases 1097 [...] > This is on Linux/x86-64, Ditto on i686-pc-linux-gnu. Undo this change to fix the problem: Index: gcc/java/ChangeLog from Tom Tromey <[EMAIL PROTECTED]> * parse.y (patch_new_array_init): Don't set length on array. After undoing this change, I'm left with: FAIL: rh174912 compilation from bytecode FAIL: rh174912 -O3 compilation from bytecode FAIL: cxxtest run XPASS: Array_3 execution - bytecode->native test XPASS: Array_3 -O3 execution - bytecode->native test (I don't understand yet why cxxtest run is marked FAILed. It seems to have run just fine. :-/ ) BTW Tom, the Red Hat bugzilla doesn't let me see the bug #174912, even after logging in. It might probably be a better idea to open a PR in GCC's bugzilla describing the problem. That said, the testcase you've included does indeed indicate the problem. Thanks, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlWRlYb1hx2wRS48RAknrAJ4+rkwjh0+f2bS6Y43RZdF1MPFewQCdHHXw nXr2HsMZ5Br3u6MdIJ2920k= =WsAP -END PGP SIGNATURE-
Re: GCC 3.4.5 status?
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes: | > Steve Ellcey <[EMAIL PROTECTED]> writes: | > | > | Has GCC 3.4.5 been officially released? | > | > Yes, tarballs are on gcc.gnu.org and ftp.gnu.org since Dec 1st. Only | > official announcement is missing. | | What are you waiting for? Finishing the manual inspection, cross-checking of PRs -- reports from bugzilla do not seem to be enough and mechanical extraction of PR numbers from ChangeLogs are not enough either (they may miss reverted patches) -- to produce the final list of changes. All that is being worked on. -- Gaby
Re: GCC 3.4.5 status?
Steve Ellcey <[EMAIL PROTECTED]> writes: | I also notice we have a "Releases" link under "About GCC" in the top | left corner of the main GCC page that doesn't look like it has been | updated in quite a while for any releases. Should this be updated or | removed? I think my previous answer to this part of your mail was hasty. Indeed, I updated (between Nov 30th and Dec 1st) that part to record the release of 3.4.5 -- but I did make a typo, listing 3.4.4 twice. That is corrected now. As for 4.x, it is not clear whether they should be listed or not, that is what I meant by deferring to Gerald. -- Gaby
[fortran] round and related builtins
Hi!
Currently there are the following builtins available from the fortran
frontends:
/* We define these separately as the fortran versions have different
semantics (they return an integer type) */
gfc_define_builtin ("__builtin_roundl", mfunc_longdouble[0],
BUILT_IN_ROUNDL, "roundl", true);
gfc_define_builtin ("__builtin_round", mfunc_double[0],
BUILT_IN_ROUND, "round", true);
gfc_define_builtin ("__builtin_roundf", mfunc_float[0],
BUILT_IN_ROUNDF, "roundf", true);
gfc_define_builtin ("__builtin_truncl", mfunc_longdouble[0],
BUILT_IN_TRUNCL, "truncl", true);
gfc_define_builtin ("__builtin_trunc", mfunc_double[0],
BUILT_IN_TRUNC, "trunc", true);
gfc_define_builtin ("__builtin_truncf", mfunc_float[0],
BUILT_IN_TRUNCF, "truncf", true);
note that if they indeed return an integer value, the corresponding
BUILT_IN_LROUND or BUILT_IN_LLROUND builtin codes should be used to
not confuse folding routines. I suppose there is support in
libgfortran for the libcall fallbacks, or are they taken from
libm? In this case they return a floating point value and I'm
confused by the comment above.
I'm currently prototyping a patch to fold (long)round(x) to lround(x)
which, with an appropriate optab for lround should improve lucas SPEC
quite a bit. The patch is working for C99, but currently fails for
fortran because the (l)lround builtins are not available from the
fortran frontend. Lucas uses dnint a lot, which is expanded to
(int)round(x) by the fortran FE, while it looks like it should expand
to lround(x) instead (if the above comment is indeed correct).
Please give me some advice on the fortran semantics of round and
the interaction with the middle-end here.
Thanks,
Richard.
Building errors for sh, h8300 and m32c targets
Hi, I am building toolchain for Renesas SH, H8300 and M32C targets for ELF format (i.e. sh-elf, h8300-elf, m32c-elf respectively) using the below mentioned sources, Binutils-051107 GCC-4.1-20051107 Newlib-dated 051114 from CVS Host: i686-pc-linux-gnu I am getting the below mentioned error at the stage of gcc building, * Error Text starts gcc -c?? -g -O2 -DIN_GCC -DCROSS_COMPILE? -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -fno-common -Wno-error? -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/pradeep/src/gcc-4.1-20051107/gcc -I/home/pradeep/src/gcc-4.1-20051107/gcc/build -I/home/pradeep/src/gcc-4.1-20051107/gcc/../include -I/home/pradeep/src/gcc-4.1-20051107/gcc/../libcpp/include? -o build/gengtype-lex.o gengtype-lex.c /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:31:27: gengtype-yacc.h: No such file or directory /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l: In function `yylex': /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:222: `yylval' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:222: (Each undeclared identifier is reported only once /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:222: for each function it appears in.) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:227: `ENT_TYPEDEF_STRUCT' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:227: `ENT_STRUCT' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:233: `ENT_EXTERNSTATIC' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:239: `ENT_YACCUNION' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:287: `GTY_TOKEN' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:288: `UNION' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:289: `STRUCT' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:290: `ENUM' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:291: `ALIAS' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:292: `NESTED_PTR' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:293: `NUM' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:296: `PARAM_IS' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:308: `SCALAR' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:329: `ID' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:339: `STRING' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:343: `ARRAY' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:347: `PERCENT_ID' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:351: `CHAR' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:367: `PERCENTPERCENT' undeclared (first use in this function) make[1]: *** [build/gengtype-lex.o] Error 1 make[1]: Leaving directory `/home/pradeep/build/gcc/gcc' make: *** [all-gcc] Error 2 Error Text Ends ** After looking into the error, I found that these files are not present in the gcc-4.1 snapshots. Hence I copied the "gengtype-yacc.c" and "gengtype-yacc.h" files from the gcc-4.0.0 sources to the respective directory of gcc-4.1.0 snapshots i.e. "/../gcc-4.1-20051107/gcc/"? After copying of these two files the building process completed successfully. Could any one suggest me the reasons of presence of these files in the previous version and the cause to delete these files in this gcc-4.1 snapshot ? I have already post the same query on the crossgcc mailing list "[EMAIL PROTECTED]", http://sources.redhat.com/ml/crossgcc/2005-11/msg00195.html Thanks in advance. Nitin Shah. KPIT Cummins InfoSystems Ltd. Pune, India Free download of GNU based tool-chains for Renesas' SH and H8 Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on October 12, 2005.
Renaming build_function_call_expr?
Hi, back in August I removed a call to fold after build_function_call_expr, since build_function_call_expr already does the folding. In a follow-up mail Richard Guenther raised the following point ( see http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01466.html ): > Following precedence and to avoid such issue in future should we rename > this to fold_build_function_call_expr? Or build_fold_function_call_expr. The problem is that there are about 113 occurrences of build_function_call_expr in the GCC tree. I wonder whether renaming them would be a too big change with too little benefit. Would it be more appropriate to just change the comment on top of the function (in builtins.c, line ~8760) from /* Conveniently construct a function call expression. */ to /* Conveniently construct and fold a function call expression. */ ? Any preferences? Regards, Volker
g++.dg/ext/packed3.C
This test contains three invocations of Ref(), but only two of them are considered ill. What I'd like to get an explanation for is why the third (middle) instance is considered correct. After all, the u member of Packed is packed, and hence all the members of Unpacked in that context are, too. Namely, even if the object referenced by p is properly aligned, p.u isn't and hence p.u.i isn't either. I'm asking this because for *-*-netware*, which uses packed structures by default, this test fails with an error message like the ones expected on the other two calls to Ref(). Thanks, Jan
gcc generates incorrect code with -Os
Hi,
gcc-4.0.1-4.fc4
gcc-4.0.2-8.fc4 (4.0.2 20051125 (Red Hat 4.0.2-8))
i386
gcc -W -Wall -Os test.c -o test -Werror && ./test
array: 1 2
array: 1 2
gcc -W -Wall -O2 test.c -o test -Werror && ./test
array: 1 2
array: 2 3
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173764
#include
void test_it(int *array)
{
int i;
for (i = 0; i < 2; i++) {
int value = array[i];
if (i != 1000 && i != 1001)
array[i] = value + 1;
}
}
int main(void)
{
int array[2] = {1, 2};
printf("array: %i %i\n", array[0], array[1]);
test_it(array);
printf("array: %i %i\n", array[0], array[1]);
return 0;
}
--
Krzysztof Halasa
Re: Building errors for sh, h8300 and m32c targets
Do you have bison installed? In my local build, that's a generated file, not a source controlled file.
testsuite issue
>2005-12-01 Hans-Peter Nilsson <[EMAIL PROTECTED]> > > * gcc.dg/20041106-1.c, gcc.dg/20030321-1.c, gcc.dg/pr17112-1.c, > gcc.dg/pr17112-1.c, g++.dg/other/packed1.C, > g++.dg/other/crash-4.C, g++.dg/ext/packed8.C: Match "attribute > ignored" warnings when "packing" is the same as the ABI layout. While most of these changes appear to be correct, I see a regression on *-*-netware* (which by default uses packed structures) in gcc.dg/20030321-1.c, and I believe the warning tested for cannot be expected (since the code generating the warning tests TYPE_ALIGN (TREE_TYPE (*node)) <= BITS_PER_UNIT which cannot reasonably be expected to be true for 'long long'. Can this part of the patch therefore be reverted? Thanks, Jan
Mention gcc 4.1 in News/Announcements
Hi gcc team, please mention gcc 4.1 in News/Announcements at http://gcc.gnu.org/index.html if this is an official release. Thanks and regards Jurij
Re: Mention gcc 4.1 in News/Announcements
On 12/6/05, Jurij Rosenthal <[EMAIL PROTECTED]> wrote: > Hi gcc team, > > please mention gcc 4.1 in News/Announcements > at > http://gcc.gnu.org/index.html > > if this is an official release. What makes you think it is? 4.1.0 is not yet released. Richard.
Re: Mention gcc 4.1 in News/Announcements
* Richard Guenther: > What makes you think it is? I think there was some release announcement on Slashdot when the branch was created. 8-)
Re: Mention gcc 4.1 in News/Announcements
Florian Weimer writes: > * Richard Guenther: > > > What makes you think it is? > > I think there was some release announcement on Slashdot when the > branch was created. 8-) ... thereby maintaining the reputation for accuracy for which Slashdot is justly famous. Andrew.
Re: MIPS: comparison modes in conditional branches
Jim Wilson writes: > Yes, it looks like fixing the combiner problem would make it possible to > remove the mistaken mode checks. Thanks very much, Jim. I will work toward removing these then. Adam
Re: Mention gcc 4.1 in News/Announcements
On Tuesday 06 December 2005 13:00, Andrew Haley wrote: > ... thereby maintaining the reputation for accuracy for which Slashdot > is justly famous. > Yes, they're collectively pretty clueless. However, in the midst of that /. interchange I did see one posting that made a relatively good point: If you go to gcc.gnu.org, you will see "Current release series: GCC 4.1.0". For the uninformed, that may be construed as "GCC 4.1.0 has been released". That may have tripped the original /. poster into thinking that. No, I'm not defending them.
gcc-prs mailing list archives
This is just to let you know that the gcc-prs mailing list archives seem to fail since June, 2004. Everything since then gives empty archives. If the list is closed (probably subsumed by bugzilla), maybe the best is to freeze the archive http://gcc.gnu.org/ml/gcc-prs/ Theo.
Re: java broken on Linux/x86-64
> "Andreas" == Andreas Jaeger <[EMAIL PROTECTED]> writes: Andreas>=== libjava Summary for unix === Andreas> # of expected passes1811 Andreas> # of unexpected failures1087 Andreas> # of expected failures 6 Andreas> # of untested testcases 1097 Sorry about this. I'll fix it today. Tom
Re: Questions about long long type
Eric Fisher <[EMAIL PROTECTED]> writes: > Firstly, shall I support it in the machine.md file, or just leave it to > libgcc? > Dose the libgcc support it if I don't implement in the machine.md file? Yes, if you supply SImode operations, libgcc will give you some DImode operations, and the others will be opencoded by the compiler. For example, addition is open coded, and multiplication is in libgcc. Sometimes you can get more efficient code by putting DImode operations in your MD file--e.g., if you have an add-with-carry instruction. > Secondly, is the long long type equal to DImode in the 32bit machine? > Such as adddi3, subdi3. Normally, yes, though it is not a requirement. You can control the type "long long" by setting LONG_LONG_TYPE_SIZE in your CPU.h file. The way to think about it is that "long long" is an integer type of a certain size, typically 64 bits but it can be something else. DImode is always the internal representation of a 64-bit integer. (Unless your processor does not address memory in 8-bit units, which is very unusual). Ian
Re: Mention gcc 4.1 in News/Announcements
On Tuesday 06 December 2005 18:10, Diego Novillo wrote: > > Yes, they're collectively pretty clueless. However, in the midst of > that /. interchange I did see one posting that made a relatively good > point: If you go to gcc.gnu.org, you will see "Current release series: > GCC 4.1.0". > > For the uninformed, that may be construed as "GCC 4.1.0 has been released". > That may have tripped the original /. poster into thinking that. No, I'm > not defending them. Or misconstrued as "Current releases are from the 4.1 series". I tripped over that, only realising my mistake when the expected tarball was no where to be seen on the ftp server... So I can only agree that the wording is a little ambiguous. Andrew Walrond
Re: java broken on Linux/x86-64
> "Ranjit" == Ranjit Mathew <[EMAIL PROTECTED]> writes: Ranjit> BTW Tom, the Red Hat bugzilla doesn't let me see the Ranjit> bug #174912, even after logging in. It might probably be Ranjit> a better idea to open a PR in GCC's bugzilla describing Ranjit> the problem. That said, the testcase you've included does Ranjit> indeed indicate the problem. I didn't realize this PR was marked private. I'll open one in gcc bugzilla. Tom
Missing link to changes.html for 4.1...
FYI: After the 4.1 branch was created there appears to be no way to navigate to: http://gcc.gnu.org/gcc-4.1/changes.html from the gcc.gnu.org home page. Navigation to changes.html for all other versions (except 4.1) is possible. David Daney.
Re: Documentation for 4.0.2
Hi, > > Any chances that the GCC Internals documentation will be updated any > > time soon? http://gcc.gnu.org/onlinedocs/gccint/ > It looks pretty current to me. Hmm... there're 30 FIXMEs and the section on C trees is missing: Macros-and-Functions.html:57:This section is not here yet. It would be nice if someone could at least update the C trees and GIMPLE sections... > Are you talking about 4.2 or 4.0.2? 4.0.2 Thx. Regards, Domagoj -- ___ Play 100s of games for FREE! http://games.mail.com/
Re: gcc generates incorrect code with -Os
The best way to get noticed and the problem fixed is to open a PR in GCC Bugzilla: http://gcc.gnu.org/bugzilla/ VH signature.asc Description: OpenPGP digital signature
C++ parser: Should we get rid of cp_parser_declarator_id?
The C++ parser contains the static function cp_parser_declarator_id (cp_parser* parser) which consists of a lot of comments and a single statement return cp_parser_id_expression (parser, /*template_keyword_p=*/false, /*check_dependency_p=*/false, /*template_p=*/NULL, /*declarator_p=*/true); and which has a single caller. Shouldn't we fold cp_parser_declarator_id into the caller and call cp_parser_id_expression directly? But what about the comments then? (Are they still accurate, btw.?) Or should we leave the function intact just to preserve the comments? Regards, Volker
Re: testsuite issue
> Date: Tue, 06 Dec 2005 18:02:51 +0100 > From: "Jan Beulich" <[EMAIL PROTECTED]> > >2005-12-01 Hans-Peter Nilsson <[EMAIL PROTECTED]> > > > > * gcc.dg/20041106-1.c, gcc.dg/20030321-1.c, gcc.dg/pr17112-1.c, > > gcc.dg/pr17112-1.c, g++.dg/other/packed1.C, > > g++.dg/other/crash-4.C, g++.dg/ext/packed8.C: Match "attribute > > ignored" warnings when "packing" is the same as the ABI layout. > > While most of these changes appear to be correct, I see a regression on > *-*-netware* (which by default uses packed structures) in > gcc.dg/20030321-1.c, and I believe the warning tested for cannot be > expected (since the code generating the warning tests > > TYPE_ALIGN (TREE_TYPE (*node)) <= BITS_PER_UNIT > > which cannot reasonably be expected to be true for 'long long'. Why not? If you don't get a warning for the attribute being ignored then, your target doesn't really pack structures; maybe we need to split default_packed into variants. > Can this part of the patch therefore be reverted? Uh, no. It works as intended and removing it would cause a regression. On the other hand, FWIW, I think the warning is generally bogus, but I've already mentioned that. brgds, H-P
Re: C++ parser: Should we get rid of cp_parser_declarator_id?
Volker Reichelt <[EMAIL PROTECTED]> writes: | The C++ parser contains the static function | cp_parser_declarator_id (cp_parser* parser) | which consists of a lot of comments and a single statement | | return cp_parser_id_expression (parser, | /*template_keyword_p=*/false, | /*check_dependency_p=*/false, | /*template_p=*/NULL, | /*declarator_p=*/true); | | and which has a single caller. | | Shouldn't we fold cp_parser_declarator_id into the caller and call | cp_parser_id_expression directly? | But what about the comments then? (Are they still accurate, btw.?) | Or should we leave the function intact just to preserve the comments? If we make it "static inline", would not we gain the same efficiency and preserve the comments and all that? In general, the methodoly seems to have a function for each non-terminal -- following a long tradition of recursive descent parser -- and maintaining that principle is helpful for code clarity. -- Gaby
Re: Torbjorn's ieeelib.c
Mark Mitchell wrote: That message contains an IEEE floating-point emulation library, like fp-bit.c. Howeve, the performance is considerably better; Joseph measured against fp-bit.c with a modern compiler, and ieeelib.c is about 10-15% better than the current code on EEMBC on a PowerPC 440. For the record, there is also FP emulation code in the gdb simulator. See the gdb src/sim/commom/sim-fpu.c file. This code was originally taken from gcc's fp-bit.c, and has since been significantly improved both for speed and accuracy. It is quite a bit better than what we have in fp-bit.c. This is another option worth investigating. I don't know how it compares to the glibc code or Torbjorn's code. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
gcc-3.4-20051206 is now available
Snapshot gcc-3.4-20051206 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20051206/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-3_4-branch revision 108132 You'll find: gcc-3.4-20051206.tar.bz2 Complete GCC (includes all of below) gcc-core-3.4-20051206.tar.bz2 C front end and core compiler gcc-ada-3.4-20051206.tar.bz2 Ada front end and runtime gcc-g++-3.4-20051206.tar.bz2 C++ front end and runtime gcc-g77-3.4-20051206.tar.bz2 Fortran 77 front end and runtime gcc-java-3.4-20051206.tar.bz2 Java front end and runtime gcc-objc-3.4-20051206.tar.bz2 Objective-C front end and runtime gcc-testsuite-3.4-20051206.tar.bz2The GCC testsuite Diffs from 3.4-20051129 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-3.4 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.
C++ 3.4.5 packed reference warning
When I compile this using gcc rev 3.4.5 (m68k-elf):
struct A { charB;
unsigned char & C; } __attribute__((packed));
unsigned char D;
A E = { 'F', D };
I get:
testpp.cpp:2: warning: ignoring packed attribute on unpacked non-POD
field `unsigned char&A::C'
sizeof( E ) == 6 (B, a byte of pad since m68k uses 16 bit alignment, and
C).
This construct compiled without warning under 3.3.3 and gave sizeof( E )
== 5.
Is this behavior under 3.4.5 (both the warning and the ignoring of the
packed attribute on the reference member) proper (justified, necessary,
good)?
BTW, the documentation for 3.4.5 (at
http://gcc.gnu.org/onlinedocs/gcc-3.4.5/gcc/Type-Attributes.html#Type-At
tributes) shows the example:
struct my_unpacked_struct
{
char c;
int i;
};
struct my_packed_struct __attribute__ ((__packed__))
{
char c;
int i;
struct my_unpacked_struct s;
};
This example, however, gives the error:
testpp.cpp:8: error: expected unqualified-id before '{' token
Changing to:
struct my_unpacked_struct
{
char c;
int i;
};
struct my_packed_struct
{
char c;
int i;
struct my_unpacked_struct s;
} __attribute__ ((__packed__));
Eliminates the error.
Re: Updated gcc+llvm patch
On Tuesday 06 December 2005 19:19, Chris Lattner wrote: > This version of the patch has many bugs fixed and several rough > corners rounded off (for example, there are no more hard coded paths > in the makefiles anymore, and the llvm-independent objc changes are > now in the apple branch instead of the patch). And the patch now > includes the new files, instead of having a tarball. A small improvement to gcc/makefile.in is attached. Instead of linking to LLVMPowerPC.o unconditionally, it now uses $(target) to link with LLVMPowerPC.o or LLVMX86.o. Rafael Index: gcc/Makefile.in === --- gcc/Makefile.in (revision 108132) +++ gcc/Makefile.in (working copy) @@ -53,6 +53,10 @@ MAKEOVERRIDES = .SUFFIXES: .SUFFIXES: .c .o .po .pox .gmo +# APPLE LOCAL begin llvm +.SUFFIXES: .cpp +# APPLE LOCAL end llvm + # --- # Standard autoconf-set variables # --- @@ -210,7 +214,15 @@ reload1.o-warn = -Wno-error # $(GCC_WARN_CFLAGS), or nothing. WARN_CFLAGS = @warn_cflags@ +# APPLE LOCAL begin LLVM [EMAIL PROTECTED]@ +LLVMBASEPATH = @LLVMBASEPATH@ +ifeq ($(LLVMBASEPATH),) CPPFLAGS = @CPPFLAGS@ +else +CPPFLAGS = @CPPFLAGS@ -DENABLE_LLVM -D__STDC_LIMIT_MACROS +endif +# APPLE LOCAL end LLVM # These exists to be overridden by the x-* and t-* files, respectively. X_CFLAGS = @@ -792,7 +804,34 @@ BUILD_LIBDEPS= $(BUILD_LIBIBERTY) # How to link with both our special library facilities # and the system's installed libraries. -LIBS = @LIBS@ $(CPPLIB) $(LIBINTL) $(LIBICONV) $(LIBIBERTY) +# APPLE LOCAL begin LLVM +ifneq ($(LLVMBASEPATH),) +ifdef CHECKING_ENABLED +BUILDMODE=Debug +else +BUILDMODE=Release +endif +LLVMLIBPATH = $(LLVMBASEPATH)/$(BUILDMODE)/lib + +LLVMTARGETOBJCMD := case $(target) in \ + powerpc*-*-*) echo LLVMPowerPC.o;; \ + i[34567]86-*-*) echo LLVMX86.o;; \ + esac + +LLVMTARGETOBJ := $(shell $(LLVMTARGETOBJCMD)) + +ifeq ($(LLVMTARGETOBJ),) +$(error Unsuported LLVM Target $(target)) +endif + +LLVMLIBS = -L$(LLVMLIBPATH) $(LLVMLIBPATH)/$(LLVMTARGETOBJ) -lLLVMScalarOpts \ + -lLLVMTransformUtils -lLLVMAnalysis \ + $(LLVMLIBPATH)/LLVMSelectionDAG.o $(LLVMLIBPATH)/LLVMCodeGen.o \ +-lLLVMTarget \ + $(LLVMLIBPATH)/LLVMCore.o -lLLVMSupport -lLLVMSystem -lstdc++ +endif +LIBS = @LIBS@ $(CPPLIB) $(LIBINTL) $(LIBICONV) $(LIBIBERTY) $(LLVMLIBS) +# APPLE LOCAL end LLVM # Any system libraries needed just for GNAT. SYSLIBS = @GNAT_LIBEXC@ @@ -823,10 +862,30 @@ BUILD_VARRAY = build/varray.o INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \ -I$(srcdir)/../include @INCINTL@ \ $(CPPINC) $(GMPINC) +# APPLE LOCAL begin LLVM +ifneq ($(LLVMBASEPATH),) +INCLUDES += -I$(LLVMBASEPATH)/include +endif +# APPLE LOCAL end LLVM .c.o: $(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION) +# APPLE LOCAL begin LLVM +# Disable C-only warning flags if they are present. +ALL_CXXFLAGS = $(filter-out -Wstrict-prototypes -Wmissing-prototypes \ +-Wold-style-definition, $(ALL_CFLAGS)) -Wno-unused +ALL_CXXFLAGS += -DTARGET_NAME=\"$(target_noncanonical)\" + +# Turn off LLVM assertions in a non-checking build. +ifndef CHECKING_ENABLED +ALL_CXXFLAGS += -DNDEBUG +endif + +.cpp.o: + $(CXX) -c $(ALL_CXXFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) $< $(OUTPUT_OPTION) +# APPLE LOCAL end LLVM + # # Support for additional languages (other than C). # C can be supported this way too (leave for later). @@ -966,11 +1025,23 @@ OBJS-md = $(out_object_file) OBJS-archive = $(EXTRA_OBJS) $(host_hook_obj) tree-inline.o \ cgraph.o cgraphunit.o tree-nomudflap.o -OBJS = $(OBJS-common) $(out_object_file) $(OBJS-archive) +# APPLE LOCAL begin LLVM +ifneq ($(LLVMBASEPATH),) +LLVM_OBJECTS = llvm-backend.o llvm-convert.o llvm-types.o +endif +OBJS = $(OBJS-common) $(LLVM_OBJECTS) $(out_object_file) $(OBJS-archive) +# APPLE LOCAL end LLVM OBJS-onestep = libbackend.o $(OBJS-archive) -BACKEND = main.o @TREEBROWSER@ libbackend.a $(CPPLIB) +# APPLE LOCAL begin LLVM +ifneq ($(LLVMBASEPATH),) +MAIN_OBJ = llvm-main.o +else +MAIN_OBJ = main.o +endif +BACKEND = $(MAIN_OBJ) @TREEBROWSER@ libbackend.a $(CPPLIB) +# APPLE LOCAL end LLVM # Files to be copied after each stage in building. STAGECOPYSTUFF = insn-flags.h insn-config.h insn-codes.h \ @@ -2266,6 +2337,15 @@ pretty-print.o: $(CONFIG_H) $(SYSTEM_H) $(TREE_H) errors.o : errors.c $(CONFIG_H) $(SYSTEM_H) errors.h +# APPLE LOCAL begin LLVM +llvm-main.o : llvm-main.cpp $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) toplev.h +ALL_HEADERS = $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) \ + llvm.h llvm-internal.h llvm-file-ostream.h llvm-abi.h +llvm-backend.o : llvm-backend.cpp $(ALL_HEADERS) +llvm-convert.o : llvm-convert.cpp $(ALL_HEADERS) +llvm-types.o : llvm-types.cpp $(ALL_HEADERS) +# APPLE LOCAL end LLVM + $(out_object_file): $(out_file) $(CONFIG
Re: Updated gcc+llvm patch
On Dec 6, 2005, at 4:35 PM, Rafael Ávila de Espíndola wrote: On Tuesday 06 December 2005 19:19, Chris Lattner wrote: This version of the patch has many bugs fixed and several rough corners rounded off (for example, there are no more hard coded paths in the makefiles anymore, and the llvm-independent objc changes are now in the apple branch instead of the patch). And the patch now includes the new files, instead of having a tarball. A small improvement to gcc/makefile.in is attached. Instead of linking to LLVMPowerPC.o unconditionally, it now uses $(target) to link with LLVMPowerPC.o or LLVMX86.o. Great, I applied it to my local tree, thanks! -Chris
gcc 4.1 code size
Hello list, I have a question concerning the size of the code generated by gcc 4.0.2 and 4.1. We talk about a C++ app with many smaller (30k) or larger (4M) C++ libraries. Being happy the size of those libs decreased by about 20% when switching from gcc 3.4.4 to gcc 4.0.2 (introducing --visibility-inlines-hidden), I was now astonished that my tests with gcc 4.1 showed that the library size has been grown by about 10%. The compiler parameters have not been changed for this test and the test has been done on the same system, so it must be related to gcc. Is this a regression, a feature (possibly better code inlining) or just the fact that gcc 4.0.2 is a release version and the gcc 4.1 was just a snapshot? Nevertheless, the generated code runs about 3% faster than the 4.0.2 code, so there's nothing to complain. The used compile options are: -ftemplate-depth-32 -finline-functions -finline-limit-10 -O3 -march=athlon-mp -ftracer -fvisibility-inlines-hidden -ftree-vectorize -pipe Andreas Killaitis
Re: gcc 4.1 code size
Andreas Killaitis <[EMAIL PROTECTED]> wrote: > I was now astonished > that my tests with gcc 4.1 showed that the library size has been > grown by about 10%. > The used compile options are: > > [...] > -O3 Don't expect GCC to optimize code size at -O3. -O3 means -O2 *and* inline as much as it makes sense to do, so it's really not a good option if you're interested in code size. Giovanni Bajo
Re: gcc 4.1 code size
On Dec 6, 2005, at 4:35 PM, Andreas Killaitis wrote: -finline-limit-10 This and wanting a small size are kinda incompatible. There might be smaller values of n that will shrink the code, and yet still give you the performance you seem to want.
Re: gcc 4.1 code size
Am 07.12.2005 um 02:14 schrieb Mike Stump: On Dec 6, 2005, at 4:35 PM, Andreas Killaitis wrote: -finline-limit-10 This and wanting a small size are kinda incompatible. There might be smaller values of n that will shrink the code, and yet still give you the performance you seem to want. Obviously I've been expressing me not very clear. I don't care for code size (well, at least not soo much), speed is what counts, and speed is what I get. I was just wondering why the code size has increased with the new gcc version. An increase of 1% or so I'd been ignoring, but 10% with the same compiler settings attracted my attendence. Andreas Killaitis
Any who heard about genmd?
A tool developed by Indian Institute of Technology Kanpur, which takes architecture description represented using Sim-nML as input and generates GCC md as output. I have been searching for source code of this tool. Anyone who has the source code, please send me a copy. __ 赶快注册雅虎超大容量免费邮箱? http://cn.mail.yahoo.com
Re: gcc 4.1 code size
On Dec 6, 2005, at 5:25 PM, Andreas Killaitis wrote: Obviously I've been expressing me not very clear. I don't care for code size (well, at least not soo much), speed is what counts, and speed is what I get. I was just wondering why the code size has increased with the new gcc version. An increase of 1% or so I'd been ignoring, but 10% with the same compiler settings attracted my attendence. gcc-help is a better place to ask such questions, but, for example, as we enhance the compiler to be able to inline more often, it isn't uncommon for the compiler to inline more often, and with that usually comes code size increases. If you're curious, you can compare the code generated by the compiler and see how it differs. Just give it -S. Also, libstdc++ also can grow, and with growth in it, the application can grow, further, libgcc.a can grow, and with it, the application can grow. If you compare object file sizes as reported with size, then you can discount these sorts of issues. So, the answer is, yes, it can be a regression, no, it might not be a regression, yes, it might be a feature, no, it might be a bug, the exact answer depends upon what exactly the circumstance is. If you want a vague answer, no, probably not a bug. If you want a good answer, we'd need a whole lot more information from you. Source codes, OS information, how the compiler was built and so on. I'd imagine that people would rather help you to help yourself figure out how it changed. For size *.o for all .o files, select the largest growth one, re-compile it with -save-temps, then, run diff old.s new.s, and then examine the resulting code to see how it changed. What is found there will suggest different ways to investigate further. If all else fails, one can binary search the compiler sources for the codegen changes in question and then ask specifically about that testcase and that compiler change. Tracking these things down can be a lot of work.
RE: Building errors for sh, h8300 and m32c targets
Hi, bison has been already installed and once I give the command, bison --version it shows, bison (GNU Bison) 1.35 Copyright 1984, 1986, 1989, 1992, 2000, 2001, 2002 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I am able to build gcc-4.0.0 successfully without making any changes in the source. Regards, Nitin Shah. KPIT Cummins InfoSystems Ltd. Pune, India Free download of GNU based tool-chains for Renesas' SH and H8 Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on October 12, 2005. -Original Message- From: DJ Delorie [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 06, 2005 9:32 PM To: Nitin Shah Cc: gcc@gcc.gnu.org Subject: Re: Building errors for sh, h8300 and m32c targets Do you have bison installed? In my local build, that's a generated file, not a source controlled file.
Re: Building errors for sh, h8300 and m32c targets
> I am able to build gcc-4.0.0 successfully without making any changes in > the source. Right, but you're comparing a release to a snapshot. Snapshots are cut straight from source control, releases are partially built so that generated files don't have to be generated.
Re: Building errors for sh, h8300 and m32c targets
Nitin Shah wrote: Hi, I am building toolchain for Renesas SH, H8300 and M32C targets for ELF format (i.e. sh-elf, h8300-elf, m32c-elf respectively) using the below mentioned sources, Binutils-051107 GCC-4.1-20051107 Newlib-dated 051114 from CVS Host: i686-pc-linux-gnu I am getting the below mentioned error at the stage of gcc building, maybe u want to try 'find -name "*.[ly]|xargs touch' and try force regeneration of all lex, bison stuff -jimmy * Error Text starts gcc -c?? -g -O2 -DIN_GCC -DCROSS_COMPILE? -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -fno-common -Wno-error? -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/pradeep/src/gcc-4.1-20051107/gcc -I/home/pradeep/src/gcc-4.1-20051107/gcc/build -I/home/pradeep/src/gcc-4.1-20051107/gcc/../include -I/home/pradeep/src/gcc-4.1-20051107/gcc/../libcpp/include? -o build/gengtype-lex.o gengtype-lex.c /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:31:27: gengtype-yacc.h: No such file or directory /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l: In function `yylex': /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:222: `yylval' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:222: (Each undeclared identifier is reported only once /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:222: for each function it appears in.) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:227: `ENT_TYPEDEF_STRUCT' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:227: `ENT_STRUCT' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:233: `ENT_EXTERNSTATIC' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:239: `ENT_YACCUNION' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:287: `GTY_TOKEN' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:288: `UNION' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:289: `STRUCT' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:290: `ENUM' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:291: `ALIAS' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:292: `NESTED_PTR' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:293: `NUM' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:296: `PARAM_IS' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:308: `SCALAR' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:329: `ID' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:339: `STRING' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:343: `ARRAY' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:347: `PERCENT_ID' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:351: `CHAR' undeclared (first use in this function) /home/pradeep/src/gcc-4.1-20051107/gcc/gengtype-lex.l:367: `PERCENTPERCENT' undeclared (first use in this function) make[1]: *** [build/gengtype-lex.o] Error 1 make[1]: Leaving directory `/home/pradeep/build/gcc/gcc' make: *** [all-gcc] Error 2 Error Text Ends ** After looking into the error, I found that these files are not present in the gcc-4.1 snapshots. Hence I copied the "gengtype-yacc.c" and "gengtype-yacc.h" files from the gcc-4.0.0 sources to the respective directory of gcc-4.1.0 snapshots i.e. "/../gcc-4.1-20051107/gcc/"? After copying of these two files the building process completed successfully. Could any one suggest me the reasons of presence of these files in the previous version and the cause to delete these files in this gcc-4.1 snapshot ? I have already post the same query on the crossgcc mailing list "[EMAIL PROTECTED]", http://sources.redhat.com/ml/crossgcc/2005-11/msg00195.html Thanks in advance. Nitin Shah. KPIT Cummins InfoSystems Ltd. Pune, India Free download of GNU based tool-chains for Renesas' SH and H8 Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on October 12, 2005.
Re: Any who heard about genmd?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 ZengNan wrote: > A tool developed by Indian Institute of Technology Kanpur, which takes > architecture description > represented using Sim-nML as input and generates GCC md as output. I have > been searching for > source code of this tool. Anyone who has the source code, please send me a > copy. I hope you have already seen: http://www.cse.iitk.ac.in/research/mtech1998/984.html and the linked-to paper presenting the thesis. You might want to contact Prof. Sanjeev K. Aggarwal: http://www.cse.iitk.ac.in/users/ska/index.html to find out more about this project and if he has any other students working on enhancing this tool. HTH, Ranjit. - -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDlnRMYb1hx2wRS48RAg7iAJ4rRbkmuFSs/th4ARGgSqCvgv5lLgCbBYog TLT3Qm3eBO8+AyFBy/Vkjxs= =SPIW -END PGP SIGNATURE-
[gomp] gcc/config/sparc/sparc.c:8795: error: too many arguments to function `gen_compare_reg'
Bootstrapping on sparc linux fails for me (revision 108129M) gcc -m32 -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc.gomp/gcc -I../../gcc.gomp/gcc/. -I../../gcc.gomp/gcc/../include -I../../gcc.gomp/gcc/../libcpp/include -I../../gcc.gomp/gcc/../libdecnumber\ ../../gcc.gomp/gcc/config/sparc/sparc.c -o sparc.o ../../gcc.gomp/gcc/config/sparc/sparc.c: In function `sparc_expand_compare_and_swap_12': ../../gcc.gomp/gcc/config/sparc/sparc.c:8795: error: too many arguments to function `gen_compare_reg' make[2]: *** [sparc.o] Error 1 -- Cheers, /ChJ
RE: Building errors for sh, h8300 and m32c targets
Hi, Thanks a lot, My doubt has been cleared. Could you please let me know the release date of gcc-4.1. Thanks in advance. Nitin Shah. KPIT Cummins InfoSystems Ltd. Pune, India Free download of GNU based tool-chains for Renesas' SH and H8 Series. The following site also offers free technical support to its users. Visit http://www.kpitgnutools.com for details. Latest versions of KPIT GNU tools were released on October 12, 2005. -Original Message- From: DJ Delorie [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 07, 2005 10:32 AM To: Nitin Shah Cc: gcc@gcc.gnu.org Subject: Re: Building errors for sh, h8300 and m32c targets > I am able to build gcc-4.0.0 successfully without making any changes > in the source. Right, but you're comparing a release to a snapshot. Snapshots are cut straight from source control, releases are partially built so that generated files don't have to be generated.
