I recently ran across an ICE building a target libiberty for one of
the multilibs of the mips64vrel-elf toolchain:
.../libiberty/regex.c: In function 'byte_re_match_2_internal':
.../libiberty/regex.c:7481: error: insn does not satisfy its constraints:
(insn 5211 1697 1699 173 .../lib
Hi Richard,
But I am pretty sure that this is the wrong solution. Since I am
not a MIPS expert however I am punting this problem to you guys. :-)
Yeah, I'm afraid it's the wrong solution. ;)
Thought so :-)
I gather from the insn above that a use of the GP pseudo
register has been int
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot
|dot org
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-03-29 11:02
---
Sigh. Wrong bug #, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
--- Comment #2 from rsandifo at gcc dot gnu dot org 2007-03-29 11:03
---
Sigh. Wrong bug #, sorry.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot
|dot org
--- Comment #4 from nickc at redhat dot com 2007-03-29 11:05 ---
Brooks' patch is better than mine, so I would recommend that it be adopted.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31353
--- Comment #4 from nickc at redhat dot com 2007-03-29 11:08 ---
Subject: Re: --help= option isn't documented.
Hi Brooks,
> The patch tracker missed the patch I'd already posted for this one as well:
> http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01655.html
>
> I think our fixes are
--- Comment #2 from nickc at redhat dot com 2007-03-29 11:11 ---
Hi Brooks,
> One difference that I see between our patches -- you have:
> + if (* descrip_extra == '\0')
> +descrip_extra = lang_names [i];
> whereas mine just unconditionally assigns descrip_extra to
> l
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-29 11:44 ---
Yes, indeed; a dummy argument of an elemental procedure cannot appear in a
specification expression.
12.7.1
Constraint: A dummy argument, or a subobject thereof, shall not appear in a
specification-expr except as the
Is the following buggy core or a bug in 4.3? I don't see why it should fail.
The problem is that when I compile an inline function with -std=gnu99, it will
not be found during linking.
Example:
gcc -c t.c
gcc -c -std=gnu99 timer.c
gcc -o t t.o timer.o
This results in:
t.c:(.text+0x1c): undefin
--- Comment #1 from tbm at cyrius dot com 2007-03-29 11:51 ---
I forgot to mention that it works fine with 4.1.
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #64 from marc dot glisse at normalesup dot org 2007-03-29
12:29 ---
(In reply to comment #63)
> However, I'm working on speculative fixes for newlib and linux, which are
> predicated on the correct __cplusplus values. I may get to solaris too, if my
> sanity stretches that f
--- Comment #4 from steven at gcc dot gnu dot org 2007-03-29 13:00 ---
No dependent bugs left.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
S
--- Comment #2 from steven at gcc dot gnu dot org 2007-03-29 13:01 ---
Lack of activity alone is reason enough to close this.
On top of that, this meta-bug has no dependent bugs left. In fact it appears
to never have had any.
--
steven at gcc dot gnu dot org changed:
Wh
--- Comment #26 from steven at gcc dot gnu dot org 2007-03-29 13:18 ---
I have looked at the various test cases in this PR, and all of them work for
me.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
I receive the following ICE:
transferbug.f90: In function bucketindexofkey:
transferbug.f90:14: internal compiler error: in gfc_get_element_type, at
fortran/trans-types.c:741
when compiling this test code:
module InternalCompilerError
type Byte
private
character(len=1)
--- Comment #8 from steven at gcc dot gnu dot org 2007-03-29 13:29 ---
For the original test case, our current output before expand (i.e. the
final_cleanup dump) on hosts where sizeof(long)==sizeof(int) is this:
;; Function convertToMinutes (convertToMinutes)
convertToMinutes (milliDif
I get the following link error with 4.3 and -O -g:
$ gcc -c -g -O test.c -o test.o
$ gcc -o m m.c test.o
test.o:(.debug_info+0x539): undefined reference to `.L4'
collect2: ld returned 1 exit status
test.c:
#include
#include
#include
typedef struct _hostEntry {
struct _hostEntry *next;
--- Comment #1 from tbm at cyrius dot com 2007-03-29 13:56 ---
This problem was introduced between 20070303 and 20070326.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31391
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-29 14:24 ---
Inline behavior is now C99 compatible by default, you need to use extern inline
in this case.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from patchapp at dberlin dot org 2007-03-29 14:25 ---
Subject: Bug number PR 30666
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01939.html
--
http://gcc.gnu.org/bugzilla/
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-03-29 14:29 ---
Mine.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
This bug is meant to collect issues related to initializations and type
declarations.
--
Summary: [meta-bug] gfortran problems with initialization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: meta-bug
Severity: normal
This bug is meant to collext bugs WRT intrinsics that happen at compile-time,
i.e. no implementation issues, but issues where an intrinsic can be called
where it shouldn't and the like.
--
Summary: [meta-bug] gfortran compile-time problems with
intrinsics
--- Comment #11 from dgregor at gcc dot gnu dot org 2007-03-29 15:11
---
Subject: Bug 30666
Author: dgregor
Date: Thu Mar 29 15:11:28 2007
New Revision: 123330
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123330
Log:
2007-03-29 Douglas Gregor <[EMAIL PROTECTED]>
PR
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #12 from dgregor at gcc dot gnu dot org 2007-03-29 15:14
---
Fix committed to mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-29 15:15 ---
Plain inline without any thing which says static or extern in C99 is the same
as what GNU-C90 considers as their "extern inline" and not what C99 considers
as "extern inline". If you add a prototype that says extern
--- Comment #11 from bangerth at dealii dot org 2007-03-29 16:13 ---
Still happens with 4.1.2
--
bangerth at dealii dot org changed:
What|Removed |Added
C
--- Comment #10 from bangerth at dealii dot org 2007-03-29 16:20 ---
This appears fixed with current mainline (at the very least, I don't know
how far back this reaches, but 3.3.5 is still broken).
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #11 from bangerth at dealii dot org 2007-03-29 16:25 ---
Still happens with a recent mainline snapshot.
--
bangerth at dealii dot org changed:
What|Removed |Added
-
--- Comment #11 from tromey at gcc dot gnu dot org 2007-03-29 16:27 ---
This still happens with -fmessage-length=80, per comment #9.
Perhaps we don't care, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=712
--- Comment #14 from bangerth at dealii dot org 2007-03-29 16:28 ---
Still happens with a recent mainline snapshot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
"bangerth at dealii dot org" <[EMAIL PROTECTED]> writes:
| Still happens with a recent mainline snapshot.
This one is tricky. I once had a patch for it, but then the patch
broke some other diagnostic. :-(
I'll try to revive it.
-- Gaby
--- Comment #15 from gdr at cs dot tamu dot edu 2007-03-29 16:43 ---
Subject: Re: Bug in template type in error message.
"bangerth at dealii dot org" <[EMAIL PROTECTED]> writes:
| Still happens with a recent mainline snapshot.
This one is tricky. I once had a patch for it, but then
--- Comment #12 from bangerth at dealii dot org 2007-03-29 17:05 ---
(In reply to comment #11)
> This still happens with -fmessage-length=80, per comment #9.
Uh, but that's exactly what I tried and it wrapped just fine, with
the tick on the second line...
W.
--
bangerth at dealii d
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-29 17:10
---
I'd say it's a duplicate of PR31193, which was fixed on 2007-03-22. At least,
your testcase doesn't trigger the bug on i386-linux nor on x86_64-linux.
Closing as duplicate: could you try it with an updated compile
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-03-29 17:10
---
*** Bug 31390 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #13 from tromey at gcc dot gnu dot org 2007-03-29 17:18 ---
Right you are. Sorry about that :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=712
--- Comment #33 from rth at gcc dot gnu dot org 2007-03-29 17:30 ---
I've been trying to track down this same failure on Alpha. I can reproduce
that
reverting the third hunk allows the bootstrap to complete. Finding what has
got
miscompiled has been very difficult. Only two files comp
--- Comment #4 from tromey at gcc dot gnu dot org 2007-03-29 17:48 ---
I suspect we're trying to initialize the logging manager too early.
In particular in libgcj we use 'null' as the loader parameter to
Class.forName during startup -- this will bypass the system class loader.
Second, J
I have some code that involves computing a cosine via cos(), specifically b =
cos(v). Depending on the context of the cos call, I get correct and incorrect
answers. In the example code's main program, I get a correct result regardless
of the compilation flags. In the MATHNEW_funceval routine, co
--- Comment #1 from sdirkse at gams dot com 2007-03-29 17:55 ---
Created an attachment (id=13297)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13297&action=view)
test case for the bug
Building with
gcc -m64 -O1 -o xxx cosbug.i -lm
shows the bug bug
gcc -m64 -o xxx cosbug.i -lm
is
--- Comment #5 from marcus at better dot se 2007-03-29 18:11 ---
(In reply to comment #4)
> Third, what's up with the class name "1catalina.org.apache.juli.FileHandler,"?
> Perhaps we are not parsing something correctly?
It comes from a configuration file for the logging mechanism,
/var
--- Comment #34 from rth at gcc dot gnu dot org 2007-03-29 18:13 ---
Actually, on second thought, I don't think the sign_bit_p change is legit:
Value ranges after VRP:
-mask_lo_1: [0, +INF] EQUIVALENCES: { } (0 elements)
+mask_lo_1: [0x0, +INF] EQUIVALENCES: { } (0 e
--- Comment #35 from rth at gcc dot gnu dot org 2007-03-29 18:21 ---
With some sed help, one can see that fold_binary is completely ruined:
- mhi = 0x0 >> 128 - width;
- if ((~(hi2 | hi1) & mhi) == 0) goto ; else goto ;
-
-:;
- mlo = 0x0;
+ mhi = 0;
--- Comment #6 from tromey at gcc dot gnu dot org 2007-03-29 18:43 ---
Thanks.
This is a little bit screwy since Java 5 claims that 'handlers' is
whitespace-separated -- but I see that in Java 6 they updated the
docs to reflect the actual implementation.
Also tomcat seems to rely on th
--- Comment #2 from dominiq at lps dot ens dot fr 2007-03-29 18:50 ---
This bug reminds me PR30980 and PR31161, though they were reported only for g++
and gfortran (they were fixed on 2007-03-16). Could you look at them to see if
the bug you have reported is not a duplicate? If yes, you
When run the following program:
PROGRAM test
INTEGER :: i = 1
WRITE(*, 10) i
10 FORMAT('i =',I2:,' this should not print')
END PROGRAM test
It prints:
i = 1 this should not print
If I insert a comma or a slash between "I2" and ":" it will work correctly.
--
Summary: Colon edit des
--- Comment #13 from dnovillo at gcc dot gnu dot org 2007-03-29 19:55
---
I can't reproduce this on mainline anymore. It does fail on the 4.2 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
A simple function that just sums over a vector is much slower if inlined than
out of line. The o-o-l version keeps the sum in a xmm register, the inline
version keeps reading and storing the stack variable on each iteration (guessed
looking at the assembler).
Timings on a 2.4 P4 Xeon:
out-of line:
--- Comment #1 from jamagallon at ono dot com 2007-03-29 23:17 ---
Created an attachment (id=13298)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13298&action=view)
testcase
Simple test case with a loop in main() and a call to a function.
Both just calculate the sum of all element
--- Comment #2 from jamagallon at ono dot com 2007-03-29 23:18 ---
Created an attachment (id=13299)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13299&action=view)
Makefile for testcase
Makefile to build tst.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31396
--- Comment #7 from law at redhat dot com 2007-03-29 23:18 ---
Subject: Re: Missed jump threading/bypassing
optimization with loop and % (or ands)
IMHO, this PR should simply be closed.
This is a case where aggressive threading is going to explode codesize
with marginal benef
--- Comment #3 from jamagallon at ono dot com 2007-03-29 23:22 ---
Sample assembler for the loops.
For the funcion, out of line:
#APP
#FBGN
#NO_APP
movldata, %edx
fldz
movl$1, %eax
.L2:
fadds -4(%edx,%eax,4)
addl$1, %eax
cmpl$268435457, %eax
--- Comment #4 from jamagallon at ono dot com 2007-03-29 23:47 ---
Assembler for the opteron.
out-of-line:
.L2:
cvtss2sd(%rdx,%rax,4), %xmm0
incq%rax
cmpq$268435456, %rax
addsd %xmm0, %xmm1
jne .L2
inline:
.L11:
cvtss2sd(%rdx,%rax,4), %xmm0
--- Comment #3 from danglin at gcc dot gnu dot org 2007-03-30 00:19 ---
I tried the modification suggested by Paolo but had similar to Steve.
There's still an issue with extending the buffer (i.e., I get more
output if I initially make the buffer bigger). However, there's still
junk at
--- Comment #4 from sje at cup dot hp dot com 2007-03-30 00:22 ---
This has been fixed for me with this patch:
2007-03-29 Zack Weinberg <[EMAIL PROTECTED]>
* gengtype.c (oprintf): Mostly revert changes from 2007-03-26;
add comment explaining why vsnprintf cannot be us
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-30
00:32 ---
Subject: Re: make[3]: *** [s-gtype] Segmentation fault (core dumped)
> This has been fixed for me with this patch:
>
> 2007-03-29 Zack Weinberg <[EMAIL PROTECTED]>
>
> * gengtype.c (oprintf): M
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-30 00:34 ---
This fixes it and regtests OK
Paul
Index: gcc/fortran/check.c
===
*** gcc/fortran/check.c (revision 123183)
--- gcc/fortran/check.c (working copy)
*
--- Comment #5 from dave dot korn at artimi dot com 2007-03-30 01:50
---
I have just checked in a fix for this in newlib. See the thread at:
http://sourceware.org/ml/newlib/2007/msg00292.html
and the references therein:
http://cygwin.com/ml/cygwin/2007-03/msg00705.html
http://gcc.gn
--- Comment #7 from tromey at gcc dot gnu dot org 2007-03-30 05:09 ---
Subject: Bug 29869
Author: tromey
Date: Fri Mar 30 05:09:35 2007
New Revision: 123356
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123356
Log:
libjava
PR libgcj/29869:
* java/util/logging/Lo
--- Comment #8 from tromey at gcc dot gnu dot org 2007-03-30 05:12 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
Status|AS
--- Comment #9 from cvs-commit at developer dot classpath dot org
2007-03-30 05:14 ---
Subject: Bug 29869
CVSROOT:/cvsroot/classpath
Module name:classpath
Changes by: Tom Tromey 07/03/30 04:13:43
Modified files:
. : ChangeLog
java/uti
--- Comment #10 from tromey at gcc dot gnu dot org 2007-03-30 05:35 ---
Subject: Bug 29869
Author: tromey
Date: Fri Mar 30 05:34:58 2007
New Revision: 123357
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123357
Log:
libjava
PR libgcj/29869:
* java/util/logging/L
--- Comment #3 from bonzini at gnu dot org 2007-03-30 08:23 ---
still occurs at -O2 (testing with checking disabled).
--
bonzini at gnu dot org changed:
What|Removed |Added
---
67 matches
Mail list logo
