Re: Miscompilation of remainder expressions
On 1/19/07, Joe Buck [EMAIL PROTECTED] wrote: On Thu, Jan 18, 2007 at 05:36:23PM -0500, Robert Dewar wrote: Morten Welinder wrote: For sure a/b is undefined In C, it is. In assembler it is perfectly well defined, i.e., it traps. But how is the trap handler supposed to know the source of a given instruction? M. Sure it traps, but what happens when that trap occurs is of course O/S dependent, there is no guarantee of the effect. We're going around in circles. Everything has been said. What if we put together a Wiki page with the problem and possible solutions, as in a) do nothing, no big deal. This is what happens if no one contributes code in any case. b) add a flag to generate code to compute something like divisor == -1 ? 0 : rem(dividend,divisor) or divisor == rem(dividend,abs(divisor)) in an efficient way (cmov to avoid busting the pipeline) Note that cmov is not the right thing to use here (at least on ia32 and x86_64) as it is more expensive than compare and jump if not the probability of taking either way are the same (which I would not expect here, as divisor == -1 should be nearly never the case). That said, a transformation on the tree level would make it possible for VRP to optimize away the special casing. Richard.
Controlling Register Allocation - GCC 4.1.1
Hi all,
I am having some problem while allocating floating point registers in GCC 4.1.1.
As of now my target does not have floating point registers. To support
floating point operations, i added 8 floating point registers that i
want the gcc to allocate only when the mode is MODE_FLOAT.
I have done the following:
1. Defined them in FIXED_REGISTERS, CALL_USED_REGISTERS.
2. Ordered them using REG_ALLOC_ORDER.
3. Created a separate class in enum reg_class (FLOAT).
4. Assigned a specific character to identify the particular class ('f').
5. Defined HARD_REGNO_MODE_OK such that if a float-register is used in
any other mode, it should return 0.
Still while emitting the insns, i get the floating point registers f0
(Reg No 16) in SI mode.
(insn/f 39 38 40 (set:SI (mem:SI (pre_dec:SI (reg/f:SI 15 a7)) [0 S4 A32])
(reg:SI 16 f0)) 0 {movsi_push} (nil)
(nil))
Have i missed out on anything?
Can anyone point out where i am going wrong!!
Thanking you in advance,
Regards,
Rohit
Re: Preventing warnings
No. This is an undocumented, unnamed, unconditional warning. We are working on fixing those for GCC 4.3 :-) Could you explain what that means? What exactly is the problem that you are talking about fixing? What change is planned?
Good book on C? http://publications.gbdirect.co.uk/c_book/
http://publications.gbdirect.co.uk/c_book/ is reportedly a free book on C -- but it is C89, more or less. If it is well written, we could look for people to update it to modern C. But if it isn't well written and clear, it probably isn't worth the trouble. If a few of you who are familiar with other good books on C would like to look through it enough to judge, and tell me your opinions, that would be useful.
Re: Getting a tree node for a field of a variable
Hi,
Look in tree.def.
Given the RECORD_TYPE node, walk down TYPE_FIELDS looking for the
FIELD_DECL that you want.
To assign to a field use a COMPONENT_REF.
Is it possible to write a short example how a it could be referred the
tree of variable field? Let's say that we have somewhere defined the
following source code:
--- code ---
typedef struct MyType
{
int field1;
int field2;
}
MyType *var;
--- code ---
What I want is to get the tree node of var-field1. For now I can
get the tree of the var declaration with the code bellow.
tree var_decl = lookup_name(get_identifier(var));
And I suppose that, having var_decl I can get a tree to the field1
field of var. Is there any function e.g. lookup_decl_field that does
it?
Ferad Zyulkyarov
Re: Preventing warnings
On 19/01/07, Richard Stallman [EMAIL PROTECTED] wrote: No. This is an undocumented, unnamed, unconditional warning. We are working on fixing those for GCC 4.3 :-) Could you explain what that means? What exactly is the problem that you are talking about fixing? What change is planned? Well, I don't want to create false expectations. I am doing this in my free time and I am new to GCC development. So I am in no way representing anyone else's views or intentions. Nevertheless, I (and others seem to agree) would like to name that particular warning, so it can be enabled/disabled. Also, there is a similar warning for unsigned = 0 and unsigned 0 in -Wextra. There are bug reports about the inconsistency (http://gcc.gnu.org/PR23587). So, it would be nice to unify them, give them a name and properly document the new option. That is just part of a proposal to update the documentation of Wextra, and name (or group under existing options) the few unnamed warnings enabled by Wextra. The idea is that Wextra would be a super-option, like Wall, that is, it just enables other warnings but it doesn't produce warning messages by itself. The discussion is still going on because we don't want to have many new options, we don't want to group under the same option unrelated warnings, we want sensible names, we want to keep current behaviour, etc. Gabriel Dos Reis in particular is investing a lot of time reviewing patches to achieve this. In addition, there have been already several bugs fixed about duplicated warning messages, missing overflow warnings for binary operators in C++, and a few more I don't remember right now. Also, Ian Lance Taylor has fixed some warning options to work in C++ as they do for C. Finally, there is a proposal by Chris Pickett to update the documentation about warning options to make easier to lookup a particular warning option, understand the relations between the different options and which options are enabled by default (and fix any documentation bugs that may be found while doing this). Cheers, Manuel.
Re: Controlling Register Allocation - GCC 4.1.1
Rohit Arul Raj [EMAIL PROTECTED] writes:
I am having some problem while allocating floating point registers in GCC
4.1.1.
As of now my target does not have floating point registers. To support
floating point operations, i added 8 floating point registers that i
want the gcc to allocate only when the mode is MODE_FLOAT.
I wish I could change my targets by simply changing the compiler.
I have done the following:
1. Defined them in FIXED_REGISTERS, CALL_USED_REGISTERS.
2. Ordered them using REG_ALLOC_ORDER.
3. Created a separate class in enum reg_class (FLOAT).
4. Assigned a specific character to identify the particular class ('f').
5. Defined HARD_REGNO_MODE_OK such that if a float-register is used in
any other mode, it should return 0.
Still while emitting the insns, i get the floating point registers f0
(Reg No 16) in SI mode.
(insn/f 39 38 40 (set:SI (mem:SI (pre_dec:SI (reg/f:SI 15 a7)) [0 S4 A32])
(reg:SI 16 f0)) 0 {movsi_push} (nil)
(nil))
Have i missed out on anything?
I think you want HARD_REGNO_MODE_OK.
Ian
Re: Controlling Register Allocation - GCC 4.1.1
Ian Lance Taylor [EMAIL PROTECTED] writes:
I have done the following:
1. Defined them in FIXED_REGISTERS, CALL_USED_REGISTERS.
2. Ordered them using REG_ALLOC_ORDER.
3. Created a separate class in enum reg_class (FLOAT).
4. Assigned a specific character to identify the particular class ('f').
5. Defined HARD_REGNO_MODE_OK such that if a float-register is used in
any other mode, it should return 0.
Still while emitting the insns, i get the floating point registers f0
(Reg No 16) in SI mode.
(insn/f 39 38 40 (set:SI (mem:SI (pre_dec:SI (reg/f:SI 15 a7)) [0 S4 A32])
(reg:SI 16 f0)) 0 {movsi_push} (nil)
(nil))
Have i missed out on anything?
I think you want HARD_REGNO_MODE_OK.
Whoops, sorry, I see that you did use HARD_REGNO_MODE_OK.
Do you have a movsf insn?
Ian
Re: Good book on C? http://publications.gbdirect.co.uk/c_book/
Richard Stallman wrote: http://publications.gbdirect.co.uk/c_book/ is reportedly a free book on C -- but it is C89, more or less. If it is well written, we could look for people to update it to modern C. But if it isn't well written and clear, it probably isn't worth the trouble. If a few of you who are familiar with other good books on C would like to look through it enough to judge, and tell me your opinions, that would be useful. 5 minutes of looking through it revealed no factual errors and a fairly readable style. In contrast, the vast majority of books on C (or C++) that I pick up in bookstores have technical errors on the first page I glance at, so I'd say the signs are hopeful that this book is a valuable starting point. -- James
Re: Getting a tree node for a field of a variable
On Jan 19, 2007, at 3:42 AM, Ferad Zyulkyarov wrote: Is it possible to write a short example how a it could be referred the tree of variable field? Sure, just compile up the C code for what you want to do, run the debugger, watch what it builds and how it builds it. If you want to know what it looks like in the end, just print the built tree. However, if you have a complex language like C++, accessing a field can be, well, kinda different. You cannot employ the same techniques that you learn from C to C++.
[wwwdocs] PATCH for Re: http://gcc.gnu.org/svnwrite.html points to non-existing source http://gcc.gnu.org/ml/gcc-SVN/
On Wed, 17 Jan 2007, Ben Elliston wrote: I found out that page http://gcc.gnu.org/svnwrite.html points to http://gcc.gnu.org/ml/gcc-SVN/ mailing list but it doesn't exist. It's in section Write access policies above Free for all subsection. It seems that correct list is http://gcc.gnu.org/ml/gcc-cvs/. Nicely spotted. I think someone got overzealous with search and replace. :-) Fixed thusly. Now I just wonder whether I did not see this with my semi-regular link check runs, but there were so many to fix that I might have missed this one... Gerald Index: svnwrite.html === RCS file: /cvs/gcc/wwwdocs/htdocs/svnwrite.html,v retrieving revision 1.14 diff -u -3 -p -r1.14 svnwrite.html --- svnwrite.html 7 Jan 2007 00:12:34 - 1.14 +++ svnwrite.html 19 Jan 2007 21:02:36 - @@ -134,7 +134,7 @@ in the MAINTAINERS file in the GCC distr pWhen you have checked in a patch exactly as it has been approved, you do not need to tell that to people -- including the approver. People interested in when a particular patch is committed can check -SVN or the a href=http://gcc.gnu.org/ml/gcc-SVN/;gcc-SVN/a +SVN or the a href=http://gcc.gnu.org/ml/gcc-cvs/;gcc-cvs/a list./p h3Free for all/h3
gcc-4.3-20070119 is now available
Snapshot gcc-4.3-20070119 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070119/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 120979 You'll find: gcc-4.3-20070119.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070119.tar.bz2 C front end and core compiler gcc-ada-4.3-20070119.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070119.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070119.tar.bz2 C++ front end and runtime gcc-java-4.3-20070119.tar.bz2 Java front end and runtime gcc-objc-4.3-20070119.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070119.tar.bz2The GCC testsuite Diffs from 4.3-20070112 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
trying to fix a bug in m6812 front-end
I am using gcc 3.3.5 with the latest m68hc1x patches to compile programs for a
9s12 processor, and cc1 calls abort when compiling the following code:
void func()
{
short a, *b;
a = *b;
}
The rtl for the instructions dump as follows:
- (insn 9 6 10 (nil) (set (reg:HI 53)
- (mem/f:HI (reg/f:HI 49 virtual-stack-vars) [0 a+0 S2 A16])) -1 (nil)
- (nil))
-
- (insn 10 9 11 (nil) (set (reg:HI 54)
- (and:HI (reg:HI 53)
- (mem:HI (mem/f:HI (plus:HI (reg/f:HI 49 virtual-stack-vars)
- (const_int 2 [0x2])) [0 b+0 S2 A16]) [0 S2 A8]))) -1
(nil)
- (nil))
-
- (insn 11 10 12 (nil) (set (mem/f:HI (reg/f:HI 49 virtual-stack-vars) [0 a+0
S2 A16])
- (reg:HI 54)) -1 (nil)
- (nil))
If I modify the '=' to '|=' instead, the code compiles fine with the following
rtl:
- (insn 9 6 10 (nil) (set (reg:HI 53)
- (mem/f:HI (reg/f:HI 49 virtual-stack-vars) [0 a+0 S2 A16])) -1 (nil)
- (nil))
-
- (insn 10 9 11 (nil) (set (reg:HI 54)
- (mem:HI (mem/f:HI (plus:HI (reg/f:HI 49 virtual-stack-vars)
- (const_int 2 [0x2])) [0 b+0 S2 A16]) [0 S2 A8])) -1 (nil)
- (nil))
-
- (insn 11 10 12 (nil) (set (reg:HI 55)
- (ior:HI (reg:HI 53)
- (reg:HI 54))) -1 (nil)
- (nil))
-
- (insn 12 11 13 (nil) (set (mem/f:HI (reg/f:HI 49 virtual-stack-vars) [0 a+0
S2 A16])
- (reg:HI 55)) -1 (nil)
- (nil))
It looks like somewhere before generating rtl in the second case, it split the
instruction
as this architecture cannot handle the second instruction in the first case.
xor behaves
similarly to or and works as well.
I am trying to find out what part of gcc to look in so I can make the change so
that the and
instruction is handled the same way.
Any hints are much appreciated.
--
Sean D'Epagnier
Re: Running GCC tests on installed compiler
On Sun, 14 Jan 2007, Dominique Dhumieres wrote: So please use contrib/test_installed This script seems quite outdated: it tests g77 and not gfortran, even with the latest 4.3.0 snapshot (20070112). As I was primarily interested in the gfortran tests, I replaced g77 by gfortran everywhere (keeping the different capitalizations) and it worked. The script also ignores java tests. Would you mind submitting this as a patch? I do not know whether you have a copyright assignment on file, but perhaps it is simply enough that we can take it even without one. I looked again to the manual (http://gcc.gnu.org/install/test.html) and did not find this script documented anywhere. Am I missing something or is this a place where the manual can be improved? The latter, I believe. Do you think you could provide a patch against gcc/doc/install.texi? ;-) I'll be happy to work with you on this if contributing to GCC is an option for you. Gerald
Re: trying to fix a bug in m6812 front-end
Sean D'Epagnier [EMAIL PROTECTED] writes: - (insn 10 9 11 (nil) (set (reg:HI 54) - (and:HI (reg:HI 53) - (mem:HI (mem/f:HI (plus:HI (reg/f:HI 49 virtual-stack-vars) - (const_int 2 [0x2])) [0 b+0 S2 A16]) [0 S2 A8]))) -1 (nil) - (nil)) I am trying to find out what part of gcc to look in so I can make the change so that the and instruction is handled the same way. Look at the andhi3 insns in the CPU.md file. You may need to change the constraints there, or rework the insn somehow. Ian
innovative new build failure
Here is an innovative new build failure, as seen on i686-apple-darwin9: ../../gcc/gcc/expmed.c:4179: warning: signed and unsigned type in conditional expression make[3]: *** [expmed.o] Error 1 make[2]: *** [all-stage2-gcc] Error 2
Re: innovative new build failure
Mike Stump [EMAIL PROTECTED] writes: Here is an innovative new build failure, as seen on i686-apple-darwin9: ../../gcc/gcc/expmed.c:4179: warning: signed and unsigned type in conditional expression make[3]: *** [expmed.o] Error 1 make[2]: *** [all-stage2-gcc] Error 2 Yikes, my fault. I wonder why it didn't fail for me? Ian
Re: innovative new build failure
On Jan 19, 2007, at 8:46 PM, Ian Lance Taylor wrote: Yikes, my fault. I wonder why it didn't fail for me? Trivially, you've not updated your tree... See, you did an rm -rf of the build tree after -Werrror was broken on Jan 4th and built, but you didn't update to pick up the fix for that breakage in r120947, and yet, you checked in r120995. r120947 r120995. :-) Top-level: 2007-01-18 Mike Stump [EMAIL PROTECTED] * configure.in: Re-enable -Werror for gcc builds. fixed it.
Re: innovative new build failure
Mike Stump [EMAIL PROTECTED] writes: Here is an innovative new build failure, as seen on i686-apple-darwin9: ../../gcc/gcc/expmed.c:4179: warning: signed and unsigned type in conditional expression make[3]: *** [expmed.o] Error 1 make[2]: *** [all-stage2-gcc] Error 2 Yikes, my fault. I wonder why it didn't fail for me? Because -Werror during bootstrap was just fixed, most likely right before you applied your patch. -- Pinski
[Bug gcov-profile/30258] [4.1.0] undefined reference to `__gcov_one_value_profiler'
--- Comment #2 from marion dot deveaud at siemens dot com 2007-01-19 10:38 --- I finally found out that the inhibit_libc flag was set during the gcc compilation because I'm building a cross-compiler without sysroot and headers. As a consequence _gcov_* functions aren't defined in libgcov. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30258
[Bug libobjc/30445] Fix for FIXME in gcc-4_2-branch/libobjc/Makefile.in
--- Comment #2 from rob1weld at aol dot com 2007-01-19 12:48 --- Thank you for your assistance. I've looked into this and found the new names. If someone wished to either fix or delete (hopefully not) the libobjc.dll support I'd consider this resolved (for me) and this complaint could be closed. This is the suggestion I came up with. Files gcc-4_2-branch/libobjc/hash.c and gcc-4_2-branch/libobjc/objc/hash.h define: objc_hash_new(), objc_hash_delete(), objc_hash_add(), objc_hash_remove(), objc_hash_next(), objc_hash_value_for_key(), and objc_hash_is_key_in_hash() . The file gcc-4_2-branch/libobjc/libobjc.def defines both the 4.1.1 versions (which do not exist) and the 4.2.0 versions (same name as 4.1.1 version with objc_ prepended) of these functions. Running the make as described above creates the file (depending on your build directory and target name) /gcc-4_2-branch-build/i686-pc-cygwin/libobjc/libobjc.exp which contains the 4.1.1 and 4.2.0. named functions. One of the authors mentions not having a Windows system to test the above on - I hope I have helped. Based on the above it is my suggestion to fix this bug by doing the following: 1) delete all 4.1.1 references of the function names from gcc-4_2-branch/libobjc/libobjc.def . 2) Make the above changes to the makefile AND, in addition, delete or rename the file /gcc-4_2-branch-build/i686-pc-cygwin/libobjc/libobjc.a (Please Note: I do NOT say to delete or rename /gcc-4_2-branch-build/i686-pc-cygwin/libobjc/.libs/libobjc.a , only the copy). It is neccesary to copy (and not move) libobjc.a from the .libs directory because the makefile (as it was written) uses the file for input and eventually overwrites it as the output - but the file size is different from the input. For the rest of gcc's makefiles and tests to operate the .a file should be in the .libs directory. 3) Consider creating .dll (and .dll.a) files in addition to the .a file for _every_ library. I am using --enable-shared --enable-static when running configure but I don't get any .so or .dll files. The configure script rejects --enable-shared for Cygwin. I need to look into that more before filing a report on that. Both the sources for Mplayer-1.0rc1 and ffmpeg are GPL and show great examples of using .dll files under Cygwin - in the event someone needs somes code to refer to. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30445
[Bug c++/30509] New: ice for legal code with -O3
I just tried to compile Suse Linux package hydrogen-0.9.3-41 with the GNU C++ compiler version 4.3 snapshot 20070112. The compiler said src/lib/Object.cpp:306: internal compiler error: in calc_dfs_tree, at dominance.c:374 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O3 required. -- Summary: ice for legal code with -O3 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30509
[Bug c++/30509] ice for legal code with -O3
--- Comment #1 from dcb314 at hotmail dot com 2007-01-19 13:54 --- Created an attachment (id=12923) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12923action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30509
[Bug middle-end/30447] Evaluate complex math functions at compile-time
--- Comment #5 from ghazi at gcc dot gnu dot org 2007-01-19 14:45 --- Patch for __complex__ builtins infrastructure and csin posted here: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01610.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30447
[Bug target/26792] [4.2 Regression] need to use autoconf when using newly-added libgcc functions
--- Comment #29 from aph at gcc dot gnu dot org 2007-01-19 15:25 --- Subject: Bug 26792 Author: aph Date: Fri Jan 19 15:25:34 2007 New Revision: 120968 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120968 Log: 2006-07-21 Steve Ellcey [EMAIL PROTECTED] PR target/26792 * unwind_ipinfo.m4: New. Added: branches/redhat/gcc-4_1-branch-java-merge-20070117/config/unwind_ipinfo.m4 - copied unchanged from r115653, trunk/config/unwind_ipinfo.m4 Modified: branches/redhat/gcc-4_1-branch-java-merge-20070117/config/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26792
[Bug c++/17947] bad warning with implicit conversion and __attribute__((deprecated))
--- Comment #4 from manu at gcc dot gnu dot org 2007-01-19 16:05 --- Subject: Bug 17947 Author: manu Date: Fri Jan 19 16:04:57 2007 New Revision: 120969 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120969 Log: 2007-01-19 Manuel Lopez-Ibanez [EMAIL PROTECTED] PR c++/17947 * toplev.c (warn_deprecated_use): Use %qD instead of %qs to print the name of the declared identifier. testsuite/ * g++.dg/warn/deprecated.C: Update warning output. * g++.dg/warn/deprecated-2.C: Likewise. * g++.dg/warn/deprecated-3.C: New. Added: trunk/gcc/testsuite/g++.dg/warn/deprecated-3.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/deprecated-2.C trunk/gcc/testsuite/g++.dg/warn/deprecated.C trunk/gcc/toplev.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17947
[Bug c++/17947] bad warning with implicit conversion and __attribute__((deprecated))
--- Comment #5 from manu at gcc dot gnu dot org 2007-01-19 16:10 --- Fixed for GCC 4.3. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17947
[Bug bootstrap/30510] New: Gcc failed to bootstrap
cc1: warnings being treated as errors /export/gnu/src/gcc/gcc/gcc/cp/parser.c: In function #226;cp_parser_type_specifier#226;: /export/gnu/src/gcc/gcc/gcc/cp/parser.c:13206: warning: #226;bases#226; may be used uninitialized in this function /export/gnu/src/gcc/gcc/gcc/cp/parser.c:13206: note: #226;bases#226; was declared here -- Summary: Gcc failed to bootstrap Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl at lucon dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug bootstrap/30511] New: False array bound check causes gcc failed to boostrap
With revision 120976, I got
cc1: warnings being treated as errors
/export/gnu/src/gcc/gcc/gcc/fortran/symbol.c: In function gfc_get_namespace:
/export/gnu/src/gcc/gcc/gcc/fortran/symbol.c:1842: warning: array subscript is
above array bounds
There are
1838 /* Initialize default implicit types. */
1839 for (i = 'a'; i = 'z'; i++)
1840 {
1841 ns-set_flag[i - 'a'] = 0;
1842 ts = ns-default_type[i - 'a'];
bash-3.1$ grep default_type *.h
gfortran.h: gfc_typespec default_type[GFC_LETTERS];
...
bash-3.1$ grep GFC_LETTERS *.h
gfortran.h:#define GFC_LETTERS 26 /* Number of letters in the
alphabet. */
I don't how array subscript can be above array bounds.
--
Summary: False array bound check causes gcc failed to boostrap
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hjl at lucon dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30511
addresses for 3 Objective-C maintainers no longer work
I received errors when trying to send mail to [EMAIL PROTECTED], [EMAIL PROTECTED], and [EMAIL PROTECTED], all of whom are listed in MAINTAINERS for the Objective-C frontend as of r120973. This is the Postfix program at host smtp1.cup.hp.com. ... [EMAIL PROTECTED] (expanded from [EMAIL PROTECTED]): [rgv01.rgv.hp.com]: Name or service not known As well as the following from apple's mailserver: The original message was received at Fri, 19 Jan 2007 10:44:46 -0800 (PST) from mail-in6.apple.com [17.254.13.9] - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 550 5.1.1 unknown or illegal alias: [EMAIL PROTECTED]) [EMAIL PROTECTED] (reason: 550 5.1.1 unknown or illegal alias: [EMAIL PROTECTED]) - Transcript of session follows - ... while talking to hemlock.apple.com.: DATA 550 5.1.1 unknown or illegal alias: [EMAIL PROTECTED] 550 5.1.1 [EMAIL PROTECTED]... User unknown 550 5.1.1 unknown or illegal alias: [EMAIL PROTECTED] 550 5.1.1 [EMAIL PROTECTED]... User unknown --xsdg signature.asc Description: OpenPGP digital signature
[Bug target/30497] compiling binutils 2.17 on aix fails with gcc 4.1.1
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30497
[Bug bootstrap/30511] False array bound check causes gcc failed to boostrap
--- Comment #1 from mueller at gcc dot gnu dot org 2007-01-19 20:04 ---
this patch fixes / works around it. I don't like it yet, I'm trying to find a
better solution.
--- tree-vrp.c (revision 120953)
+++ tree-vrp.c (working copy)
@@ -3583,6 +3583,25 @@ check_array_bounds (tree *tp, int *walk_
*walk_subtree = FALSE;
return NULL_TREE;
}
+
+ /* Don't warn if the result ssa_name is used in another
+ binary expr. */
+ if (TREE_CODE ((tree)data) == GIMPLE_MODIFY_STMT
+GIMPLE_STMT_OPERAND ((tree)data, 0)
+TREE_CODE (GIMPLE_STMT_OPERAND ((tree)data, 0)) == SSA_NAME)
+ {
+ imm_use_iterator iter;
+ tree lhs = GIMPLE_STMT_OPERAND ((tree)data, 0);
+ tree use;
+
+ FOR_EACH_IMM_USE_STMT (use, iter, lhs)
+if (TREE_CODE (use) == GIMPLE_MODIFY_STMT
+ BINARY_CLASS_P (GIMPLE_STMT_OPERAND (use, 1)))
+ *walk_subtree = FALSE;
+
+ if (*walk_subtree == FALSE)
+return NULL_TREE;
+ }
while (handled_component_p (t))
{
if (TREE_CODE (t) == ARRAY_REF)
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-01-19 20:04:36
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30511
[Bug bootstrap/30511] False array bound check causes gcc failed to boostrap
--- Comment #2 from roger at eyesopen dot com 2007-01-19 20:55 --- It looks like the ivopts pass is creating dubious? array references. The symbol.c.053t.vrp1 D.12252_12 = (long unsigned int) i_2; D.12255_15 = ns_4-default_type[D.12252_12]; ts_16 = D.12255_15 + -2328B; i.e. we now have ns-default_type[i] - ns-default_type['a']. I wouldn't like to offer an opinion on whether this IV is valid in the middle-end. The transformation is certainly unsafe in C, where a pointer arithmetic is not guaranteed to be valid outside of the declared object. I think the appropriate fix is that if ivopts is going to create these suspicious array refs, it should appropriately set TREE_NO_WARNING, which will then cause the reference to be ignored by the bounds checking in VRP. Alternatively, we need more context in array bounds checking such that x['a'] is not a problem, but x['a'] on it's own is diagnosed. i.e. we could perhaps keep an in_indirect_ref_p flag during the tree walking. I hope this helps. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30511
[Bug fortran/30389] ACHAR() intrinsic gives erroneous errors in constant-folding.
--- Comment #3 from tkoenig at gcc dot gnu dot org 2007-01-19 21:35 ---
In order to fix this, we should know what we would prefer :-)
Constant folding maps a lot of characters (all ASCII
characters 127, and a lot of control characters) to zero.
In the rest of the library, we treat the A* functions identically
to the non-ASCII versions. For example, we encode
subroutine comp(a, b, t)
implicit none
logical t
character(*) a, b
t = lle(a,b)
end
as
comp (a, b, t, _a, _b)
{
bit_size_type D.994;
unnamed type D.995;
bit_size_type D.996;
unnamed type D.997;
D.994 = (bit_size_type) (unnamed type) _a * 8;
D.995 = (unnamed type) _a;
D.996 = (bit_size_type) (unnamed type) _b * 8;
D.997 = (unnamed type) _b;
*t = _gfortran_compare_string (_a, a, _b, b) = 0;
}
We also encode
program main
integer i
character(1) c
i = 154
c = achar(i)
end
as
i = 154;
{
char char.0;
char.0 = (char) i;
c[1]{lb: 1 sz: 1} = char.0;
}
So, we could either
a) fix constant folding to ignore the ascii_table and xascii_table
b) fix the library and runtime conversion to honor the ascii_table.
a) is perfectly fine, as long as we document it. I'd vote for it.
Comments?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30389
[Bug bootstrap/30511] False array bound check causes gcc failed to boostrap
--- Comment #3 from mrs at apple dot com 2007-01-19 22:02 ---
Testcase from delta, compile with:
$ ./xgcc -B./ t.c -O2 -S -Wall
t.c: In function 'gfc_get_namespace':
t.c:10: warning: array subscript is above array bounds
typedef struct { int kind; } gfc_typespec;
typedef struct gfc_namespace { gfc_typespec default_type[26]; } gfc_namespace;
void gfc_get_namespace ()
{
gfc_namespace *ns=0;
gfc_typespec *ts =0;
int i;
for (i = 'a'; i = 'z'; i++)
{
ts = ns-default_type[i - 'a'];
ts-kind = 0;
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30511
[Bug bootstrap/30511] False array bound check causes gcc failed to boostrap
--- Comment #4 from pinskia at gcc dot gnu dot org 2007-01-19 22:05 --- (In reply to comment #3) Testcase from delta, compile with: Hmm, in the non reduced testcase, is default_type last? Since in the reduced testcase, default_type is last, it seems like we should not warn about that case even if the bounds does go over anyways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30511
[Bug bootstrap/30511] False array bound check causes gcc failed to boostrap
--- Comment #5 from mueller at gcc dot gnu dot org 2007-01-19 22:15 --- the ivopts problem is a duplicate of bug 26726. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30511
[Bug c++/30504] Error when linking. Trying to create a library
--- Comment #2 from dams_napp at hotmail dot com 2007-01-19 22:16 --- Subject: RE: Error when linking. Trying to create a library Is there a better way to do that then, I do want to create a static library. Take Care, Dams From: pinskia at gcc dot gnu dot org [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug c++/30504] Error when linking. Trying to create a library Date: 18 Jan 2007 22:12:38 - --- Comment #1 from pinskia at gcc dot gnu dot org 2007-01-18 22:12 --- How are you creating a library with -static? The command line you posted looks more like you are linking in all of libc, libgcc, libstdc++ which all seems wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30504 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. _ Do women make better employees? Join the debate http://msnspecials.in/debate/topicdetails.aspx?TID=64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30504
[Bug c++/30504] Error when linking. Trying to create a library
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-19 22:18 --- Is there a better way to do that then, I do want to create a static library. You should use ar to create a static library. I think we can declare this issue as invalid as you are using the wrong options for a shared library and ar is for creating a static library. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30504
[Bug debug/29558] [4.2/4.3 Regression] ICE in set_variable_part, at var-tracking.c:2140
--- Comment #5 from bergner at gcc dot gnu dot org 2007-01-19 22:30 ---
The src we seem to be having problems with is:
temp[0] |= bit;
After local-alloc, we have the following RTL:
(insn 143 28 29 6 pr29558.c:7 (set (reg:QI 142)
(const_int -128 [0xff80])) 327 {*movqi_internal} (nil)
(expr_list:REG_EQUIV (const_int -128 [0xff80])
(nil)))
(insn 29 143 30 6 pr29558.c:7 (set (reg:SI 144)
(ior:SI (subreg:SI (reg:QI 143 [ temp ]) 0)
(subreg:SI (reg:QI 142) 0))) 137 {*boolsi3_internal1}
(insn_list:REG_DEP_TRUE 27 (insn_list:REG_DEP_TRUE 28 (nil)))
(expr_list:REG_DEAD (reg:QI 143 [ temp ])
(expr_list:REG_DEAD (reg:QI 142)
(nil
(insn 30 29 138 6 pr29558.c:7 (set (mem/s/j:QI (plus:DI (reg/f:DI 113 sfp)
(const_int 48 [0x30])) [0 temp+0 S1 A128])
(subreg:QI (reg:SI 144) 3)) 327 {*movqi_internal}
(insn_list:REG_DEP_TRUE 29 (nil))
(expr_list:REG_DEAD (reg:SI 144)
(nil)))
Which looks ok, but then after global-alloc/reload, we end up with:
(insn 143 28 29 6 pr29558.c:7 (set (reg:QI 9 9 [142])
(const_int -128 [0xff80])) 327 {*movqi_internal} (nil)
(expr_list:REG_EQUIV (const_int -128 [0xff80])
(nil)))
(insn 29 143 30 6 pr29558.c:7 (set (reg:SI 0 0 [144])
(ior:SI (reg:SI 0 0 [orig:143 temp+-3 ] [143])
(reg:SI 9 9 [orig:142+-3 ] [142]))) 137 {*boolsi3_internal1}
(insn_list:REG_DEP_TRUE 27 (insn_list:REG_DEP_TRUE 28
(nil)))
(nil))
(insn 30 29 138 6 pr29558.c:7 (set (mem/s/j:QI (plus:DI (reg/f:DI 1 1)
(const_int -16 [0xfff0])) [0 temp+0 S1 A128])
(reg:QI 0 0 [orig:144+3 ] [144])) 327 {*movqi_internal}
(insn_list:REG_DEP_TRUE 29 (nil))
(nil))
I'm not sure why yet, but it seems the -3 offset in reg:SI 0 0 [orig:143
temp+-3 ] [143]) is causing problems in the var tracking code, such that
find_variable_location_part() always returns -1 (ie, failure) which puts us
into the code we ICE in.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29558
[Bug debug/29558] [4.2/4.3 Regression] ICE in set_variable_part, at var-tracking.c:2140
--- Comment #6 from bergner at gcc dot gnu dot org 2007-01-19 22:32 --- I should mention, I'm using current mainline on powerpc64-linux using -g -O -m64. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29558
[Bug fortran/30321] program crash for SUM applied to zero-size array
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-01-19 22:38 --- Fixed on trunk and 4.2. Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30321
[Bug bootstrap/29889] jc1 segfaults while bootstrap
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-19 22:51 --- This is an odd stack trace... it is hard to see how that code could fail this way. Perhaps building gcj without -O would help; I notice some other oddities in the stack trace. Also the date here is from before the big gcj-eclipse merge. So, maybe things are different now. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29889
[Bug bootstrap/29482] libcpp/configure - no usable dependency style found
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-19 22:57 --- checking dependency style of gcc... none This is a weird message (from comment #2 and comment #3). It suggests to me that something else is going on -- something unrelated to the original bug filed in this PR. For this perhaps you could look in config.log to see what has gone wrong. As to the original PR -- I think fixes to depcomp should be handled upstream, in Automake. Also, libcpp should be changed to accept --disable-dependency-tracking, so that odd cases like this can be more easily worked around. Some users just want to do a single build and do not really need dependencies. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29482
[Bug java/30035] libjava cannot be built when objdir != srcdir
--- Comment #3 from tromey at gcc dot gnu dot org 2007-01-19 22:59 ---
Is this still a bug?
I always build GCC with a separate objdir, and I don't see this problem.
Furthermore my 4.1 tree has a copy of config.{guess,sub} in libjava/libltdl.
I believe these are used by the libltdl build.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
CC||tromey at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30035
[Bug bootstrap/30510] Gcc failed to bootstrap
--- Comment #1 from andreast at gcc dot gnu dot org 2007-01-19 23:07 --- This works here: Index: parser.c === --- parser.c(revision 120949) +++ parser.c(working copy) @@ -13203,7 +13203,7 @@ bool saved_in_function_body; tree old_scope = NULL_TREE; tree scope = NULL_TREE; - tree bases; + tree bases = NULL_TREE; push_deferring_access_checks (dk_no_deferred); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
Found Error in link-script for R8C
Hello to everyone, I found an Error with gcc-4.1.1 and binutils-2.17 when using it for crosscompiling source for Renesas R8C Microcontroller. (m32c-elf) In the file r8c.ld you can find this line: RESETVEC (r) : ORIGIN = 0xfffc, LENGTH = 4 But this is wrong. The Resetvektor for R8C is only 16Bit and not 32bit. When you write 32Bit value to 0xfffc it writes a 0x00 in Adress 0x, but this is the Register OFS. After this the watchdog is switched on and the controller is only working for short time. If you try this, please understand that it is not enought to reset the controller by the reset button on your testboard. Only after power-off-power-on the controller use the new OFS byte. Olaf p.s: I am not subscribed to this list. For question please email me.
Re: Found Error in link-script for R8C
Hello to everyone, Wrong list. The R8C link scripts are part of newlib (libgloss), not gcc. RESETVEC (r) : ORIGIN = 0xfffc, LENGTH = 4 But this is wrong. The Resetvektor for R8C is only 16Bit and not 32bit. The REJ09B0169-0100 page 61 shows the reset vector as being 0FFFCh to 0h. Addresses in R8C are 20 bits, not 16, and are normally stored in a 3 or 4 byte location. The R8C/2D, for example, is available with 96K of flash. When you write 32Bit value to 0xfffc it writes a 0x00 in Adress 0x, but this is the Register OFS. After this the watchdog is switched on and the controller is only working for short time. My flash utility has a command line option for whether the watchdog should be set or disabled. It overrides this byte before programming. Note that all the vectors in the interrupt and reset vector tables are essentially three byte values, with the top byte used for other purposes. Hmmm... I thought there was a .3byte pseudo-op just for this case, but I see now that there isn't. With it, you could do this: .section .resetvec .3byte _start .byte 0xff If you know your start address is in the first 64k, you can do this: .section .resetvec .short _start .byte 0 .byte 0xff
[Bug fortran/30512] New: MAXVAL() incorrect for zero-size int arrays, and for -HUGE-1 maximum values.
Consider the following program: debian-gfortran:~/test cat maxval.f90 integer(1) :: i(3) logical :: msk(3) i = -huge(i) i = i - 1 write(*,*) i write(*,*) maxval(i) msk = .false. i = 1 write(*,*) i write(*,*) -huge(i), maxval(i, msk) end In both of these cases, the result of the MAXVAL call should be -huge(i)-1. (For the latter case, see the standard on the definition of the intrinsic, which says that the result is the negative number with the largest magnitude possible within the representation). However, the actual result is this: debian-gfortran:~/test ../bin-trunk/bin/gfortran maxval.f90 -o maxval debian-gfortran:~/test ./maxval -128 -128 -128 -127 111 -127 -127 This error holds for larger integer kinds, as well. The error seems to stem from the libgfortran implementation, in which the initial search value is initialized as -GFC_INTEGER_n_HUGE, where it should be one less than that. -- Summary: MAXVAL() incorrect for zero-size int arrays, and for - HUGE-1 maximum values. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30512
[Bug bootstrap/30510] Gcc failed to bootstrap
--- Comment #2 from hjl at lucon dot org 2007-01-20 00:24 --- I also got /export/gnu/src/gcc/gcc/gcc/fortran/resolve.c: In function gfc_resolve_expr: /export/gnu/src/gcc/gcc/gcc/fortran/resolve.c:1541: warning: name may be used uninitialized in this function /export/gnu/src/gcc/gcc/gcc/fortran/resolve.c:1541: note: name was declared here -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30510
[Bug middle-end/29335] transcendental functions with constant arguments should be resolved at compile-time
--- Comment #38 from ghazi at gcc dot gnu dot org 2007-01-20 00:33 --- Subject: Bug 29335 Author: ghazi Date: Sat Jan 20 00:33:00 2007 New Revision: 120993 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=120993 Log: PR middle-end/29335 * builtins.c (fold_builtin_1): Handle builtin fdim. testsuite: * gcc.dg/torture/builtin-math-3.c: Test fdim. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/builtin-math-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29335
[Bug libgcj/30513] New: Bootstrap failure with libgcj on sparc-sun-solaris2.10
Current mainline bootstrap fails with the following error when building libjava. I haven't built mainline for about two weeks so I don't know when it started failing exactly. /caip/u12/kishgcc/tmpdisk/gcc-testing/43/build/./gcc/xgcc -shared-libgcc -B/caip/u12/kishgcc/tmpdisk/gcc-testing/43/build/./gcc -nostdinc++ -L/caip/u12/kishgcc/tmpdisk/gcc-testing/43/build/sparc-sun-solaris2.10/sparcv9/libstdc++-v3/src -L/caip/u12/kishgcc/tmpdisk/gcc-testing/43/build/sparc-sun-solaris2.10/sparcv9/libstdc++-v3/src/.libs -B/usr/local/sparc-sun-solaris2.10/bin/ -B/usr/local/sparc-sun-solaris2.10/lib/ -isystem /usr/local/sparc-sun-solaris2.10/include -isystem /usr/local/sparc-sun-solaris2.10/sys-include -m64 -DHAVE_CONFIG_H -I. -I../../../../egcc-SVN20070118/libjava -I./include -I./gcj -I../../../../egcc-SVN20070118/libjava -Iinclude -I../../../../egcc-SVN20070118/libjava/include -I../../../../egcc-SVN20070118/libjava/classpath/include -Iclasspath/include -I../../../../egcc-SVN20070118/libjava/classpath/native/fdlibm -I../../../../egcc-SVN20070118/libjava/../boehm-gc/include -I../boehm-gc/include -I../../../../egcc-SVN20070118/libjava/libltdl -I../../../../egcc-SVN20070118/libjava/libltdl -I../../../../egcc-SVN20070118/libjava/.././libjava/../gcc -I../../../../egcc-SVN20070118/libjava/../zlib -I../../../../egcc-SVN20070118/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/usr/local\ -DTOOLEXECLIBDIR=\/usr/local/lib/sparcv9\ -DJAVA_HOME=\/usr/local\ -DBOOT_CLASS_PATH=\/usr/local/share/java/libgcj-4.3.0.jar\ -DJAVA_EXT_DIRS=\/usr/local/share/java/ext\ -DGCJ_ENDORSED_DIRS=\/usr/local/share/java/gcj-endorsed\ -DGCJ_VERSIONED_LIBDIR=\/usr/local/lib/sparcv9/gcj-4.3.0\ -DPATH_SEPARATOR=\:\ -DLIBGCJ_DEFAULT_DATABASE=\/usr/local/lib/sparcv9/gcj-4.3.0/classmap.db\ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.3.0/classmap.db\ -g -O2 -m64 -MT jni-libjvm.lo -MD -MP -MF .deps/jni-libjvm.Tpo -c ../../../../egcc-SVN20070118/libjava/jni-libjvm.cc -fPIC -DPIC -o .libs/jni-libjvm.o In file included from ./include/java-threads.h:22, from ../../../../egcc-SVN20070118/libjava/include/jvm.h:23, from ../../../../egcc-SVN20070118/libjava/jni-libjvm.cc:14: ./sysdep/locks.h:11:2: error: #error Thread synchronization primitives not implemented for this platform. In file included from ../../../../egcc-SVN20070118/libjava/include/jvm.h:35, from ../../../../egcc-SVN20070118/libjava/jni-libjvm.cc:14: ./sysdep/locks.h:11:2: error: #error Thread synchronization primitives not implemented for this platform. In file included from ../../../../egcc-SVN20070118/libjava/include/jvm.h:23, from ../../../../egcc-SVN20070118/libjava/jni-libjvm.cc:14: ./include/java-threads.h:358: error: 'obj_addr_t' does not name a type In file included from ../../../../egcc-SVN20070118/libjava/jni-libjvm.cc:14: ../../../../egcc-SVN20070118/libjava/include/jvm.h:750: error: 'obj_addr_t' does not name a type make[5]: *** [jni-libjvm.lo] Error 1 make[5]: Leaving directory `/caip/u12/kishgcc/gcc-testing/gcc-testing/43/build/sparc-sun-solaris2.10/sparcv9/libjava' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/caip/u12/kishgcc/gcc-testing/gcc-testing/43/build/sparc-sun-solaris2.10/sparcv9/libjava' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/caip/u12/kishgcc/gcc-testing/gcc-testing/43/build/sparc-sun-solaris2.10/libjava' make[2]: *** [all-multi] Error 2 make[2]: Leaving directory `/caip/u12/kishgcc/gcc-testing/gcc-testing/43/build/sparc-sun-solaris2.10/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/caip/u12/kishgcc/gcc-testing/gcc-testing/43/build' make: *** [bootstrap] Error 2 -- Summary: Bootstrap failure with libgcj on sparc-sun-solaris2.10 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: build Severity: critical Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ghazi at gcc dot gnu dot org GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30513
[Bug libgcj/30513] Bootstrap failure with libgcj on sparc-sun-solaris2.10
--- Comment #1 from tromey at gcc dot gnu dot org 2007-01-20 01:22 --- It looks as though your build is choosing sysdep/generic as the sysdep dir. But, that is wrong, it should be choosing sparc. I'll attach a patch; if you could try it that would be great. Most likely, this patch will just help the build fail later; I think you may need read_barrier and write_barrier implementations as well. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-01-20 01:22:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30513
[Bug libgcj/30513] Bootstrap failure with libgcj on sparc-sun-solaris2.10
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-20 01:24 --- Well, bugzilla would not let me make an attachment. So, here it is inline. Index: configure.host === --- configure.host (revision 120900) +++ configure.host (working copy) @@ -159,6 +159,7 @@ enable_hash_synchronization_default=yes ;; sparc*-*) + sysdeps_dir=sparc libgcj_interpreter=yes ;; ia64-*) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30513
[Bug libgcj/30513] [4.3 Regression] Bootstrap failure with libgcj on sparc-sun-solaris2.10
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-01-20 01:30 --- I remember Andreas T. mentioned this before. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|Bootstrap failure with |[4.3 Regression] Bootstrap |libgcj on sparc-sun-|failure with libgcj on |solaris2.10 |sparc-sun-solaris2.10 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30513
[Bug preprocessor/30468] [4.0/4.1/4.2/4.3 Regression] -M not fully chops dirname
--- Comment #2 from tromey at gcc dot gnu dot org 2007-01-20 04:23 --- I'm testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-01-15 02:34:25 |2007-01-20 04:23:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30468
[Bug driver/12448] -MT / -MQ don't behave as documented.
--- Comment #8 from tromey at gcc dot gnu dot org 2007-01-20 06:19 --- The patch in this PR looks correct to me. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12448
[Bug driver/30246] -ggdb3 does not cause -dD to be passed to cc1 for preprocessing
--- Comment #4 from tromey at gcc dot gnu dot org 2007-01-20 06:23 --- I'm testing a patch to add -dD when -ggdb3 is passed. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-01-07 00:49:47 |2007-01-20 06:23:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30246
