[Bug target/19411] Simple program causes gcc to run out of memory

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 06:22 --- Fixed in 4.1.0 and above by: 2005-05-02 Paolo Bonzini <[EMAIL PROTECTED]> * c-common.c (resolve_overloaded_builtin): Forward to target hook for BUILT_IN_MD built-ins. --

[Bug bootstrap/21230] [4.0/4.1 Regression] bootstrap failed unless bootstrap compiler is gcc.

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 06:11 --- *** Bug 21411 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug bootstrap/21411] Bug in configure script for libcpp

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 06:11 --- *** This bug has been marked as a duplicate of 21230 *** -- What|Removed |Added

Re: Double backslashes in fixincl header (__FD_ZERO macro)

Bruce Korb wrote: > Frank wrote: > > gcc-3.4.3 contains an incorrect header fix for "the __FD_ZERO macro > > present in glibc 1.x". The file installed in > > /lib/gcc/i686-pc-linux-gnulibc1/3.4.3/include/gnu/types.h > > contains the following, with spurious double-backslashes: > [[...]] > > This p

[Bug preprocessor/21410] Infinite memory usage in preprocessor

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-05-06 04:39 --- gamdit.h:2426: #define ___FIXADDP(x,y)x)^(y))&___FIX(___MIN_FIX))<=(((y)^((x)+(y)))&___FIX(___MIN_FIX))?___FIXADD(x,y):___FAL) test2.c:3500: ___SET_R2(___FIXADDP(___FIXADDP(___FIXADDP(___FIXA

[Bug bootstrap/21411] New: Bug in configure script for libcpp

C compiler used : Sun Studio 10 Here how I configured gcc : /usr/local/inst/gcc-4.0.0/configure --prefix=/usr/local/gnu --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-languages=c,c++ The 'make bootstrap' step of the build process fails. I am using the proper version of GNU make,tar

[Bug libgcj/21058] [4.1 Regression] libgcj can't find class

--- Additional Comments From green at redhat dot com 2005-05-06 03:21 --- *** Bug 20693 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug libgcj/20693] [4.1 Regression] javax-imageio.lo failed to build

--- Additional Comments From green at redhat dot com 2005-05-06 03:21 --- *** This bug has been marked as a duplicate of 21058 *** -- What|Removed |Added Statu

[Bug tree-optimization/21380] [4.0 Regression] ICE compiling with -O

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-06 03:04 --- Subject: Bug 21380 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-06 03:04:16 Modified files: gcc: Change

[Bug java/21070] [4.1 Regression]: java compiler generates wrong code on ia64

--- Additional Comments From hjl at lucon dot org 2005-05-06 02:48 --- Which binutils are you using? It looks like this problem http://sourceware.org/ml/binutils/2005-04/msg00011.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21070

Double backslashes in fixincl header (__FD_ZERO macro)

Frank wrote: > gcc-3.4.3 contains an incorrect header fix for "the __FD_ZERO macro > present in glibc 1.x". The file installed in > /lib/gcc/i686-pc-linux-gnulibc1/3.4.3/include/gnu/types.h > contains the following, with spurious double-backslashes: [[...]] > This patch fixes the issue for me: > >

[Bug preprocessor/21410] New: Infinite memory usage in preprocessor

You guys will like this one ... The most recent test is with 4.0.0 on Red Hat Enterprise Linux 4.0, but it also happens with 3.4.3 and 4.0.0 on sparc-sun-solaris2.9. In http://www.math.purdue.edu/~lucier/bugzilla/6/ you'll find compressed versions of test2.c and gambit.h. With this command lin

[Bug fortran/21409] Attached fortran 95 code generates error

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 01:24 --- Reduced testcase (I tried not to reduce it too much): subroutine difq3 (jmax, ngmax, ams) implicit none integer*4 :: jmax, ngmax real*8, dimension(32) :: ams real*8, dimension

[Bug fortran/21409] Attached fortran 95 code generates error

--- Additional Comments From joe at confucius dot gnacademy dot org 2005-05-06 00:59 --- Created an attachment (id=8826) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8826&action=view) Sample fortran file which generates error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=214

[Bug fortran/21409] New: Attached fortran 95 code generates error

[EMAIL PROTECTED] hcol]$ gfortran -c difq3.F -o difq3.o In file difq3.F:693 ams(1:ngmax)= 1 Error: The FORALL with index 'j' cause more than one assignment to this object at (1) In file difq3.F:696 p2m(1:ngmax)=0.5d0*(3.0d0*ams(1:ngmax)-1d0) 1 Error: The

