[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-20 08:21 --- Subject: Bug 17832 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-20 08:21:10 Modified files: fixincludes: ChangeLog fixincl.c fixlib.h procopen

[Bug bootstrap/17832] [4.0 Regression] Bootstrap broken by fixincludes failures

--- Additional Comments From aaronavay62 at aaronwl dot com 2004-10-20 08:39 --- One more patch left to be reviewed, besides PR17991: . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17832

[Bug c++/18072] New: Function overload being selected from file scope instead of template class scope when called from base template class

This problem evolved out of my trying to implement a context aware logger. It appears that template classes with template parameters that themselves have template parameters can cause gcc to be unable to select an overload from the class correctly and incorrectly goes to the file scope for the def

[Bug c++/18072] Function overload being selected from file scope instead of template class scope when called from base template class

--- Additional Comments From dwoldrich_ebay at yahoo dot com 2004-10-20 09:29 --- Created an attachment (id=7384) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7384&action=view) Source code This is the source code to the test I wrote. -- http://gcc.gnu.org/bugzilla/show_bug.cg

gcc-bugs@gcc.gnu.org

--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-20 09:33 --- Do we want to add a testcase to testsuite for this? -- What|Removed |Added Sta

[Bug c++/11240] Pointer comparison problem when using constructors

--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-20 09:49 --- Fixed by Mark's patch http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg01166.html Do we want to have a testcase for this one? -- What|Removed |Added --

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

--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-20 09:54 --- With Mark's patch http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg01166.html we now get an additional ICE on mainline: bug.cc: In function `int main()': bug.cc:6: error: 'main()::Base' is an inaccessible base of

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

Mark, since your patch http://gcc.gnu.org/ml/gcc-cvs/2004-10/msg01166.html the C++ frontend rejects the following code: = #include = I get gazillions of messages like /Work/reichelt/GCC/FARM/gcc-4.0-20041020/bin/../lib/gcc

[Bug inline-asm/18074] New: SSE2 intrinsics generates wrong code

The command line: gcc -O2 -msse2 -S 2.c The code: #include int f(__m128i x, __m128i y) { __m128i m[1]; m[0] = _mm_add_epi16(x, y); return *(int*)(&m[0]); } int g(__m128i x, __m128i y) { __m128i m[2]; m[0] = _mm_add_epi16(x, y); return *(int*)(&m[0]); } The compiler generates correct c

[Bug c++/18075] New: #pragma implementation broken in presence of #pragma ident

I get with the testcase I'm about to attach: [EMAIL PROTECTED] gcc-4.0 -S -Wall pragma_bug.ii /home/eric/cvs/gcc/libjava/java/lang/natClass.cc:34: warning: ignoring #pragma ident implementation With 3.4.3pre, all works fine. This is critical on Solaris because there are #pragma ident all over th

[Bug c++/18075] #pragma implementation broken in presence of #pragma ident

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-20 11:43 --- Created an attachment (id=7385) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7385&action=view) Testcase extracted from libgcj. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18075

[Bug target/18074] SSE2 intrinsics generates wrong code

-- What|Removed |Added Component|inline-asm |target Keywords||wrong-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id

[Bug c++/18075] [4.0 Regression] #pragma implementation broken in presence of #pragma ident

-- What|Removed |Added Keywords||build, wrong-code Summary|#pragma implementation |[4.0 Regression] #pragma |

[Bug target/18074] SSE2 intrinsics generates wrong code

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 11:59 --- Either use an union to extract the component or use -fno-strict-aliasing. -- What|Removed |Added -

[Bug java/17265] [4.0 Regression] Libjava doesn't build

--- Additional Comments From ebotcazou at gcc dot gnu dot org 2004-10-20 11:59 --- > That sounds like C++ bug. Indeed, relating to the handling of #pragma (PR c++/18075). -- What|Removed |Added ---

[Bug c++/18075] [4.0 Regression] #pragma implementation broken in presence of #pragma ident

-- What|Removed |Added OtherBugsDependingO||17265 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18075

[Bug target/18074] SSE2 intrinsics generates wrong code

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 11:59 --- Either use an union to extract the component or use -fno-strict-aliasing. You are violating aliasing rules. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18074

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

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 12:00 --- Confirmed. This should be accepted. -- What|Removed |Added Severity|normal

[Bug tree-optimization/18076] New: Missed jump threading optimization

