[Bug c/35505] New: builtins.c: 5 * set but not used

I just applied Intel C to a bootstrap build of GNU C version 4.4 snapshot 20080229. The Intel compiler said ../../src/gcc-4.4-20080229/gcc/builtins.c(2868): remark #593: variable "val" was set but never used ../../src/gcc-4.4-20080229/gcc/builtins.c(5152): remark #593: variable "c" was set but ne

[Bug target/35498] libgomp/testsuite/libgomp.c/atomic-3.c fails on ppc-linux

--- Comment #4 from jakub at gcc dot gnu dot org 2008-03-08 07:48 --- The reason why the old code without the right shift almost worked is that for the 4 byte aligned 16-bit vars each loop was executed usually twice. .L6: lha 0,0(27) lhz 8,2(26) .align 4 .L4:

[Bug target/35498] libgomp/testsuite/libgomp.c/atomic-3.c fails on ppc-linux

--- Comment #3 from jakub at gcc dot gnu dot org 2008-03-08 07:37 --- Subject: Bug 35498 Author: jakub Date: Sat Mar 8 07:36:35 2008 New Revision: 133025 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133025 Log: PR target/35498 * config/rs6000/rs6000.c (rs6000_

[Bug target/35498] libgomp/testsuite/libgomp.c/atomic-3.c fails on ppc-linux

--- Comment #2 from jakub at gcc dot gnu dot org 2008-03-08 07:31 --- Subject: Bug 35498 Author: jakub Date: Sat Mar 8 07:30:55 2008 New Revision: 133024 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133024 Log: PR target/35498 * config/rs6000/rs6000.c (rs6000_

[Bug target/25277] missed optimization for simple mmx code.

--- Comment #4 from ubizjak at gmail dot com 2008-03-08 07:29 --- Duplicate of PR 14552. *** This bug has been marked as a duplicate of 14552 *** -- ubizjak at gmail dot com changed: What|Removed |Added

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

--- Comment #22 from ubizjak at gmail dot com 2008-03-08 07:29 --- *** Bug 25277 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552

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

--- Comment #11 from ubizjak at gmail dot com 2008-03-08 07:23 --- Fixed for real. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW

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

--- Comment #8 from ubizjak at gmail dot com 2008-03-08 07:22 --- Fixed for real. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW

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

--- Comment #7 from ubizjak at gmail dot com 2008-03-08 07:21 --- For updated testcase: typedef int __m64 __attribute__ ((__vector_size__ (8))); typedef long long __v1di __attribute__ ((__vector_size__ (8))); __m64 unsigned_add3 (const __m64 * a, const __m64 * b, unsigned long count) {

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

--- Comment #6 from ubizjak at gmail dot com 2008-03-08 07:09 --- Patch at http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00517.html. New asm for the original testcase is now much better [see patch post]. -- ubizjak at gmail dot com changed: What|Removed

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

--- Comment #5 from uros at gcc dot gnu dot org 2008-03-08 07:00 --- Subject: Bug 22152 Author: uros Date: Sat Mar 8 06:59:33 2008 New Revision: 133023 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133023 Log: 2008-03-08 Uros Bizjak <[EMAIL PROTECTED]> PR target/221

[Bug c++/35159] g++ and gfortran inoperable with no error message

--- Comment #20 from jvdelisle at gcc dot gnu dot org 2008-03-08 06:06 --- This looks like bad stuff. See my separate note to see if I can get to a point of reproducing this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35159

[Bug target/35504] incorrect code generated on i386 for C++ multiple inheritance, large return structures and regparm or fastcall calling conventions

--- Comment #2 from mikulas at artax dot karlin dot mff dot cuni dot cz 2008-03-08 04:55 --- Created an attachment (id=15280) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15280&action=view) a patch for the bug A patch for gcc 4.3.0. When the function returns an aggregate value:

[Bug target/35504] incorrect code generated on i386 for C++ multiple inheritance, large return structures and regparm or fastcall calling conventions

--- Comment #1 from mikulas at artax dot karlin dot mff dot cuni dot cz 2008-03-08 04:51 --- Created an attachment (id=15279) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15279&action=view) A testcase for the bug A testcase for thunk functions with all calling conventions. It fa

[Bug target/35504] New: incorrect code generated on i386 for C++ multiple inheritance, large return structures and regparm or fastcall calling conventions

Hi When GCC generates virtual methods for objects with multiple inheritance, it creates special "thunk" functions that adjust this pointer and jump to an original method. When a member function returns a structure, the first argument is a pointer where return structure should be placed, the secon

