[Bug target/31388] New: ICE building libiberty multilib for mips16 multilibs
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 .../libiberty/regex.c:6589
(set (reg:SI 5 $5)
(lo_sum:SI (reg/f:SI 1104)
(symbol_ref:SI ("byte_reg_unset_dummy") [flags 0x6]
))) 204 {*lowsi_mips16} (nil)
(expr_list:REG_EQUAL (symbol_ref:SI ("byte_reg_unset_dummy") [flags
0x6] )
(nil)))
.../libiberty/regex.c:7481: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:393
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [regex.o] Error 1
make[3]: Leaving directory
.../mips64vrel-elf/mips64vrel-elf/mips16/libiberty'
--
Summary: ICE building libiberty multilib for mips16 multilibs
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nickc at redhat dot com
GCC host triplet: x86_64-pc-linux-gnulibc2.3
GCC target triplet: mips64vrel-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31388
Re: Bug building target libiberty for mips64vrel-elf toolchain
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 introduced during reload. At first blush, I think the fix is to make mips_split_symbol move (const (unspec [(const_int 0)] UNSPEC_GP)) into "temp" when no_new_pseudos. I tried doing this but I could not find a way to make it work. :-( But then I am not as clued up on this stuff as you guys. I might have time to try a fix this weekend. Please feel free to file a bug report and assign it to [EMAIL PROTECTED] I have created a PR (31388) but I do not have the authority to assign it you. Cheers Nick
[Bug c++/31338] [4.1/4.2/4.3 regression] Cannot apply "!" to complex constants
-- 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 |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-29 11:01:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
[Bug c++/31338] [4.1/4.2/4.3 regression] Cannot apply "!" to complex constants
--- 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
[Bug c++/31338] [4.1/4.2/4.3 regression] Cannot apply "!" to complex constants
--- 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 AssignedTo|rsandifo at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
[Bug target/31388] ICE building libiberty multilib for mips16 multilibs
-- 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 |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-29 11:04:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31388
[Bug driver/31353] gcc --help=target gives a linker error.
--- 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
[Bug driver/31355] --help= option isn't documented.
--- 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 fairly equivalent here; yours specifies the list of
> language, whereas mine uses @var{language} -- which I think is slightly
> better,
> because the list of languages isn't necessarily fixed (and you missed
> obj-c++),
> though I could see yours as being slightly clearer. However, note that my
> patch includes some formatting fixes to this section, which should be
> incorporated regardless.
Agreed, your patch is superior to mine.
> (Note, by the way, that the small problem you mention in --help=
> output is Bug #31356. :) )
:-)
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31355
[Bug other/31356] gcc --help= option has problems in the output header line.
--- 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 > lang_names[i]. Is there are reason you made this conditional? Not really, just a hunch. I felt that the first language name set would probably be the most "mainstream" of the possible language names that might be displayed. Of course I did not actually go so far as to check this, and your version of the patch is simpler and therefore better. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31356
[Bug fortran/31259] ICE on elemental character function
--- 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 argument to one of the intrinsic functions BIT_SIZE, KIND, LEN, or the numeric inquiry functions (13.11.8). Confirmed Paul -- pault 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-03-29 11:44:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31259
[Bug c/31389] New: [4.3 Regression] undefined reference with inline function and -std=gnu99
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): undefined reference to `timerdiv'
but it works when I either remove the "inline" attribute to timerdiv or
the -std=gnu99.
Code:
timer.c:
#include
inline void
timerdiv(struct timeval *tvp, float div)
{
double interval;
if (div == 0 || div == 1)
return;
interval = ((double)tvp->tv_sec * 100 + tvp->tv_usec) / (double)div;
tvp->tv_sec = interval / (int)100;
tvp->tv_usec = interval - (tvp->tv_sec * 100);
}
t.c:
#include
struct tcpr_speed_s {
float speed;
};
typedef struct tcpr_speed_s tcpr_speed_t;
struct tcpreplay_opt_s {
tcpr_speed_t speed;
};
typedef struct tcpreplay_opt_s tcpreplay_opt_t;
struct timeval nap;
tcpreplay_opt_t options;
extern void timerdiv(struct timeval *tvp, float div);
int main() {
timerdiv(&nap, options.speed.speed);
return 0;
}
--
Summary: [4.3 Regression] undefined reference with inline
function and -std=gnu99
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31389
[Bug c/31389] [4.3 Regression] undefined reference with inline function and -std=gnu99
--- 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 CC||tbm at cyrius dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31389
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- 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 far, or I may fail entirely, everywhere. Weird, when solaris is the easiest one. > Based on Solaris 11 x86, I don't see a way for say cstdlib to have only the > namespace std versions of functions, and not also the global scoped ones. #include (this is how sun studio compiler does it) If you also want the C99 functions, then you have to wait for the next c++ standard to actually exist before solaris changes its headers accordingly. > My RFC message about C++0x headers had the details on my implementation plan, > I think. Sorry for the dumb question, but where is it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug target/19745] [meta-bug]: cris-elf gcc, g++, objc testsuite failures as of "Tue Feb 1 22:03:59 UTC 2005"
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19745
[Bug libstdc++/19747] [meta-bug] : cris-elf libstdc++ testsuite failures as of "Tue Feb 1 22:03:59 UTC 2005"
--- 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: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19747
[Bug tree-optimization/13875] [tree-ssa] missed jump thread optimization on the tree-level
--- 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 Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13875
[Bug fortran/31390] New: ICE due to transfer function
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) :: singleByte end type contains function BucketIndexOfKey(key) result (hash) type(Byte), intent(in):: key(:) integer :: hash integer, parameter:: intPrototype(1) = 0 integer :: intKey( size(transfer(key, intPrototype)) ) intKey = transfer(key, intPrototype) ! This line causes the ICE hash = 0 end function end module program main use InternalCompilerError end program The ICE seems to disappear when removing the following line, which makes me think that it is the direct cause: intKey = transfer(key, intPrototype) ! This line causes the ICE Regards, Drew McCormack -- Summary: ICE due to transfer function Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drewmccormack at mac dot com GCC build triplet: 4.3.0 20070316 (experimental) GCC target triplet: powerpc-apple-darwin8.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31390
[Bug tree-optimization/24568] [meta-bug] Missed optimization: trivialization of silly code
--- 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 (milliDiff)
{
int minutesDiff.24;
int minutesDiff;
:
if (milliDiff < 0) goto ; else goto ;
:;
minutesDiff = -milliDiff / 6;
minutesDiff.24 = -minutesDiff;
goto ();
:;
if (milliDiff == 0) goto ; else goto ;
:;
minutesDiff.24 = 0;
goto ();
Invalid sum of outgoing probabilities 0.0%
Invalid sum of incoming frequencies 2000, should be 0
:;
minutesDiff.24 = milliDiff / 6;
Invalid sum of incoming frequencies 8000, should be 1
:;
return minutesDiff.24;
}
Note that on hosts where sizeof(long) != sizeof(int), you can't optimize the
original test case to i/6.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2006-02-26 19:10:03 |2007-03-29 13:29:35
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24568
[Bug debug/31391] New: [4.3 Regression] undefined label with -O -g
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;
int type;
} HostEntry;
typedef struct _displayEntry {
struct _displayEntry*next;
int type;
int chooser;
HostEntry *hosts;
} DisplayEntry;
char* name;
char *ReadWord(FILE *file) {
return name;
}
static HostEntry *
ReadHostEntry (FILE *file)
{
char*hostOrAlias;
HostEntry *h;
struct hostent *hostent;
tryagain:
hostOrAlias = ReadWord (file);
if (!hostOrAlias)
return NULL;
h = (HostEntry *) malloc (sizeof (DisplayEntry));
if (!hostent)
{
free ((char *) h);
goto tryagain;
}
return h;
}
static DisplayEntry *
ReadDisplayEntry (FILE *file)
{
DisplayEntry*d;
HostEntry *h, **prev;
struct hostent *hostent;
switch (hostent->h_addrtype)
{
default:
break;
}
prev = &d->hosts;
while ((h = ReadHostEntry (file)))
{
if (h->type == 3)
{
d->chooser = 1;
}
else {
*prev = h;
prev = &h->next;
}
}
return d;
}
int ScanAccessDatabase (FILE *file)
{
ReadDisplayEntry (file);
}
m.c:
int main() {
}
--
Summary: [4.3 Regression] undefined label with -O -g
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31391
[Bug debug/31391] [4.3 Regression] undefined label with -O -g
--- 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
[Bug c/31389] [4.3 Regression] undefined reference with inline function and -std=gnu99
--- 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 Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31389
[Bug middle-end/30666] [4.3 Regression] warning: canonical types differ for identical types double __complex__ and double __complex__
--- 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/show_bug.cgi?id=30666
[Bug tree-optimization/31383] ICE with -O2 -ftree-vectorize (regression)
--- 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 at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-03-28 12:45:13 |2007-03-29 14:29:29 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31383
[Bug fortran/31392] New: [meta-bug] gfortran problems with initialization
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 Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org BugsThisDependsOn: 20373,20851,22571,24978,25057,25104,29507,29962,31221,31 222,31229,31243,31244,31250,31251,31253 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31392
[Bug fortran/31393] New: [meta-bug] gfortran compile-time problems with intrinsics
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 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: meta-bug Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobi at gcc dot gnu dot org BugsThisDependsOn: 20373,22572,28378,29507,29828,29962,30372,31253 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31393
[Bug middle-end/30666] [4.3 Regression] warning: canonical types differ for identical types double __complex__ and double __complex__
--- 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 tree-optimization/30666 * tree.c (build_complex_type): When creating type names for DWARF2 debug info, create TYPE_DECLs for TYPE_NAME instead of IDENTIFIER_NODEs. (build_common_tree_nodes_2): Use build_complex_type when building predefined complex types, to preserve canonical types. Modified: trunk/gcc/ChangeLog trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30666
[Bug debug/31391] [4.3 Regression] undefined label with -O -g
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31391
[Bug middle-end/30666] [4.3 Regression] warning: canonical types differ for identical types double __complex__ and double __complex__
--- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30666
[Bug c/31389] [4.3 Regression] undefined reference with inline function and -std=gnu99
--- 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, it will just work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31389
[Bug c++/950] Template problem: decay of pointer-to-member-of-derived to p-o-m-o-base
--- 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 CC||bangerth at dealii dot org Known to fail|3.4.4 4.0.1 4.1.0 |3.4.4 4.0.1 4.1.0 4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=950
[Bug c++/712] diagnostic line is split between quotes if it happens to appear in the wrong place
--- 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 |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=712
[Bug c++/189] [DR176] parse error in qualified member name lookup
--- 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 CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=189
[Bug c++/712] diagnostic line is split between quotes if it happens to appear in the wrong place
--- 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
[Bug c++/99] Bug in template type in error message.
--- 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
Re: [Bug c++/99] 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 the patch broke some other diagnostic. :-( I'll try to revive it. -- Gaby
[Bug c++/99] Bug in template type in error message.
--- 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 the patch broke some other diagnostic. :-( I'll try to revive it. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
[Bug c++/712] diagnostic line is split between quotes if it happens to appear in the wrong place
--- 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 dot org changed: What|Removed |Added CC||bangerth at dealii dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=712
[Bug fortran/31390] ICE due to transfer function
--- 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 compiler (maybe download it from http://gcc.gnu.org/wiki/GFortranBinaries, as I recently uploaded a new MacOS/powerpc package) and reopen the PR if the bug is not fixed for you? *** This bug has been marked as a duplicate of 31193 *** -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31390
[Bug fortran/31193] [4.2 only] ICE on non-constant character tranfert
--- 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 CC||drewmccormack at mac dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31193
[Bug c++/712] diagnostic line is split between quotes if it happens to appear in the wrong place
--- 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
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- 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 compile differently: fold-const.c and tree.c. Unfortunately, a function early in fold-const.c gets compiled differently legitimately -- sign_bit_p actually benefits from the optimization -- and all the functions after that differ in decl_uid numbers, which completely obscures the rest of the changes. I'll keep searching... -- rth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-03-14 20:03:38 |2007-03-29 17:30:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug libgcj/29869] LogManager class loading failure with Tomcat
--- 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, JarUtils using a logger? That seems weird. At least it should only do that lazily... Third, what's up with the class name "1catalina.org.apache.juli.FileHandler,"? Perhaps we are not parsing something correctly? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29869
[Bug c/31394] New: cos() returns wrong value unless -O0 is used
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, correctness depends on the flags. Just a note on "correctness" since these are floating-point operations: IMHO the incorrect result is far enough away from the true result to remove all doubt, but I can say more if necessary. In the output below, "b =" is correct, but "b2=" is incorrect. Here's the output I get: sunamd1:/export/home/gams/lang/cosbug$gmake && ./cosbug gcc -m64 -Wall -w -m64 -fwrapv -O1 -save-temps -v -o cosbug cosbug.c -lm Using built-in specs. Target: i386-pc-solaris2.10 Configured with: ../configure --build=i386-pc-solaris2.10 --with-gnu-as --with-as=/usr/sfw/bin/gas --without-gnu-ld -with-ld=/usr/ccs/bin/ld --with-gmp=/usr/local --with-mpfr=/usr/local --enable-languages=c,c++,fortran --enable-shared Thread model: posix gcc version 4.3.0 20070301 (experimental) /usr/local/libexec/gcc/i386-pc-solaris2.10/4.3.0/cc1 -E -quiet -v -imultilib amd64 cosbug.c -m64 -mtune=generic -Wall -w -fwrapv -O1 -fpch-preprocess -o cosbug.i ignoring nonexistent directory "/usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/../../../../i386-pc-solaris2.10/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/include /usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/include-fixed /usr/include End of search list. /usr/local/libexec/gcc/i386-pc-solaris2.10/4.3.0/cc1 -fpreprocessed cosbug.i -quiet -dumpbase cosbug.c -m64 -mtune=generic -auxbase cosbug -O1 -Wall -w -version -fwrapv -o cosbug.s GNU C version 4.3.0 20070301 (experimental) (i386-pc-solaris2.10) compiled by GNU C version 4.3.0 20070301 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 15fd974b8d70fc2c218783c6076c49f0 /usr/sfw/bin/gas --traditional-format -V -Qy --64 -s -o cosbug.o cosbug.s GNU assembler version 2.15 (i386-pc-solaris2.10) using BFD version 2.15 /usr/local/libexec/gcc/i386-pc-solaris2.10/4.3.0/collect2 -V -Y P,/lib/64:/usr/lib/64 -Qy -o cosbug /usr/lib/amd64/crt1.o /usr/lib/amd64/crti.o /usr/lib/amd64/values-Xa.o /usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/amd64/crtbegin.o -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/amd64 -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/../../../amd64 -L/lib/amd64 -L/usr/lib/amd64 -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0 -L/usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/../../.. cosbug.o -lm -lgcc -lgcc_eh -lc -lgcc -lgcc_eh /usr/local/lib/gcc/i386-pc-solaris2.10/4.3.0/amd64/crtend.o /usr/lib/amd64/crtn.o ld: Software Generation Utilities - Solaris Link Editors: 5.10-1.482 0 = 0 x0= -635.4813998334932 y = -7.036102677544457e-09 z = 635.4813998264574 *** |t| < mu: return smoother v = -3.141592653589793 b = -1.224646799147353e-16 *** |t| < mu: return smoother v2= -3.141592653589793 b2= -0.04318444754676655 sunamd1:/export/home/gams/lang/cosbug$ Now using the .i file I get: sunamd1:/export/home/gams/lang/cosbug$gcc -m64 -o xxx cosbug.i -lm sunamd1:/export/home/gams/lang/cosbug$./xxx 0 = 0 x0= -635.4813998334932 y = -7.036102677544457e-09 z = 635.4813998264574 *** |t| < mu: return smoother v = -3.141592653589793 b = -1.224646799147353e-16 *** |t| < mu: return smoother v2= -3.141592653589793 b2= -1.224646799147353e-16 sunamd1:/export/home/gams/lang/cosbug$gcc -m64 -O1 -o xxx cosbug.i -lm sunamd1:/export/home/gams/lang/cosbug$./xxx 0 = 0 x0= -635.4813998334932 y = -7.036102677544457e-09 z = 635.4813998264574 *** |t| < mu: return smoother v = -3.141592653589793 b = -1.224646799147353e-16 *** |t| < mu: return smoother v2= -3.141592653589793 b2= -0.04318444754676655 -- Summary: cos() returns wrong value unless -O0 is used Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sdirkse at gams dot com GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: i386-pc-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31394
[Bug c/31394] cos() returns wrong value unless -O0 is used
--- 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 OK. I observe the bug also with -O2 and -O3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31394
[Bug libgcj/29869] LogManager class loading failure with Tomcat
--- 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/lib/tomcat5.5/conf/logging.properties:
handlers = 1catalina.org.apache.juli.FileHandler,
2localhost.org.apache.juli.FileHandler, 3
manager.org.apache.juli.FileHandler, 4admin.org.apache.juli.FileHandler,
5host-manager.org.
apache.juli.FileHandler, java.util.logging.ConsoleHandler
.handlers = 1catalina.org.apache.juli.FileHandler,
java.util.logging.ConsoleHandler
# Handler specific properties.
# Describes specific configuration info for Handlers.
1catalina.org.apache.juli.FileHandler.level = FINE
1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
1catalina.org.apache.juli.FileHandler.prefix = catalina.
2localhost.org.apache.juli.FileHandler.level = FINE
2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
2localhost.org.apache.juli.FileHandler.prefix = localhost.
3manager.org.apache.juli.FileHandler.level = FINE
3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
3manager.org.apache.juli.FileHandler.prefix = manager.
4admin.org.apache.juli.FileHandler.level = FINE
4admin.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
4admin.org.apache.juli.FileHandler.prefix = admin.
5host-manager.org.apache.juli.FileHandler.level = FINE
5host-manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29869
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- 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 elements)
lo_2: [0, +INF] EQUIVALENCES: { } (0 elements)
mask_hi_3: VARYING
hi_4: VARYING
@@ -8971,7 +8971,7 @@ mask_hi_38: VARYING
D.30338_41: [-1, 63] EQUIVALENCES: { } (0 elements)
lo_42: [0, +INF] EQUIVALENCES: { } (0 elements)
D.30339_44: [0, 64] EQUIVALENCES: { } (0 elements)
-mask_lo_45: [0, +INF] EQUIVALENCES: { } (0 elements)
+mask_lo_45: [0x0, +INF] EQUIVALENCES: { } (0 elements)
D.30340_47: [22, 22] EQUIVALENCES: { D.30324_17 D.30324_96 } (2 elements)
D.30341_49: VARYING
D.30342_50: VARYING
@@ -9211,7 +9211,7 @@ sign_bit_p (exp, val)
# hi_4 = PHI
# mask_hi_3 = PHI
# lo_2 = PHI <0(13), lo_42(14)>
- # mask_lo_1 = PHI <0x0(13), mask_lo_45(14)>
+ # mask_lo_1 = PHI <0x0(13), 0x0(14)>
:;
D.30340_47 = 22;
D.30341_49 = val_102(D)->int_cst.int_cst.high;
@@ -9221,7 +9221,7 @@ sign_bit_p (exp, val)
:;
D.30343_52 = 22;
D.30344_54 = val_102(D)->int_cst.int_cst.low;
- D.30345_55 = D.30344_54 & mask_lo_1;
+ D.30345_55 = D.30344_54;
if (D.30345_55 == lo_2) goto ; else goto ;
:;
The VRP change for mask_lo_1 is correct; the two values that the variable
can obtain are 0x... and 0x0fff.... But removing the BIT_AND
is incorrect, afaics.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821
--- 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; goto (); Incorrect folding is surely what causes ivopts to do bad things, and bad loop opts is the visible miscompilation problem in stage3. Probably you can extract sign_bit_p from any target's preprocessing and debug the problem. If that's not true, I can go back and do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169
[Bug libgcj/29869] LogManager class loading failure with Tomcat
--- 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 the implementation ignoring classes it can't find. And, tomcat extends the meaning of this field; see the JULI configuration stuff here: http://tomcat.apache.org/tomcat-5.5-doc/logging.html That's sort of gross :( Anyway, working on a patch now. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-29 18:43:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29869
[Bug target/31394] cos() returns wrong value unless -O0 is used
--- 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 should update your build. Could you be also kind enough to look at the related optimization problem PR31249 and see it affects also your platform? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31394
[Bug fortran/31395] New: Colon edit descriptor is ignored unless preceded by a comma or a slash
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 descriptor is ignored unless preceded by a
comma or a slash
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: michael dot a dot richmond at nasa dot gov
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31395
[Bug tree-optimization/29585] [4.2 Regression] tree check: expected ssa_name, have var_decl in is_old_name, at tree-into-ssa.c:558
--- 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
[Bug c/31396] New: Inline code performance much worse than out-of-line
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: T0: 3117.44 ms T1: 653.93 ms inline: T0: 3097.05 ms T1: 3104.18 ms -- Summary: Inline code performance much worse than out-of-line Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jamagallon at ono dot com GCC target triplet: i586-mandriva-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31396
[Bug c/31396] Inline code performance much worse than 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 elements on a vector. The code in main() is muuch slower that the function. If the function is inlined (-DINLINE), it becomes equally slower. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31396
[Bug c/31396] Inline code performance much worse than out-of-line
--- 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
[Bug tree-optimization/17116] Missed jump threading/bypassing optimization with loop and % (or ands)
--- 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 benefits. Jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17116
[Bug c/31396] Inline code performance much worse than out-of-line
--- 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 jne .L2 #APP #FEND #NO_APP For the loop in main(): .L11: fldl-56(%ebp) <= look here fadds -4(%edx,%eax,4) fstpl -56(%ebp) <= and here addl$1, %eax cmpl$268435457, %eax jne .L11 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31396
[Bug middle-end/31396] Inline code performance much worse than out-of-line
--- 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 incq%rax cmpq$268435456, %rax addsd 24(%rsp), %xmm0 movsd %xmm0, 24(%rsp) jne .L11 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31396
[Bug bootstrap/31379] make[3]: *** [s-gtype] Segmentation fault (core dumped)
--- 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 the end. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||sje at cup dot hp dot com, ||bonzini at gnu dot org, ||zackw at panix dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31379
[Bug bootstrap/31379] make[3]: *** [s-gtype] Segmentation fault (core dumped)
--- 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 used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31379
[Bug bootstrap/31379] make[3]: *** [s-gtype] Segmentation fault (core dumped)
--- 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): Mostly revert changes from 2007-03-26; > add comment explaining why vsnprintf cannot be used. Thanks for the pointer. I'll update and close the PR if the problem is fixed. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31379
[Bug fortran/31222] Rejected: implicitly-typed dummys used in initialization expressions
--- 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)
*** numeric_check (gfc_expr *e, int n)
*** 58,63
--- 58,75
if (gfc_numeric_ts (&e->ts))
return SUCCESS;
+ /* If the expression has not got a type, check if its namespace can
+ offer a default type. */
+ if ((e->expr_type == EXPR_VARIABLE || e->expr_type == EXPR_VARIABLE)
+ && e->symtree->n.sym->ts.type == BT_UNKNOWN
+ && gfc_set_default_type (e->symtree->n.sym, 0,
+ e->symtree->n.sym->ns) == SUCCESS
+ && gfc_numeric_ts (&e->symtree->n.sym->ts))
+ {
+ e->ts = e->symtree->n.sym->ts;
+ return SUCCESS;
+ }
+
gfc_error ("'%s' argument of '%s' intrinsic at %L must be a numeric type",
gfc_current_intrinsic_arg[n], gfc_current_intrinsic, &e->where);
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
Last reconfirmed|2007-03-16 15:06:50 |2007-03-30 00:34:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31222
[Bug bootstrap/31039] Latest CVS-stage 2-Cannot create executables
--- 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.gnu.org/ml/gcc/2007-03/msg00948.html http://gcc.gnu.org/ml/gcc/2007-03/msg01088.html This bug could be closed fixed now. cheers, DaveK -- dave dot korn at artimi dot com changed: What|Removed |Added CC||dave dot korn at artimi dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31039
[Bug libgcj/29869] LogManager class loading failure with Tomcat
--- 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/LogManager.java (readConfiguration): Handle comma-separated 'handlers'. Don't try to add a non-existing handler. libgcj/classpath PR libgcj/29869: * gnu/java/util/jar/JarUtils.java (log): Commented out. (readSFManifest): Don't log. Modified: trunk/libjava/ChangeLog trunk/libjava/classpath/ChangeLog trunk/libjava/classpath/gnu/java/util/jar/JarUtils.java trunk/libjava/classpath/lib/gnu/java/util/jar/JarUtils.class trunk/libjava/classpath/lib/java/util/logging/LogManager$1.class trunk/libjava/classpath/lib/java/util/logging/LogManager.class trunk/libjava/java/util/logging/LogManager.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29869
[Bug libgcj/29869] LogManager class loading failure with Tomcat
--- 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|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29869
[Bug libgcj/29869] LogManager class loading failure with Tomcat
--- 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/util/logging: LogManager.java Log message: PR libgcj/29869: * java/util/logging/LogManager.java (readConfiguration): Handle comma-separated 'handlers'. Don't try to add a non-existing handler. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.9184&r2=1.9185 http://cvs.savannah.gnu.org/viewcvs/classpath/java/util/logging/LogManager.java?cvsroot=classpath&r1=1.27&r2=1.28 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29869
[Bug libgcj/29869] LogManager class loading failure with Tomcat
--- 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/LogManager.java (readConfiguration): Handle comma-separated 'handlers'. Don't try to add a non-existing handler. libgcj/classpath PR libgcj/29869: * gnu/java/util/jar/JarUtils.java (log): Commented out. (readSFManifest): Don't log. Modified: branches/redhat/gcc-4_1-branch/libjava/ChangeLog branches/redhat/gcc-4_1-branch/libjava/classpath/ChangeLog branches/redhat/gcc-4_1-branch/libjava/classpath/gnu/java/util/jar/JarUtils.java branches/redhat/gcc-4_1-branch/libjava/java/util/logging/LogManager.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29869
[Bug rtl-optimization/31025] [dataflow] Crash in caller-save.c due to x87 math
--- 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 Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31025