On AMD64 the following piece of code still triggers one jump threading opportunity in the RTL threader that we miss it in the tree threader on the tree-cleanup-branch: = extern int x; extern int y; void foo (void) { if ((x & 0x0

[Bug c++/18077] New: Members of anonymous namespaces get name mangled with first global variable instead of file name

Members of anonymous namespaces should get a name that is mangled in a way so as to make them unique. This is not the case if a global variable is defined before the keyword "namespace" is used. In that case the first global variable name is used for the name mangling. If I then link with "-z mu

[Bug c++/18075] [4.0 Regression] #pragma implementation broken in presence of #pragma ident

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 12:56 --- : Search converges between 2004-09-20-161001-trunk (#551) and 2004-09-21-094824-trunk (#552). Almost certain caused by: 2004-09-20 Matt Austern <[EMAIL PROTECTED]> Zack Weinberg <[EMAIL PROTEC

[Bug c++/18077] [3.3/3.4/4.0 Regression] Members of anonymous namespaces get name mangled with first global variable instead of file name

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 13:05 --- Confirmed, a regression from 3.0.4. -- What|Removed |Added Status|UNCONFIRMED

[Bug c++/18072] Function overload being selected from file scope instead of template class scope when called from base template class

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 13:11 --- Did you read the release notes? This is documented in them and how the code should change. Invalid by the C++ standard. -- What|Removed |Added

gfortran internal compiler error - "Please submit a full bug report" being attempted

Reporting the bug requires setting up my 1,070,045th user account somewhere so I will use the email version as the gccbug script exists somewhere else. Mac Os X 10.3.5 Dual 1.8 G5 Mac standard configuration, i.e middle model before first speed bump "sudo fink install gfortran" used to insta

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

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 13:28 --- Two things for specialization you have to define the template functions like: template<> IOCM::Status IOCM_SequenceTempl::_unpack(IOCM::MessageBox& msgBox) instead of the current without "template<>", This

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

--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-20 13:38 --- Many C++ headers also fail when compiled with -pedantic: == #include == /Work/reichelt/GCC/FARM/gcc-4.0-20041020/bin/../lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include

[Bug ada/18066] GCC error: in expand_call, at calls.c

--- Additional Comments From "RUNKLE, TIMOTHY A dot (TIM) (JSC-EG) (NASA)" 2004-10-20 13:40 --- Subject: RE: GCC error: in expand_call, at calls.c Hello, Thanks for looking at the bug. It does indeed look like the bug you mentioned below. What is the fix? I extracted code fro

[Bug ada/18066] GCC error: in expand_call, at calls.c

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 13:46 --- Use 3.4.0 and above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18066

[Bug c/18070] Contradicting function attributes

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 13:49 --- This is actually two different bugs, one target issue and one really midde-end issue (noinline vs always_inline). I will file them sperately. -- What|Removed |Added --

Re: gfortran internal compiler error - "Please submit a full bug report" being attempted

On Oct 20, 2004, at 9:21 AM, Gordon Sande wrote: Reporting the bug requires setting up my 1,070,045th user account somewhere so I will use the email version as the gccbug script exists somewhere else. Mac Os X 10.3.5 Dual 1.8 G5 Mac standard configuration, i.e middle model before first speed bu

[Bug c++/18069] Contradicting type and variable attributes (possible regression)

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 13:53 --- Confirmed not a regression. -- What|Removed |Added Status|UNCONFIRMED

[Bug target/18078] New: Contradicting function attributes (cdecl vs stdcall)

/* contradicting - should be an error */ static __attribute__((cdecl)) __attribute__((stdcall)) int test_cdecl_03(int r) { return r << 3; } /* contradicting - should be an error */ static __attribute__((stdcall)) __attribute__((cdecl)) int test_cdecl_04(int r) { return r << 4; } --

[Bug c/18079] New: Contradicting function attributes (always_inline vs noinline)

/* contradicting - should be an error */ static __attribute__((noinline)) __attribute__((always_inline)) int test_inline_03(int r) { return r & 4; } /* contradicting - should be an error */ static __attribute__((always_inline)) __attribute__((noinline)) int test_inline_04(int r) { return r

[Bug c/18070] Contradicting function attributes

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 13:55 --- I filed 18079 and 18078 for both the problems, closing as invalid. -- What|Removed |Added

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

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2004-10-20 13:57 --- Subject: Bug 18032 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2004-10-20 13:57:23 Modified files: gcc: ChangeLog gcc/config/sh : s

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

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 14:00 --- Confirmed, a 3.4 and 4.0 regression. But note -O3 enables -finline-functions which enables inlining for all functions so that is not a documentation problem at all. : Search converges between 2004-01-01-

[Bug c/18079] Contradicting function attributes (always_inline vs noinline)

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 14:12 --- Confirmed, this was break up of bug 18070. -- What|Removed |Added CC|

[Bug target/18078] Contradicting function attributes (cdecl vs stdcall)

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 14:13 --- Confirmed, this was break up of bug 18070. -- What|Removed |Added CC|

[Bug c/18063] Gcc doesn't check overflowed size of structure

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

[Bug libstdc++/17755] Can't compile djgpp cross-compiler

-- What|Removed |Added Severity|critical|normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17755

[Bug tree-optimization/18076] Missed jump threading optimization

--- Additional Comments From pinskia at gcc dot gnu dot org 2004-10-20 14:35 --- If I make the x variable a paramater and y a variable (return y so that y is still used) then it works on the tree level so this is an aliasing causing missed optimization. Aka this works: int foo (int x)

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

I had to implement a new deque myself (had to have special behaviour for modifications) and could not come up with a way to do the summarized operations in O(1). I then looked at the deque in g++ and saw it had, basically, the same algorithm I had come up with. I don't know if there is an impleme

[Bug rtl-optimization/18081] New: Infinite memory allocation on -O3

When compiling the following code, cc1 enters an infinite loop allocating memory until virtual memory is exhausted. arm-rtems-elf-gcc-3.4.2 -O3 -c -otest.o test.c The bug disappears when using -O2 or when using -O3 with -fno-inline-functions or -fno-gcse It also disappears by removing lines from

[Bug fortran/18082] New: Excessively long compile time

I use gcc version GNU Fortran 95 (GCC 4.0.0 20041019 (experimental)) to compile the enclosed source file with the options /home/eschnett/gcc/bin/gfortran -ftrapv -march=pentium4 -malign-double -g3 -c -o /home/eschnett/Calpha/Cactus/configs/einstein-gcc-debug/build/EHFinder/EHFinder_ReadD

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

-- What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18080

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

Calendar returns incorrect values for DAY_OF_YEAR and DAY_OF_WEEK after calling add(). Here is an example code to test it: import java.util.Calendar; public class CalendarTest { public static void main( String [] args ) { boolean fail = false; Calendar c

[Bug fortran/18082] Excessively long compile time

--- Additional Comments From schnetter at aei dot mpg dot de 2004-10-20 15:53 --- Created an attachment (id=7386) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7386&action=view) failing source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18082

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

--- Additional Comments From pcarlini at suse dot de 2004-10-20 15:57 --- Could you please have a look to libstdc++/13537? IMO, wither we should reopen that one or close both ;) Thanks. -- What|Removed |Added ---

[Bug java/12760] Binary Compatibility: moving a method into a superinterface

--- Additional Comments From aph at gcc dot gnu dot org 2004-10-20 15:58 --- Job done. -- What|Removed |Added Status|NEW |RESOLVED

[Bug java/12725] [meta-bug] gcj does not conform to Binary Compatibility specification

-- Bug 12725 depends on bug 12760, which changed state. Bug 12760 Summary: Binary Compatibility: moving a method into a superinterface http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12760 What|Old Value |New Value --

[Bug libgcj/13606] need extra runtime verification of compiled code

--- Additional Comments From aph at gcc dot gnu dot org 2004-10-20 15:59 --- Job done. -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug libgcj/13603] [meta-bug] Java security model tracking PR

-- Bug 13603 depends on bug 13606, which changed state. Bug 13606 Summary: need extra runtime verification of compiled code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13606 What|Old Value |New Value -

[Bug java/12725] [meta-bug] gcj does not conform to Binary Compatibility specification

-- Bug 12725 depends on bug 13606, which changed state. Bug 13606 Summary: need extra runtime verification of compiled code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13606 What|Old Value |New Value -

[Bug java/12759] Binary compatibility: rip out -fno-assume-compiled

--- Additional Comments From aph at gcc dot gnu dot org 2004-10-20 16:02 --- This is fairly low priority because it doesn't really affect anything. However, removing no-assume-compiled could cause considerable lossage. For the time being, we could simply remove the command line option.

[Bug java/12757] Binary Compatibility: overlap between constant pool and tables

-- What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12757

[Bug fortran/18082] Excessively long compile time

--- Additional Comments From reichelt at gcc dot gnu dot org 2004-10-20 16:04 --- Confirmed. Reduced testcase: = subroutine FOO ( X ) character(len=*), intent(IN) :: X character(len=len(X)) :: C1, C2 C1 = '' C2 = '' end subroutine

[Bug libgcj/13604] AccessController unfinished

--- Additional Comments From aph at gcc dot gnu dot org 2004-10-20 16:16 --- Is there any special reason why this patch is unreviewed? Might it make things worse? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13604

[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

[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++/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++/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 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 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 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 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++/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 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 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 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/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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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/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/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/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/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: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 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/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 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 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: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 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 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 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 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 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) (

  1   2   >