[Bug target/39139] [4.4 Regression] ICE with stringop and register var

--- Comment #23 from bonzini at gnu dot org 2009-02-10 09:50 --- > I guess it is too expensive to add a new reg class for each > register to support constraints for all registers. This has no reference to the actual problem of this PR. The sparc testcase that Jakub posted is particular

[Bug c++/34397] [4.2/4.3/4.4 regression] ICE on invalid default template parameter

--- Comment #25 from paolo dot carlini at oracle dot com 2009-02-10 10:03 --- Thanks. I'll try to submit something more polished along these lines... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34397

[Bug c/12245] [4.2/4.3/4.4 regression] Uses lots of memory when compiling large initialized arrays

--- Comment #39 from rguenth at gcc dot gnu dot org 2009-02-10 10:12 --- *** Bug 39142 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added -

[Bug middle-end/39142] Compilation fails with specialised optimisations.

--- Comment #6 from rguenth at gcc dot gnu dot org 2009-02-10 10:12 --- gcc: Internal error: Killed (program cc1) Please submit a full bug report. See for instructions. Which means that your kernel killed the compiler, likely due to memory usage issues. O

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

--- Comment #24 from jakub at gcc dot gnu dot org 2009-02-10 10:20 --- Their loads and stores are already separated from other computations, as they aren't is_gimple_reg. And they do have VDEFs/VUSES: # a1D.1284_24 = VDEF { a1D.1284 } a1D.1284 = 11; y.0D.1287_15 = (long unsigned

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

--- Comment #25 from jakub at gcc dot gnu dot org 2009-02-10 10:29 --- Created an attachment (id=17275) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17275&action=view) gcc44-pr39139.patch Quick patch to avoid sinking of block copies or clearings if current function has local expl

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

--- Comment #26 from rguenth at gcc dot gnu dot org 2009-02-10 10:35 --- I could imagine that other architectures have other special registers, so I think treating them like pointer dereferences to anything would be more robust than changing all code-motion passes. -- http://gcc.gn

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

--- Comment #27 from bonzini at gnu dot org 2009-02-10 10:49 --- The patch does not seem too bad. You could add a target hook to get a HARD_REG_SET or constituting an optimization barriers (defaulting to all call-clobbered registers, which would be okay for all targets that do not have

[Bug middle-end/39142] Compilation fails with specialised optimisations.

--- Comment #7 from paolo dot carlini at oracle dot com 2009-02-10 10:21 --- Thanks Richard, noticed the Killed too late... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39142

[Bug middle-end/39127] Invalid GIMPLE with OpenMP

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-10 12:46 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|

[Bug libstdc++/35942] Self Reference In Dynamic Linked Library builds for building Cross-Compiler

--- Comment #13 from earthengine at gmail dot com 2009-02-10 12:48 --- > whereas the --build part used to not be necessary. (Although I suppose > omitting > both host and build flags might work too, or just supplying > --host=x86_64-unknown-linux-gnu when compiling on x86_64 so that au

[Bug c++/39140] g++ doesn't inline vararg functions

--- Comment #2 from thomas dot bleher at philosys dot de 2009-02-10 12:53 --- Thank you for the very fast response! Good to see that this is already fixed in a newer GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39140

[Bug tree-optimization/39132] wrong code generated with -ftree-loop-disttribution

--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-10 13:15 --- Confirmed. There is wrong alias-information on the memset: : Invalid sum of outgoing probabilities 0.0% D.1641_35 = &ep + 8; # rx_ring_36 = VDEF # SMT.12_37 = VDEF __builtin_memset (D.1641_35, 0, 20); :

[Bug tree-optimization/39132] wrong code generated with -ftree-loop-disttribution

--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-10 13:29 --- I have a patch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|

[Bug target/39119] Update classification of aggregates with __m256

--- Comment #3 from hjl at gcc dot gnu dot org 2009-02-10 14:01 --- Subject: Bug 39119 Author: hjl Date: Tue Feb 10 14:00:46 2009 New Revision: 144058 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144058 Log: gcc/ 2009-02-10 H.J. Lu PR target/39119 * config

[Bug middle-end/39124] [4.4 Regression]: -fno-exceptions leads to a ICE

--- Comment #5 from jakub at gcc dot gnu dot org 2009-02-10 14:11 --- Created an attachment (id=17276) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17276&action=view) gcc44-pr39124.patch The problem is that remove_path first calls remove_bbs and afterwards cancel_loop_tree. The