[Bug ada/35503] New: Warning about restricted pointers?

I've again seen some code like this: sprintf(buf, "%s-%s", buf, to_add); and gcc doesn't complain, even though the declaration of sprintf is extern int sprintf (char *__restrict __s, __const char *__restrict __format, ...); Wouldn't it be possible for gcc to check the enforcement of restricted

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

--- Comment #5 from brian at dessent dot net 2008-03-07 23:48 --- Subject: Re: Documentation for -fPIC/-fpic/-fpie is not clear > I am still learning about linking and loading and I can't guess why non-PIC > DSOs would work on x86 but not on x86_64. Could you please explain briefly. >

[Bug debug/35502] -Wall should include -Wswitch-default

--- Comment #7 from jeff at schwabcenter dot com 2008-03-07 23:43 --- http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html does not list -Wswitch-default being enabled by -Wall. -- jeff at schwabcenter dot com changed: What|Removed |Added ---

[Bug debug/35502] -Wall should include -Wswitch-default

--- Comment #6 from jeff at schwabcenter dot com 2008-03-07 23:42 --- > Is there any particular reason for changing the docs, rather than the code? Kindly disregard that question. I have just been informed by a co-worker that some of our third-party library headers include switch stat

[Bug debug/35502] -Wall should include -Wswitch-default

--- Comment #5 from jeff at schwabcenter dot com 2008-03-07 23:38 --- Thanks for the quick response and the links. FYI, the latter link seems to be broken: http://archives.free.net.ph/message/20071001.204624.0ca57fae.de.html Is there any particular reason for changing the docs, rather

[Bug debug/35502] -Wall should include -Wswitch-default

--- Comment #4 from pinskia at gcc dot gnu dot org 2008-03-07 23:31 --- See http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01761.html and http://archives.free.net.ph/message/20071001.204624.0ca57fae.de.html . -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug debug/35502] -Wall should include -Wswitch-default

--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-07 23:26 --- This is a documentation fix which has already happened, see http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html . -Wall This enables all the warnings about constructions that some users consider questionable, and

[Bug debug/35502] -Wall should include -Wswitch-default

--- Comment #2 from jeff at schwabcenter dot com 2008-03-07 23:24 --- Created an attachment (id=15278) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15278&action=view) Fix for this bug Setting warn_switch_default = value in the OPT_Wall case of c_common_handle_option (in gcc/c-opt

[Bug debug/35502] -Wall should include -Wswitch-default

--- Comment #1 from jeff at schwabcenter dot com 2008-03-07 23:21 --- Created an attachment (id=15277) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15277&action=view) Preprocessed sample code Compiling the attached file with g++ -Wall should produce "warning: switch missing defau

[Bug debug/35502] New: -Wall should include -Wswitch-default

The g++ man page says -Wall is equivalent to "All of the above -W options combined." The -Wswitch-default option should therefore be included in -Wall, but currently is not. The correct solution IMO is to add -Wswitch-default to -Wall in c-opts.c. Please see the attached patch. Script started o

[Bug target/34734] attribute((progmem)) not handled properly in C++ for AVRs

--- Comment #2 from hsteinhaus at gmx dot de 2008-03-07 20:59 --- version 4.2.1 seems to be affected as well: [EMAIL PROTECTED]:~/scratch$ cat foo.cpp #include const int foobar1 = 42; int foobar2 = 42; const int PROGMEM foobar3 = 42; int PR

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

--- Comment #4 from ddenisen at altera dot com 2008-03-07 20:11 --- I am still learning about linking and loading and I can't guess why non-PIC DSOs would work on x86 but not on x86_64. Could you please explain briefly. This is all very useful information that I couldn't find anywhere e

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-07 19:47 --- (In reply to comment #2) > But DSOs still work if I don't use PIC. Why is that? Depends on the target :). If this is x86, then you can guess why. In fact x86_64 errors out when linking if you did not use -fPIC (or

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

--- Comment #2 from ddenisen at altera dot com 2008-03-07 19:45 --- But DSOs still work if I don't use PIC. Why is that? Why would anybody want to create position-independent executable? What are the advantages and disadvantages? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35500

[Bug c++/35499] Symbol resolution optimization should be separately controlled from -fPIC

--- Comment #3 from ddenisen at altera dot com 2008-03-07 19:43 --- I did read "How to write Shared Libraries" and re-read PIC section a couple of times. Could you please clarify what am I missing here? If symbol resolution is already controlled separately, what's the flag? I couldn't f

[Bug c++/35500] Documentation for -fPIC/-fpic/-fpie is not clear

--- Comment #1 from pinskia at gcc dot gnu dot org 2008-03-07 19:39 --- DSO requires PIC code. PIC means is it produces position independent code. PIE means it produces code for position independent executable, not DSOs though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35500

[Bug c++/35499] Symbol resolution optimization should be separately controlled from -fPIC

--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-07 19:37 --- Already controlled separately really so closing as such. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/35499] Symbol resolution optimization should be separately controlled from -fPIC