[Bug target/21408] DAZ related macros are improperly guarded in pmmintrin.h

-- What|Removed |Added Component|c |target Keywords||ssemmx http://gcc.gnu.org/bugzilla/show_bug.cgi?id=214

[Bug c/21408] New: DAZ related macros are improperly guarded in pmmintrin.h

In GCC's version of pmmintrin.h we have: #ifdef __SSE3__ #include #include /* Additional bits in the MXCSR. */ #define _MM_DENORMALS_ZERO_MASK 0x0040 #define _MM_DENORMALS_ZERO_ON 0x0040 #define _MM_DENORMALS_ZERO_OFF 0x #define _MM_SET_DENORMALS_ZERO_MODE(mode)

[Bug tree-optimization/21407] [4.1 Regression] wrong code with upcast in C++

--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-05-06 00:27 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED

[Bug tree-optimization/21407] [4.1 Regression] wrong code with upcast in C++

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-06 00:25 --- Oh, I got the idea for this testcase after ssb asked about what the kernel was doing was valid and his example code but unlike that code, this is valid as C++ works slightly different than C. -- http:

[Bug tree-optimization/21407] [4.1 Regression] wrong code with upcast in C++

-- What|Removed |Added Target Milestone|--- |4.1.0 Version|4.0.0 |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21407

[Bug tree-optimization/21407] New: [4.1 Regression] wrong code with upcast in C++

The is huge bug which effects a large amount of C++, we should not abort. extern "C" void abort(void); struct T1 {int a, b; virtual void f(){}}; struct T : T1 { struct T1 w; int b; }; void foo (struct T1 *p) { struct T *q = dynamic_cast(p); if (q->b != 2) abort (); } int main () { struct T c; c.b

[Bug c++/21405] Template inlines have global visibility

--- Additional Comments From mike at navi dot cx 2005-05-06 00:17 --- No, there is very definitely a bug here even if it's just in the documentation. The GCC docs say in very clear and unambiguous terms that this will work, by design. Not by accident, by design. That's the whole point of

[Bug target/21195] SSE intrinsics not inlined, sometimes.

--- Additional Comments From tbptbp at gmail dot com 2005-05-05 23:58 --- For future reference, i'm including my end-user offline answer to Uros regarding always_inline usage. Here we go: > I was trying to take a quick look at your bugreport regarding > always_inline attrubite. Just a q

[Bug c++/21352] [3.4 Regression] ICE with passing template function type as template type

--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-05-05 23:35 --- This code is not valid (it tries to use a non-static member function, without taking its address to form a pointer-to-member). The ICE has been fixed in 4.0.1 and 4.1. This bug will not be fixed in 3.4.x.

[Bug c++/21352] [3.4/4.0/4.1 Regression] ICE on valid code with passing template function type as template type

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-05 23:30 --- Subject: Bug 21352 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-05 23:30:27 Modified files: gcc/cp : Change

[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran

-- Bug 19292 depends on bug 18781, which changed state. Bug 18781 Summary: [ICE] WRITE with FMT from CHARACTER array http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18781 What|Old Value |New Value

[Bug fortran/15966] ICE and segmentation fault on internal write

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 23:26 --- *** Bug 21406 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug fortran/15966] ICE and segmentation fault on internal write

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 23:26 --- *** Bug 21406 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug fortran/18834] ICE on reading from internal file character array

-- Bug 18834 depends on bug 18781, which changed state. Bug 18781 Summary: [ICE] WRITE with FMT from CHARACTER array http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18781 What|Old Value |New Value

[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran

-- Bug 19276 depends on bug 18781, which changed state. Bug 18781 Summary: [ICE] WRITE with FMT from CHARACTER array http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18781 What|Old Value |New Value

[Bug fortran/21406] gfortran barfs on READ line

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 23:26 --- *** This bug has been marked as a duplicate of 15966 *** -- What|Removed |Added

[Bug fortran/15966] ICE and segmentation fault on internal write

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 23:26 --- *** Bug 18781 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug fortran/18781] [ICE] WRITE with FMT from CHARACTER array

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 23:26 --- *** This bug has been marked as a duplicate of 15966 *** -- What|Removed |Added

[Bug fortran/21406] New: gfortran barfs on READ line

