[Bug tree-optimization/36881] [4.4 Regression] Creating runtime relocations for code which does not need it

--- Comment #8 from jakub at gcc dot gnu dot org 2008-10-15 06:48 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug tree-optimization/36881] [4.4 Regression] Creating runtime relocations for code which does not need it

--- Comment #7 from jakub at gcc dot gnu dot org 2008-10-15 06:44 --- Subject: Bug 36881 Author: jakub Date: Wed Oct 15 06:43:19 2008 New Revision: 141129 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141129 Log: PR tree-optimization/36881 * tree-switch-conversi

[Bug fortran/37832] System_Clock

--- Comment #2 from burnus at gcc dot gnu dot org 2008-10-15 06:33 --- See also PR 28484 comment 5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37832

[Bug fortran/37832] System_Clock

--- Comment #1 from kargl at gcc dot gnu dot org 2008-10-15 05:50 --- You can already get an integer(8) result. integer(8) ticks,rate call system_clock(count=ticks,count_rate=rate) print *, ticks, rate end gfc -o z a.f90 ./z 2131173368 1000 count_rate is det

[Bug fortran/37832] New: System_Clock

Resolution of the System_Clock(TICKS,RATE,MAX) intrinsic degraded from about 3.6 MHz to 1,000 Hz when I upgraded from g77 to gfortran (for Windows). There is a computer clock that I have accessed in Visual Basic that represents elapsed time since my computer was turned on, returned as an integer*8

[Bug c++/37831] -Wshadow warns about variables inside classes member functions

--- Comment #3 from bangerth at dealii dot org 2008-10-15 01:51 --- (In reply to comment #2) > bar the function shadows bar the variable. I think the warning is correct. > The variable _bar is not being taken into account at all. Ah, bummer, I didn't even look close enough to see that

[Bug c++/37831] -Wshadow warns about variables inside classes member functions

--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-15 01:40 --- bar the function shadows bar the variable. I think the warning is correct. The variable _bar is not being taken into account at all. -- pinskia at gcc dot gnu dot org changed: What|Removed

[Bug c++/37831] -Wshadow warns about variable names that aren't equal

--- Comment #1 from bangerth at dealii dot org 2008-10-15 01:38 --- Note also that the documentation plainly states: @item -Wshadow @opindex Wshadow @opindex Wno-shadow Warn whenever a local variable shadows another local variable, parameter or global variable or whenever a built-in fun

[Bug c++/37831] New: -Wshadow warns about variable names that aren't equal

-Wshadow is silly about this piece of code: - class Foo { int bar_; public: void bar(int bar) { bar_ = bar; } }; - This is a fairly common style. Note that local and member variable have names th

[Bug testsuite/35677] Intermitent failure "FAIL: libgomp.fortran/crayptr2.f90"

--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-14 23:30 --- I still see this, though it was failing a lot more than it was passing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35677

[Bug middle-end/37674] [4.4 Regression] Bootstrap failure due to miscompilation of genattrtab

--- Comment #6 from hjl at gcc dot gnu dot org 2008-10-14 22:50 --- Subject: Bug 37674 Author: hjl Date: Tue Oct 14 22:49:36 2008 New Revision: 141122 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141122 Log: 2008-10-14 Vladimir Makarov <[EMAIL PROTECTED]> PR middle-

[Bug tree-optimization/37830] g++ 4.3.1 generates incorrect output when using -O2 (other optimization levels work okay)

--- Comment #3 from jaf at meyersound dot com 2008-10-14 22:39 --- Created an attachment (id=16495) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16495&action=view) This unit test reproduces the bug under g++ 4.3.1, running under SUSE 10.0 (32-bit mode) on my Xeon Mac (w/VMWare Fus

[Bug tree-optimization/37830] g++ 4.3.1 generates incorrect output when using -O2 (other optimization levels work okay)