--- Comment #1 from belyshev at depni dot sinp dot msu dot ru 2008-03-07 19:25 --- You need to study http://people.redhat.com/drepper/dsohowto.pdf carefully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35499

[Bug tree-optimization/35501] New: Wrong value returned from const int

[EMAIL PROTECTED] gcc]$ cat x.i const int conststaticvariable = 3; int f(void) { return conststaticvariable; } [EMAIL PROTECTED] gcc]$ ./xgcc -B./ -O2 x.i -S -fPIC -m32 [EMAIL PROTECTED] gcc]$ cat x.s .file "x.i" .text .p2align 4,,15 .globl f .type f, @functio

[Bug c++/35500] New: Documentation for -fPIC/-fpic/-fpie is not clear

Documentation for -fpic and family is not clear. Here are the points I would like clarified: - Does pic required for SOs (No)? - What are the upsides/downsides of using pic (faster SO loading vs run-time hit, others?)? - Why would anybody want to create a PIE? -- Summary: Do

[Bug c++/35499] New: Symbol resolution optimization should be separately controlled from -fPIC

I'm working on a large non-UI C++ program on Linux. It consists of hundreds of SOs and takes a long time to run (hours). I'm seeing about 10% speedup if I do *not* use -fPIC for some SOs (the executable never uses -fPIC of -fPIE) and, since run-time is very important to me, I want to not use -fPIC

[Bug middle-end/35249] miscompilation of Emacs at -O

-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35249

[Bug tree-optimization/35493] [4.4 Regression] Assert_Failure uintp.adb:1593

