[Bug c++/18094] Failure to specialize function

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-21 04:28 --- There is no data_type which is part of the map template so this is invalid. -- What|Removed |Added ---

[Bug c++/18094] Failure to specialize function

--- Additional Comments From vassili dot karpov at iss dot ru 2004-10-21 04:18 --- Along with GCC 3.4.2 this code was rejected by: GCC 3.3.3 (i686-pc-linux-gnu) GCC 3.3.4 (i686-pc-linux-gnu) ICC 8.1 (i686-pc-linux-gnu) MS VCToolkit2003 (MSVC 13.10.3052) But accepted by Comeau online com

[Bug c++/18094] Failure to specialize function

--- Additional Comments From vassili dot karpov at iss dot ru 2004-10-21 04:15 --- Created an attachment (id=7393) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7393&action=view) .cpp .i and gcc -v output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18094

[Bug c++/18094] New: Failure to specialize function

-- Summary: Failure to specialize function Product: gcc Version: 3.4.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vassili dot

[Bug tree-optimization/17506] [4.0 regression] warning about uninitialized variable points to wrong location

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-21 04:09 --- I will post this patch after you say if the message is a good idea or not. I messed up on the patch though, it should be inform instead of "note". I changed it from warning as it should not be warning. -

[Bug tree-optimization/17506] [4.0 regression] warning about uninitialized variable points to wrong location

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-21 04:05 --- Created an attachment (id=7391) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7391&action=view) Patch which fixes the problem ChangeLog: * tree-ssa.c (warn_uninit): Say where the variables are declare

[Bug c++/18055] seems not possible to specialize a template member function

--- Additional Comments From ramya dot chandar at wipro dot com 2004-10-21 03:49 --- Subject: Re: seems not possible to specialize a template member function I tried the way you have mentioned. Giving the "template<> " in all the specialized function definitions. But, it didn't wor

[Bug rtl-optimization/13674] [4.0 Regression] ICE in reload_cse_simplify_operands, at postreload.c:378 on PPC64

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-21 03:41 --- Here is the testcase which can reproduce it on the mainline for -mpowerpc64: struct __attribute__((packed)) G { unsigned char i; unsigned long long l; }; unsigned long long foo (struct G x) { return x.l; }

[Bug target/14981] [3.4/4.0 Regression] ICE in _mm_xor_pd for SSE2 with -O1

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-21 03:17 --- Actually it will not slow down the compiler that much on the mainline because of my fix for PR 13987. -- What|Removed |Added

[Bug other/17594] [3.4/4.0 Regression] GCC does not error about unknown options which starts with a valid option

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-21 03:10 --- The problem is in find_opt. Neil can you look into this as it looks like you caused? -- What|Removed |Added --

[Bug c/17407] [4.0 Regression] ICE in int_mode_for_mode

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-21 03:07 --- Patch here: . -- What|Removed |Added

[Bug c/17407] [4.0 Regression] ICE in int_mode_for_mode

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-21 02:44 --- Here is the patch if you need it sooner: Index: c-decl.c === RCS file: /cvs/gcc/gcc/gcc/c-decl.c,v retrieving revision 1.602 diff -u -p -r1.60

[Bug target/17990] [3.4/4.0 Regression] unaligned xmm movaps on the stack with -O2 -msse because of the frame pointer

--- Additional Comments From shadow at serverart dot org 2004-10-21 02:15 --- i tested -mno-sse and it is a functional good workaround. also seems to override '-march=athlon-xp' which in this case is a good thing. -E -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17990

[Bug c/17407] [4.0 Regression] ICE in int_mode_for_mode

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-21 02:07 --- This is a C front-end problem where we don't call layout_type on the array, having it call layout_type on the type, makes this work. -- What|Removed |Added

[Bug c++/17115] [3.3 Regression] -Winline does not respect __attribute__((__noinline__))

