[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
[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 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 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 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] 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] 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 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=gcc&view=rev&rev=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 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 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__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
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
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.
[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
[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/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 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 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 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 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 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 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 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 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 #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 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;
D.995;
bit_size_type D.996;
D.997;
D.994 = (bit_size_type) () _a * 8;
D.995 = () _a;
D.996 = (bit_size_type) () _b * 8;
D.997 = () _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 #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 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 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
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 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
[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 âcp_parser_type_specifierâ: /export/gnu/src/gcc/gcc/gcc/cp/parser.c:13206: warning: âbasesâ may be used uninitialized in this function /export/gnu/src/gcc/gcc/gcc/cp/parser.c:13206: note: âbasesâ 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 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 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=gcc&view=rev&rev=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 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=gcc&view=rev&rev=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 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 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=12923&action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30509
[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 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 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 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
