--- 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 libg
--- 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
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.
S
--- 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
--- 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
--- 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/267
--- 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+
--- 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
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
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
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 PROTEC
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30497
--- 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, i
--- 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
--- 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
--- 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_n
--- 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
--- 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
--- 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]>
>
--- 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 shar
--- 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 {
--- 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
--- 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
--- 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 b
--- 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
--- 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.
--- 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_functio
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 16
> 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
0FF
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 sho
--- 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/
--- 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
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/
--- 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
--- 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)
+++ confi
--- 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
--- 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
Assigned
--- 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
-
--- 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
-
39 matches
Mail list logo