I'm trying to use gfortran version "GNU Fortran 95 (GCC 4.0.0)" on an Opteron system: Linux nika 2.6.11.7 #1 SMP Wed Apr 13 13:55:17 AKDT 2005 x86_64 GNU/Linux I'm building NCAR Graphics, which is a large Fortran 77 and C based software package. This software builds under various versions of g7

[Bug rtl-optimization/21254] [4.0/4.1 regression] Incorrect code with -funroll-loops for multiple targets with same code

--- Additional Comments From rakdver at gcc dot gnu dot org 2005-05-05 22:50 --- http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00448.html -- What|Removed |Added Key

[Bug c++/21405] Template inlines have global visibility

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 22:40 --- So here is the story really global templates have aways global visibility in C++ so this is not a bug in GCC or binutils. This is a bug in how you think that you can use two different versions. --

[Bug c++/21405] Template inlines have global visibility

--- Additional Comments From mike at navi dot cx 2005-05-05 22:39 --- I don't understand what you mean. There's definitely a bug here because a configuration that the docs say should work, causes mysterious crashes due to mis-binds of symbols. I suspect building with -fvisibility-inlines-

[Bug target/14839] configure does not check for the presence of 32bits libc with --disable-multilib

--- Additional Comments From gary at intrepid dot com 2005-05-05 22:32 --- I ran into this recently, and also would like to see configure auto-detect the lack of 32 bit libs. That failing, perhaps the install documentation at http://gcc.gnu.org/install/specific.html#x86-64-x-x can be u

[Bug c++/21405] Template inlines have global visibility

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 22:27 --- I don't know if this is really a vaild bug, as the standard requires the inline function as the same so it would be undefined if they are different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21405

[Bug c++/21405] New: Template inlines have global visibility

See http://gcc.gnu.org/ml/libstdc++/2005-04/msg00173.html If you have code like: std::string b = "bee"; std::string c = "see"; std::string a = b + c; Then the string + operator overload will appear in the final ELF image with GLOBAL WEAK visibility, meaning it can be bound to the wrong version

[Bug rtl-optimization/16613] [3.4/4.0 Regression] compile time regression, when adding cerr usage

--- Additional Comments From andre dot maute at gmx dot de 2005-05-05 20:12 --- i want to supplement my compile time tests which shows that a regression was introduced between 2005/03/26 an 2005/04/02 > g++-4.0-20050402 -v Using built-in specs. Target: i686-pc-linux-gnu Conf

[Bug fortran/20925] "Possible frontend bug: array constructor not expanded"

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 20:12 --- *** Bug 21394 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug fortran/21394] Internal compiler error, possibly due to large parameter array

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 20:12 --- *** This bug has been marked as a duplicate of 20925 *** -- What|Removed |Added

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