[Bug target/16331] x86-64 inline asm register constraints insufficient WRT ABI

--- Comment #13 from thutt at vmware dot com 2009-02-10 14:34 --- (In reply to comment #12) > (In reply to comment #11) > > Uros, how hard to support this in x86 backend? > > OTOH, constraints should be used to support correct register > allocation for machine instructions, not to emu

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

--- Comment #6 from rearnsha at gcc dot gnu dot org 2009-02-10 14:36 --- This is not a bug, but a problem with your source code. In order to understand why, you need to pre-process the code and look at the output: ... void *memset_arm9(void *a, int b, int c) { return ({ uint8_t *dst

[Bug target/39119] Update classification of aggregates with __m256

--- Comment #4 from hjl dot tools at gmail dot com 2009-02-10 14:38 --- Fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39119

[Bug target/39119] Update classification of aggregates with __m256

--- Comment #5 from hjl dot tools at gmail dot com 2009-02-10 14:38 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRM

[Bug tree-optimization/39132] wrong code generated with -ftree-loop-disttribution

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-10 14:54 --- Subject: Bug 39132 Author: rguenth Date: Tue Feb 10 14:54:13 2009 New Revision: 144060 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144060 Log: 2009-02-10 Richard Guenther PR tree-optimization/

[Bug middle-end/39127] Invalid GIMPLE with OpenMP

--- Comment #2 from rguenth at gcc dot gnu dot org 2009-02-10 14:55 --- Subject: Bug 39127 Author: rguenth Date: Tue Feb 10 14:55:15 2009 New Revision: 144061 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144061 Log: 2009-02-10 Richard Guenther PR middle-end/39127

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

--- Comment #7 from siarhei dot siamashka at gmail dot com 2009-02-10 15:11 --- (In reply to comment #6) > This is not a bug, but a problem with your source code. > > In order to understand why, you need to pre-process the code and look at the > output: > > ... > void *memset_arm9(voi

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

--- Comment #11 from jsm28 at gcc dot gnu dot org 2009-02-10 15:17 --- I plan to fix this for 4.5. Testing the preliminary patch to make cpplib use the diagnostic.c infrastructure. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added -

[Bug target/16331] x86-64 inline asm register constraints insufficient WRT ABI

--- Comment #14 from ubizjak at gmail dot com 2009-02-10 15:20 --- > > OTOH, constraints should be used to support correct register > > allocation for machine instructions, not to emulate ABI in order to > > support calls from inside asm statements. > > Please indulge me for a moment.

[Bug inline-asm/31693] Incorrectly assigned registers to operands for ARM inline asm

--- Comment #8 from rearnsha at gcc dot gnu dot org 2009-02-10 15:21 --- Opinions vary wildly as to which warnings should be on by default, and which should be part of whatever bundle. I personally agree that shadowing variables is generally bad practice, but you then have to be wary w

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

--- Comment #12 from manu at gcc dot gnu dot org 2009-02-10 15:24 --- Could we take a look at the patch? I have also a half-baked patch. Are you going to replace cpplib functions completely or just set up call-backs as C++ does? If the latter, then there is already a patch in bug 34695.

[Bug target/16331] x86-64 inline asm register constraints insufficient WRT ABI

--- Comment #15 from thutt at vmware dot com 2009-02-10 15:35 --- (In reply to comment #14) > > > OTOH, constraints should be used to support correct register > > > allocation for machine instructions, not to emulate ABI in order to > > > support calls from inside asm statements. > > > >

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

--- Comment #13 from joseph at codesourcery dot com 2009-02-10 15:35 --- Subject: Re: gcc should have option to treat missing headers as fatal On Tue, 10 Feb 2009, manu at gcc dot gnu dot org wrote: > Could we take a look at the patch? I have also a half-baked patch. Are you > going

[Bug tree-optimization/39132] wrong code generated with -ftree-loop-disttribution

--- Comment #4 from rguenth at gcc dot gnu dot org 2009-02-10 16:12 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug middle-end/39127] Invalid GIMPLE with OpenMP

--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-10 16:12 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation

--- Comment #9 from uros at gcc dot gnu dot org 2009-02-10 16:12 --- Subject: Bug 39118 Author: uros Date: Tue Feb 10 16:12:33 2009 New Revision: 144063 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144063 Log: PR target/39118 * config/i386/i386.c (expand_prolog