--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-14 22:31 --- Works on the trunk. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug middle-end/37535] [4.4 Regression] gcc/libgcc2.c:404: internal compiler error: Floating point exception

--- Comment #18 from hjl at gcc dot gnu dot org 2008-10-14 22:26 --- Subject: Bug 37535 Author: hjl Date: Tue Oct 14 22:25:09 2008 New Revision: 141121 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141121 Log: 2008-10-14 Vladimir Makarov <[EMAIL PROTECTED]> PR middle

[Bug c++/37830] g++ 4.3.1 generates incorrect output when using -O2 (other optimization levels work okay)

--- Comment #1 from jaf at meyersound dot com 2008-10-14 22:26 --- Created an attachment (id=16494) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16494&action=view) This is the unit test described above; compile and run this to reproduce the bug -- http://gcc.gnu.org/bugzilla/

[Bug target/37633] [4.4 Regression] wrong register use on sh64

--- Comment #4 from hjl at gcc dot gnu dot org 2008-10-14 22:24 --- Subject: Bug 37633 Author: hjl Date: Tue Oct 14 22:23:23 2008 New Revision: 141120 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141120 Log: 2008-10-14 Vladimir Makarov <[EMAIL PROTECTED]> PR target/

[Bug c++/37830] New: g++ 4.3.1 generates incorrect output when using -O2 (other optimization levels work okay)

The source files in this attachment demonstrate an apparent bug in g++'s -O2 optimizer. To reproduce the bug, do the following: 1) make 2) ./testmessage If the bug is reproduced, you should see output like this: [EMAIL PROTECTED]:~/bug> ./testmessage COMPILER BUG! _iterList is 0xbfc371e0, shou

[Bug c++/37819] [4.4 Regression] ice for bitfield code

--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-14 21:59 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug c++/37819] [4.4 Regression] ice for bitfield code

--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-14 21:59 --- Subject: Bug 37819 Author: jakub Date: Tue Oct 14 21:57:44 2008 New Revision: 141118 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141118 Log: PR c++/37819 * cp-gimplify.c (cp_genericize_r): O

[Bug regression/37824] funroll-loops miscompiles php

--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-14 21:59 --- There are two aliasing violations here. The first is what Richard mentioned and the second is also in foo, there is a load from p via long* and also a store via void*. That is where the issue comes down to here and

[Bug target/37381] [4.4 Regression] ICE in ia64_speculate_insn, at config/ia64/ia64.c:6902

--- Comment #11 from hjl dot tools at gmail dot com 2008-10-14 21:50 --- I didn't see the testcase in comment #2 in gcc. -- hjl dot tools at gmail dot com changed: What|Removed |Added ---

[Bug fortran/37826] gfortran compiled with -gstabs+ on OSX emits incorrect debug information if compiled with -finit-local-zero

--- Comment #4 from chris dot walter at duke dot edu 2008-10-14 21:33 --- > To my knowledge OS X also supports DWARF debugging symbols, cf. > http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00745.html Hmm.. Well when I try it I get (using gfortran -gdwarf-2) this when I start gdb: GNU g

[Bug fortran/37826] gfortran compiled with -gstabs+ on OSX emits incorrect debug information if compiled with -finit-local-zero

--- Comment #3 from pinskia at gcc dot gnu dot org 2008-10-14 21:12 --- In fact g77 did the same, see PR 15171. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37826

[Bug fortran/37826] gfortran compiled with -gstabs+ on OSX emits incorrect debug information if compiled with -finit-local-zero

--- Comment #2 from pinskia at gcc dot gnu dot org 2008-10-14 21:10 --- To me the initialization of the variables should be recorded when using -finit-local-zero. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37826

[Bug fortran/37826] gfortran compiled with -gstabs+ on OSX emits incorrect debug information if compiled with -finit-local-zero

