[Bug tree-optimization/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

--- Additional Comments From vda at port dot imtp dot ilyichevsk dot odessa dot ua 2005-06-23 06:59 --- Created an attachment (id=9131) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9131&action=view) While we are at it, speed up ix86_data_alignment All if()s below are true only if

[Bug tree-optimization/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

--- Additional Comments From vda at port dot imtp dot ilyichevsk dot odessa dot ua 2005-06-23 06:04 --- Created an attachment (id=9130) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9130&action=view) Same patch with slightly different formatting Also run tested -- http://gcc.g

[Bug tree-optimization/22158] char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

--- Additional Comments From vda at port dot imtp dot ilyichevsk dot odessa dot ua 2005-06-23 06:03 --- Created an attachment (id=9129) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9129&action=view) Do not align at all if -Os Sorry only have 3.4.1 sources available locally... Pa

[Bug tree-optimization/22158] New: char global_var[] = "larger than 32 bytes"; uses silly amounts of alignment even with -Os

static char *s0 = ""; static char s1[] = ""; static char *s2 = ""; static char s3[] = ""; void f(char*); v

[Bug tree-optimization/22157] [4.0/4.1 Regression] struct copying code gen

-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22157

[Bug middle-end/22156] [4.0/4.1 Regression] bit-field copying regressed

-- What|Removed |Added BugsThisDependsOn||22157 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22156

[Bug tree-optimization/22157] New: [4.0/4.1 Regression] struct copying code gen