--- Additional Comments From giovannibajo at libero dot it 2004-10-21 01:36 --- Subject: Re: [3.3 Regression] -Winline does not respect __attribute__((__noinline__)) > Mayn thanks for the fix. No problem. > May I also draw > your attention to bug18071 (-Winline > does not respect -

[Bug target/17317] [3.3 Regression] Match Constraints for *movdf_insn fails

--- Additional Comments From giovannibajo at libero dot it 2004-10-21 01:34 --- Committed to 3.4 as well. Now only a 3.3 regression. -- What|Removed |Added Summar

[Bug target/17317] [3.3/3.4 Regression] Match Constraints for *movdf_insn fails

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-21 01:33 --- Subject: Bug 17317 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2004-10-21 01:33:16 Modified files: gcc: Change

[Bug target/17717] SH4 internal compiler error: in emit_move_insn

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-21 01:30 --- Fixed so closing. -- What|Removed |Added Status|UNCONFIRMED |RES

[Bug tree-optimization/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From schlie at comcast dot net 2004-10-21 01:28 --- Subject: Re: usual arithmetic conversion not applying correctly Andrew, So regardless of the all other things, it seems minimally clear that the promotion code as it stands now should allow the required result

[Bug tree-optimization/17716] [4.0 Regression] ICE in tree-ssa-dom

--- Additional Comments From bje at gcc dot gnu dot org 2004-10-21 01:12 --- Pinski asked me to close this :-) -- What|Removed |Added Status|ASSIGNED

[Bug libgcj/14664] [3.4 Regression] All gcj-built programs SEGV on startup

--- Additional Comments From rth at gcc dot gnu dot org 2004-10-21 01:11 --- === libjava tests === Running target unix WARNING: program timed out. FAIL: linking simple FAIL: initexc execution - gij test FAIL: initexc execution - gij test === libjava Summ

[Bug tree-optimization/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From schlie at comcast dot net 2004-10-21 01:04 --- Subject: Re: usual arithmetic conversion not applying correctly Ok, a more basic observation/recommendation: the front end should not be masking true operand types by promoting them prematurely, as it generates

[Bug target/17990] [3.4/4.0 Regression] unaligned xmm movaps on the stack with -O2 -msse because of the frame pointer

--- Additional Comments From shadow at serverart dot org 2004-10-21 00:47 --- -fomit-frame-pointer has no effect. thanks anyways G. -E -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17990

[Bug tree-optimization/18092] [4.0 Regression] Infinite loop in tree-ssa-loop-niter.c:inverse

--- Additional Comments From rakdver at gcc dot gnu dot org 2004-10-21 00:04 --- I have a patch that might solve this as a side effect. I will post it once it passes regtesting. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18092

[Bug tree-optimization/18092] [4.0 Regression] Infinite loop in tree-ssa-loop-niter.c:inverse

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 23:58 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug c++/18093] [3.4/4.0 regression] bogus conflict in namespace aliasing

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 23:41 --- Note this is related to PR 11762. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18093

[Bug c++/18093] [3.4/4.0 regression] bogus conflict in namespace aliasing

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 23:32 --- : Search converges between 2003-12-18-trunk (#431) and 2003-12-24-trunk (#432). Note we just to ICE before also, this is the date which the ICE was fixed: : Search converges between 2004-08-01-trunk (#501)

[Bug tree-optimization/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From schlie at comcast dot net 2004-10-20 23:28 --- Subject: Re: usual arithmetic conversion not applying correctly What size promotion is required for char sized integer operations? I see none? What size promotion is required for short sized integer operatio

[Bug tree-optimization/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From jsm at polyomino dot org dot uk 2004-10-20 23:03 --- Subject: Re: C integer promotion semantics / front end problems. I presume you sent your message directly to me by mistake, so am sending the reply back to the bug database so it can benefit more than o

[Bug c++/18093] [3.4/4.0 regression] bogus conflict in namespace aliasing

--- Additional Comments From bangerth at dealii dot org 2004-10-20 22:52 --- Confirmed. A regression in 3.4 and mainline over 3.3. W. -- What|Removed |Added Sta

[Bug tree-optimization/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From jsm at polyomino dot org dot uk 2004-10-20 22:41 --- Subject: Re: usual arithmetic conversion not applying correctly On Wed, 20 Oct 2004, schlie at comcast dot net wrote: > It's a pretty major screw-up to presume > all target machines are large, and then

[Bug c++/18093] New: bogus conflict in namespace aliasing

$ cat >test.cxx namespace m { namespace n { } } namespace n { } namespace o { namespace n = ::m::n; } $ g++-3.4 test.cxx test.cxx:14: error: declaration of `namespace n' conflicts with test.cxx:9: error: previous declaration of `namespace n' here BTW, this bug in combination with #164

[Bug tree-optimization/18092] [4.0 Regression] Infinite loop in tree-ssa-loop-niter.c:inverse

-- What|Removed |Added Keywords||compile-time-hog Summary|Infinite loop in tree-ssa- |[4.0 Regression] Infinite |

[Bug tree-optimization/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 22:31 --- That was not me writting that but a C front-end person so why did you write Andrew? -- What|Removed |Added ---

[Bug tree-optimization/18092] New: Infinite loop in tree-ssa-loop-niter.c:inverse

Compiling gcc.c-torture/execute/20040307-1.c for alpha-linux will not terminate. We attempt to find the inverse of 1 in a 1-bit type, and the algorithm does not converge. -- Summary: Infinite loop in tree-ssa-loop-niter.c:inverse Product: gcc Version: 4.0.0

[Bug c/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From schlie at comcast dot net 2004-10-20 22:27 --- Subject: Re: usual arithmetic conversion not applying correctly Andrew, It has nothing to do with "optimizing code", if the 3.X and 4.X front-ends are promoting the size of anything other than bool, enum, or b

[Bug target/17717] SH4 internal compiler error: in emit_move_insn

--- Additional Comments From dennisc at harding dot ca 2004-10-20 22:17 --- I have requilt my cross compiler using the latest GCC 3.4.2 source and the bug is gone. It compiles the same test case code without the ICE. This bug can probably be closed now. Good job. -- What

[Bug middle-end/18071] [3.4/4.0 Regression] -Winline does not respect -fno-default-inline

--- Additional Comments From giovannibajo at libero dot it 2004-10-20 21:52 --- Mine. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |giovannibajo at

[Bug c/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From schlie at comcast dot net 2004-10-20 21:46 --- Subject: Re: usual arithmetic conversion not applying correctly Andrew, And if it's already declared as, or cast to signed char's in the code? unsigned char x, y ; (signed char)x = (signed char)x / (signed c

[Bug java/17574] [meta-bug] gcj and libgcj 4.0 tracking PR

--- Additional Comments From mckinlay at redhat dot com 2004-10-20 21:41 --- Removing PR 14664 because its fixed on the 4.0 trunk. -- What|Removed |Added BugsThisDependsOn|1

[Bug java/17574] [meta-bug] gcj and libgcj 4.0 tracking PR

-- Bug 17574 depends on bug 15575, which changed state. Bug 15575 Summary: HAVE_LANGINFO_CODESET never defined http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15575 What|Old Value |New Value --

[Bug java/15575] HAVE_LANGINFO_CODESET never defined

--- Additional Comments From mckinlay at redhat dot com 2004-10-20 21:38 --- Fix checked in. -- What|Removed |Added Status|NEW |RESOLVED

[Bug java/15575] HAVE_LANGINFO_CODESET never defined

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-20 21:36 --- Subject: Bug 15575 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-20 21:36:48 Modified files: gcc: ChangeLog configure.ac aclocal.m4 con

[Bug c/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From jsm at polyomino dot org dot uk 2004-10-20 21:31 --- Subject: Re: usual arithmetic conversion not applying correctly On Wed, 20 Oct 2004, pinskia at gcc dot gnu dot org wrote: > Otherwise, the integer promotions are performed on both operands. Then > the

[Bug c/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 21:25 --- As I have said before, this has nothing to RTL, only the front-end. Read the code which I copied from the GCC, this is in the front-end. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065

[Bug c/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From schlie at comcast dot net 2004-10-20 21:19 --- Subject: Re: usual arithmetic conversion not applying correctly Andrew, Yes, and with respect to / and % operations: - the modulo/reminder result can always be represented in the same type and size as its d

[Bug java/18091] Valgrind errors building libjava

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 21:04 --- I think the "unitialized conditional move" will get fixed when: ==21620== Conditional jump or move depends on uninitialised value(s) ==21620==at 0x80C4165: get_attribute (jcf-parse.c:160) is fixed. See

[Bug java/18091] Valgrind errors building libjava

--- Additional Comments From mckinlay at redhat dot com 2004-10-20 20:49 --- For the memcpy() thing, in the error given we seem to be relocating something to the exact same position. In this case the memcpy() should be harmless. But, maybe it is possible to get real overlapping relocation

[Bug libgcj/13604] AccessController unfinished

--- Additional Comments From konqueror at gmx dot de 2004-10-20 20:36 --- Please put native code into VMAccessController from start if possible. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13604

[Bug java/18091] Valgrind errors building libjava

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 20:27 --- memcpy(0x1BE08FEC, 0x1BE08FEC, 5) new_ptr -= n; old_ptr -= n; if (n > 0) memcpy (new_ptr, old_ptr, n); Someone needs to look into this part though because I don't

[Bug java/18091] Valgrind errors building libjava

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 20:24 --- This is definitely a bug: /* Concatenate current package prefix with new sfname. */ char *buf = xmalloc (i+new_len+3); /* Replace '.' by DIR_SEPARATOR. */ for (; i >=

[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding

--- Additional Comments From bkorb at veritas dot com 2004-10-20 20:22 --- Subject: Re: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org wrote: > > --- Additional Comments From skunk at iskunk dot org 2004-10-20 20:14 --- > Tried a new build,

[Bug tree-optimization/18089] Valgrind errors in real.c

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 20:18 --- REAL_VALUE_TYPE x = TREE_REAL_CST (arg1); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18089

[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding

--- Additional Comments From skunk at iskunk dot org 2004-10-20 20:14 --- Tried a new build, with the second patch given in comment #8; same failure mode as before. bkorb, are there embedded tabs in your patch? I can't pull it out of the comment without expanding them; perhaps a patch-at

[Bug java/18091] New: Valgrind errors building libjava

I saw several kinds of errors, in huge quantity. /home/drow/valgrind/gcc/gcj -B/home/drow/valgrind/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/ i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-linux-g nu/sys-include --encoding=UTF-8 -Wno-de

[Bug fortran/18090] New: Valgrind errors while building libgfortran

/home/drow/valgrind/gcc/gfortran -B/home/drow/valgrind/gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/l ocal/i686-pc-linux-gnu/lib/ -isystem /usr/local/i686-pc-linux-gnu/include -isystem /usr/local/i686-pc-li nux-gnu/sys-include -g -O2 -Wall -fno-repack-arrays -fno-underscoring -c /home/drow/src/g

[Bug tree-optimization/18089] Valgrind errors in real.c

--- Additional Comments From drow at gcc dot gnu dot org 2004-10-20 20:01 --- Created an attachment (id=7389) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7389&action=view) Testcase. valgrind --db-attach=yes gcc/stage2/cc1 -fpreprocessed ggc-common2.i -quiet -O1 -o ggc-common.s -

[Bug tree-optimization/18089] New: Valgrind errors in real.c

During an --enable-checking=valgrind (and the normal checks) bootstrap, stage2 gives warnings compiling ggc-common.c. The first one is: ==29462== Conditional jump or move depends on uninitialised value(s) ==29462==at 0x853CB22: do_fix_trunc (real.c:963) 963 if (REAL_EXP (r) <= 0) (

[Bug c/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 19:54 --- When I am talking about promoting means that we add casts. aka sc%sc gets changed to (signed char) (((int)sc)%((int)sc)). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18065

[Bug rtl-optimization/17450] Use of uninitialized data in reorder_insns

--- Additional Comments From drow at gcc dot gnu dot org 2004-10-20 19:42 --- Appears to be gone with current HEAD. A number of new problems appeared, which I will report separately. -- What|Removed |Added -

[Bug libgcj/18087] Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

--- Additional Comments From mckinlay at redhat dot com 2004-10-20 19:36 --- I've added a regression test based on this test case, to mauve's gnu.testlet.java.util.Calendar.set -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18087

[Bug c/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From schlie at comcast dot net 2004-10-20 19:33 --- Subject: Re: usual arithmetic conversion not applying correctly Maybe the confusion is that you're not recognizing that: char, short, int, long, long long, are all integer types, with different storage formats

[Bug c/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 19:29 --- And the reason why we don't shoten back to signed char % signed char: /* Although it would be tempting to shorten always here, that loses on some targets, since the modulo instruction

[Bug c/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 19:25 --- The promotion is coming from: if (convert_p) { op0 = default_conversion (orig_op0); op1 = default_conversion (orig_op1); } else { op0 = orig_op0; op1 = orig_op1; }

[Bug c/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 19:18 --- But the front-end is doing the promotions where the problem comes from, nowhere else (I am using 4.0 to verify my claim that the front-end is actually doing the promotion). -- http://gcc.gnu.org/bugzil

[Bug libgcj/18083] Calendar returns incorrect values for DAY_OF_YEAR and DAY_OF_WEEK after calling add().

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 19:16 --- This is a bug (at least by reading Sun's docs for Calendar). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18083

[Bug c/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From schlie at comcast dot net 2004-10-20 19:14 --- Subject: Re: usual arithmetic conversion not applying correctly Please read rule 1: "If both operands have the same type, then no further conversion is needed." (no promotion to int is specified or implied

[Bug libgcj/18087] Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 19:13 --- Oh, you are right, what throw me off is the printing of todays date. This is fixed on the mainline. -- What|Removed |Added -

[Bug libgcj/18087] Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

--- Additional Comments From mckinlay at redhat dot com 2004-10-20 19:07 --- ?? Pinskia: are you sure? This should be fixed already on mainline. Here's the output I get with 4.0.0 20041019: $ gij CalendarTest2 Today: Wednesday, 2004-10-20 [294] 15:05:28.0425 Friday, 2004-10-01 [275] 12:0

[Bug libgcj/18087] Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 19:05 --- *** Bug 18088 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18087

[Bug libgcj/18088] Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 19:05 --- *** This bug has been marked as a duplicate of 18087 *** -- What|Removed |Added

[Bug libgcj/18088] New: Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field -- it should not be adjusted. Here is a sample code. import java.util.Calendar; import java.text.SimpleDateFormat; public class CalendarTest2 { public static void main( String [] args ) {

[Bug libgcj/18087] Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 19:00 --- Confirmed on the mainline. -- What|Removed |Added Status|UNCONFIRMED

[Bug libgcj/18087] New: Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field.

Calendar's HOUR field gets adjusted when setting DAY_OF_MONTH field -- it should not be adjusted. Here is a sample code. import java.util.Calendar; import java.text.SimpleDateFormat; public class CalendarTest2 { public static void main( String [] args ) {

[Bug c/18065] usual arithmetic conversion not applying correctly

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 18:50 --- >From C99 (6.5.5/3): The usual arithmetic conversions are performed on the operands. 6.3.1.8 Usual arithmetic conversions Otherwise, the integer promotions are performed on both operands. Then the followin

[Bug target/17717] SH4 internal compiler error: in emit_move_insn

--- Additional Comments From dennisc at harding dot ca 2004-10-20 18:49 --- This bug is triggered by calls to functions that return a char value combined with the -mrenesas compiler option. Removing the compiler option, or changing the functions return type to int will both eliminate the

[Bug target/18065] not using qi version of divmod

--- Additional Comments From schlie at comcast dot net 2004-10-20 18:34 --- Subject: Re: wrong code emitted Hi Andrew, Please correct the failure mode description to " critical, wrong code", as upon reviewing the avr.md file, it's now clear that this isn't a "missed optimization"; GCC

[Bug libgcj/18086] automate marking of Class object

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 18:27 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug libgcj/18086] New: automate marking of Class object

Currently we have hand-written code to mark Class instances. This is slow and is also bug-prone; we find problems in this code with annoying frequency. It may also be related to PR 16902. It doesn't look hard to automate marking of Class. Here is a plan: * Rearrange fields of Class so that all

[Bug java/15575] HAVE_LANGINFO_CODESET never defined

--- Additional Comments From mckinlay at redhat dot com 2004-10-20 18:10 --- Forget what I said, Tom is right. I just tested this again, and javac from JDK 1.5 does indeed use the Locale setting to determine the default encoding. Further more, javac does appear to distinguish between ASCI

[Bug target/17717] SH4 internal compiler error: in emit_move_insn

--- Additional Comments From dennisc at harding dot ca 2004-10-20 18:06 --- Created an attachment (id=7388) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7388&action=view) gcc command and output for minimal test This is the command line and compiler output produce with the new mini

[Bug target/17717] SH4 internal compiler error: in emit_move_insn

--- Additional Comments From dennisc at harding dot ca 2004-10-20 18:04 --- Created an attachment (id=7387) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7387&action=view) preprocessed 6line file that triggers ICE This is the preprocessor output of a minimal (6 line) file that trig

[Bug java/15575] HAVE_LANGINFO_CODESET never defined

--- Additional Comments From tromey at gcc dot gnu dot org 2004-10-20 18:03 --- My understanding is that other java compilers do use the locale's default encoding. However, unlike the glibc iconv() converter, typically javac treats ASCII as equivalent to Latin 1. -- http://gcc.gnu

[Bug rtl-optimization/18084] [3.4 only]setfill coupled with inline function: incorrect results on Linux x86

--- Additional Comments From bangerth at dealii dot org 2004-10-20 18:00 --- Here's something slightly smaller: -- #include #include #include uint64_t mask1, mask2; uint64_t calc() { return mask1 & mask2; } int main() { mask1 = 0xull

[Bug java/15575] HAVE_LANGINFO_CODESET never defined

--- Additional Comments From jsm at polyomino dot org dot uk 2004-10-20 17:59 --- Subject: Re: HAVE_LANGINFO_CODESET never defined On Wed, 20 Oct 2004, mckinlay at redhat dot com wrote: > Do we really want to fix this? > > The "buggy" behaviour actually seems better here because it m

[Bug java/15575] HAVE_LANGINFO_CODESET never defined

--- Additional Comments From mckinlay at redhat dot com 2004-10-20 17:52 --- Do we really want to fix this? The "buggy" behaviour actually seems better here because it more closely matches what other Java compilers do and seems to have resulted in less complaints from users since it "bro

[Bug libgcj/13604] AccessController unfinished

--- Additional Comments From mckinlay at redhat dot com 2004-10-20 17:45 --- Actually using the native API is probably the better option, since having a public stack trace API in Java is likely a security problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13604

[Bug libgcj/13604] AccessController unfinished

--- Additional Comments From mckinlay at redhat dot com 2004-10-20 17:44 --- The patch will need to be updated for the new stack trace infrastructure, because the interface to stack traces has changed. In particular, the gnu.gcj.runtime.StackTrace class is no longer supported. Either a)

[Bug target/18032] [4.0.0] SH: wrong code for EH

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 17:39 --- Fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug libgcj/18083] Calendar returns incorrect values for DAY_OF_YEAR and DAY_OF_WEEK after calling add().

--- Additional Comments From mnefedov at rogers dot com 2004-10-20 17:33 --- This could be a workaround. Do this: cal.setTime( cal.getTime() ) before calling get( Calendar.DAY_OF_{YEAR|WEEK} ); Seems to fix the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18083

[Bug libgcj/18083] Calendar returns incorrect values for DAY_OF_YEAR and DAY_OF_WEEK after calling add().

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 17:19 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW

[Bug c++/18073] [4.0 regression] mmintrin.h rejected by C++ frontend

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW

[Bug fortran/18082] Excessively long compile time

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 17:15 --- For some reason c1 and c2 are chained together in an infinite list. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18082

[Bug c++/10841] rejects valid explicit type conversion to/from pointers-to-member of private base

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW

[Bug rtl-optimization/18084] [3.4 only]setfill coupled with inline function: incorrect results on Linux x86

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 17:09 --- It works on the mainline but not on 3.4.0 and I don't know if this is a regression. But I should note that -O2 is enough and -O2 -fno-gcse works. -- What|Removed |Added

[Bug ada/18085] New: [Ada] - C++ interoperability sample program fails, 3.4.2, Linux 2.4.20-8, Red Hat 9.0

This program source is modified (additional print statements) from: http://gcc.gnu.org/onlinedocs/gcc-3.4.2/gnat_ugn_unw/A-Simple-Example.html#A-Simple-Example An example of interoperating C++ and Ada code. The results seem to indicate that the calls between the two languages are working

[Bug c++/18080] STL deque push_front, pop_front, push_back, and pop_back not O(1)

--- Additional Comments From ron at vaniwaarden dot org 2004-10-20 16:45 --- (In reply to comment #1) > Could you please have a look to libstdc++/13537? IMO, wither we should reopen > that one or close both ;) Thanks. Quoting from Sean Kirby in that discussion: >> 23.2.1.3.3 says, "Inse

[Bug c++/18084] New: setfill coupled with inline function: incorrect results on Linux x86

The problem... The following program produces incorrect results on a Linux x86 system when compiled with gcc v3.4.2 (and 3.4.1) with full optimizations. The program is supposed to print 0x, but instead produces random results (seems to be a stack corruption problem). The source... #inclu

[Bug c++/13495] Friendship to class nested within a template is broken

--- Additional Comments From lerdsuwa at gcc dot gnu dot org 2004-10-20 16:25 --- I am closing this as fixed by patch: http://gcc.gnu.org/ml/gcc-patches/2004-10/msg01709.html For access checking problem mentioned in the comments, it's already covered in PR16617. That part requires s

[Bug c++/13495] Friendship to class nested within a template is broken

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-20 16:20 --- Subject: Bug 13495 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-20 16:20:51 Modified files: gcc/cp : ChangeLog cp-tree.h decl.c friend.c p

  1   2   >