--- Comment #1 from burnus at gcc dot gnu dot org 2008-10-14 21:03 --- > I can't test other -g options as they don't generate > usuable debug information on OSX. To my knowledge OS X also supports DWARF debugging symbols, cf. http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00745.html Howe

possible bug in 4.1.2 g++ arm compiler -O2 optimization

I already sent this to [EMAIL PROTECTED], but no responses, so posting here also. -b I seem to have found a bug in the ARM 4.1.2 g++ optimization code. This attached test case demonstrates an apparent optimizer bug in the 4.1.2 ARM g++ compiler. Compile this code: arm-linux-g++ -

[Bug middle-end/37742] [4.4 Regression] ICE in vectorizer with restrict pointer

--- Comment #12 from rguenth at gcc dot gnu dot org 2008-10-14 20:46 --- This is because data-ref uses p1 for DR_BASE_ADDRESS instead of p (which is restrict qualified), for the scalar load we do not do this "propagation" because we try to retain restrict qualifications. simple_iv () i

[Bug fortran/37829] New: ICE in resolve_symbol

module modx use, intrinsic :: iso_c_binding common /spaces/ sp integer (c_long) :: sp bind (c) :: /spaces/ end module modx block data use modx double precision sums common /cblock/ sums (4) data (sums (i), i = 1,4) / 1.0, 2.0, 3.0, 4.0 / end ICEs in resolve_symbol: 9102 /* Make s

[Bug fortran/37827] Fortran IO structure - compiler vs. library (libgfortran) [requires ABI breaking?]

--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-14 19:56 --- You cannot touch the library part, but you certainly can align what the compiler does to the library part of the structure definition. Thus, if the behavior is wrong (as in wrong-code) at the moment, changing the "A

[Bug middle-end/37674] [4.4 Regression] Bootstrap failure due to miscompilation of genattrtab

--- Comment #5 from vmakarov at redhat dot com 2008-10-14 19:50 --- Updating of total_conflict_hard_regs in ira-build.c::ira_flattening was completely wrong. So I rewrite the calculation of total_conflict_hard_regs and total_no_stack_reg_p. It is now done from the scratch. The code be

[Bug target/37633] [4.4 Regression] wrong register use on sh64

--- Comment #3 from vmakarov at redhat dot com 2008-10-14 19:42 --- I've checked the old RA. It does not assigned partially clobbered hard register because it is done only when non partially clobbered hard regs were tried first. Sh has a lot of such registers therefore the chance to ge

[Bug middle-end/37828] [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3421 with -floop-block

--- Comment #5 from spop at gcc dot gnu dot org 2008-10-14 18:29 --- Fixed on graphite branch. We should open another bug once the -fgraphite-identity is in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37828

[Bug middle-end/37828] [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3421 with -floop-block

--- Comment #4 from spop at gcc dot gnu dot org 2008-10-14 18:24 --- Subject: Bug 37828 Author: spop Date: Tue Oct 14 18:23:05 2008 New Revision: 141116 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141116 Log: 2008-10-14 Sebastian Pop <[EMAIL PROTECTED]> Harsha J

[Bug middle-end/37828] [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3421 with -floop-block

--- Comment #3 from grosser at gcc dot gnu dot org 2008-10-14 17:55 --- (In reply to comment #2) > It makes no sense to loop block single nested loops. Using -fgraphite-identity (not yet commited) or removing the ifdef at graphite.c:4915 the Polyhedron also fails with this bug. So it se

[Bug c++/37650] [4.2/4.3 regression] ICE with broken default template parameter

--- Comment #4 from paolo dot carlini at oracle dot com 2008-10-14 17:53 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added

[Bug c++/37650] [4.2/4.3/4.4 regression] ICE with broken default template parameter

--- Comment #3 from paolo at gcc dot gnu dot org 2008-10-14 17:53 --- Subject: Bug 37650 Author: paolo Date: Tue Oct 14 17:51:55 2008 New Revision: 141115 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141115 Log: /cp 2008-10-14 Paolo Carlini <[EMAIL PROTECTED]> PR c+

[Bug tree-optimization/37449] [4.4 Regression] calculix gets wrong answer for -O1 -ffast-math

--- Comment #13 from jakub at gcc dot gnu dot org 2008-10-14 17:35 --- The different results between -O1 -f{,no}unsafe-math-optimizations are because this testcase relies heavily on signed zeros, and with with fast math 0 and -0 aren't considered to make a difference, you get at least di

[Bug c++/35483] GCC on AIX doesn't support dollar in symbols name.

--- Comment #7 from dje at gcc dot gnu dot org 2008-10-14 17:06 --- Created an attachment (id=16493) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16493&action=view) patch to convert dollar signs to underscores New patch. This patch intercepts the dollar signs at a lower level an

[Bug fortran/35681] wrong result for vector subscripted array expression in MVBITS

--- Comment #5 from domob at gcc dot gnu dot org 2008-10-14 16:20 --- I will look at this and try to work it out, taking it for now. -- domob at gcc dot gnu dot org changed: What|Removed |Added --

[Bug c++/37553] [4.3/4.4 Regression] ICE in build_c_cast

--- Comment #5 from doug dot gregor at gmail dot com 2008-10-14 16:03 --- Fixed on mainline -- doug dot gregor at gmail dot com changed: What|Removed |Added

[Bug middle-end/37828] [graphite] in expand_scalar_variables_expr, at graphite.c:3421

--- Comment #2 from spop at gcc dot gnu dot org 2008-10-14 15:32 --- Mine. It makes no sense to loop block single nested loops. -- spop at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug middle-end/37828] [graphite] in expand_scalar_variables_expr, at graphite.c:3421

--- Comment #1 from dwarak dot rajagopal at amd dot com 2008-10-14 15:29 --- Created an attachment (id=16492) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16492&action=view) Testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37828

[Bug middle-end/37828] New: [graphite] in expand_scalar_variables_expr, at graphite.c:3421

g++ -c -floop-block -O3 bug_rep.cpp bug_rep.cpp: In function ‘int sort_and_split(foo**, foo**&, long int)’: bug_rep.cpp:9: internal compiler error: in expand_scalar_variables_expr, at graphite.c:3421 Please submit a full bug report, with preprocessed source if appropriate. See

[Bug c++/37553] [4.3/4.4 Regression] ICE in build_c_cast

--- Comment #4 from dgregor at gcc dot gnu dot org 2008-10-14 15:05 --- Subject: Bug 37553 Author: dgregor Date: Tue Oct 14 15:03:51 2008 New Revision: 14 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=14 Log: 2008-10-14 Douglas Gregor <[EMAIL PROTECTED]> PR c+

[Bug fortran/37827] New: Fortran IO structure - compiler vs. library (libgfortran) [requires ABI breaking?]

See http://gcc.gnu.org/ml/fortran/2008-10/msg00105.html Steve Ellcey writes there: While examining the failures of some of the f2003 IO tests on my IA64 HP-UX systems I found what I think is a mismatch between the st_parameter_dt in the library and in the compiler. It seems like this would affec

[Bug fortran/37826] New: gfortran compiled with -gstabs+ on OSX emits incorrect debug information if compiled with -finit-local-zero

If I compile the following program with -gstabs+ under OSX 10.5.5 with gcc4.4 Using built-in specs. Target: i386-apple-darwin8.10.1 Configured with: /tmp/gfortran-20081006/ibin/../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/tmp/gfortran-20081006/gfortran_lib

[Bug target/37381] [4.4 Regression] ICE in ia64_speculate_insn, at config/ia64/ia64.c:6902

--- Comment #10 from amonakov at gcc dot gnu dot org 2008-10-14 13:41 --- Since Andrey has just committed ia64 changes from sel-sched branch to trunk, the underlying problem is fixed and ICEs on original testcase and mentioned regression tests are gone. Closing as fixed. -- amonako

[Bug fortran/37821] [4.4 Regression] gfortran is ignoring #includes with the syntax

--- Comment #6 from chris dot walter at duke dot edu 2008-10-14 13:39 --- Sorry, for leaving out the test case, but I see it is confirmed now. I can't use the conforming INCLUDE since I am dealing with a large legacy code base and ~150 colleagues who are also using the code with variou

[Bug regression/37824] funroll-loops miscompiles php

--- Comment #2 from rguenth at gcc dot gnu dot org 2008-10-14 13:20 --- It is indeed an aliasing violation, you store a long and read a long*. Fix it like int main() { int i; long a; long **b = malloc(8 * sizeof(long)); for (i = 0; i < 8; i++)

[Bug fortran/37821] [4.4 Regression] gfortran is ignoring #includes with the syntax

--- Comment #5 from burnus at gcc dot gnu dot org 2008-10-14 12:31 --- (In reply to comment #3) > #include "..." search starts here: > test_directory > /projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude > . That "." comes last is also wrong; it should come first

[Bug fortran/37821] [4.4 Regression] gfortran is ignoring #includes with the syntax

--- Comment #4 from dfranke at gcc dot gnu dot org 2008-10-14 12:23 --- Bugger. How much time do we have left before 4.4? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37821

[Bug bootstrap/37825] '--with-abi=aapcs-linux' rejected

--- Comment #1 from enrico dot scholz at informatik dot tu-chemnitz dot de 2008-10-14 12:22 --- mmh... fixed in SVN already... closing bug -- enrico dot scholz at informatik dot tu-chemnitz dot de changed: What|Removed |Added -

[Bug bootstrap/37825] New: '--with-abi=aapcs-linux' rejected

When using '--with-abi' to preconfigure the 'aapcs-linux' ABI, the build fails with | Unknown ABI used in --with-abi=aapcs-linux As this ABI is accepted for '-mabi=', it should be accepted for bootstrapping too. -- Summary: '--with-abi=aapcs-linux' rejected Product: gcc

[Bug fortran/37821] [4.4 Regression] gfortran is ignoring #includes with the syntax

--- Comment #3 from burnus at gcc dot gnu dot org 2008-10-14 12:11 --- Confirm. gcc (the C compiler) has using -I test_directory: #include "..." search starts here: #include <...> search starts here: test_directory /usr/local/include /projects/tob/gcc-trunk/include /projects/tob/gcc

[Bug middle-end/37805] [4.3/4.4 Regression] gcc --help=separate

--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-14 12:08 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug middle-end/37805] [4.3/4.4 Regression] gcc --help=separate

--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-14 12:01 --- Subject: Bug 37805 Author: jakub Date: Tue Oct 14 12:00:19 2008 New Revision: 141106 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141106 Log: PR middle-end/37805 * opts.c (common_handle_optio

[Bug regression/37824] funroll-loops miscompiles php

--- Comment #1 from anton at samba dot org 2008-10-14 11:59 --- Alan Modra points out the cast is not required and removing it does fix the issue. BTW -Wstrict-aliasing (or -Wstrict-aliasing=2) doesn't warn about the code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37824

[Bug rtl-optimization/37782] [4.4 regression] Stage2 ada compiler miscompiled

--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-14 11:50 --- I couldn't reproduce this on powerpc64-linux --with-cpu=default32 --enable-languages=ada, I can only reproduce the var-tracking.c ICE which is already tracked in PR37815. -- http://gcc.gnu.org/bugzilla/show_bug.cg

[Bug middle-end/37815] [4.4 Regression] ICE in vt_add_function_parameters (bootstrap error)

--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-14 11:47 --- vt_add_function_parameters asserts that REG_EXPR or MEM_EXPR of DECL_RTL of a PARM decl, if it is non-NULL, is the PARM_DECL itself, but with the r141077 patch when the stack slots may be shared, decl might be actually

[Bug regression/37824] New: funroll-loops miscompiles php

A gcc checkout from yesterday (4.4.0 20081013) is miscompiling php when built with 64bit and funroll-loops. A cut down test case is below but at this stage im not sure if its a violation of the aliasing rules. good: # gcc -m64 -O2 -o /tmp/foo /tmp/foo.c # /tmp/foo 0xfabef50 0xfabef50 0xfff

[Bug middle-end/37815] [4.4 Regression] ICE in vt_add_function_parameters (bootstrap error)

--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-14 11:25 --- Created an attachment (id=16491) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16491&action=view) libgcc2.i Indeed, caused by r141077. On the attached preprocessed source reproduceable with -> sparc-linux cross

[Bug c/37106] [4.4 Regression] ICE with -fpic or -fPIC: in mems_in_disjoint_alias_sets_p, at alias.c:278

--- Comment #12 from dominiq at lps dot ens dot fr 2008-10-14 10:57 --- Possible candidates revisions 138075, 138089, and 138092. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37106

[Bug c/37106] [4.4 Regression] ICE: in mems_in_disjoint_alias_sets_p, at alias.c:278

--- Comment #11 from dominiq at lps dot ens dot fr 2008-10-14 10:14 --- > I confirm the opt-1/opt-2 failures on i686-linix and x86_64-linux when using > -fpic or -fPIC: > ... > The issue is not darwin-specific. Digging the archives the failures on x86_64-linux when using -fpic or -fPIC

[Bug target/37823] Missed optimization - ffs() from strings.h

--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-14 09:31 --- Trunk produces: foo: pushl %ebp xorl%eax, %eax movl%esp, %ebp bsfl12(%ebp), %edx sete%al negl%eax orl %eax, %edx movl8(%e

[Bug c/37822] Code deficiency in function fold

--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-14 09:25 --- As you say, this is fixed in later versions. GCC 3.4.x has long been out of maintainance. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added --

[Bug middle-end/37805] [4.3/4.4 Regression] gcc --help=separate

--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-14 09:16 --- This isn't ice-on-valid-code, but rather ice-on-invalid-option-argument, but we don't have such a category. -- jakub at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c/37823] New: Missed optimization - ffs() from strings.h

GCC produces some redundant addl/subl instructions for the following function, which calls the built-in ffs(): --- snip --- #include int foo(int i, int j) { return i + ffs(j) - 1; } --- output of gcc -O3 -m32 -S foo.c --- foo: pushl %ebp xorl%edx, %edx movl%esp

[Bug c++/37819] [4.4 Regression] ice for bitfield code

-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org

[Bug c/37106] [4.4 Regression] ICE: in mems_in_disjoint_alias_sets_p, at alias.c:278

--- Comment #10 from ghazi at gcc dot gnu dot org 2008-10-14 08:10 --- (In reply to comment #9) > Well, I guess then the first thing to ask for is for both the > gcc.target/i386/opt-1.c and gcc.target/i386/opt-2.c tests to be > extended so that they are run with -fPIC. It would be helpfu

[Bug middle-end/37815] [4.4 Regression] ICE in vt_add_function_parameters (bootstrap error)

--- Comment #3 from doko at ubuntu dot com 2008-10-14 07:21 --- reverting r141077 on current trunk lets the bootstrap succeed on sparc-linux -- doko at ubuntu dot com changed: What|Removed |Added

[Bug target/37809] [4.2/4.3/4.4 Regression] Incorrect code with MMX right shift __builtin_ia32_psradi

--- Comment #4 from suckfish at ihug dot co dot nz 2008-10-14 07:17 --- Digging a bit, in combine.c, the ASHIFTRT case of force_to_mode() contains two calls to simplify_shift_const(). Disabling those for vector modes fixes the test case here (patch below). But I suspect this is just th