--- Additional Comments From pinskia at physics dot uc dot edu 2005-05-05 20:06 --- Subject: Re: [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception" On May 5, 2005, at 4:03 PM, tsv at solvo dot ru wrote: > I am trying to find out where unaligned poi

Re: [Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

On May 5, 2005, at 4:03 PM, tsv at solvo dot ru wrote: I am trying to find out where unaligned pointer is came from. Going couple functions back I found that it is the address if "unsigned char" variable allocated on stack. Should I look at this issue or it might be possible in theory and I shou

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

--- Additional Comments From tsv at solvo dot ru 2005-05-05 20:03 --- (In reply to comment #20) > (In reply to comment #19) > > Should not be some warning to be generated? > > There is a warning if going directly from char * to the union pointer but since you go through a void > pointer

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 19:22 --- (In reply to comment #19) > Should not be some warning to be generated? There is a warning if going directly from char * to the union pointer but since you go through a void pointer, the warning is gone.

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

--- Additional Comments From tsv at solvo dot ru 2005-05-05 19:16 --- I just extracted it from "dbus" package which I am testing on linux/alpha platform. There are other packages (mozilla one of them) that started to generate unaligned access exceptions then built by gcc 4.0. Should not

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 19:10 --- (In reply to comment #17) > gcc version 4.0.0 20050423 (Red Hat 4.0.0-2) > > Here is another test case that generates unaligned access exception: That code is invalid due to the alignment requirements in s

[Bug c++/21352] [3.4/4.0/4.1 Regression] ICE on valid code with passing template function type as template type

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-05 19:08 --- Subject: Bug 21352 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-05 19:08:14 Modified files: gcc/cp : ChangeLog pt.c gcc/testsuite

[Bug target/20625] [4.0/4.1 regression] ivopts produces code that generates "unaligned access exception"

--- Additional Comments From tsv at solvo dot ru 2005-05-05 19:07 --- gcc version 4.0.0 20050423 (Red Hat 4.0.0-2) Here is another test case that generates unaligned access exception: typedef union { short i16; unsigned short u16; int i3

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

--- Additional Comments From pinskia at physics dot uc dot edu 2005-05-05 18:41 --- Subject: Re: wrong-code with inlining and type-punned pointer On May 5, 2005, at 1:19 PM, schlie at comcast dot net wrote: > > --- Additional Comments From schlie at comcast dot net 2005-05-05 >

Re: [Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

On May 5, 2005, at 1:19 PM, schlie at comcast dot net wrote: --- Additional Comments From schlie at comcast dot net 2005-05-05 17:19 --- (In reply to comment #2) "unsigned char *" and "char *" are in two different aliasing sets while char and unsigned char are in the same one, well char

[Bug c/11751] wrong evaluation order of an expression

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 18:12 --- *** Bug 21404 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug rtl-optimization/21404] wrong code for array copy in while loop

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 18:12 --- This is invalid, there is no sequence point between the access of i and the increment of i so either can be first. With -W -Wall we get a warning: t.c:8: warning: operation on `i' may be undefined *** T

[Bug target/19636] Can't compile ethernut OS (avr-gcc)

--- Additional Comments From ericw at evcohs dot com 2005-05-05 18:09 --- Will someone with the requisite permissions please set this bug to NEW? This has been confirmed. Thanks Eric -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19636

[Bug tree-optimization/21380] [4.0 Regression] ICE compiling with -O

--- Additional Comments From law at redhat dot com 2005-05-05 18:01 --- I know what's causing this and I'm testing a fix now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21380

[Bug rtl-optimization/21404] wrong code for array copy in while loop

--- Additional Comments From janis at gcc dot gnu dot org 2005-05-05 17:49 --- A workaround is to replace the body of the loop with: { p[i] = q[i]; i++; } -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21404

[Bug c++/20961] [4.0/4.1 Regression] ICE on pragma weak/__attribute__((weak))

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW

[Bug fortran/21203] Segfault while compiling libgfortran/intrinsics/selected_int_kind.f90

--- Additional Comments From ericw at evcohs dot com 2005-05-05 17:25 --- (In reply to comment #2) > Bootstrapping avr-rtems w/ f95 enabled trips a similar or may-be the same bug > (also a target which probably doesn't provide REAL 8). As a side note, it is known that Fortran does not b

[Bug c++/21280] [4.0/4.1 Regression] #pragma interface, templates, and "inline function used but never defined"

--- Additional Comments From prw at ceiriog1 dot demon dot co dot uk 2005-05-05 17:23 --- Bug 21306 is not the same bug. The attached patch FIX1 fixes the test cases for this bug, but not for 21306 - you will need to look at the test case for that bug. -- http://gcc.gnu.org/bugzil

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

--- Additional Comments From schlie at comcast dot net 2005-05-05 17:19 --- (In reply to comment #2) > "unsigned char *" and "char *" are in two different aliasing sets while char > and unsigned char are in the same one, well char is every aliasing set. Then I can't help but wonder if i

[Bug middle-end/20983] [4.0 regression] varargs functions force va_list variable to stack unnecessarily

--- Additional Comments From jakub at gcc dot gnu dot org 2005-05-05 17:11 --- This could be fixed by expanding __builtin_va_start, __builtin_va_copy and __builtin_va_end in or soon after pass_stdarg. Then SRA etc. can also optimize va_list handling. On the other side, tree-stdarg.c need

[Bug rtl-optimization/21404] New: wrong code for array copy in while loop

This test case fails for GCC 3.3.x and GCC 3.4.x at any level of optimization other than -O0: extern void abort (void); char buffer[20]; void foo (char *p, const char *q) { int i = 0; while (q[i]) p[i] = q[i++

[Bug rtl-optimization/21395] Performance degradation when building code that uses MMX intrinsics with gcc-4.0.0

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 17:00 --- Note with the following code, I get back to what it is without -mmx: union b { int i[2]; __m64 j; }a; __m64 sum = _mm_set_pi32(0, 0); for (int j=0 ; j < yl ; j++) {

[Bug bootstrap/21403] New: Canadian cross build fails.

A canadian cross of the compiler failed as it tried to link fix-header. It's using a mix of build and host object files to build this. The Makefile reads: # This is nominally a 'build' program, but it's run only when host==build, # so we can (indeed, must) use $(LIBDEPS) and $(LIBS). I, however

[Bug rtl-optimization/21395] Performance degradation when building code that uses MMX intrinsics with gcc-4.0.0

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 16:53 --- Note C and C++ aliasing rules are being violated in the source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21395

[Bug libstdc++/19781] testsuite_hooks.cc doesn't test for mkfifo

--- Additional Comments From bkoz at gcc dot gnu dot org 2005-05-05 16:49 --- This indeed can be fixed. Instead of #if defined (_NEWLIB_VERSION) || defined (__MINGW32_VERSION) /* Newlib and MinGW32 do not have mkfifo. */ exit(0); #else do something like #if _GLIBCXX_HAVE_MK

[Bug rtl-optimization/21395] Performance degradation when building code that uses MMX intrinsics with gcc-4.0.0

-- What|Removed |Added GCC target triplet|i686-pc-linux-gnu configured|i686-pc-linux-gnu |with: ../gcc-4.0.0/configure| |--pref

[Bug fortran/18108] [gfortran] overloading does not work for functions

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 16:40 --- *** Bug 21401 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug fortran/21401] INTERFACE/FUNCTION problem

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 16:40 --- *** This bug has been marked as a duplicate of 18108 *** -- What|Removed |Added

[Bug middle-end/21362] ICE in make_edges, at cfgbuild.c:327

--- Additional Comments From aph at gcc dot gnu dot org 2005-05-05 16:33 --- This may be a dup of 20606 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21362

[Bug middle-end/21362] ICE in make_edges, at cfgbuild.c:327

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 16:29 --- Patch here: . -- What|Removed |Added

[Bug target/21284] [4.0/4.1 Regression] AVR target: switch/case jump table is placed in .data instead of .progmem.gcc_sw_table

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 16:25 --- Fixed. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 16:13 --- "unsigned char *" and "char *" are in two different aliasing sets while char and unsigned char are in the same one, well char is every aliasing set. -- What|Removed |Ad

[Bug target/21284] AVR target: switch/case jump table is placed in .data instead of .progmem.gcc_sw_table

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-05 15:42 --- Subject: Bug 21284 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-05-05 15:42:05 Modified files: gcc: ChangeLog gcc/config/avr : a

[Bug rtl-optimization/21402] wrong-code with inlining and type-punned pointer

--- Additional Comments From gcc at arbruijn dot dds dot nl 2005-05-05 15:38 --- Created an attachment (id=8825) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8825&action=view) C source exposing problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21402

[Bug target/21284] AVR target: switch/case jump table is placed in .data instead of .progmem.gcc_sw_table

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-05-05 15:36 --- Subject: Bug 21284 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-05-05 15:36:34 Modified files: gcc: Change

[Bug rtl-optimization/21402] New: wrong-code with inlining and type-punned pointer

The attached C source gives wrong output when compiled with inlined functions (-O3 or -O2 -finline-functions) with gcc-4.1-20050501 or gcc-4.0.0. Compiling gives the following warning twice: dereferencing type-punned pointer will break strict-aliasing rules The expected output is 0 0, the actual o

[Bug fortran/21401] New: INTERFACE/FUNCTION problem

The type of a function interface is not taken over from the MODULE PROCEDURE's which constitute the INTERFACE. ---BUG.f90--- start module interface_vs_functions_bug implicit none private interface ex1 ! fails, but should be ok module procedure func1, func2 end interface inte

[Bug rtl-optimization/19210] not using do-loop for some loops

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gcc dot gnu dot |dot org |org Status|SUSPENDED

[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 15:01 --- A slightly more reduced testcase: typedef struct __FILE FILE; extern "C" int fputs(const char *, FILE *); void f(FILE* file) throw() { const char* str = "a"; fputs(str, file); } The problem is somehow c

[Bug tree-optimization/21399] [4.1 Regression] libstdc++ 12077.cc ICE

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 14:55 --- Confirmed, reduced testcase: typedef struct __FILE FILE; extern "C" int fputs(const char *, FILE *); struct a { ~a(); }; void f(FILE* file) { a b; const char* str = "a"; fputs(str, file); } --

[Bug rtl-optimization/21254] [4.0/4.1 regression] Incorrect code with -funroll-loops for multiple targets with same code

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW

[Bug middle-end/21282] [4.1 Regression] Converting floor into lfloor built-in function

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 14:43 --- *** Bug 21400 has been marked as a duplicate of this bug. *** -- What|Removed |Added

[Bug middle-end/21400] ppc-eabisim ICE in expand_builtin_int_roundingfn

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 14:43 --- Time to update the sources. This is a dup of bug 21282. *** This bug has been marked as a duplicate of 21282 *** -- What|Removed |Added

[Bug other/21398] gcc emits invalid operands for xchgb %b0, %h0

--- Additional Comments From pluto at pld-linux dot org 2005-05-05 14:41 --- (In reply to comment #3) > (In reply to comment #2) > > in online docs i see that "q" means "byte addressable register (a,b,c,d)". > > in i386.h i see something differ for x86_64. did i miss something in doc

[Bug c/21400] New: ppc-eabisim ICE in expand_builtin_int_roundingfn

bash-2.05b$ cat tst.c extern double floor (double); int f (float minX) { return (int)floor(minX); } bash-2.05b$ ./cc1 tst.c -Os f Analyzing compilation unitPerforming intraprocedural optimizations Assembling functions: f tst.c: In function ‘f’: tst.c:6: internal compiler error: in expand_bu

[Bug tree-optimization/21399] libstdc++ 12077.cc ICE

--- Additional Comments From dje at gcc dot gnu dot org 2005-05-05 14:37 --- The failure appeared April 25. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399

[Bug tree-optimization/21399] libstdc++ 12077.cc ICE

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 14:35 --- Also happens on ppc-darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399

[Bug tree-optimization/21399] libstdc++ 12077.cc ICE

--- Additional Comments From dje at gcc dot gnu dot org 2005-05-05 14:34 --- Created an attachment (id=8824) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8824&action=view) pre-processed source for 12077.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21399

[Bug tree-optimization/21399] libstdc++ 12077.cc ICE

-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/sh

[Bug tree-optimization/21399] New: libstdc++ 12077.cc ICE

libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc ICEs when compiled on AIX: libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc : In function 'void test01()': libstdc++-v3/testsuite/ext/stdio_sync_filebuf/wchar_t/12077.cc :24: error: BB 3 can not throw but has EH edges lib

[Bug other/21398] gcc emits invalid operands for xchgb %b0, %h0

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 14:24 --- (In reply to comment #2) > in online docs i see that "q" means "byte addressable register (a,b,c,d)". > in i386.h i see something differ for x86_64. did i miss something in docs? Yes see comment #1 which

[Bug other/21398] gcc emits invalid operands for xchgb %b0, %h0

--- Additional Comments From pluto at pld-linux dot org 2005-05-05 14:22 --- in online docs i see that "q" means "byte addressable register (a,b,c,d)". in i386.h i see something differ for x86_64. did i miss something in docs? #define REG_CLASS_FROM_LETTER(C)\ ((C) == 'r'

[Bug java/21070] [4.1 Regression]: java compiler generates wrong code on ia64

--- Additional Comments From schwab at suse dot de 2005-05-05 14:14 --- I'm seeing the same error in some C++-only packages. The smallest example I could find is jikes : g++ -O2 -fmessage-length=0 -Wall -o jikes ast.o

[Bug c++/21363] no compilation error for inheriting Base class with private constructor when the constructor for Derived Class is compiler generated

--- Additional Comments From giovannibajo at libero dot it 2005-05-05 13:54 --- The compiler is allowed to generate syntectic methods as lazy as possible, which is upon the first actual use. Thus, this is not a bug. -- What|Removed |Added ---

[Bug other/21398] gcc emits invalid operands for xchgb %b0, %h0

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-05 13:49 --- "`a', b, c, or d register for the i386. For x86-64 it is equivalent to `r' class (for 8-bit instructions that do not use upper halves). " -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21398

[Bug other/21398] gcc emits invalid operands for xchgb %b0, %h0

-- What|Removed |Added CC||mmazur at kernel dot pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21398

[Bug other/21398] New: gcc emits invalid operands for xchgb %b0, %h0

the code like this: unsigned short swap16(unsigned short x) { asm volatile ("xchgb %b0, %h0" : "=q" (x) : "0" (x)); return x; } produces: swap16: xchgb %dil, %di <== %di isn't valid high 8-bit form. movzwl %di, %eax ret IIRC the %rdi, %rsi, %rsp, %rbp

  1   2   >