Take the following code: struct s { short t; short y1; }; void f(struct s *x, struct s *y) { struct s t = *x; *y = t; } In 3.4.0, we produced: _f: lwz r0,0(r3) stw r0,0(r4) blr but in 4.0.0 and above: _f: lhz r2,2(r3) lha r0,0(r3) sth r2,2(r

[Bug middle-end/22156] [4.0/4.1 Regression] bit-field copying regressed

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 05:11 --- The main difference between the C++ front-end and the C front-end in this respect is how they repesent bit-fields. for the C++ front-end we get the following output from SRA: Cannot scalarize variable D.16

[Bug c++/22154] [DR 382] qualified names should allow typename keyword in front of it (even in non-templates)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 05:05 --- Oh and I thought I saw a bug or two about this before. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22154

[Bug middle-end/22156] [4.0/4.1 Regression] bit-field copying regressed

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 05:04 --- Note this also effects PPC, though not as badly as there is only one load: in 3.3.3: _f: lwz r0,0(r4) stw r0,0(r3) blr in 4.0.0 and above: _f: lwz r11,0(r4) lwz r0,0(

[Bug middle-end/22156] New: [4.0/4.1 Regression] bit-field copying regressed

Take the following code: struct s { int i1:1; int i2:1; int i3:1; }; void f(struct s *x, struct s *y) { *x = *y; } In 3.4.0 (and currently with the C++ compiler too), we were able to get optimal code: movl8(%esp), %eax movl(%eax), %edx movl4(%esp), %eax

[Bug middle-end/19466] [meta-bug] bit-fields are non optimal

-- What|Removed |Added BugsThisDependsOn||22156 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19466

[Bug libmudflap/22155] ICE with: "-fmudflap -D_GLIBCXX_DEBUG"

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 04:43 --- I thought there was a bug about something like this before (and it was fixed too) but I cannot find it right now, maybe I am not looking hard enough. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=2215

[Bug libmudflap/22155] New: ICE with: "-fmudflap -D_GLIBCXX_DEBUG"

I get an ICE for gcc 4.0.0 when trying to use mudflap and libstdc++ debug mode together; This is the smallest testcase I could make: test.cc: """ #include struct S { unsigned i; }; void g(const unsigned u, std::vector& s); void f(const S& s) { std::vector > t(1); g(s.i,t[0]); } """ $ g++

[Bug c++/22154] [DR 382] qualified names should allow typename keyword in front of it (even in non-templates)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 04:28 --- Suspend this as it only in the ready state. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22154

[Bug c++/22154] [DR 382] qualified names should allow typename keyword in front of it (even in non-templates)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 04:27 --- Confirmed, to ... -- What|Removed |Added Status|UNCONFIRMED |NEW

[Bug c++/22154] New: [DR 382] qualified names should allow typename keyword in front of it (even in non-templates)

The following should compile according to this DR report (but it is only in ready state so I am going to confirm it and then suspend it): class a {}; typename ::a f(); Also the following should not compile as a is not qualified then: class a {}; typename a f(); -- Summary: [DR 382]

[Bug c++/6273] [4.0/4.1 regression] User-defined operator+ and use of enum values in computation of array bounds

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 03:47 --- (In reply to comment #7) > - > template struct X { > enum { N = 10 }; > int items[N+1]; > }; > template int operator+(A,B); > X x

[Bug c++/22147] [4.1 regression] ICE in get_bindings

--- Additional Comments From bangerth at dealii dot org 2005-06-23 02:45 --- Is this really valid? class Y is undeclared at the point of the friend declaration... W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22147

[Bug c++/16635] g++ instantiates templates at the wrong place

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 01:27 --- (In reply to comment #6) > (In reply to comment #5) > > Here's the same thing with overloaded functions, causing a wrong-code > > error. If the last definition of > > 'bar' is commented out, the testcase

[Bug c++/16635] g++ instantiates templates at the wrong place

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 01:19 --- (In reply to comment #5) > Here's the same thing with overloaded functions, causing a wrong-code error. > If the last definition of > 'bar' is commented out, the testcase passes, but otherwise not. That c

[Bug c/20631] Support -std=c90 as alias for -std=c89

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-23 00:21 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)

--- Additional Comments From guardia at sympatico dot ca 2005-06-22 22:59 --- Thanks to Uros and everybody! -- What|Removed |Added Status|RESOLVED

[Bug translation/21364] [4.0/4.1 regression] [translation] %J in translation instead of %H causes ICE in de.po

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-22 22:34 --- Fixed in gcc 4.0.1 and mainline by the new .po file. -- What|Removed |Added St

[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 22:17 --- Fixed. -- What|Removed |Added Status|WAITING |RESOLVED

[Bug c++/22153] [3.4/4.0/4.1 regression] ICE on invalid template specialization

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 22:10 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)

--- Additional Comments From guardia at sympatico dot ca 2005-06-22 21:59 --- Yup, excited, today, I just compiled the mainbranch to check this out (gcc-4.1-20050618) and it seems to be fixed! I don't see any strange movlps in any of the code I tried to compile with it. Can be moved to F

[Bug c++/22153] New: [3.4/4.0/4.1 regression] ICE on invalid template specialization

Since GCC 3.4.0 we get an ICE on the following invalid code snippet: === template void foo(); template struct A { template<> friend void foo<0>(); }; === bug.cc:5: error: invalid explicit specialization before '>' token

[Bug c++/22147] [4.1 regression] ICE in get_bindings

--- Additional Comments From reichelt at gcc dot gnu dot org 2005-06-22 21:41 --- Confirmed. Reduced testcase: template struct A; template void foo(A* p) { *p; } template struct A { friend void foo(A*); }; void bar() { foo(0);

[Bug AWT/19840] drawImage bug

--- Additional Comments From mark at gcc dot gnu dot org 2005-06-22 21:29 --- This seems to have been fixed in GNU Classpath by Sven de Marothy. http://fitzsim.org/blog/?p=5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19840

[Bug libstdc++/22111] [4.0 Regression] libstdc++ abi_check

--- Additional Comments From themis_hv at yahoo dot co dot uk 2005-06-22 20:53 --- Fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED

[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-06-22 20:50 --- Subject: Re: [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506 On Wed, 2005-06-22 at 20:13 +, bkoz at gcc dot gnu dot org wrote: > --- Additional Comments From bko

[Bug bootstrap/17383] [4.0 Regression] Building in src dir fails

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-22 20:49 --- Subject: Bug 17383 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-06-22 20:42:06 Modified files: . : Change

[Bug libstdc++/22111] [4.0 Regression] libstdc++ abi_check

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-22 20:47 --- Subject: Bug 22111 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-06-22 20:39:41 Modified files: libstdc++-v3 : Change

[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 20:29 --- (In reply to comment #11) > Can somebody do a binary search and find out what patch or patches broke this? No need to as it is obvious what caused it as the person who caused it already commented on this, i

[Bug target/22076] Strange code for MMX register moves

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 20:27 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW E

[Bug target/22076] Strange code for MMX register moves

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

[Bug target/22152] Poor loop optimization when using mmx builtins

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 20:26 --- This comes down to PR 14552 and PR 19161. Since this is MMX code, it is very hard to get correct as GCC does not currently output emms and vector code without you doing it which is what PR 19161 is abou

[Bug libfortran/22124] eoshift with dim=2 fails

--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-22 20:18 --- (In reply to comment #3) > Um, Thomas, PR 21592 which you claim this is a duplicate of, is a C++ front > end bug. Did you mean that? No, I meant 21594. Thomas -- http://gcc.gnu.org/bugzilla/show_bug.

[Bug rtl-optimization/22152] Poor loop optimization when using mmx builtins

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 20:16 --- This is a MMX builtin and not a SSE builtin. -- What|Removed |Added GCC build triplet|apple

[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506

--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 20:13 --- Can somebody do a binary search and find out what patch or patches broke this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22071

[Bug rtl-optimization/22152] New: Poor loop optimization when using sse2 builtins - regression from 3.3

In the following trivial test case, gcc-4.1 produces very ineffecient code for the loop. gcc-3.3 produces much better code. typedef int __m64 __attribute__ ((__vector_size__ (8))); __m64 unsigned_add3( const __m64 *a, const __m64 *b, unsigned long count ) { __m64 sum;

[Bug libstdc++/22111] [4.0 Regression] libstdc++ abi_check

--- Additional Comments From mark at codesourcery dot com 2005-06-22 19:46 --- Subject: Re: [4.0 Regression] libstdc++ abi_check bkoz at gcc dot gnu dot org wrote: > --- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 > 18:17 --- > > I'd like to move this to

[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-06-22 19:23 --- Subject: Re: [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506 On Wed, 2005-06-22 at 19:02 +, pinskia at physics dot uc dot edu wrote: > --- Additional Comments Fr

[Bug c++/22149] func pointer non-type template parm invalid access control

-- What|Removed |Added Known to fail||2.95.3 3.0.4 3.2.3 3.3.3 ||3.4.0 4.0.0 4.1.0 http://gcc.gnu.org

[Bug SWING/22151] New: JInternalFrame causes OutOfMemory error when maximized.

JInternalFrame causes OutOfMemory error when maximized. Run the test case below, maximize the JInternalFrame, wait a while. OutOfMemory error. When the JInternalFrame is positioned at (10,10) rather than (60,60) the error doesn't occur. ==TEST CASE== import java.awt.*; import javax.swing.*; i

[Bug SWING/22150] BasicTreeUI Implementation

--- Additional Comments From langel at redhat dot com 2005-06-22 19:06 --- I am working on this! -- What|Removed |Added Status|UNCONFIRMED |ASSIG

[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506

--- Additional Comments From pinskia at physics dot uc dot edu 2005-06-22 19:02 --- Subject: Re: [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506 On Jun 22, 2005, at 2:59 PM, bkoz at gcc dot gnu dot org wrote: > > --- Additional Comments From bkoz at g

Re: [Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506

On Jun 22, 2005, at 2:59 PM, bkoz at gcc dot gnu dot org wrote: --- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 18:59 --- Ah, the old "can't find the tunnel at the end of the bridge at the end of this hole" problem. Bummer. I hate it when that happens. Is the

[Bug SWING/22150] New: BasicTreeUI Implementation

Implementation not complete -- Summary: BasicTreeUI Implementation Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: SWING AssignedTo: langel at redhat dot com Report

[Bug c++/22149] New: func pointer non-type template parm invalid access control

I notice that program1 (the 1st program attached below) fails to compile, but very similar programs 2 and 3 (attached further below) do. The only difference being related to how the non-type template parameter is declared "void (*FOOBAR) ()" vs "void FOOBAR ()" vs "void (&FOOBAR) ()". /cygdrive/d

[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506

--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 18:59 --- Ah, the old "can't find the tunnel at the end of the bridge at the end of this hole" problem. Bummer. I hate it when that happens. Is there an easier way than -O0 to revert back to the old behavior? -- h

[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506

--- Additional Comments From dberlin at gcc dot gnu dot org 2005-06-22 18:54 --- Subject: Re: [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506 On Wed, 2005-06-22 at 17:59 +, bkoz at gcc dot gnu dot org wrote: > --- Additional Comments From bko

[Bug fortran/21034] [4.0 only] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036

-- What|Removed |Added Keywords||ice-on-valid-code Summary|internal compiler error: in |[4.0 only] internal compiler

[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036

-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pbrook at gcc dot gnu dot |dot org |org Status|REOPENED

[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036

--- Additional Comments From pbrook at gcc dot gnu dot org 2005-06-22 18:51 --- Reopening until 4.0 is unforzen and the patch applied there -- What|Removed |Added

[Bug target/22148] gcc.dg/vect/vect-reduc-1* fail

-- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Keywords|

[Bug libstdc++/22111] [4.0 Regression] libstdc++ abi_check

--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 18:17 --- I'd like to move this to gcc-4_0-branch. -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22111

[Bug target/22148] New: gcc.dg/vect/vect-reduc-1* fail

The following FAILs have appeared on ia64-hpux (both -milp32 and -mlp64) on mainline on 20050622. gcc-testresults shows them also on ia64-linux. FAIL: gcc.dg/vect/vect-reduc-1char.c (test for excess errors) FAIL: gcc.dg/vect/vect-reduc-1.c (test for excess errors) The first is a new test. The

[Bug c++/22147] [4.1 regression] ICE in get_bindings

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

[Bug c++/22147] New: [4.1 regression] ICE in get_bindings

The following code ICEs: // Line 1 class A { public: A() { }; ~A() { }; }; class B { public: B(); B(const A& a) { }; ~B(); }; template class T; template T* func(T* p); template class T { X*m_; public: T(X* x) : m_(x) { }; ~T() { }; friend T* func(T* p); }; tem

[Bug tree-optimization/22071] [4.1 regression] ICE in first_vi_for_offset, at tree-ssa-structalias.c:2506

--- Additional Comments From bkoz at gcc dot gnu dot org 2005-06-22 17:59 --- I am running into this as well. Turning off all optimizations (-O0) allows compilation, anything over -O1 hits it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22071

[Bug fortran/22146] ICE when calling ELEMENTAL subroutines

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 17:52 --- Confirmed. here is the backtrace: #0 0x080a7931 in gfc_conv_function_call (se=0xbfe81c08, sym=0xa52cf80, arg=0xa52d5b8) at /home/peshtigo/pinskia/src/gnu/gcc/src/gcc/fortran/trans-expr.c:1287 #1 0x080

[Bug fortran/22146] New: ICE when calling ELEMENTAL subroutines

$ cat gfortranbug.f90 module buggy contains elemental subroutine foo(a) integer, intent(out) :: a a = 0 end subroutine foo subroutine bar() integer :: a(10) call foo(a) end subroutine bar end module buggy $ gfortran41 -c gfortranbug.f90 gfortra

[Bug tree-optimization/22122] [4.1 Regression] -ftree-vectorize ICE get_loop_body, at cfgloop.c:819

--- Additional Comments From marcus at jet dot franken dot de 2005-06-22 17:26 --- gcc-Version 4.1.0 20050622 (experimental) ../BIN/bin/gcc -ftree-vectorize -O2 -c ~/thread.i /home/marcus/thread.i: In function 'f': /home/marcus/thread.i:2: internal compiler error: in get

[Bug target/21571] ICE in rs6000.c with -msdata=default.

-- What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21571

[Bug target/21571] ICE in rs6000.c with -msdata=default.

-- What|Removed |Added GCC build triplet|i686-pc-linux-gnu | GCC host triplet|i686-pc-linux-gnu | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21571

[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036

--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-06-22 16:03 --- What about 4.0? Right now, we've been trying to keep all patches applied on both branches. Doesn't this bug happen on 4.0 too? -- What|Removed |Added --

[Bug target/21571] ICE in rs6000.c with -msdata=default.

--- Additional Comments From osv at javad dot ru 2005-06-22 16:00 --- Reproducible on 4.1.0 (mainline) by adding -ffast-math to the command-line: $ ppc-eabi-gcc -v -msdata=default -ffast-math -c test.cc -o test.o Using built-in specs. Target: ppc-eabi Configured with: ../../gcc/configure

[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036

--- Additional Comments From pbrook at gcc dot gnu dot org 2005-06-22 16:00 --- Fixed. -- What|Removed |Added Status|NEW |RESOLVED

[Bug fortran/21034] internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3036

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-22 15:34 --- Subject: Bug 21034 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-22 15:34:02 Modified files: gcc/fortran: ChangeLog symbol.c gcc/tests

[Bug rtl-optimization/20945] about 2x perfomance regression in comparision with 3.4.2

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 14:37 --- I think this is the normal register pressure issue in GCC's RA. See for a discussion which will happen later today. -- What

[Bug fortran/20945] about 2x perfomance regression in comparision with 3.4.2

--- Additional Comments From denis dot nagorny at intel dot com 2005-06-22 14:34 --- Ok. It seems like this issue is mostly fixed now. I incresead NIT counter up to 200 and obtained following results: 3.4.2 ~ 3.4s old 4.0 ~ 6.4s mainline ~ 4.0s -- http://gcc.gnu.org/bugzilla/show_b

[Bug libfortran/22124] eoshift with dim=2 fails

--- Additional Comments From bangerth at dealii dot org 2005-06-22 14:09 --- Um, Thomas, PR 21592 which you claim this is a duplicate of, is a C++ front end bug. Did you mean that? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22124

[Bug middle-end/20593] [4.0 Regression] Simple array of string access miscompiled on x86 and x86_64 and PPC

--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-06-22 13:38 --- Subject: Bug 20593 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-06-22 13:38:25 Modified files: gcc: ChangeLog varasm.c Log message:

[Bug middle-end/20593] [4.0 Regression] Simple array of string access miscompiled on x86 and x86_64 and PPC

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 13:37 --- I committed the patch to the mainline after testing and will commit to the 4.0 branch once reopened so mine. -- What|Removed |Added

[Bug target/22145] New: /usr/include/objc/objc-runtime.h on powerpc-darwin7.8.0 needs fixed included

For Obj-C++, /usr/include/objc/objc-runtime.h contains Class class; which will not work with Obj-C++ at all. This causes testsuite failures and causes you not to be able to compile almost any obj-C++ program. -- Summary: /usr/include/objc/objc-runtime.h on powerpc-darwin7.8.0

[Bug middle-end/22141] [4.0/4.1 Regression] Missing optimization when storing structures

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 13:07 --- Reduced testcase for the regression: typedef struct type { char a; char b; char c; char d; } type_t; type_t u; void f(void) { u = (type_t){ 1, 2, 3, 4}; } 3.3 produced: lis r0,0x102

[Bug libfortran/22144] New: eoshift1, eoshift3, cshift1 lack memory allocation

$ cat cshift-alloc.f90 program main implicit none integer, dimension (:,:),allocatable :: a integer, dimension (3) :: sh integer :: i allocate (a(3,3)) a = reshape((/(i,i=1,9)/),shape(a)) sh = (/ 2, -1, -2 /) write(*,fmt='(10I5)') cshift(a, shift=sh) end program main $ gfortran cs

[Bug libfortran/22143] New: missing kinds 1 and 2 for eoshift and cshift

$ cat shift-kind.f90 program main implicit none integer, dimension (3,3) :: a, b, w integer(kind=2), dimension (3) :: sh2 integer(kind=1), dimension (3) :: sh1 integer, dimension(3) :: bo integer :: i,j a = reshape((/(i,i=1,9)/),shape(a)) sh1 = (/ -3, -1, 3 /) sh2 = (/ -3, -1, 3

[Bug middle-end/17965] ice in expand_call

--- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-22 12:07 --- Patch was posted here: -- What|Removed |Added --

[Bug c++/21592] [3.4/4.0/4.1 Regression] ICE in resolve_overloaded_unification/arg_assoc

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

[Bug libfortran/22124] eoshift with dim=2 fails

--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-22 11:42 --- This is a duplicate of 21592. The problem is that we are really running off the end here, as Andrew suggested. *** This bug has been marked as a duplicate of 21592 *** -- What|Removed

[Bug fortran/21594] FAIL: gfortran.dg/eoshift.f90 -O0 execution test

--- Additional Comments From tkoenig at gcc dot gnu dot org 2005-06-22 11:41 --- This can be made to fail on any architecture by increasing the amount of shifting: $ cat eoshift-really-fails.f90 program main character(len=20) line write (line,'(I4)') eoshift((/1, 3/), 1000) end prog

[Bug libfortran/22142] New: eoshift: boundary not filled in correctly

Another corner case of eoshift that's not correct... in eoshift3, this time. $ cat eoshift.f90 program main implicit none integer, dimension (3,3) :: a, b, w integer, dimension (3) :: bo, sh integer :: i,j a = reshape((/(i,i=1,9)/),shape(a)) sh = (/ 3, -1, -3 /) bo = (/-999, -99, -9

[Bug tree-optimization/22122] [4.1 Regression] -ftree-vectorize ICE get_loop_body, at cfgloop.c:819

--- Additional Comments From hubicka at ucw dot cz 2005-06-22 11:12 --- Subject: Re: [4.1 Regression] -ftree-vectorize ICE get_loop_body, at cfgloop.c:819 > > --- Additional Comments From pinskia at gcc dot gnu dot org 2005-06-21 > 12:51 --- > Hmm, reconfirmed, then. Strange

[Bug c/22141] New: Missing optimization when storing structures

In the attached example, the store of type_t is not optimized by gcc. Instead of storing one 32-bit value, four 8-bit values are stored. gcc-4.0.1 produces the following code: /home/fm3/foo.c:16 80483b7: c6 05 13 96 04 08 04movb $0x4,0x8049613 80483be: c6 05 12 96 04 0

[Bug target/14552] compiled trivial vector intrinsic code is ineffiencent

--- Additional Comments From uros at kss-loka dot si 2005-06-22 10:14 --- Just for fun, I have compiled the testcase with MMX/x87 mode switching patch included, to check MMX vector extensions. This little patch is needed to enable MMX vector extensions (only MMX vector add expander is

[Bug target/19530] MMX load intrinsic produces SSE superfluous instructions (movlps)

--- Additional Comments From uros at kss-loka dot si 2005-06-22 07:02 --- As this bug is getting a bit confused, I have summarised testcases below: --cut here-- #include __m64 moo_1 (int i) { __m64 tmp = _mm_cvtsi32_si64 (i); return tmp; } __m64 moo_2 (__m64 mmx1) { __m64 mmx2 =