--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-03-07 18:28 --- > I think the Ada front-end has TREE_CONSTANT and TREE_READONLY definition > swapped around: > > /* Whether we will make TREE_CONSTANT the DECL we produce here, in which > case the initializer may be used

[Bug c++/35350] FAIL: gcc.target/i386/isa-10.c execution test

--- Comment #6 from hjl dot tools at gmail dot com 2008-03-07 17:00 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00480.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug tree-optimization/35493] [4.4 Regression] Assert_Failure uintp.adb:1593

--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-03-07 16:46 --- Based on Andreas' latest comment. The Ada FE may need inspection though. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added --

[Bug target/35498] libgomp/testsuite/libgomp.c/atomic-3.c fails on ppc-linux

--- Comment #1 from jakub at gcc dot gnu dot org 2008-03-07 16:33 --- Patch: 2008-03-07 Jakub Jelinek <[EMAIL PROTECTED]> PR target/35498 * config/rs6000/rs6000.c (rs6000_expand_compare_and_swapqhi): Shift wdst back after sync_compare_and_swapqhi_internal. ---

[Bug target/35488] A incorrect result in a simple division, only in 32-bit gcc.

--- Comment #10 from purnnam1 at naver dot com 2008-03-07 16:15 --- Thanks to Brian's kind comment, I have knew that the exact mechanism. In my understannding, the conclusion is as follows; 1. GCC 3.x doesn't generate any codes for 80-bit precision. the FPU h/w just uses the 80-bit

[Bug target/35373] [4.4 Regression] bootstraping on powerpc with 128bit long double fails with revision 132578

--- Comment #13 from bergner at gcc dot gnu dot org 2008-03-07 15:44 --- (In reply to comment #11) > Is there a reason why you don't use GET_MODE_SIZE (mode) != N in the > expression? Well, the T[IFD]mode don't allow reg+reg addressing, but other 8 byte modes do (eg, V4SImode). --

[Bug target/35373] [4.4 Regression] bootstraping on powerpc with 128bit long double fails with revision 132578

--- Comment #12 from bergner at gcc dot gnu dot org 2008-03-07 15:21 --- Subject: Bug 35373 Author: bergner Date: Fri Mar 7 15:20:31 2008 New Revision: 133008 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133008 Log: PR target/35373 * config/rs6000/rs6000.c (r

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

--- Comment #10 from rguenther at suse dot de 2008-03-07 15:20 --- Subject: Re: [4.4 Regression]: Revision 132991 breaks 483.xalancbmk On Fri, 7 Mar 2008, hjl dot tools at gmail dot com wrote: > > > --- Comment #8 from hjl dot tools at gmail dot com 2008-03-07 14:56 > ---

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

--- Comment #9 from hjl dot tools at gmail dot com 2008-03-07 15:17 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-03/msg00466.html -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug target/35498] New: libgomp/testsuite/libgomp.c/atomic-3.c fails on ppc-linux

/* { dg-do run } */ /* { dg-options "-fopenmp -O2" } */ extern int omp_get_num_threads (void); extern void abort (void); short e[64]; int num_threads; int g; _Complex double d, f; __attribute__((noinline)) void foo (int x, long long y) { #pragma omp parallel num_threads (4) { int i; #p

[Bug ada/35493] [4.4 Regression] Assert_Failure uintp.adb:1593

--- Comment #4 from schwab at suse dot de 2008-03-07 14:59 --- The patch in works here as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35493

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

--- Comment #8 from hjl dot tools at gmail dot com 2008-03-07 14:56 --- Another testcase in C: --- const int conststaticvariable; int f(void) { return conststaticvariable; } --- Can we assume conststaticvariable will be 0? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35494

[Bug c++/35497] New: Compiling error with template part. spec. involving function call and >>

The following code gives a compiling error with gcc-4.3.0 with -std=c++0x: template class A {}; template class B {}; template class A> {}; main.cpp:3: error: a function call cannot appear in a constant-expression While if we use > > (instead of >>) in the class specialization, it compiles fin

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

--- Comment #7 from hjl dot tools at gmail dot com 2008-03-07 14:39 --- My patch works on 483.xalancbmk with test input. I am running with ref input. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35494

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

--- Comment #6 from hjl dot tools at gmail dot com 2008-03-07 14:24 --- This patch --- tree-ssa-ccp.c.local2008-03-06 14:18:27.0 -0800 +++ tree-ssa-ccp.c 2008-03-07 06:21:57.0 -0800 @@ -306,9 +306,10 @@ get_symbol_constant_value (tree sym) if (val

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

--- Comment #5 from rguenther at suse dot de 2008-03-07 14:22 --- Subject: Re: [4.4 Regression]: Revision 132991 breaks 483.xalancbmk On Fri, 7 Mar 2008, hjl dot tools at gmail dot com wrote: > --- Comment #4 from hjl dot tools at gmail dot com 2008-03-07 14:03 > --- > (In

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

--- Comment #4 from hjl dot tools at gmail dot com 2008-03-07 14:03 --- (In reply to comment #1) > Subject: Re: New: [4.4 Regression]: Revision 132991 breaks 483.xalancbmk > > This is most likely the c++ front-end setting readonly when it should > not. > I think you should check a

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

--- Comment #3 from hjl dot tools at gmail dot com 2008-03-07 13:54 --- Are bash-3.2$ cat y.cc class bar { public: static const int conststaticvariable; }; int f(void) { return bar::conststaticvariable; } bash-3.2$ cat z.cc extern int foo (void); class bar { public: static cons

[Bug target/35496] New: [4.4 Regression] test failures between revs. 132950 and 132974

On i686-apple-darwin9 with rev. 132974, I see the following regressions (not in rev. 132950): FAIL: gcc.dg/bf-ms-layout-2.c execution test FAIL: gcc.dg/bf-ms-layout.c execution test FAIL: gfortran.dg/array_constructor_12.f90 -O3 -fomit-frame-pointer execution test FAIL: gfortran.dg/array_constr

[Bug c++/35244] Broken diagnostic: 'type_decl' not supported by dump_expr

--- Comment #3 from jakub at gcc dot gnu dot org 2008-03-07 13:16 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug rtl-optimization/33009] -frtl-abstract-sequences causes an infinite loop

--- Comment #16 from belyshev at depni dot sinp dot msu dot ru 2008-03-07 12:47 --- (In reply to comment #15) > This bug was about an infinite loop. Okay. -- belyshev at depni dot sinp dot msu dot ru changed: What|Removed |Added --

[Bug rtl-optimization/33009] [4.4 Regression] -frtl-abstract-sequences causes an ICE

--- Comment #15 from loki at gcc dot gnu dot org 2008-03-07 12:33 --- (In reply to comment #14) > It is now broken on trunk on x86_64-linux with -m32 -fPIC: > > pr11832.c: In function 'foo': > pr11832.c:30: error: unrecognizable insn: > (insn 216pr11832.c:30: internal compiler error: Se

[Bug ada/35493] [4.4 Regression] Assert_Failure uintp.adb:1593

-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|Assert_Failure |[4.4 Regre

[Bug ada/35493] Assert_Failure uintp.adb:1593

--- Comment #3 from pinskia at gcc dot gnu dot org 2008-03-07 12:05 --- I think the Ada front-end has TREE_CONSTANT and TREE_READONLY definition swapped around: /* Whether we will make TREE_CONSTANT the DECL we produce here, in which case the initializer may be used in-lieu of th

[Bug fortran/35476] Accepts invalid: USE/host association of generics with same specifics

--- Comment #3 from fxcoudert at gcc dot gnu dot org 2008-03-07 12:03 --- (In reply to comment #0) > - openf95 and sunf95 reject it > - ifort, gfortran, NAG f95, and g95 accept it > Bill Long writes that he tested two non-Sun compilers, of which two gave an > error and two did not. For

[Bug ada/35493] Assert_Failure uintp.adb:1593

--- Comment #2 from pinskia at gcc dot gnu dot org 2008-03-07 11:59 --- This has to be a bug in the Ada front-end because all the rest of the middle-end assumes that if DECL_INITIAL is NULL, the value is going to be zero. I might be the case where TREE_READONLY is being set and it shoul

[Bug fortran/35478] [4.2 regression] internal compiler error: Segmentation fault

--- Comment #2 from fxcoudert at gcc dot gnu dot org 2008-03-07 11:57 --- Confirmed on i686-linux; it is a 4.2 regression, as it used to work with 4.0.4 and 4.1.2. It was fixed in 4.3 and 4.4, and it's an ICE on invalid code, so chances that we fix it are really close to zero. (I actual

[Bug fortran/35423] Implement OpenMP workshare

-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last recon

[Bug c++/35049] [4.3 Regression] g++.dg/conversion/simd3.C:12: error: invalid operands to binary + (have 'float __vector__' and 'int __vector__')

--- Comment #15 from bonzini at gnu dot org 2008-03-07 11:48 --- Subject: Bug 35049 Author: bonzini Date: Fri Mar 7 11:47:20 2008 New Revision: 133007 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133007 Log: cp: 2008-03-07 Paolo Bonzini <[EMAIL PROTECTED]> Revert:

[Bug bootstrap/35115] [4.3 Regression] ../../gcc-4.3-work/gcc/objcp/objcp-decl.c:98: error: implicit declaration of function 'comptypes'

--- Comment #5 from bonzini at gnu dot org 2008-03-07 11:48 --- Subject: Bug 35115 Author: bonzini Date: Fri Mar 7 11:47:20 2008 New Revision: 133007 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133007 Log: cp: 2008-03-07 Paolo Bonzini <[EMAIL PROTECTED]> Revert:

[Bug c++/35096] [4.3 regression] ICE with vector attribute

--- Comment #4 from bonzini at gnu dot org 2008-03-07 11:48 --- Subject: Bug 35096 Author: bonzini Date: Fri Mar 7 11:47:20 2008 New Revision: 133007 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133007 Log: cp: 2008-03-07 Paolo Bonzini <[EMAIL PROTECTED]> Revert:

[Bug tree-optimization/35493] Assert_Failure uintp.adb:1593

--- Comment #1 from schwab at suse dot de 2008-03-07 10:48 --- This was caused by this change: 2008-03-06 Andrew Pinski <[EMAIL PROTECTED]> PR tree-opt/35402 * tree-ssa-ccp.c (get_symbol_constant_value): Handle integral and scalar float variables which have a

[Bug tree-optimization/35472] [4.3 Regression] tree DSE is broken

--- Comment #6 from rguenth at gcc dot gnu dot org 2008-03-07 09:49 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug tree-optimization/35472] [4.3 Regression] tree DSE is broken

--- Comment #5 from rguenth at gcc dot gnu dot org 2008-03-07 09:47 --- Subject: Bug 35472 Author: rguenth Date: Fri Mar 7 09:47:06 2008 New Revision: 133004 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133004 Log: 2008-03-07 Richard Guenther <[EMAIL PROTECTED]> PR

[Bug tree-optimization/35494] [4.4 Regression]: Revision 132991 breaks 483.xalancbmk

--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-07 09:08 --- Will probably happen in cases like static const int i = foo(); ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35494

[Bug rtl-optimization/17236] inefficient code for long long multiply on x86

-- bonzini at gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236

[Bug rtl-optimization/17236] inefficient code for long long multiply on x86

--- Comment #29 from bonzini at gnu dot org 2008-03-07 08:26 --- ira branch produces the same code as with my patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17236