[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation

--- Comment #10 from uros at gcc dot gnu dot org 2009-02-10 16:13 --- Subject: Bug 39118 Author: uros Date: Tue Feb 10 16:12:47 2009 New Revision: 144064 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144064 Log: PR target/39118 * config/i386/i386.c (expand_prolo

[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation

--- Comment #11 from ubizjak at gmail dot com 2009-02-10 16:14 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED

[Bug tree-optimization/39132] wrong code generated with -ftree-loop-disttribution

--- Comment #5 from kazu at gcc dot gnu dot org 2009-02-10 16:19 --- Thanks, Richard! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39132

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

--- Comment #28 from jakub at gcc dot gnu dot org 2009-02-10 16:22 --- Subject: Bug 39139 Author: jakub Date: Tue Feb 10 16:22:29 2009 New Revision: 144065 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144065 Log: PR target/39139 * function.h (struct function):

[Bug middle-end/39124] [4.4 Regression]: -fno-exceptions leads to a ICE

--- Comment #6 from jakub at gcc dot gnu dot org 2009-02-10 16:23 --- Subject: Bug 39124 Author: jakub Date: Tue Feb 10 16:23:17 2009 New Revision: 144066 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144066 Log: PR middle-end/39124 * cfgloopmanip.c (remove_path

[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3

--- Comment #20 from dwarak dot rajagopal at amd dot com 2009-02-10 16:28 --- Paulo, (a) movaps (%rax, %rsi), %xmm0 addps %xmm0, %xmm1 (b) movaps %xmm0, %xmm1 addps (%rax, %rsi), %xmm1 Yes, case (a) is slightly better than case (b). It shouldn't matter much though

[Bug c/39084] [4.3/4.4 regression] ice on struct redefinition

--- Comment #5 from sje at gcc dot gnu dot org 2009-02-10 16:33 --- Subject: Bug 39084 Author: sje Date: Tue Feb 10 16:33:19 2009 New Revision: 144067 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144067 Log: PR c/39084 * c-decl.c (start_struct): Return NULL on

[Bug c/39084] [4.3/4.4 regression] ice on struct redefinition

--- Comment #6 from sje at gcc dot gnu dot org 2009-02-10 16:34 --- Subject: Bug 39084 Author: sje Date: Tue Feb 10 16:34:30 2009 New Revision: 144068 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144068 Log: PR c/39084 gcc.dg/pr39084.c: New test. Added: tr

[Bug target/39139] [4.4 Regression] ICE with stringop and register var

--- Comment #29 from jakub at gcc dot gnu dot org 2009-02-10 16:35 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW

[Bug middle-end/39124] [4.4 Regression]: -fno-exceptions leads to a ICE

--- Comment #7 from jakub at gcc dot gnu dot org 2009-02-10 16:35 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3

--- Comment #21 from bonzini at gnu dot org 2009-02-10 16:39 --- So my patch should be a uniform win. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38824

[Bug c/39084] [4.3/4.4 regression] ice on struct redefinition

--- Comment #7 from sje at gcc dot gnu dot org 2009-02-10 16:44 --- Subject: Bug 39084 Author: sje Date: Tue Feb 10 16:43:49 2009 New Revision: 144070 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144070 Log: PR c/39084 * c-decl.c (start_struct): Return NULL on

[Bug c/39084] [4.3/4.4 regression] ice on struct redefinition

--- Comment #8 from sje at gcc dot gnu dot org 2009-02-10 16:45 --- Subject: Bug 39084 Author: sje Date: Tue Feb 10 16:45:37 2009 New Revision: 144071 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144071 Log: PR c/39084 gcc.dg/pr39084.c: New test. Added: br

[Bug c/39084] [4.3/4.4 regression] ice on struct redefinition

--- Comment #9 from sje at cup dot hp dot com 2009-02-10 16:49 --- Fixed on mainline for 4.4.0 and on 4.3 branch for 4.3.4. -- sje at cup dot hp dot com changed: What|Removed |Added --

[Bug fortran/38979] OpenMP extension: THREADPRIVATE for EQUIVALENCEd symbols

--- Comment #3 from burnus at gcc dot gnu dot org 2009-02-10 17:05 --- A patch: http://gcc.gnu.org/ml/fortran/2009-01/msg00325.html Comment to the patch: http://gcc.gnu.org/ml/fortran/2009-02/msg00050.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38979

[Bug driver/39147] New: [4.4 Regression] Gcc accepts invalid options

Gcc accepts any -Wno-foobar, even if -Wfoobar doesn't exist: [...@gnu-6 gcc]$ ./xgcc -B./ -Wno-foobar -S /tmp/x.c [...@gnu-6 gcc]$ ./xgcc -B./ -Wfoobar -S /tmp/x.c cc1: error: unrecognized command line option "-Wfoobar" [...@gnu-6 gcc]$ -- Summary: [4.4 Regression] Gcc accepts inval

[Bug driver/39147] [4.4 Regression] Gcc accepts invalid options

-- hjl dot tools at gmail dot com changed: What|Removed |Added Known to fail||4.4.0 Known to work||4.3.4 Target

[Bug driver/39147] [4.4 Regression] Gcc accepts invalid options

--- Comment #1 from pinskia at gcc dot gnu dot org 2009-02-10 17:32 --- I think this is by design. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39147

[Bug driver/39147] [4.4 Regression] Gcc accepts invalid options

--- Comment #2 from hjl dot tools at gmail dot com 2009-02-10 17:40 --- (In reply to comment #1) > I think this is by design. > It is different from gcc 4.3. Where is this feature documented? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39147

[Bug c++/23287] [4.2 regression] Explicitly invoking destructor of template class in a template and is dependent

--- Comment #25 from jason at gcc dot gnu dot org 2009-02-10 17:51 --- fixed for 4.3 as well, closing. -- jason at gcc dot gnu dot org changed: What|Removed |Added

[Bug driver/39147] [4.4 Regression] Gcc accepts invalid options

--- Comment #3 from jakub at gcc dot gnu dot org 2009-02-10 18:01 --- *** This bug has been marked as a duplicate of 28322 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added --

[Bug other/28322] GCC new warnings and compatibility

--- Comment #23 from jakub at gcc dot gnu dot org 2009-02-10 18:01 --- *** Bug 39147 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added --

[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation

--- Comment #12 from ian at airs dot com 2009-02-10 19:56 --- I didn't get around to commenting on the patch; I'll just note that it is conservative. We don't have to block every instruction, just those which use memory. Do we have to worry about the function epilogue? I don't see any

[Bug target/39148] New: -Os increase code size when stack is aligned

[...@gnu-6 pr39137]$ cat pr39137-3.i void foo (unsigned long long *); void bar (void) { unsigned long long l __attribute__ ((aligned(32))); foo (&l); } [...@gnu-6 pr39137]$ /export/build/gnu/gcc-work/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-avx/build-x86_64-linux/gcc/ -m32 -Os pr39

[Bug target/39148] -Os increase code size when stack is aligned

-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39148

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

--- Comment #5 from hjl dot tools at gmail dot com 2009-02-10 20:32 --- Created an attachment (id=17277) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17277&action=view) A patch Does this patch look OK? If yes, I will submit it with a couple of testcases. -- http://gcc.gnu.or

[Bug target/39148] -Os increase code size when stack is aligned

--- Comment #1 from hjl dot tools at gmail dot com 2009-02-10 20:46 --- The problem is static rtx ix86_get_drap_rtx (void) { if (ix86_force_drap || !ACCUMULATE_OUTGOING_ARGS) crtl->need_drap = true; -Os turns off ACCUMULATE_OUTGOING_ARGS, which turns on DRAP. Does ACCUMULATE_OU

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

--- Comment #6 from jakub at gcc dot gnu dot org 2009-02-10 20:48 --- This would mean -Os vs. -O2 gives different __alignof__(long long) values, I think that's a bad idea. I think a new option to disable dynamic realignment or at least do that if estimated stack size is <= 64 bits would

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

--- Comment #7 from hjl dot tools at gmail dot com 2009-02-10 21:02 --- (In reply to comment #6) > This would mean -Os vs. -O2 gives different __alignof__(long long) values, I > think that's a bad idea. I think a new option to disable dynamic realignment > or at least do that if estimat

[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation

--- Comment #13 from ian at airs dot com 2009-02-10 21:03 --- Created an attachment (id=17278) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17278&action=view) Test case This test case is from Mark Heffernan. When compiling with -O2 -fno-omit-frame-pointer with gcc 4.3, it shows

[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation

--- Comment #14 from ian at airs dot com 2009-02-10 21:10 --- I've verified that the problem in the epilogue occurs using the current 4.3 sources, so reopening the bug report. (There is no longer any problem in the prologue.) -- ian at airs dot com changed: What|Remo

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

--- Comment #8 from hjl dot tools at gmail dot com 2009-02-10 21:15 --- (In reply to comment #6) > This would mean -Os vs. -O2 gives different __alignof__(long long) values, I __alignof__(type) isn't that useful. The alignment of double changes depending on 1. If it is on stack. 2. If

[Bug target/39082] union with long double doesn't follow x86-64 psABI

--- Comment #4 from hjl dot tools at gmail dot com 2009-02-10 21:44 --- The updated patch is at http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00477.html -- hjl dot tools at gmail dot com changed: What|Removed |Added

[Bug c++/34397] [4.2/4.3/4.4 regression] ICE on invalid default template parameter

--- Comment #26 from paolo at gcc dot gnu dot org 2009-02-10 21:47 --- Subject: Bug 34397 Author: paolo Date: Tue Feb 10 21:47:12 2009 New Revision: 144083 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144083 Log: /cp 2009-02-10 Paolo Carlini PR c++/34397 *

[Bug c++/34397] [4.2/4.3 regression] ICE on invalid default template parameter

--- Comment #27 from paolo dot carlini at oracle dot com 2009-02-10 21:48 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added

[Bug c/33466] mixed-case suffix for decimal float constants

--- Comment #3 from janis at gcc dot gnu dot org 2009-02-10 21:50 --- Suffixes for fixed-point constants are broken as well. GCC allows the letters in them to be in any order, except that "ll" must be together and in the same case. GCC does not reject 'l' by itself as invalid. N1169,

[Bug target/39149] New: Typo in i386.c

[...@gnu-6 gcc]$ ./xgcc -B./ -malign-functions=3 /tmp/x.c -S /tmp/x.c:1: warning: -malign-functions is obsolete, use -malign-functions Shouldn't be /tmp/x.c:1: warning: -malign-functions is obsolete, use -falign-functions -- Summary: Typo in i386.c Product: gcc

[Bug target/39149] Typo in i386.c

-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39149

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

--- Comment #10 from pinskia at gcc dot gnu dot org 2009-02-10 22:03 --- Reopening to ... -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Stat

[Bug target/39149] Typo in i386.c

--- Comment #1 from hjl dot tools at gmail dot com 2009-02-10 22:03 --- [...@gnu-6 gcc]$ ./xgcc -B./ -malign-loops=3 /tmp/x.c -S /tmp/x.c:1: warning: -malign-loops is obsolete, use -malign-loops [...@gnu-6 gcc]$ ./xgcc -B./ -malign-jumps=3 /tmp/x.c -S /tmp/x.c:1: warning: -malign-jumps i

[Bug libstdc++/39136] std::mem_fun_ref fails to accept a member function whose second argument with default value

--- Comment #11 from pinskia at gcc dot gnu dot org 2009-02-10 22:03 --- Mark this as a dup of bug 37088. *** This bug has been marked as a duplicate of 37088 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added

[Bug c++/37088] Functions with default parameters not correctly handled inside templates.

--- Comment #3 from pinskia at gcc dot gnu dot org 2009-02-10 22:03 --- *** Bug 39136 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added ---

[Bug c/26542] bogus diagnostic with -pedantic?: format '%p'; expects type 'void*', but argument 2 has type 'A*'

--- Comment #9 from jason dot orendorff at gmail dot com 2009-02-10 22:22 --- Please consider reopening this bug. I appreciate that the relevant standards don't guarantee this idiom will always work. On the other hand, this warning is in practice only a nuisance. Balance the real wor

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

--- Comment #9 from hjl dot tools at gmail dot com 2009-02-10 22:29 --- Created an attachment (id=17279) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17279&action=view) A patch to add a new -malign-double= option -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137

[Bug c++/36744] [C++0x] function modifying argument received by-value affects caller's variable when passed as rvalue

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

[Bug c++/37862] Parenthesised indirection alters class member access

--- Comment #7 from jason at gcc dot gnu dot org 2009-02-10 23:11 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING

[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign

--- Comment #10 from Joey dot ye at intel dot com 2009-02-11 01:03 --- (In reply to comment #9) > Created an attachment (id=17279) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17279&action=view) [edit] > A patch to add a new -malign-double= option This patch looks OK to me. --

[Bug preprocessor/34695] Preprocessor warning->error conversion from -Werror is silent

--- Comment #9 from jsm28 at gcc dot gnu dot org 2009-02-11 01:14 --- This is fixed by my patch to make cpplib always use the diagnostic.c infrastructure: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00491.html (This change is the cause of the Wvariadic-1.c and Wvariadic-3.c testcase ch

[Bug preprocessor/15638] gcc should have option to treat missing headers as fatal

--- Comment #14 from joseph at codesourcery dot com 2009-02-11 01:16 --- Subject: Re: gcc should have option to treat missing headers as fatal I have now posted my preliminary patch: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00491.html -- http://gcc.gnu.org/bugzilla/show_bug

[Bug target/39082] union with long double doesn't follow x86-64 psABI

--- Comment #5 from mmitchel at gcc dot gnu dot org 2009-02-11 01:45 --- Is this a regression? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39082

[Bug bootstrap/39150] New: Configure scripts have no 64-Bit Solaris defined (only i386-solaris*).

=== g++ Summary === # of expected passes38731 # of expected failures 282 # of unsupported tests 346 /export/gnu/import/svn/gcc-test/bld/gcc/testsuite/g++/../../g++ version 4.4.0 20090210 (experimental) [trunk revision 144083] (GCC) ... -- When

[Bug bootstrap/39151] New: If you build and install 'ppl' (and not 'cloog') then files will still link with 'ppl'.

I'm running OpenSolaris 2009.06, building "gcc 4.4.0 [trunk revision 144083]". If you build and install 'ppl' (because you desire to try it) and choose not to build and install 'cloog' (because you do not desire to have it) the ./configure scripts detect ppl (and not cloog) but files will link w

[Bug target/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_

--- Comment #2 from hbent at cs dot oberlin dot edu 2009-02-11 04:32 --- I am seeing this on NetBSD 5.99.7, and can confirm that this prevents gcc from building at all on NetBSD 5.99.x. Is there any way this can get into 4.4.0? It is a very simple fix and applies cleanly. -- hbent

[Bug c++/36744] [C++0x] function modifying argument received by-value affects caller's variable when passed as rvalue

--- Comment #6 from jason at gcc dot gnu dot org 2009-02-11 05:23 --- Subject: Bug 36744 Author: jason Date: Wed Feb 11 05:23:02 2009 New Revision: 144091 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144091 Log: PR c++/36744 * tree.c (lvalue_p_1): Condition rva

[Bug c++/38649] [4.4 regression] Trouble with defaulted constructors

--- Comment #3 from jason at gcc dot gnu dot org 2009-02-11 05:23 --- Subject: Bug 38649 Author: jason Date: Wed Feb 11 05:23:38 2009 New Revision: 144092 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144092 Log: PR c++/38649 * class.c (defaultable_fn_p): Handle

[Bug c++/38649] [4.4 regression] Trouble with defaulted constructors

--- Comment #4 from jason at gcc dot gnu dot org 2009-02-11 05:25 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug c++/36744] [C++0x] function modifying argument received by-value affects caller's variable when passed as rvalue

--- Comment #7 from jason at gcc dot gnu dot org 2009-02-11 05:26 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED

[Bug c++/30111] Value-initialization of POD base class doesn't initialize members

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

[Bug target/39118] [4.3/4.4 Regression] x86_64 red zone violation

--- Comment #15 from ubizjak at gmail dot com 2009-02-11 07:09 --- (In reply to comment #12) > I didn't get around to commenting on the patch; I'll just note that it is > conservative. We don't have to block every instruction, just those which use > memory. True, but as described in th

[Bug target/39149] Typo in i386.c

--- Comment #2 from ubizjak at gmail dot com 2009-02-11 07:15 --- See the comment: "... Remove this code in GCC 3.2 or later." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39149

[Bug target/38824] [4.4 Regression] performance regression of sse code from 4.2/4.3

--- Comment #22 from xuepeng dot guo at intel dot com 2009-02-11 07:37 --- (In reply to comment #18) > Xuepeng, can you test with the loop as produced by my posted patch, that is: > .L11: > movaps (%rsi,%rax), %xmm0 > addps %xmm1, %xmm0 > movaps %xmm0, (%rdi,

[Bug inline-asm/39078] Registers in on clober list are cloberred when compiled with optimization (x86_64) ?

--- Comment #7 from ubizjak at gmail dot com 2009-02-11 07:50 --- (In reply to comment #5) > Any why you say I shouldn't call other function from inside asm ? See for example [1]. [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16331#c14 -- http://gcc.gnu.org/bugzilla/show_bug.cg